Seminar Airtest – Intensivseminar Game Testing mit Poco und Engine-SDKs

Das fünftägige Intensivformat bündelt Game-Teststrategie, Airtest, Poco, Engine-Integration, Spielzustände und skalierbare Ausführung in einem vollständigen Testprojekt.

Inhaltsverzeichnis

1. Seminarprofil
2. Lernziele
3. Schrittweise Lernstrecke
4. Praxisbausteine
5. Zielgruppe und Voraussetzungen
6. Didaktische Einordnung

Seminarprofil

Der Lernpfad beginnt mit der Zerlegung einer Spieloberfläche und führt über stabile Bildobjekte, Poco-Hierarchien und robuste Gesten zur Integration in Unity, Cocos und Unreal. Abschließend werden Spielstände, Rendering-Matrizen, Mehrgeräte-Ausführung, Berichte und Wartungsregeln zu einer produktionsnahen Testsuite verbunden.

Lernziele

• eine vollständige Game-Testarchitektur entwickeln
• Poco-SDK-Integrationsmuster für mehrere Engines bewerten
• hybride Tests mit stabilen Zustandsprüfungen erstellen
• Spielstände und Gerätevarianten reproduzierbar steuern
• Game-Tests parallel betreiben und diagnostizieren

Schrittweise Lernstrecke

1. Automatisierungsziele und Systemgrenzen

1. Geschäftskritische Benutzerwege, technische Prüfziele und erwartete Wiederholungsfrequenz werden getrennt erfasst.
2. Oberflächentypen, Geräteklassen, Rendering-Verhalten und notwendige Integrationspunkte werden systematisch inventarisiert.
3. Nutzen, Wartungsaufwand, Fehlerrisiko und erforderliche Diagnoseinformationen werden für jeden Testbereich bewertet.

2. Bausteine der AirtestProject-Toolchain

1. Airtest wird als Python-basiertes Framework für bildgestützte Interaktionen und plattformbezogene Geräteoperationen eingeordnet.
2. Poco wird als Zugriffsschicht auf UI-Hierarchien, Selektoren, Eigenschaften und strukturierte Interaktionen abgegrenzt.
3. AirtestIDE, Kommandozeile, Berichtserzeugung und Browserautomation werden zu einer durchgängigen Arbeitskette verbunden.

3. Arbeitsumgebung und Projektstart

1. Systemvoraussetzungen, Schreibrechte, Projektpfade und notwendige Laufzeitkomponenten werden vor der Installation geprüft.
2. AirtestIDE und eine lokale Python-Umgebung werden hinsichtlich Zweck, Abhängigkeiten und reproduzierbarer Nutzung getrennt eingerichtet.
3. Ein Selbsttest validiert Codeausführung, Bildaufnahme, Logverzeichnis, Berichtsfunktion und Zugriff auf das Zielsystem.

4. Matching, Suchräume und Auflösungsanpassung

1. Positive, grenzwertige und negative Bildschirmzustände werden als Kalibrierungsmenge für jedes kritische Bildobjekt zusammengestellt.
2. Schwellen, Suchregionen, Skalierungsregeln und Zielpositionen werden anhand realer Geräte- oder Fensterkonfigurationen abgestimmt.
3. Nichtfunde, falsche Treffer und schwankende Konfidenzen erhalten unterschiedliche Diagnose- und Korrekturpfade.

5. Poco-Hierarchien und robuste Selektoren

1. Elementnamen, Typen, Texte, Eigenschaften, Sichtbarkeit, Position und hierarchische Beziehungen werden systematisch inspiziert.
2. Selektoren bevorzugen stabile Attribute und relationale Bezüge gegenüber langen absoluten Hierarchiepfaden.
3. Mehrdeutige Treffer, dynamische Listen und nicht zugängliche Bereiche werden explizit behandelt und bei Bedarf bildbasiert ergänzt.

6. Interaktionen, Gesten und Koordinaten

1. Klick, Long-Press, Ziehen, Wischen, Scrollen und Texteingabe werden mit Sichtbarkeits- und Zustandsprüfungen verknüpft.
2. Geräte-, Fenster-, Engine- und Bildschirmkoordinaten werden durch dokumentierte Umrechnungs- und Bezugssysteme verbunden.
3. Nach jeder komplexen Interaktion bestätigt eine unabhängige Eigenschaft oder Bildprüfung den erwarteten Zustand.

7. Hybride Game-Tests mit Airtest und Poco

1. Menüs, gerenderte Szenen, Overlays, Ladephasen und Plattformdialoge werden als unterschiedliche Automatisierungsbereiche inventarisiert.
2. Poco bestätigt strukturelle UI-Zustände, während Airtest sichtbare Rendering-Ergebnisse und nicht zugängliche Bereiche prüft.
3. Screen- und Scene-Objekte kapseln Selektoren, Bildvorlagen, Gesten und Übergangslogik für wiederverwendbare Spielabläufe.

8. Spielstände, Rendering und Gerätevarianten

1. Konten, Fortschritt, Inventar, Zufall, Netzwerk und Serverzustände werden als kontrollierte Testdatenabhängigkeiten behandelt.
2. Seitenverhältnis, Orientierung, Grafikqualität, Framerate und Eingabemethode werden in einer risikobasierten Matrix geplant.
3. Flaky Ergebnisse werden nach Timing, Rendering, Daten, Netzwerk, Selektor und Bildmatch klassifiziert.

9. Poco-SDK in Unity integrieren

