Screenshot Test: Was es ist, Arten und wie es beim Testen funktioniert

Was ist ein Screenshot Test und warum wird er benötigt?

Screenshot Test ist ein End-to-End-Benutzeroberflächentest, bei dem der Test einen App-Bildschirm öffnet, Aktionen ausführt (Tippen, Texteingabe, Scrollen) und einen Screenshot des resultierenden Zustands macht. Der Screenshot wird mit einer im Repository gespeicherten Baseline verglichen. Wenn die Screenshots abweichen — schlägt der Test fehl. Screenshot-Tests erkennen visuelle Regressionen, die Unit-Tests nicht sehen können: falsche Abstände, überlappende Elemente, falsche Farben.

Warum brauchen wir Screenshot-Tests, wenn wir Golden-Tests haben? — Golden-Tests prüfen Komponenten isoliert: ein Button, eine Karte, ein Text. Screenshot-Tests prüfen einen gesamten Bildschirm in einer Umgebung, die der Produktion möglichst nahe kommt: echte Navigation, echte Daten (oder maximal realistische Mocks), echte Systemschriftarten, echte Statusleiste. Nur ein Screenshot-Test zeigt, dass ein Button auf einem echten Gerät von einem anderen Element überlappt wird.

Geschäftswert von Screenshot-Tests

Geschäftswert — laut Google (2023) machen visuelle Fehler 15–25 % aller Fehler in mobilen Apps aus. Screenshot-Tests automatisieren die visuelle Qualitätsprüfung, die früher manuell von QA-Ingenieuren durchgeführt wurde. Ein Screenshot-Test ersetzt 5–10 Minuten manuelles Testen eines Bildschirms. Bei einer App mit 50 Bildschirmen beträgt die Einsparung: 4–8 Personenstunden pro Regressionstestlauf. Screenshot-Tests amortisieren sich in 2–3 Release-Zyklen.

Screenshot Test vs Golden Test: Vergleich der Ansätze

Golden-Tests sind schneller und einfacher: Das Rendern einer Komponente in einem Off-Screen-Buffer dauert Millisekunden, benötigt kein Gerät und ist auf CI stabil. Screenshot-Tests sind realistischer: Sie erfassen einen echten Bildschirm mit Systemelementen, unterstützen Animationen und Navigation und arbeiten auf echten Geräten. Die Wahl hängt vom Ziel ab: schnelles Feedback für den Entwickler (Golden) oder maximale Realitätsnähe vor dem Release (Screenshot).

Abdeckungsstrategie: Golden + Screenshot

Golden + Screenshot — verwenden Sie Golden-Tests für jede UI-Komponente in der Komponentenbibliothek (Design System). 80 % der visuellen Regressionen werden auf Komponentenebene erfasst. Screenshot-Tests — für kritische Benutzerpfade: Onboarding, Login, Zahlungsfluss, Warenkorb. 20 % der Regressionen im Zusammenhang mit der Komponentenintegration auf einem echten Bildschirm werden nur durch Screenshot-Tests erfasst. Bei IT Sectr verwenden wir ein 80/20-Verhältnis: 400 Golden + 100 Screenshot.

Wann ein Screenshot-Test nicht benötigt wird — wenn der Bildschirm aus statischem Inhalt ohne Interaktivität besteht, liefert ein Golden-Komponententest das gleiche Maß an Überprüfung zu geringeren Kosten. Wenn sich der Bildschirm dynamisch ändert (Feed, Chat), erfordert ein Screenshot-Test eine komplexe Dateneinrichtung und Wartezeiten. Verwenden Sie in solchen Fällen Screenshot für den Basisstatus (leere Liste, Laden) und Golden für einzelne Karten in der Liste.

UI Automator und Firebase Test Lab für Android

UI Automator ist ein Android-Framework für übergreifendes UI-Testing. Es ermöglicht das Aufnehmen von Screenshots über UiDevice.takeScreenshot(). Im Gegensatz zu Espresso (arbeitet innerhalb einer einzelnen App) kann UI Automator mit Systemdialogen (Berechtigungen, Benachrichtigungen) und anderen Apps interagieren. Ein UI Automator-Screenshot-Test: App öffnen, Laden abwarten, Screenshot machen, mit Baseline vergleichen.

class LoginScreenScreenshotTest {

    @get:Rule
    val rule = ComposeTestRule.createAndroidComposeRule<MainActivity>()

