Seminar QF-Test Mobile: CI/CD, Batch, Daemon und Geräte-Matrizen

Einordnung

Der produktive Betrieb mobiler Tests umfasst deutlich mehr als einen Kommandozeilenaufruf. Das Seminar entwickelt eine vollständige Ausführungskette von der testsuitenbezogenen Baseline über Batch und Daemon bis zur parallelen Geräte-Matrix. Berücksichtigt werden Ressourcen, Lizenzen, Zustandsbereinigung, Ergebnisartefakte, Wiederholungsregeln und nachvollziehbare Pipeline-Gates.

Inhaltsverzeichnis

1. Einordnung
2. Lernziele
3. Zielgruppe
4. Voraussetzungen
5. Schrittweise Seminarinhalte
6. Praxisübungen
7. Methodik

Lernziele

• mobile Testsuiten für unbeaufsichtigte Batch-Läufe vorbereiten
• Exitcodes, Run-IDs, Logs und Reports zuverlässig an eine Pipeline übergeben
• Daemon- und Remote-Ausführung mit klarer Prozessverantwortung einrichten
• Android- und iOS-Geräte-Matrizen parallel und kollisionsfrei planen
• Fehlerwiederherstellung, Quarantäne und Freigaberegeln betriebssicher gestalten

Zielgruppe

• Testautomation Engineers
• DevOps- und CI/CD-Engineering
• Build- und Release-Engineering
• Testarchitektur
• Mobile QA Leads

Voraussetzungen

Sichere QF-Test-Grundkenntnisse, wartbare mobile Testsuite, Kenntnisse der eingesetzten CI/CD-Plattform sowie verfügbare Ausführungsmaschinen und Geräte.

Schrittweise Seminarinhalte

1. Automatisierungsreife der Testsuite prüfen

1. Interaktive Dialoge, lokale Pfade, feste Gerätekennungen und manuelle Testdaten werden identifiziert.
2. Konfigurationen werden über Variablen, Umgebungsprofile und geschützte Parameter entkoppelt.
3. Setup, Testausführung, Cleanup und Report-Erzeugung erhalten klare Fehlergrenzen.

2. Batch-Ausführung standardisieren

1. Ein minimaler Batch-Aufruf wird mit Testsuite, Testmenge, Variablen und Run-Log erstellt.
2. Exitcodes werden in technische Fehler, Testfehler und erfolgreiche Läufe übersetzt.
3. Zeitüberschreitung, Abbruch und Prozessbeendigung werden kontrolliert getestet.
4. Ein lokales Startskript bildet exakt die spätere Pipeline-Ausführung ab.

3. Reports und Artefakte bereitstellen

1. HTML-, XML- und JUnit-Ergebnisse werden mit konsistenter Run-ID erzeugt.
2. Run-Logs, Screenshots und Umgebungsdaten werden als getrennte Artefaktklassen abgelegt.
3. Aufbewahrung, Namenskonvention und Zugriffsschutz werden für Fehleranalyse und Audit festgelegt.

4. Daemon und Remote-Ausführung einrichten

1. Rollen von Steuerinstanz, Daemon, Ausführungsrechner und Gerät werden abgegrenzt.
2. Ein entfernter Lauf wird mit eindeutigen Ports, Arbeitsverzeichnissen und Berechtigungen konfiguriert.
3. Verbindungsabbruch, Neustart und konkurrierende Aufträge werden gezielt simuliert.
4. Health-Checks prüfen Daemon, Gerät, Speicherplatz und benötigte Werkzeuge vor der Ausführung.

5. Geräte-Matrix planen

1. Geräteklassen werden risikobasiert nach Plattform, Version, Formfaktor und Ausführungsart ausgewählt.
2. Smoke-, Regressions- und Freigabematrix erhalten unterschiedliche Abdeckungsziele.
3. Geräte werden exklusiv reserviert; Clientnamen, Ports und Ergebnisverzeichnisse bleiben kollisionsfrei.

6. Parallele Läufe orchestrieren

1. Die Testmenge wird nach Laufzeit, Datenabhängigkeit und Geräteanforderung partitioniert.
2. Parallele Jobs erhalten eigene App-Zustände, Testkonten und Cleanup-Verantwortung.
3. Gesamtergebnis und Teilreports werden nach Abschluss deterministisch zusammengeführt.

7. Pipeline-Gates definieren

1. Fehlerklassen werden in blockierend, toleriert, quarantänisiert und infrastrukturell unterteilt.
2. Wiederholungen sind auf nachweislich flüchtige Infrastrukturfehler begrenzt.
3. Freigaberegeln berücksichtigen Testabdeckung, fehlende Geräte und unvollständige Läufe.
4. Benachrichtigungen enthalten komprimierte Ursache, betroffene Matrixzelle und Artefaktverweis innerhalb der Plattform.

8. Betrieb und Recovery absichern

1. Geräte- und Simulatorzustände werden vor und nach jedem Auftrag zurückgesetzt.
2. Hängende Prozesse, verlorene Verbindungen und volle Dateisysteme erhalten automatisierte Wiederherstellungsschritte.
3. Betriebskennzahlen zu Laufzeit, Stabilität, Auslastung und Fehlerrate werden definiert.
4. Eine Runbook-Struktur dokumentiert Diagnose, Eskalation und kontrollierten Neustart.

Praxisübungen

• Erstellung eines reproduzierbaren Batch-Aufrufs mit Variablen und Exitcode-Auswertung
• Aufbau eines entfernten Daemon-Laufs mit Health-Check
• Orchestrierung einer kleinen Android- oder iOS-Geräte-Matrix mit parallelen Teilmengen
• Erzeugung zusammengeführter Reports und Umsetzung eines Pipeline-Gates
• Recovery-Übung bei Verbindungsverlust und blockiertem Gerät

Methodik

Die Inhalte werden als zusammenhängender Betriebsaufbau umgesetzt. Nach jeder Ausbaustufe folgen Negativtests mit absichtlich gestörter Umgebung. Dadurch entsteht neben der Pipeline eine belastbare Diagnose- und Recovery-Struktur.