Screenshot Test: mi ez, típusok és hogyan működik a tesztelésben

Mi az a Screenshot Test és miért van rá szükség?

Screenshot Test — a felhasználói felület end-to-end tesztelése, ahol a teszt megnyitja az alkalmazás képernyőjét, műveleteket végez (érintés, szövegbevitel, görgetés) és képernyőképet készít a kapott állapotról. A képernyőképet összehasonlítja a repozitóriumban tárolt referenciával (baseline). Ha a képernyőképek eltérnek — a teszt megbukik. A screenshot tesztek olyan vizuális regressziókat észlelnek, amelyek nem láthatók az egységtesztekben: helytelen margók, elemek átfedése, rossz színek.

Miért van szükség screenshot tesztekre, ha léteznek golden tesztek — a golden tesztek elkülönítve ellenőrzik a komponenseket: egy gomb, egy kártya, egy szöveg. A screenshot tesztek a teljes képernyőt ellenőrzik a gyártási környezethez lehető legközelebbi környezetben: valós navigáció, valós adatok (vagy a lehető legvalósághűbb mock-ok), valós rendszerbetűtípusok, valós állapotsor. Csak egy screenshot teszt fogja megmutatni, hogy a gomb átfed egy másik elemet egy valós eszközön.

A screenshot tesztek üzleti értéke

Üzleti érték — a Google (2023) adatai szerint a vizuális hibák a mobilalkalmazások összes hibájának 15-25%-át teszik ki. A screenshot tesztek automatizálják a vizuális minőség ellenőrzését, amelyet korábban a QA mérnökök végeztek kézzel. Egy screenshot teszt 5-10 perc kézi tesztelést vált ki egy képernyőn. Egy 50 képernyős alkalmazás esetén megtakarítás: 4-8 emberóra egyetlen regressziós futtatásonként. A screenshot tesztek 2-3 kiadási ciklus alatt megtérülnek.

Screenshot Test vs Golden Test: megközelítések összehasonlítása

Golden tesztek gyorsabbak és egyszerűbbek: a komponens off-screen pufferben történő megjelenítése ezredmásodpercekig tart, nem igényel eszközt, stabil a CI-ban. A screenshot tesztek valósághűbbek: valódi képernyőt rögzítenek rendszerelemekkel, támogatják az animációkat és a navigációt, valós eszközökön működnek. A választás a céltól függ: gyors visszajelzés a fejlesztő számára (golden) vagy maximális valósághűség a kiadás előtt (screenshot).

Lefedettségi stratégia: golden + screenshot

Golden + Screenshot — használjon golden teszteket minden UI komponenshez a komponenskönyvtárban (Design System). A vizuális regressziók 80%-a komponens szinten elkapható. Screenshot tesztek — a kritikus felhasználói útvonalakhoz: onboarding, bejelentkezés, fizetési folyamat, kosár. A komponensek valós képernyőn történő integrációjával kapcsolatos regressziók 20%-a csak screenshot tesztekkel fogható el. Az IT Sectr-nál a 80/20 arányt használjuk: 400 golden + 100 screenshot.

Mikor nincs szükség screenshot tesztre — ha a képernyő statikus tartalomból áll interaktivitás nélkül, a komponens golden tesztje ugyanazt az ellenőrzési szintet nyújtja alacsonyabb költségen. Ha a képernyő dinamikusan változik (feed, chat), a screenshot teszt összetett adatkonfigurációt és várakozási időt igényel. Ilyen esetekben használjon screenshot-ot az alapállapothoz (üres lista, betöltés) és golden-t az egyes kártyákhoz a listában.

UI Automator és Firebase Test Lab Androidhoz

UI Automator — Android keretrendszer alkalmazásközi UI teszteléshez. Lehetővé teszi képernyőképek készítését az UiDevice.takeScreenshot()-on keresztül. Az Espresso-val ellentétben (egy alkalmazáson belül működik) az UI Automator képes interakcióba lépni a rendszerpárbeszédekkel (engedélyek, értesítések) és más alkalmazásokkal. Screenshot teszt UI Automator-on: nyissa meg az alkalmazást, várja meg a betöltést, készítsen képernyőképet, hasonlítsa össze a referenciával.

class LoginScreenScreenshotTest {

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

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

        // Várjuk a képernyő betöltését
        IdlingRegistry.getInstance().waitForIdle()

