Screenshot Test: vad är det, typer och hur det fungerar i testning

Vad är Screenshot Test och varför behövs det?

Screenshot Test — är end-to-end-testning av användargränssnittet, där testet öppnar applikationens skärm, utför åtgärder (tryck, textinmatning, scrollning) och tar en skärmbild av det erhållna tillståndet. Skärmbilden jämförs med en referens (baseline) som lagras i repot. Om skärmbilderna skiljer sig — misslyckas testet. Screenshot-tester upptäcker visuella regressioner som inte syns i enhetstester: felaktiga marginaler, överlappande element, felaktiga färger.

Varför behövs screenshot-tester när golden-tester finns — golden-tester kontrollerar komponenter isolerat: en knapp, ett kort, en text. Screenshot-tester kontrollerar hela skärmen i en miljö som är så nära produktion som möjligt: verklig navigering, verklig data (eller så realistiska mockar som möjligt), verkliga systemteckensnitt, verklig statusrad. Endast ett screenshot-test kommer att visa att knappen överlappar ett annat element på en verklig enhet.

Affärsvärdet av screenshot-tester

Affärsvärde — enligt Google (2023) utgör visuella buggar 15-25% av alla buggar i mobilapplikationer. Screenshot-tester automatiserar kontrollen av visuell kvalitet som tidigare gjordes manuellt av QA-ingenjörer. Ett screenshot-test ersätter 5-10 minuters manuell testning av en skärm. För en applikation med 50 skärmar, besparing: 4-8 arbetstimmar per regressionskörning. Screenshot-tester betalar sig själva inom 2-3 releasecykler.

Screenshot Test vs Golden Test: jämförelse av tillvägagångssätt

Golden-tester är snabbare och enklare: rendering av komponenten i en off-screen-buffert tar millisekunder, kräver ingen enhet, är stabila i CI. Screenshot-tester är mer realistiska: de fångar den verkliga skärmen med systemelement, stödjer animationer och navigering, fungerar på verkliga enheter. Valet beror på målet: snabb återkoppling för utvecklaren (golden) eller maximal realism före release (screenshot).

Täckningsstrategi: golden + screenshot

Golden + Screenshot — använd golden-tester för varje UI-komponent i komponentbiblioteket (Design System). 80% av visuella regressioner fångas på komponentnivå. Screenshot-tester — för kritiska användarvägar: onboarding, inloggning, betalningsflöde, varukorg. 20% av regressioner relaterade till integration av komponenter på verklig skärm fångas endast av screenshot-tester. På IT Sectr använder vi förhållandet 80/20: 400 golden + 100 screenshot.

När screenshot-test inte behövs — om skärmen består av statiskt innehåll utan interaktivitet, ger komponentens golden-test samma kontrollnivå till lägre kostnad. Om skärmen ändras dynamiskt (feed, chatt), kräver screenshot-test komplex datakonfiguration och väntetid. I sådana fall, använd screenshot för grundtillstånd (tom lista, laddning) och golden för enskilda kort i listan.

UI Automator och Firebase Test Lab för Android

UI Automator — Android-ramverk för tvär applikations UI-testning. Möjliggör tagning av skärmbilder via UiDevice.takeScreenshot(). Till skillnad från Espresso (fungerar inuti en applikation) kan UI Automator interagera med systemdialogrutor (behörigheter, meddelanden) och andra applikationer. Screenshot-test på UI Automator: öppna applikationen, vänta på laddning, ta en skärmbild, jämför med referensen.

class LoginScreenScreenshotTest {

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

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

        // Väntar på att skärmen ska laddas
        IdlingRegistry.getInstance().waitForIdle()

