Screenshot Test: ce este, tipuri și cum funcționează în testare

Ce este Screenshot Test și de ce este necesar?

Screenshot Test — este testarea end-to-end a interfeței de utilizator, în care testul deschide ecranul aplicației, execută acțiuni (atingeri, introducere text, derulare) și face o captură de ecran a stării obținute. Captura de ecran este comparată cu o referință (baseline) stocată în depozit. Dacă capturile de ecran diferă — testul eșuează. Testele screenshot detectează regresii vizuale care nu sunt vizibile în testele unitare: margini incorecte, suprapunerea elementelor, culori greșite.

De ce sunt necesare testele screenshot dacă există testele golden — testele golden verifică componentele izolat: un buton, o carte, un text. Testele screenshot verifică întregul ecran într-un mediu cât mai apropiat de producție: navigare reală, date reale (sau mock-uri cât mai realiste), fonturi de sistem reale, bară de stare reală. Doar un test screenshot va arăta că butonul se suprapune peste alt element pe un dispozitiv real.

Valoarea de afaceri a testelor screenshot

Valoarea de afaceri — conform datelor Google (2023), erorile vizuale constituie 15-25% din toate erorile aplicațiilor mobile. Testele screenshot automatizează verificarea calității vizuale, care anterior era făcută manual de inginerii QA. Un test screenshot înlocuiește 5-10 minute de testare manuală a unui ecran. Pentru o aplicație cu 50 de ecrane, economie: 4-8 ore-om pentru o singură rulare de regresie. Testele screenshot se amortizează în 2-3 cicluri de lansare.

Screenshot Test vs Golden Test: compararea abordărilor

Testele golden sunt mai rapide și mai simple: randarea componentei în buffer-ul off-screen durează milisecunde, nu necesită dispozitiv, sunt stabile în CI. Testele screenshot sunt mai realiste: capturează ecranul real cu elemente de sistem, suportă animații și navigare, funcționează pe dispozitive reale. Alegerea depinde de scop: feedback rapid pentru dezvoltator (golden) sau realism maxim înainte de lansare (screenshot).

Strategia de acoperire: golden + screenshot

Golden + Screenshot — utilizați teste golden pentru fiecare componentă UI din biblioteca de componente (Design System). 80% din regresiile vizuale sunt prinse la nivel de componentă. Testele screenshot — pentru căi critice de utilizator: onboarding, autentificare, flux de plată, coș. 20% din regresiile legate de integrarea componentelor pe ecranul real sunt prinse doar de testele screenshot. La IT Sectr folosim raportul 80/20: 400 golden + 100 screenshot.

Când testul screenshot nu este necesar — dacă ecranul constă din conținut static fără interactivitate, testul golden al componentei oferă același nivel de verificare la un cost mai mic. Dacă ecranul se schimbă dinamic (flux, chat), testul screenshot necesită o configurare complexă a datelor și timp de așteptare. în astfel de cazuri, utilizați screenshot pentru starea de bază (listă goală, încărcare) și golden pentru carduri individuale în listă.

UI Automator și Firebase Test Lab pentru Android

UI Automator — framework Android pentru testarea UI inter-aplicații. Permite realizarea de capturi de ecran prin UiDevice.takeScreenshot(). Spre deosebire de Espresso (funcționează în interiorul unei singure aplicații), UI Automator poate interacționa cu dialogurile de sistem (permisiuni, notificări) și alte aplicații. Test screenshot pe UI Automator: deschideți aplicația, așteptați încărcarea, faceți o captură de ecran, comparați cu referința.

class LoginScreenScreenshotTest {

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

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

        // Așteptăm încărcarea ecranului
        IdlingRegistry.getInstance().waitForIdle()

