Seminar Genymotion Self-hosted / Device Image – CI/CD und parallele Testausführung

Automatisierte mobile Tests benötigen verfügbare Geräte, eindeutige Zuordnung, isolierte Testdaten, stabile ADB- oder API-Zugänge und eine kontrollierte Bereinigung. Das Seminar entwickelt eine Pipeline für parallele Android-Testläufe mit belastbarer Fehlerbehandlung und Ergebnisaufbereitung.

Seminarziel

Eine skalierbare CI/CD-Kette kann Geräte bereitstellen, vorbereiten, Tests parallel verteilen, Artefakte sichern und Ressourcen zuverlässig zurücksetzen. Parallelität wird anhand von Kapazität, Testdauer und Fehlerisolation geplant.

Inhaltsübersicht

1. 1. Pipeline- und Gerätevertrag
2. 2. Gerät bereitstellen und qualifizieren
3. 3. Anwendung und Testdaten vorbereiten
4. 4. Parallele Ausführung steuern
5. 5. Framework- und ADB-Integration
6. 6. Artefakte und Diagnose
7. 7. Bereinigung und Ressourcenrückgabe
8. 8. Fehlerbehandlung und Retry-Strategie
9. 9. Kapazität und Kosten optimieren
10. Praxisprojekt und Übungen
11. Zielgruppe und Voraussetzungen
12. Didaktik und Arbeitsweise

Fachliche Einordnung

Der Themenblock ist als eigenständiger Qualifizierungsbaustein für produktionsnahe Android-Test- und Betriebsumgebungen abgegrenzt. Konfigurationen werden nicht nur demonstriert, sondern mit Sollwerten, Negativtests, Rücksetzschritten und dokumentierten Prüfpunkten abgesichert. Dadurch bleiben die erarbeiteten Abläufe auf Self-hosted- und Device-Image-Szenarien übertragbar.

Seminarinhalte

1. Pipeline- und Gerätevertrag

Zwischen CI-System und Geräteplattform wird ein eindeutiger technischer Vertrag definiert.

1. Schritt 1: Eingabeparameter für Android-Version, Architektur, Profil und Testpaket festlegen.
2. Schritt 2: Ausgabewerte für Geräteadresse, Status, Logs und Ergebnisartefakte definieren.
3. Schritt 3: Timeouts, Wiederholungen und Abbruchbedingungen dokumentieren.
4. Schritt 4: Vertrag mit einem manuellen Provisionierungs- und Freigabeablauf verifizieren.

2. Gerät bereitstellen und qualifizieren

Nur startbereite und zum Test passende Geräte werden an Jobs übergeben.

1. Schritt 1: Freies Gerät auswählen oder neue Instanz nach definiertem Profil anfordern.
2. Schritt 2: Erreichbarkeit, Bootstatus, Android-Version und Architektur prüfen.
3. Schritt 3: ADB- oder API-Zugang herstellen und eine kurze Gesundheitsprüfung ausführen.
4. Schritt 4: Gerätekennung und Job-ID für die gesamte Laufzeit miteinander verknüpfen.

3. Anwendung und Testdaten vorbereiten

Jeder Testlauf startet mit einem bekannten, isolierten Zustand.

1. Schritt 1: APK, Testpaket und Prüfsummen aus dem Build-Artefakt übernehmen.
2. Schritt 2: Vorhandene Paket- und Datenstände entfernen oder zurücksetzen.
3. Schritt 3: Anwendung, Konfiguration und Testdaten installieren.
4. Schritt 4: Startzustand mit Paketversion, Berechtigungen und Referenzdateien validieren.

4. Parallele Ausführung steuern

Tests werden auf mehrere Geräte verteilt, ohne Ergebnisse oder Daten zu vermischen.

1. Schritt 1: Tests nach Dauer, Geräteanforderung und Konfliktpotenzial in Shards aufteilen.
2. Schritt 2: Maximale Parallelität aus verfügbarer Kapazität und Sicherheitsreserve bestimmen.
3. Schritt 3: Je Shard ein eindeutiges Gerät, Datenpräfix und Artefaktverzeichnis vergeben.
4. Schritt 4: Start, Heartbeat und Abschluss aller Shards zentral überwachen.

5. Framework- und ADB-Integration

