Seminar Intensivseminar Mobly Testarchitektur und Betrieb

Seminarprofil

Der Schwerpunkt liegt auf langfristig wartbaren Testsystemen statt auf einzelnen Skripten. Architekturentscheidungen werden bis in Pipeline, Laborbetrieb und Fehleranalyse verfolgt.

Didaktische Einordnung: Fünf Tage sind erforderlich, um Entwurf, Implementierung und Betriebsaspekte gemeinsam zu behandeln und ein vollständiges skalierbares Referenzprojekt mit Custom Controller und CI-Ablauf zu erstellen.

Lernziele

• Eine modulare und skalierbare Mobly-Architektur entwerfen
• Controller, Services, Testlogik und Konfiguration sauber trennen
• Suites, Datenmatrizen und Ergebnisverarbeitung standardisieren
• CI/CD und physische Testbeds betriebssicher integrieren
• Stabilität, Sicherheit, Migration und Wartung systematisch regeln

Zielgruppe

Testarchitekten, Framework-Verantwortliche, technische Testleiter, DevOps-Teams und Betreiber von Gerätelaboren.

Voraussetzungen

Sichere Python-Kenntnisse, praktische Mobly-Erfahrung und Grundlagen von CI/CD sowie Systemtestarchitektur.

Inhaltsübersicht

1. Tag 1 – Qualitätsziele und Testschichten definieren
2. Tag 1 – Testbed- und Controller-Modell entwickeln
3. Tag 1 – Lifecycle und Zustandsmanagement standardisieren
4. Tag 2 – Custom Controller produktionsnah umsetzen
5. Tag 2 – Services und Diagnosebausteine entwerfen
6. Tag 2 – Testbarkeit der Framework-Bausteine sichern
7. Tag 3 – Datengetriebene Tests und Matrizen strukturieren
8. Tag 3 – Suites und Runner standardisieren
9. Tag 3 – Reporting und Fehlerklassifikation
10. Tag 4 – CI/CD-Ablauf und Geräteallokation
11. Tag 4 – Parallelität und Kapazitätssteuerung
12. Tag 4 – Stabilitätsmanagement
13. Tag 5 – Sicherheit und Betriebsrichtlinien
14. Tag 5 – Modernisierung und Migration
15. Tag 5 – Skalierbares Referenzprojekt

1. Tag 1 – Qualitätsziele und Testschichten definieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Systemrisiken und End-to-End-Eigenschaften priorisieren.
2. Schritt 2: Verantwortung zwischen Unit-, Komponenten-, Instrumentierungs- und Mobly-Tests abgrenzen.
3. Schritt 3: Laufzeit, Diagnosewert und Wartungskosten als Architekturziele festlegen.

2. Tag 1 – Testbed- und Controller-Modell entwickeln

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Physische und virtuelle Komponenten als Controller-Rollen modellieren.
2. Schritt 2: Konfigurationsschema und Geräteidentität standardisieren.
3. Schritt 3: Abhängigkeiten und Initialisierungsreihenfolgen dokumentieren.

3. Tag 1 – Lifecycle und Zustandsmanagement standardisieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Setup- und Teardown-Verantwortungen nach Ebene verteilen.
2. Schritt 2: Idempotente Ausgangszustände und Cleanup-Regeln definieren.
3. Schritt 3: Abbruchsignale und Recovery-Pfade anhand von Fehlerklassen festlegen.

4. Tag 2 – Custom Controller produktionsnah umsetzen

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Test-API, Treiber und Transport in getrennte Bausteine zerlegen.
2. Schritt 2: create, destroy und get_info mit Validierung implementieren.
3. Schritt 3: Fehler, Timeouts und Wiederverbindung konsistent behandeln.

5. Tag 2 – Services und Diagnosebausteine entwerfen

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Querschnittsfunktionen als Services statt in Testfällen implementieren.
2. Schritt 2: Logging, Artefakte und Gerätekennungen vereinheitlichen.
3. Schritt 3: Service-Lebenszyklen bei Neustart und Disconnect testen.