        // Képernyőképet készítünk
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Összehasonlítjuk az etalonnal
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab — Google Cloud szolgáltatás instrumentális tesztek párhuzamos futtatására százám valós eszközön. A Firebase Test Lab screenshot tesztjei képernyőképeket készítenek különböző eszközökön (Pixel 7, Galaxy S24, Xiaomi 14) és hasonlítják őket össze a referenciákkal. Előny: egyetlen teszt 20 eszközön ellenőrzi az UI-t 10-15 perc alatt. Hátrány: költség ($1-5 tesztemként 20 eszközön). A Firebase Test Lab CI-val integrálódik a gcloud CLI-n vagy a Gradle beútpótg-on keresztül.

Shot: könyvtár a screenshot tesztek egyszerűsítésére

Shot — könyvtár screenshot teszteléshez Androidon, amely megkönnyíti a képernyőképek készítését és összehasonlítását. A Shot az Espresso és az UI Automator tetején működik, hozzáadva a golden menedzsmentet (létrehozás, frissítés, törlés), a küszöbértékkel történő összehasonlítást (pixelek vagy százalékok) és a HTML jelentés generálását. A Shot olyan projektek számára alkalmas, amelyek gyorsan szeretnék bevezetni a screenshot tesztelést anélkül, hogy saját képösszehasonlító infrastruktúrát írnának.

XCUITest és Xcode Cloud iOS-hez

XCUITest — Apple keretrendszer iOS, iPadOS és tvOS alkalmazások UI teszteléséhez. A XCUITest screenshot tesztjei az XCUIScreen.main.screenshot()-ot használják a képernyő rögzítéséhez és az XCAttachment-et a képernyőkép mentéséhez. A XCUITest szimulálja a felhasználói műveleteket: tap, swipe, typeText, és minden lépés után képernyőképet készít. Az Xcode 16+-ban beépített támogatás került hozzáadásra a képernyőképek referenciákkal való összehasonlításához az XCTAttachment-on keresztül.

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)

        // Képernyőképet készítünk
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Összehasonlítás az etalonnal (XCTAttachment + golden szükséges)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud — Apple felhőalapú CI szolgáltatása iOS alkalmazások építéséhez és teszteléséhez. Az Xcode Cloud támogatja a XCUITest tesztek futtatását szimulátorokon. A screenshot tesztek párhuzamosan futtathatók több szimulátoron (iPhone 15, iPhone 15 Pro Max, iPad Pro). Eredmények: XCResult Bundle mellékletekkel. Az Xcode Cloud nincs beépítve a GitHub/GitLab rendszerbe — használja az Xcode Cloud Webhooks-t az integrációhoz. Alternatíva: GitHub Actions macos-14-gyel és xcodebuild-del.

Összehasonlító keretrendszerek — az iOSSnapshotTestCase (Uber) screenshot tesztekhez is működik, ha szimulátoron futtatják. A SwiftSnapshotTesting (pointfree) inkább a komponensek golden tesztjeire összpontosít. iOS screenshot tesztekhez használja a beépített XCUITest + XCTAttachment + egyedi ImageComparator (Pixelmator vagy AImage) eszközöket. CI-ban használjon szimulátort — valós eszközökön a screenshot tesztek csak Device Farm-on (AWS Device Farm) keresztül működnek.

Screenshot tesztek automatizálásának folyamata CI-ben

Baseline menedzsment — a referenciaképernyőképek a repozitóriumban (Git LFS) vagy S3-ban tárolódnak. Minden képernyőkép a következő sablon szerint van elnevezve: {testName}_{device}_{orientation}_{locale}.png. Példa: loginScreenPixel7PortraitRu.png. Új eszköz vagy locale hozzáadásakor új baseline jön létre. Az UI megváltoztatásakor a régi baseline-ok újjakra cserélődnek a code review után. A baseline a kódbázis része, akárcsak a tesztforrások.

CI Pipeline — (1) Alkalmazás építése. (2) Screenshot tesztek futtatása emulátorokon/szimulátorokon. (3) Képernyőképek összehasonlítása a baseline-nal. (4) Eltérés esetén — diff kép generálása. (5) Diff artefaktumok feltöltése (actual, expected, diff — három fájl). (6) HTML jelentés közzététele eredménytáblával. (7) Ha a küszöbérték túllépésre kerül — a teszt megbukik. (8) A felülvizsgáló átnézi a diff artefaktumokat és döntést hoz: jóváhagyás (baseline frissítése) vagy elutasítás (kód javítása).

Küszöbérték és tolerancia — az abszolút pixelről pixelre történő összehasonlítás túl szigorú. Használjon SSIM (Structural Similarity Index) vagy MSE (Mean Squared Error) módszert. SSIM 0.98 = 98%-os strukturális hasonlóság — jó küszöbérték. Különböző képernyőkhöz különböző küszöbértékekre lehet szükség: sötét téma (több fekete — nagyobb pontosság), átmenetek (több zaj — kisebb pontosság). Konfigurálja a küszöbértéket tesztenként a paraméteren keresztül: @ScreenshotTest(threshold = 0.99).

Device Farm vs Szimulátor — a valós eszközökön végzett tesztek (Firebase Test Lab, AWS Device Farm) maximális valósághűséget nyújtanak, de lassúk és fizetősek. A szimulátorokon/emulátorokon végzett tesztek — gyorsak és ingyenesek, de nem mutatják a valós eszköz jellemzőit (különböző GPU-k, képernyő színmegjelenítés, pixel sűrűség). Stratégia: szimulátor a pre-merge ellenőrzéshez (5 perc), Device Farm az éjszakai futtatásokhoz (30 perc, 20 eszköz). Az IT Sectr-nál a Firebase Test Lab-et használjuk éjszakai futtatásokhoz a top-10 Android eszközön.