Seminar Airtest – Game Testing mit Airtest und Poco

Das Praxisseminar verbindet visuelle Prüfungen und UI-Hierarchien zu stabilen End-to-End-Tests für Menüs, Szenen, Overlays und plattformabhängige Spielabläufe.

Inhaltsverzeichnis

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

Seminarprofil

Game-UI und gerenderte Szenen werden nach Zugänglichkeit, Dynamik und Testziel klassifiziert. Airtest übernimmt sichtbare Zustände und nicht instrumentierte Bereiche, Poco liefert strukturierte Selektoren und Eigenschaften. Teststände, Zufall, Rendering-Varianten, Szenenwechsel und Diagnose werden in einem zusammenhängenden Spielprojekt beherrscht.

Lernziele

• Game-Oberflächen teststrategisch zerlegen
• Airtest- und Poco-Prüfungen sinnvoll kombinieren
• Spielstände und Rendering-Varianten kontrollieren
• Szenen- und Screen-Objekte wiederverwendbar modellieren
• flaky Game-Tests systematisch stabilisieren

Schrittweise Lernstrecke

1. 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.

2. 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.

3. 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.

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. 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.

6. 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.

7. 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.

8. 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.

9. 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. Inventar von Menüs, Szenen und Overlays
2. Hybrider Test mit Poco und Bildvergleich
3. Kontrollierter Spielstand für Wiederholbarkeit
4. Stabilitätsmatrix über mehrere Rendering-Profile

Zielgruppe und Voraussetzungen

Zielgruppe: Game QA, Technical QA, Testautomatisierer, Game-Entwickler und Build-Verantwortliche.

Voraussetzungen: Airtest- und Python-Grundkenntnisse; Zugriff auf ein instrumentierbares Spiel oder eine vorbereitete Testanwendung.

Didaktische Einordnung

Vier Tage sind notwendig, weil Game Testing zusätzlich zu Airtest und Poco kontrollierte Spielstände, Rendering- und Gerätevarianten, Szenenmodelle, Gesten und umfangreiche Flaky-Diagnose erfordert.

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.