        // Facem captură de ecran
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Comparăm cu referința
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab — serviciu Google Cloud pentru rularea testelor instrumentale pe sute de dispozitive reale în paralel. Testele screenshot pe Firebase Test Lab capturează capturi de ecran pe diferite dispozitive (Pixel 7, Galaxy S24, Xiaomi 14) și le compară cu referințele. Avantaj: un singur test verifică UI pe 20 de dispozitive în 10-15 minute. Dezavantaj: costul ($1-5 per test pe 20 de dispozitive). Firebase Test Lab se integrează cu CI prin gcloud CLI sau pluginul Gradle.

Shot: biblioteca pentru simplificarea testelor screenshot

Shot — bibliotecă pentru testarea screenshot pe Android, care facilitează crearea și compararea capturilor de ecran. Shot funcționează pe bază de Espresso și UI Automator, adăugând gestionarea golden (creare, actualizare, ștergere), comparare cu prag (pixeli sau procente) și generarea raportului HTML. Shot este potrivit pentru proiectele care doresc să implementeze rapid testarea screenshot fără a-și scrie propria infrastructură de comparare a imaginilor.

XCUITest și Xcode Cloud pentru iOS

XCUITest — framework Apple pentru testarea UI a aplicațiilor iOS, iPadOS și tvOS. Testele screenshot pe XCUITest utilizează XCUIScreen.main.screenshot() pentru capturarea ecranului și XCAttachment pentru salvarea capturii de ecran. XCUITest simulează acțiunile utilizatorului: tap, swipe, typeText și face capturi de ecran după fiecare pas. În Xcode 16+ a fost adăugat suportul încorporat pentru compararea capturilor de ecran cu referințele prin XCTAttachment.

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)

        // Facem captură de ecran
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Comparare cu referința (necesită XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud — CI cloud de la Apple pentru construirea și testarea aplicațiilor iOS. Xcode Cloud suportă rularea testelor XCUITest pe simulatoare. Testele screenshot pot fi rulate pe mai multe simulatoare în paralel (iPhone 15, iPhone 15 Pro Max, iPad Pro). Rezultate: XCResult Bundle cu atașamente. Xcode Cloud nu este încorporat în GitHub/GitLab — utilizați Xcode Cloud Webhooks pentru integrare. Alternativă: GitHub Actions cu macos-14 și xcodebuild.

Framework-uri de comparare — iOSSnapshotTestCase (Uber) funcționează și pentru teste screenshot dacă este rulat pe simulator. SwiftSnapshotTesting (pointfree) este mai orientat spre testele golden ale componentelor. Pentru testele screenshot pe iOS, utilizați instrumentele încorporate XCUITest + XCTAttachment + un ImageComparator personalizat (Pixelmator sau AImage). în CI utilizați simulatorul — pe dispozitive reale, testele screenshot funcționează doar prin Device Farm (AWS Device Farm).

Procesul de automatizare a testelor screenshot în CI

Gestionarea baseline — capturile de ecran de referință sunt stocate în depozit (Git LFS) sau în S3. Fiecare captură de ecran este denumită după șablonul: {testName}_{device}_{orientation}_{locale}.png. Exemplu: loginScreenPixel7PortraitRu.png. La adăugarea unui nou dispozitiv sau locale, se creează un nou baseline. La modificarea UI, baseline-urile vechi sunt înlocuite cu altele noi după code review. Baseline face parte din baza de cod, la fel ca sursele testelor.

CI Pipeline — (1) Construirea aplicației. (2) Rularea testelor screenshot pe emulatoare/simulatoare. (3) Compararea capturilor de ecran cu baseline. (4) În caz de nepotrivire — generarea imaginii diff. (5) Încărcarea artefactelor diff (actual, expected, diff — trei fișiere). (6) Publicarea raportului HTML cu tabelul de rezultate. (7) Dacă pragul este depășit — testul eșuează. (8) Reviewer-ul examinează artefactele diff și ia o decizie: aprobare (actualizare baseline) sau respingere (corectare cod).

Prag și toleranță — compararea absolută pixel cu pixel este prea strictă. Utilizați SSIM (Structural Similarity Index) sau MSE (Mean Squared Error). SSIM 0.98 = 98% similaritate structurală — un prag bun. Pentru diferite ecrane pot fi necesare praguri diferite: tema întunecată (mai mult negru — precizie mai mare), gradientți (mai mult zgomot — precizie mai mică). Configurați pragul per-test prin parametru: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulator — testele pe dispozitive reale (Firebase Test Lab, AWS Device Farm) oferă realism maxim, dar sunt lente și costisitoare. Testele pe simulatoare/emulatoare — rapide și gratuite, dar nu arată caracteristicile dispozitivelor reale (GPU diferite, redarea culorilor ecranului, densitatea pixelilor). Strategie: simulator pentru verificarea pre-merge (5 minute), Device Farm pentru nightly (30 minute, 20 dispozitive). La IT Sectr folosim Firebase Test Lab pentru rulări nocturne pe top-10 dispozitive Android.