Seminar Appium – Android-Testautomatisierung mit UiAutomator2 und Espresso

Android-Tests werden nur dann reproduzierbar, wenn Treiberwahl, SDK-Umgebung, Gerätezustand und Synchronisation als zusammenhängendes System behandelt werden. Die Schulung führt von einer geprüften Laborumgebung bis zu parallelisierbaren Testfällen auf Emulatoren und realen Geräten.

Inhaltsübersicht

• Zielsetzung
• Android-Plattform und Treiberwahl
• Sessions, Apps und Interaktionen
• Stabilität, Parallelbetrieb und Diagnose
• Praxisstrecke
• Didaktische Einordnung

Zielsetzung

Die Teilnehmenden richten eine Android-Testumgebung ein, wählen UiAutomator2 oder Espresso anhand technischer Kriterien, erstellen W3C-konforme Sessions und implementieren stabile Tests für typische native und hybride Abläufe. Fehler werden anhand von Appium-Serverlog, ADB, Logcat und Seitensource systematisch eingegrenzt.

Android-Plattform und Treiberwahl

Die technische Ausgangslage bestimmt, welcher Treiber sinnvoll ist und welche Eingriffe in die App oder Build-Pipeline notwendig werden.

Architektur verstehen

• Zusammenspiel von Appium-Server, Clientbibliothek, Android-Treiber, ADB und Zielgerät
• Abgrenzung von UiAutomator2 als systemnaher Black-Box-Automatisierung und Espresso als app-naher Instrumentierung
• Auswahlkriterien für native Apps, Systemdialoge, eingebettete WebViews und kontrollierte Test-Builds
• Grenzen bei Herstelleroberflächen, sicherheitsgeschützten Ansichten und nicht automatisierbaren Betriebssystemdialogen

Toolchain prüfen

• Android SDK, Platform Tools, Java-Laufzeit, Umgebungsvariablen und ADB-Verbindung kontrollieren
• Emulatorprofile, API-Level, Hardwarebeschleunigung, Snapshots und reproduzierbare Gerätezustände planen
• Reale Geräte für USB-Debugging, Berechtigungen, Sperrbildschirm und stabile Gerätekennungen vorbereiten
• Treiberinstallation und Doctor-Prüfungen als automatisierbaren Preflight etablieren

Sessions, Apps und Interaktionen

Session-Konfiguration

• W3C-Capabilities mit platformName, automationName und treiberspezifischen appium:-Optionen strukturieren
• App-Datei, App-Paket, Startaktivität, Geräteziel, Installationsverhalten und Reset-Strategie festlegen
• Berechtigungen, Sprache, Gebietsschema, Bildschirmorientierung und Systemanimationen kontrollieren
• Ports und Gerätekennungen so konfigurieren, dass mehrere Sessions konfliktfrei laufen können

Elemente und Gesten

• Accessibility-IDs, Android-Ressourcen-IDs und plattformspezifische Selektoren priorisieren
• Listen, Dialoge, Tastatur, Benachrichtigungen und dynamisch nachgeladene Inhalte bedienen
• Tippen, langes Drücken, Ziehen, Wischen und Mehrschrittgesten mit W3C Actions abbilden
• Assertions auf sichtbare Zustände, fachliche Werte und Navigation statt auf bloße Wartezeiten ausrichten

Stabilität, Parallelbetrieb und Diagnose

Flaky Tests vermeiden

• Explizite Zustandsbedingungen, kontrollierte Testdaten und idempotente Vorbedingungen verwenden
• Animationen, Netzwerkverzögerungen, Hintergrundprozesse und wechselnde Gerätezustände berücksichtigen
• Treiber- und App-Lebenszyklus sauber trennen und Sessions zuverlässig beenden
• Tests nach Plattform, Gerät, API-Level und Risikoklasse sinnvoll schneiden

Fehler systematisch eingrenzen

• Serverlog, Logcat, ADB-Ausgaben, Screenshot, Seitensource und Video zeitlich zusammenführen
• Fehler zwischen Client, Server, Treiber, App, Android-System und Gerät zuordnen
• Timeouts, nicht gefundene Elemente, Stale-Zustände, Installationsprobleme und Portkonflikte unterscheiden
• Diagnoseartefakte für lokale Läufe und CI-Ausführung einheitlich sichern

Praxisstrecke

Eine Beispiel-App wird auf Emulator und realem Gerät automatisiert. Jeder Schritt baut auf dem vorherigen auf und endet mit einer technischen Kontrolle.

1. SDK, Java, ADB, Appium und installierte Android-Treiber mit einer Preflight-Checkliste prüfen.
2. Ein reproduzierbares Emulatorprofil anlegen und ein reales Gerät mit eindeutiger Kennung vorbereiten.
3. Je eine UiAutomator2- und Espresso-Session konfigurieren und die Eignung für das Testszenario vergleichen.
4. Mit dem Inspector robuste Selektoren ermitteln und einen Login- sowie Navigationsablauf implementieren.
5. Wartebedingungen, Systemdialoge, Tastatur und eine Wischgeste in den Test integrieren.
6. Einen absichtlich instabilen Test anhand von Serverlog, Logcat und Seitensource korrigieren.
7. Zwei Sessions mit getrennten Ports ausführen und Artefakte für eine spätere CI-Auswertung sichern.

Didaktische Einordnung

Drei Seminartage sind erforderlich, weil die Android-Toolchain, zwei unterschiedliche Treibermodelle, reale Interaktionen und eine vollständige Diagnose- und Parallelisierungsstrecke praktisch aufgebaut werden. Eine kürzere Dauer würde entweder die Espresso-Abgrenzung oder die notwendige Stabilitätsarbeit auf reine Demonstrationen reduzieren.