Testframeworks greifen reproduzierbar auf das ihnen zugewiesene Zielgerät zu.

1. Schritt 1: Geräteadresse oder ADB-Seriennummer als Pipelinevariable bereitstellen.
2. Schritt 2: Testtreiber mit explizitem Ziel und definierten Wartezeiten starten.
3. Schritt 3: Ein kleiner Smoke-Test vor dem Hauptlauf ausführen.
4. Schritt 4: Verbindungsabbrüche erkennen und nach festgelegter Regel neu verbinden oder abbrechen.

6. Artefakte und Diagnose

Fehlerläufe liefern genügend Kontext für schnelle Ursachenanalyse.

1. Schritt 1: Logcat, Screenshots, Video, Testreport und Geräte-Metadaten je Shard sammeln.
2. Schritt 2: Zeitstempel und Job-ID in Dateinamen und Metadaten vereinheitlichen.
3. Schritt 3: Artefakte auch bei Timeout oder Abbruch über einen Abschlussblock sichern.
4. Schritt 4: Sensible Inhalte filtern und Aufbewahrungsdauer kennzeichnen.

7. Bereinigung und Ressourcenrückgabe

Geräte werden nach jedem Lauf in einen definierten Zustand versetzt.

1. Schritt 1: Testprozess beenden und Verbindungen kontrolliert trennen.
2. Schritt 2: Anwendung, Konten, Testdaten und temporäre Dateien entfernen.
3. Schritt 3: Gerätezustand prüfen oder Instanz verwerfen und neu bereitstellen.
4. Schritt 4: Kapazität freigeben und Abschlussstatus an das CI-System melden.

8. Fehlerbehandlung und Retry-Strategie

Infrastrukturfehler werden von Produktfehlern getrennt behandelt.

1. Schritt 1: Fehler nach Provisionierung, Verbindung, Test, Artefakt und Bereinigung klassifizieren.
2. Schritt 2: Nur technisch idempotente Schritte mit begrenzter Anzahl wiederholen.
3. Schritt 3: Quarantäne für instabile Geräte oder Images einrichten.
4. Schritt 4: Fehlerquote und Retry-Wirkung aus Pipeline-Messwerten auswerten.

9. Kapazität und Kosten optimieren

Parallelität wird auf Durchsatz und Ressourcenverbrauch abgestimmt.

1. Schritt 1: Ankunftsrate, mittlere Testdauer und Spitzenlast aus historischen Läufen ermitteln.
2. Schritt 2: Warteschlange, Parallelität und Reservekapazität modellieren.
3. Schritt 3: Geräteklassen nach interaktivem und automatisiertem Bedarf trennen.
4. Schritt 4: Zielwerte für Durchsatz, Wartezeit und Auslastung in einem Betriebsdashboard festlegen.

Praxisprojekt und Übungen

Die Übungen verwenden einen zusammenhängenden Laborfall. Jeder Arbeitsauftrag enthält Ausgangslage, Sollzustand, Durchführung, Prüfpunkte und eine kontrollierte Bereinigung. Fehlerfälle werden bewusst eingebaut, damit Diagnose und Rückfall nicht erst im Produktivbetrieb erprobt werden.

1. Übung 1: Eine Pipeline stellt Geräte bereit, installiert eine Anwendung und führt einen Smoke-Test aus.
2. Übung 2: Ein Testsatz wird in mehrere parallele Shards mit isolierten Daten und Artefakten zerlegt.
3. Übung 3: Timeout, Verbindungsabbruch und fehlerhafte Bereinigung werden kontrolliert simuliert und ausgewertet.

Zielgruppe und Voraussetzungen

Zielgruppe: DevOps, Testautomatisierung, Mobile QA, Build Engineering und Plattformbetrieb.

Voraussetzungen: Erfahrung mit CI/CD-Grundkonzepten, Android-Tests und Kommandozeilenwerkzeugen.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurationsschritte, Praxisübungen und kontrollierte Fehlerfälle vertieft. Für jeden wesentlichen Ablauf entstehen wiederverwendbare Checklisten, Konfigurationsnachweise oder Runbooks. Die Bearbeitung erfolgt ohne undokumentierte Sonderkonfigurationen und endet jeweils mit einer technischen Validierung des erreichten Zustands.