Seminar Airtest – CI/CD, Parallelisierung und Gerätefarmen

Das Aufbauseminar überführt lokale Tests in eine kontrollierte, parallele Ausführungsplattform mit Qualitätsgates, Geräteverwaltung und belastbarer Diagnose.

Inhaltsverzeichnis

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

Seminarprofil

Eine vorhandene Airtest-Testsuite wird für unbeaufsichtigte Ausführung, parallele Jobs und mehrere Gerätegruppen vorbereitet. Runner-Verträge, Testdatenisolierung, Reservierung, Wartung, Berichtskonsolidierung, Sicherheitsregeln und Betriebskennzahlen werden in einer vollständigen Laborstrecke verbunden.

Lernziele

• Airtest-Jobs reproduzierbar in CI/CD ausführen
• Tests sicher auf mehrere Geräte verteilen
• Geräte reservieren, vorbereiten und bereinigen
• Berichte und Qualitätsgates konsolidieren
• Betriebs- und Sicherheitsverfahren definieren

Schrittweise Lernstrecke

1. Kommandozeile und reproduzierbare Ausführung

1. Skriptpfad, Geräteangabe, Konfiguration, Logverzeichnis und Berichtspfad werden als stabiler Jobvertrag definiert.
2. Exitcodes unterscheiden Testfehler, Infrastrukturproblem, Konfigurationsfehler und ungültigen Aufruf.
3. Aufrufe werden in wiederverwendbaren Runnern gekapselt, damit lokale und automatisierte Ausführung denselben Vertrag nutzen.

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

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

4. CI/CD-Pipeline und Qualitätsentscheidungen

1. Pipeline-Stufen trennen Paketierung, Umgebungscheck, Geräteprüfung, Testausführung, Bericht, Qualitätsentscheidung und Aufräumen.
2. Testauswahl nach Änderung, Risiko, Plattform und Laufzeit wird als nachvollziehbare Regel implementiert.
3. Qualitätsgates berücksichtigen Kritikalität, Plattformabdeckung, Infrastrukturstatus und bekannte Quarantänefälle.

5. Gerätefarm, Reservierung und Lebenszyklus

1. Geräte werden inventarisiert, gruppiert und mit Zuständen für verfügbar, belegt, gestört und in Wartung geführt.
2. Vor und nach jedem Lauf werden Verbindung, Speicher, App-Zustand, Orientierung, Energieversorgung und Bereinigung geprüft.
3. Wartungsfenster, Betriebssystemänderungen, App-Verteilung und Austausch defekter Geräte erhalten klare Verantwortlichkeiten.

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

7. Sicherheit und kontrollierter Betrieb

1. Zugangsdaten, Signiermaterial, Gerätekennungen und sensible Testdaten werden außerhalb des Quellcodes geschützt bereitgestellt.
2. Runner, Testbuilds und Gerätefarm erhalten minimale Berechtigungen und nachvollziehbare administrative Zugriffe.
3. Instrumentierung wird ausschließlich in freigegebenen Testkonfigurationen aktiviert und gegen unerwünschten Netzwerkzugriff begrenzt.

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

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. Runner mit eindeutigen Exitcodes
2. Parallelisierung mit isolierten Testkonten
3. Reservierungs- und Health-Check-Prozess
4. Pipeline mit Bericht und Qualitätsgate

Zielgruppe und Voraussetzungen

Zielgruppe: Testarchitekten, DevOps Engineers, QA Leads, Gerätefarm-Betreiber und erfahrene Testautomatisierer.

Voraussetzungen: Sichere Airtest- und Python-Kenntnisse; Grundlagen in CI/CD, Prozessen und Testinfrastruktur.

Didaktische Einordnung

Vier Tage sind notwendig, weil neben der technischen Jobausführung auch Parallelität, Testdaten, Gerätefarm-Lifecycle, Berichtskonsolidierung, Security und produktiver Betrieb praktisch verbunden werden.

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.