    @Test
    fun login_screen_default() {
        val device = UiDevice.getInstance(
            InstrumentationRegistry.getInstrumentation()
        )

        // Auf das Laden des Bildschirms warten
        IdlingRegistry.getInstance().waitForIdle()

        // Screenshot aufnehmen
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Mit der Referenz vergleichen
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab ist ein Google Cloud-Dienst zum parallelen Ausführen von instrumentierten Tests auf Hunderten von echten Geräten. Screenshot-Tests auf Firebase Test Lab erfassen Screenshots auf verschiedenen Geräten (Pixel 7, Galaxy S24, Xiaomi 14) und vergleichen sie mit Baselines. Vorteil: Ein Test prüft die UI auf 20 Geräten in 10–15 Minuten. Nachteil: Kosten (1–5 $ pro Test auf 20 Geräten). Firebase Test Lab integriert sich über die gcloud CLI oder das Gradle-Plugin in CI.

Shot: Bibliothek zur Vereinfachung von Screenshot-Tests

Shot ist eine Bibliothek für Screenshot-Tests auf Android, die das Erstellen und Vergleichen von Screenshots vereinfacht. Shot arbeitet auf Espresso und UI Automator auf und fügt Golden-Verwaltung (Erstellen, Aktualisieren, Löschen), Vergleich mit Schwellenwert (Pixel oder Prozent) und HTML-Berichtsgenerierung hinzu. Shot eignet sich für Projekte, die schnell Screenshot-Tests implementieren möchten, ohne eine eigene Bildvergleichsinfrastruktur zu schreiben.

XCUITest und Xcode Cloud für iOS

XCUITest ist Apples Framework für UI-Tests von iOS-, iPadOS- und tvOS-Anwendungen. Screenshot-Tests auf XCUITest verwenden XCUIScreen.main.screenshot() zur Bildschirmaufnahme und XCAttachment zum Speichern von Screenshots. XCUITest simuliert Benutzeraktionen: Tap, Swipe, typeText und macht nach jedem Schritt Screenshots. In Xcode 16+ wurde eine integrierte Unterstützung für den Vergleich von Screenshots mit Baselines über XCTAttachment hinzugefügt.

final class LoginScreenScreenshotTests: XCTestCase {

    var app: XCUIApplication!

    override func setUp() {
        super.setUp()
        app = XCUIApplication()
        app.launch()
    }

    func test_login_initial_state() {
        let loginButton = app.buttons["login_button"]
        XCTAssertTrue(loginButton.exists)

        // Screenshot aufnehmen
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Vergleich mit der Referenz (erfordert XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud ist Apples Cloud-CI zum Erstellen und Testen von iOS-Anwendungen. Xcode Cloud unterstützt die Ausführung von XCUITest-Tests auf Simulatoren. Screenshot-Tests können auf mehreren Simulatoren parallel ausgeführt werden (iPhone 15, iPhone 15 Pro Max, iPad Pro). Ergebnisse: XCResult Bundle mit Anhängen. Xcode Cloud ist nicht in GitHub/GitLab integriert — verwenden Sie Xcode Cloud Webhooks zur Integration. Alternative: GitHub Actions mit macos-14 und xcodebuild.

Vergleichs-Frameworks — iOSSnapshotTestCase (Uber) funktioniert auch für Screenshot-Tests, wenn es auf einem Simulator ausgeführt wird. SwiftSnapshotTesting (pointfree) ist eher auf Komponenten-Golden-Tests ausgerichtet. Für Screenshot-Tests auf iOS verwenden Sie die integrierten XCUITest-Tools + XCTAttachment + einen benutzerdefinierten ImageComparator (Pixelmator oder AImage). Verwenden Sie auf CI den Simulator — auf echten Geräten funktionieren Screenshot-Tests nur über Device Farm (AWS Device Farm).

Automatisierungsprozess von Screenshot-Tests in CI

Baseline-Management — Baseline-Screenshots werden im Repository (Git LFS) oder in S3 gespeichert. Jeder Screenshot wird nach Vorlage benannt: {testName}_{device}_{orientation}_{locale}.png. Beispiel: loginScreenPixel7PortraitRu.png. Beim Hinzufügen eines neuen Geräts oder Gebietsschemas wird eine neue Baseline erstellt. Bei Änderung der UI werden alte Baselines nach Code-Review durch neue ersetzt. Die Baseline ist Teil der Codebasis, wie Testquellen.

CI-Pipeline — (1) App erstellen. (2) Screenshot-Tests auf Emulatoren/Simulatoren ausführen. (3) Screenshots mit Baselines vergleichen. (4) Bei Abweichung — Diff-Bild generieren. (5) Diff-Artefakte hochladen (actual, expected, diff — drei Dateien). (6) HTML-Bericht mit Ergebnistabelle veröffentlichen. (7) Bei Überschreitung des Schwellenwerts — Test schlägt fehl. (8) Prüfer untersucht Diff-Artefakte und entscheidet: Genehmigen (Baseline aktualisieren) oder Ablehnen (Code korrigieren).

Schwellenwert und Toleranz — absoluter Pixel-für-Pixel-Vergleich ist zu streng. Verwenden Sie SSIM (Structural Similarity Index) oder MSE (Mean Squared Error). SSIM 0.98 = 98 % strukturelle Ähnlichkeit — ein guter Schwellenwert. Unterschiedliche Bildschirme können unterschiedliche Schwellenwerte erfordern: dunkles Thema (mehr Schwarz — höhere Genauigkeit), Verläufe (mehr Rauschen — geringere Genauigkeit). Konfigurieren Sie den Schwellenwert pro Test über den Parameter: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulator — Tests auf echten Geräten (Firebase Test Lab, AWS Device Farm) bieten maximale Realitätsnähe, sind aber langsam und kostenpflichtig. Tests auf Simulatoren/Emulatoren sind schnell und kostenlos, zeigen aber keine echten Geräteeigenschaften (unterschiedliche GPUs, Display-Farbwiedergabe, Pixeldichte). Strategie: Simulator für Pre-Merge-Prüfung (5 Minuten), Device Farm für Nächte (30 Minuten, 20 Geräte). Bei IT Sectr verwenden wir Firebase Test Lab für nächtliche Läufe auf den Top-10-Android-Geräten.