Seminar OmniLab Android Test Station (ATS) – API und Workflow-Automatisierung

Die grafische Oberfläche eignet sich für interaktive Arbeit, während wiederkehrende Abläufe eine belastbare Programmschnittstelle benötigen. Das Seminar entwickelt aus der vorhandenen REST-Schnittstelle automatisierte Prozesse für Testplanung, Laufüberwachung, Ergebnisübernahme und Einbindung in bestehende Entwicklungsabläufe.

Inhaltsverzeichnis

• Lernziele
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Schnittstellenmodell und Ressourcen
• OpenAPI auswerten und Clientzugriff vorbereiten
• Testläufe programmgesteuert starten
• Status, Warteschlange und Abbruch
• Ergebnisse und Artefakte verarbeiten
• Robuste Automatisierung
• Einbindung in CI/CD und Freigaben
• Praxisübungen
• Methodik

Lernziele

• Ressourcenorientierte ATS-Endpunkte und JSON-Datenmodelle sicher einordnen.
• Die lokale OpenAPI-Beschreibung lesen und daraus einen Client oder gezielte Aufrufe ableiten.
• Testläufe automatisiert anlegen, überwachen, abbrechen und auswerten.
• Fehlerbehandlung, Wiederholbarkeit und Protokollierung für produktive Abläufe umsetzen.
• ATS in Build-, Release- und Qualitätsprozesse integrieren, ohne manuelle Bedienung vorauszusetzen.

Zielgruppe

Testautomatisierung, DevOps, CI/CD-Engineering, Softwareentwicklung, Quality Engineering und technische Integration.

Voraussetzungen

Praktische ATS-Grundkenntnisse sowie Erfahrung mit einer Skript- oder Programmiersprache. Grundwissen zu REST, HTTP-Methoden und JSON ist erforderlich.

Seminarinhalte

Schnittstellenmodell und Ressourcen

1. Schritt 1: Die API-Struktur nach Ressourcen, Methoden, Parametern, Antworten und Fehlerobjekten gliedern.
2. Schritt 2: Objekte für Testdefinitionen, Geräte, Testläufe, Pläne und Resultate den betrieblichen Aufgaben zuordnen.
3. Schritt 3: Lesende und verändernde Operationen hinsichtlich Wirkung, Berechtigung und Wiederholbarkeit unterscheiden.

OpenAPI auswerten und Clientzugriff vorbereiten

1. Schritt 1: Die lokale Schnittstellenbeschreibung abrufen und relevante Endpunkte nach Anwendungsfall auswählen.
2. Schritt 2: Datentypen, Pflichtfelder und Rückgabestrukturen in ein technisches Aufrufmodell übertragen.
3. Schritt 3: Einen generierten oder schlanken eigenen Client mit konfigurierbarer Basisadresse und Zeitüberschreitungen vorbereiten.

Testläufe programmgesteuert starten

1. Schritt 1: Testdefinition, Geräteanforderungen, Aktionen und Ressourcen als vollständigen Auftrag zusammenstellen.
2. Schritt 2: Eingaben vor dem Versand validieren und sensible Werte außerhalb des Quelltexts bereitstellen.
3. Schritt 3: Die erzeugte Laufkennung speichern und mit Build-, Ticket- oder Releasekennung verknüpfen.

Status, Warteschlange und Abbruch

1. Schritt 1: Den Laufstatus mit angemessenem Abfrageintervall überwachen und Zustandswechsel protokollieren.
2. Schritt 2: Warteschlangen, Ressourcenabruf und Gerätezuweisung getrennt bewerten, um Fehlalarme zu vermeiden.
3. Schritt 3: Abbruchregeln für Zeitüberschreitung, fehlerhafte Vorbedingungen und manuelle Freigaben implementieren.

Ergebnisse und Artefakte verarbeiten

1. Schritt 1: Gesamtstatus, Modulergebnisse und verfügbare Ausgabedateien strukturiert erfassen.
2. Schritt 2: Ergebnisdaten normalisieren und in Berichtssysteme, Dashboards oder Qualitätsgates übernehmen.
3. Schritt 3: Große Artefakte bedarfsgerecht laden und Aufbewahrung sowie Zugriff nachvollziehbar steuern.

Robuste Automatisierung

1. Schritt 1: Netzwerkfehler, ungültige Eingaben, Konflikte und serverseitige Fehler in klaren Fehlerklassen behandeln.
2. Schritt 2: Wiederholungslogik mit Begrenzung, Wartezeiten und eindeutigen Auftragskennungen gegen Doppelstarts absichern.
3. Schritt 3: Technische Protokolle mit Korrelationskennungen, Laufkennung und relevanten Parametern anreichern.

Einbindung in CI/CD und Freigaben

1. Schritt 1: Den ATS-Aufruf an Buildbereitstellung, Geräteverfügbarkeit und Freigaberegeln koppeln.
2. Schritt 2: Schnelle Vorprüfungen und umfangreiche Nachtläufe als getrennte Pipeline-Stufen modellieren.
3. Schritt 3: Ergebnisgrenzen für Warnung, Abbruch und Freigabe definieren und als wiederverwendbare Pipeline-Regel umsetzen.

Praxisübungen

• Erkunden der lokalen API-Beschreibung und Dokumentieren eines vollständigen Testlaufablaufs.
• Implementieren eines Skripts zum Starten eines Testlaufs und Überwachen bis zum Endzustand.
• Einlesen von Resultaten und Erzeugen einer maschinenlesbaren Qualitätsentscheidung.
• Erweitern des Skripts um Zeitüberschreitung, Wiederholungslogik und eindeutige Protokollierung.

Methodik

Die Schnittstelle wird anhand kleiner, aufeinander aufbauender Automatisierungsbausteine erschlossen. Der Schwerpunkt liegt auf reproduzierbarem Code, kontrollierter Fehlerbehandlung und der Übertragbarkeit in vorhandene Pipeline-Systeme.