        // Tar en skärmbild
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Jämför med referensen
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab — Google Cloud-tjänst för parallell körning av instrumentella tester på hundratals verkliga enheter. Screenshot-tester på Firebase Test Lab tar skärmbilder på olika enheter (Pixel 7, Galaxy S24, Xiaomi 14) och jämför dem med referenser. Fördel: ett test kontrollerar UI på 20 enheter på 10-15 minuter. Nackdel: kostnad ($1-5 per test på 20 enheter). Firebase Test Lab integreras med CI via gcloud CLI eller Gradle-plugin.

Shot: bibliotek för att förenkla screenshot-tester

Shot — bibliotek för screenshot-testning på Android som underlättar skapande och jämförelse av skärmbilder. Shot fungerar ovanpå Espresso och UI Automator, och lägger till golden-hantering (skapa, uppdatera, ta bort), jämförelse med tröskel (pixlar eller procent) och generering av HTML-rapport. Shot är lämpligt för projekt som snabbt vill införa screenshot-testning utan att skriva egen infrastruktur för bildjämförelse.

XCUITest och Xcode Cloud för iOS

XCUITest — Apple-ramverk för UI-testning av iOS-, iPadOS- och tvOS-applikationer. Screenshot-tester på XCUITest använder XCUIScreen.main.screenshot() för att fånga skärmen och XCAttachment för att spara skärmbilden. XCUITest simulerar användaråtgärder: tap, swipe, typeText, och tar skärmbilder efter varje steg. I Xcode 16+ har inbyggt stöd för jämförelse av skärmbilder med referenser via XCTAttachment lagts till.

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)

        // Tar en skärmbild
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Jämförelse med referensen (kräver XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud — molnbaserad CI från Apple för att bygga och testa iOS-applikationer. Xcode Cloud stödjer körning av XCUITest-tester på simulatorer. Screenshot-tester kan köras på flera simulatorer parallellt (iPhone 15, iPhone 15 Pro Max, iPad Pro). Resultat: XCResult Bundle med bilagor. Xcode Cloud är inte inbyggt i GitHub/GitLab — använd Xcode Cloud Webhooks för integration. Alternativ: GitHub Actions med macos-14 och xcodebuild.

Jämförelseramverk — iOSSnapshotTestCase (Uber) fungerar även för screenshot-tester om det körs på en simulator. SwiftSnapshotTesting (pointfree) är mer inriktat på golden-tester av komponenter. För screenshot-tester på iOS, använd de inbyggda verktygen XCUITest + XCTAttachment + en anpassad ImageComparator (Pixelmator eller AImage). I CI, använd simulator — på verkliga enheter fungerar screenshot-tester endast via Device Farm (AWS Device Farm).

Automatiseringsprocess för screenshot-tester i CI

Baseline-hantering — referensskärmbilder lagras i repot (Git LFS) eller i S3. Varje skärmbild namnges enligt mallen: {testName}_{device}_{orientation}_{locale}.png. Exempel: loginScreenPixel7PortraitRu.png. När en ny enhet eller locale läggs till, skapas en ny baseline. När UI ändras, ersätts gamla baseline med nya efter code review. Baseline är en del av kodbasen, precis som testkällorna.

CI Pipeline — (1) Bygg applikationen. (2) Kör screenshot-tester på emulatorer/simulatorer. (3) Jämför skärmbilder med baseline. (4) Vid avvikelse — generera diff-bild. (5) Ladda upp diff-artefakter (actual, expected, diff — tre filer). (6) Publicera HTML-rapport med resultattabell. (7) Om tröskeln överskrids — testet misslyckas. (8) Granskaren inspekterar diff-artefakterna och fattar beslut: godkänn (uppdatera baseline) eller avvisa (fixa kod).

Tröskel och tolerans — absolut pixel-för-pixel-jämförelse är för sträng. Använd SSIM (Structural Similarity Index) eller MSE (Mean Squared Error). SSIM 0.98 = 98% strukturell likhet — en bra tröskel. För olika skärmar kan olika trösklar behövas: mörkt tema (mer svart — högre noggrannhet), gradienter (mer brus — lägre noggrannhet). Konfigurera tröskeln per-test via parameter: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulator — tester på verkliga enheter (Firebase Test Lab, AWS Device Farm) ger maximal realism, men är långsamma och betalda. Tester på simulatorer/emulatorer — snabba och gratis, men visar inte verkliga enhetsegenskaper (olika GPU:er, skärmfärgåtergivning, pixeltäthet). Strategi: simulator för pre-merge-kontroll (5 minuter), Device Farm för nightly (30 minuter, 20 enheter). På IT Sectr använder vi Firebase Test Lab för nattliga körningar på de 10 bästa Android-enheterna.