1. Unity-Version, UI-System, Szenenstruktur, persistente Objekte und Buildziele werden vor der Integration erfasst.
2. Die passenden SDK-Komponenten und ein langlebiger Poco-Manager werden in einem dedizierten Testbuild eingerichtet.
3. Canvas, Panels, Listen und Szenen werden über stabile Namen, Beziehungen und Eigenschaften testbar gemacht.

10. Poco-SDK in Cocos-Projekte integrieren

1. Engine-Version, Sprache, Scripting-Variante, UI-System und Buildziel bestimmen den geeigneten SDK-Integrationsweg.
2. SDK-Dateien, Bindings, Modulregistrierungen und Laufzeitdienst werden schrittweise eingebaut und nach jedem Schritt kompiliert.
3. Dynamische Knoten, Szenencontainer und UI-Eigenschaften werden für robuste Selektoren und Wartung dokumentiert.

11. Poco-SDK in Unreal Engine integrieren

1. Engine-Version, Projektmodule, UI-Technologie, Zielplattform und Buildkonfiguration werden vor der Integration geprüft.
2. SDK-Komponenten, Buildregeln, Laufzeitdienst und Portkommunikation werden in einem freigegebenen Testbuild aktiviert.
3. Widgets, Container, Texte, Sichtbarkeit und Interaktionszustände werden in der Poco-Hierarchie validiert.

12. Eigene Engine- und Agent-Architektur

1. Ein Agent trennt Enginezugriff, Hierarchieexport, Eigenschaftsmodell, Abfragen, Interaktionen und Transport voneinander.
2. Knotenidentität, Eltern-Kind-Beziehungen, Position, Größe, Sichtbarkeit und benutzerdefinierte Attribute werden spezifiziert.
3. Aktionen erhalten eindeutige Fehlerzustände, Zeitgrenzen und Schutz gegen zerstörte, verdeckte oder veraltete Knoten.

13. Testdaten, Ausgangszustände und Bereinigung

1. App-Version, Benutzerstatus, lokale Daten, Serverdaten, Berechtigungen und Geräteorientierung werden als Vorbedingungen beschrieben.
2. Testkonten und Datensätze erhalten eindeutige Identitäten, Reservierungsregeln und konfliktfreie Nutzung bei parallelen Läufen.
3. Vorbereitung und Bereinigung werden idempotent gestaltet und auch nach Fehler oder Abbruch zuverlässig ausgeführt.

14. Batch-, Mehrgeräte- und Parallelausführung

1. Tests werden nach Ressourcen, Datenkonflikten, Plattform und Laufzeit in unabhängig ausführbare Einheiten zerlegt.
2. Mehrere Geräte werden eindeutig registriert, reserviert und entweder kooperativ oder in getrennten Prozessen angesprochen.
3. Parallelität wird schrittweise erhöht und anhand von Durchsatz, Stabilität, Wartezeit und Geräteauslastung bewertet.

15. Logging, Berichte und Diagnoseartefakte

1. Jeder Lauf erhält eine eindeutige Identität, die in Logpfad, Bericht, Screenshot und Zusatzartefakt wiederverwendet wird.
2. Fachliche Kontrollpunkte und technische Zustandswechsel werden mit unterschiedlich kategorisierten Logeinträgen dokumentiert.
3. Fehlerartefakte enthalten erwarteten Zustand, tatsächliche Beobachtung, letzten stabilen Schritt und relevante Geräte- oder UI-Daten.

16. Stabilität, Flaky-Analyse und Wartung

1. Tests werden wiederholt unter identischen und variierten Bedingungen ausgeführt, um Fehlerquote, Laufzeit und Muster zu bestimmen.
2. Wiederholungen gelten nur für definierte technische Fehlerklassen und dürfen den ersten Fehlschlag nicht unsichtbar machen.
3. Review, Quarantäne und Wartungsbacklog werden nach Geschäftskritikalität, Fehlerhäufigkeit und Wiederverwendungsgrad gesteuert.

17. Durchgängiges Praxisprojekt

1. Ein repräsentativer Benutzerweg wird in Ausgangszustand, fachliche Schritte, Kontrollpunkte und Abschlusszustand zerlegt.
2. Die Testsuite wird schrittweise implementiert, auf Varianten ausgeführt und durch absichtlich erzeugte Störungen geprüft.
3. Ergebnisse werden anhand von Stabilität, Verständlichkeit, Laufzeit, Wartbarkeit und Diagnosequalität bewertet und verbessert.

Praxisbausteine

1. Engine- und UI-Testinventar
2. SDK-Integration in einem vorbereiteten Beispielprojekt
3. Hybrider End-to-End-Spielablauf
4. Mehrgeräte- und Rendering-Matrix
5. Stabilitäts- und Wartungsreview

Zielgruppe und Voraussetzungen

Zielgruppe: Game QA Engineers, Technical QA, Engine-Entwickler, Testarchitekten und Automatisierungsverantwortliche.

Voraussetzungen: Gute Python- und Testkenntnisse; Grundlagen in mindestens einer Game Engine und Zugriff auf vorbereitete Testbuilds.

Didaktische Einordnung

Fünf Tage sind als maximale Verdichtung erforderlich, um sämtliche Game-bezogenen Seminarthemen von Strategie und SDK-Integration bis zu Testdesign, Zustandskontrolle, Skalierung und Betrieb praktisch zusammenzuführen.

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, geführte Umsetzungsschritte, eigenständige Übungen und kontrollierte Fehlerfälle vertieft. Jeder Praxisblock verwendet definierte Ausgangszustände, überprüfbare Zwischenergebnisse und dokumentierte Diagnoseinformationen.