6. Tag 2 – Testbarkeit der Framework-Bausteine sichern

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Treiberzugriffe durch Fakes oder Simulatoren austauschbar machen.
2. Schritt 2: Vertragstests für Controller und Services definieren.
3. Schritt 3: Fehlerpfade ohne reale Hardware automatisiert prüfen.

7. Tag 3 – Datengetriebene Tests und Matrizen strukturieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Parameterquellen und Gültigkeitsregeln zentralisieren.
2. Schritt 2: Dynamische Fälle deterministisch erzeugen und benennen.
3. Schritt 3: Matrixgröße anhand von Risiko und Laufzeit begrenzen.

8. Tag 3 – Suites und Runner standardisieren

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Testklassen zu fachlichen Suites bündeln.
2. Schritt 2: Auswahl, Listing und Metadaten für unterschiedliche Laufprofile festlegen.
3. Schritt 3: Exit-Codes und Abbruchverhalten für aufrufende Systeme definieren.

9. Tag 3 – Reporting und Fehlerklassifikation

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Summary- und Einzelrecords zu einem einheitlichen Datenmodell verbinden.
2. Schritt 2: Produkt-, Test-, Geräte- und Infrastrukturfehler klassifizieren.
3. Schritt 3: Diagnosepakete für reproduzierbare Fehler erstellen.

10. Tag 4 – CI/CD-Ablauf und Geräteallokation

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Reproduzierbare Umgebung und Vorabprüfungen implementieren.
2. Schritt 2: Geräte reservieren, sperren, prüfen und sicher freigeben.
3. Schritt 3: Pipeline-Status aus Test- und Infrastrukturresultaten ableiten.

11. Tag 4 – Parallelität und Kapazitätssteuerung

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Ressourcenkonflikte und gemeinsam genutzte Komponenten erfassen.
2. Schritt 2: Testbeds auf Worker verteilen und Prioritäten anwenden.
3. Schritt 3: Warteschlange, Auslastung und Engpässe messbar machen.

12. Tag 4 – Stabilitätsmanagement

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Flakiness mit wiederholbaren Messläufen quantifizieren.
2. Schritt 2: Retry, Quarantäne und Blockierungsregeln voneinander trennen.
3. Schritt 3: Gesundheitschecks und automatische Recovery für Geräte einführen.

13. Tag 5 – Sicherheit und Betriebsrichtlinien

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Zugangsdaten, Geräteberechtigungen und sensible Artefakte schützen.
2. Schritt 2: Aufbewahrung und Zugriff für Logs, Videos und Konfigurationen regeln.
3. Schritt 3: Änderungs- und Freigabeprozess für Framework-Komponenten definieren.

14. Tag 5 – Modernisierung und Migration

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Altcode, Python-Versionen und veraltete Schnittstellen inventarisieren.
2. Schritt 2: Snippet-, Lifecycle- und Suite-Anpassungen schrittweise planen.
3. Schritt 3: Kompatibilitäts- und Regressionstests für Updates etablieren.

15. Tag 5 – Skalierbares Referenzprojekt

Die Arbeitsschritte bauen aufeinander auf und werden unmittelbar am Testsystem nachvollzogen.

1. Schritt 1: Controller, Suite, Reporting und CI-Aufruf zusammenführen.
2. Schritt 2: Parallelitäts- und Fehlerfälle im Modelllabor ausführen.
3. Schritt 3: Betriebscheckliste und technische Akzeptanzkriterien anwenden.

Praxisprojekt

1. Schritt 1: Eine Zielarchitektur für ein heterogenes Gerätelabor modellieren.
2. Schritt 2: Einen Custom Controller mit Fake-Treiber und Vertragstests implementieren.
3. Schritt 3: Suite, Ergebnisverarbeitung und Geräteallokation integrieren.
4. Schritt 4: Stabilitäts-, Sicherheits- und Migrationsregeln am Referenzprojekt prüfen.