Screenshot Test: ano ito, mga uri at paano ito gumagana sa pagsubok

Ano ang Screenshot Test at bakit ito kailangan?

Screenshot Test — ito ay end-to-end na pagsubok ng user interface, kung saan binubuksan ng test ang screen ng application, nagsasagawa ng mga aksyon (tap, pagpasok ng text, scroll) at kumukuha ng screenshot ng nakuhang estado. Ang screenshot ay inihahambing sa reference (baseline) na nakaimbak sa repository. Kung magkaiba ang mga screenshot — babagsak ang test. Ang screenshot test ay nakakatuklas ng visual regression na hindi nakikita sa unit test: maling margin, overlapping na elemento, maling kulay.

Bakit kailangan ang screenshot test kung may golden test — ang golden test ay sumusuri ng mga component nang nakahiwalay: isang button, isang card, isang text. Ang screenshot test ay sumusuri ng buong screen sa kapaligirang mas malapit hangga't maaari sa produksyon: tunay na nabigasyon, tunay na data (o pinaka-makatotohanang mock), tunay na system font, tunay na status bar. Tanging screenshot test ang magpapakita na ang button ay nag-o-overlap sa ibang elemento sa isang tunay na device.

Business value ng screenshot test

Business value — ayon sa data ng Google (2023), ang visual bug ay bumubuo ng 15-25% ng lahat ng bug sa mobile application. Ang screenshot test ay nag-a-automate ng pagsusuri ng visual na kalidad na dati ay ginagawa nang manu-mano ng QA engineers. Isang screenshot test ang pumapalit sa 5-10 minuto ng manu-manong pagsubok ng isang screen. Para sa application na may 50 screen, pagtitipid: 4-8 oras-tao para sa isang regression run. Ang screenshot test ay magbabayad sa loob ng 2-3 release cycle.

Screenshot Test vs Golden Test: paghahambing ng mga approach

Golden test ay mas mabilis at mas simple: ang pag-render ng component sa off-screen buffer ay tumatagal ng millisecond, hindi nangangailangan ng device, stable sa CI. Ang screenshot test ay mas makatotohanan: kumukuha ng tunay na screen na may mga system element, sumusuporta sa mga animation at nabigasyon, gumagana sa mga tunay na device. Ang pagpili ay depende sa layunin: mabilis na feedback para sa developer (golden) o maximum realism bago ang release (screenshot).

Istratehiya ng coverage: golden + screenshot

Golden + Screenshot — gumamit ng golden test para sa bawat UI component sa library ng component (Design System). 80% ng visual regression ay nahuhuli sa antas ng component. Screenshot test — para sa kritikal na path ng user: onboarding, login, payment flow, cart. 20% ng regression na may kaugnayan sa integration ng component sa tunay na screen ay nahuhuli lamang ng screenshot test. Sa IT Sectr ginagamit namin ang ratio na 80/20: 400 golden + 100 screenshot.

Kailan hindi kailangan ang screenshot test — kung ang screen ay binubuo ng static na content nang walang interaktibidad, ang golden test ng component ay nagbibigay ng parehong antas ng pagsusuri sa mas mababang halaga. Kung ang screen ay nagbabago nang dynamic (feed, chat), ang screenshot test ay nangangailangan ng komplikadong configuration ng data at oras ng paghihintay. Sa ganitong mga kaso, gumamit ng screenshot para sa base state (walang laman na listahan, naglo-load) at golden para sa mga indibidwal na card sa listahan.

UI Automator at Firebase Test Lab para sa Android

UI Automator — Android framework para sa cross-application UI testing. Nagbibigay-daan sa pagkuha ng screenshot sa pamamagitan ng UiDevice.takeScreenshot(). Hindi tulad ng Espresso (gumagana sa loob ng isang application), ang UI Automator ay maaaring makipag-ugnayan sa system dialog (permiso, notification) at iba pang application. Screenshot test sa UI Automator: buksan ang application, maghintay sa pag-load, kumuha ng screenshot, ihambing sa reference.

class LoginScreenScreenshotTest {

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

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

        // Hintayin natin ang pag-load ng screen
        IdlingRegistry.getInstance().waitForIdle()

        // Kumuha ng screenshot
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Ikumpara sa reference
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab — serbisyo ng Google Cloud para sa pagpapatakbo ng instrumental test sa daan-daang tunay na device nang magkakasabay. Ang screenshot test sa Firebase Test Lab ay kumukuha ng screenshot sa iba't ibang device (Pixel 7, Galaxy S24, Xiaomi 14) at inihahambing ang mga ito sa reference. Bentahe: isang test sumusuri ng UI sa 20 device sa loob ng 10-15 minuto. Disbentahe: gastos ($1-5 bawat test sa 20 device). Ang Firebase Test Lab ay nagsasama sa CI sa pamamagitan ng gcloud CLI o Gradle plugin.

Shot: library para sa pagpapasimple ng screenshot test

Shot — library para sa screenshot testing sa Android na nagpapadali sa paggawa at paghahambing ng mga screenshot. Gumagana ang Shot sa ibabaw ng Espresso at UI Automator, nagdaragdag ng golden management (paglikha, pag-update, pagtanggal), paghahambing sa threshold (pixel o porsyento) at pagbuo ng HTML report. Ang Shot ay angkop para sa mga proyektong nais mabilis na magpatupad ng screenshot testing nang hindi sumusulat ng sariling imprastraktura sa paghahambing ng larawan.

XCUITest at Xcode Cloud para sa iOS

XCUITest — Apple framework para sa UI testing ng iOS, iPadOS at tvOS application. Ang screenshot test sa XCUITest ay gumagamit ng XCUIScreen.main.screenshot() para kumuha ng screen at XCAttachment para i-save ang screenshot. Ginagaya ng XCUITest ang mga aksyon ng user: tap, swipe, typeText, at kumukuha ng screenshot pagkatapos ng bawat hakbang. Sa Xcode 16+ idinagdag ang built-in na suporta para sa paghahambing ng screenshot sa reference sa pamamagitan ng 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)

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

        // Paghahambing sa reference (nangangailangan ng XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud — cloud CI mula sa Apple para sa pagbuo at pagsubok ng iOS application. Sinusuportahan ng Xcode Cloud ang pagpapatakbo ng XCUITest sa mga simulator. Ang screenshot test ay maaaring patakbuhin sa maraming simulator nang magkakasabay (iPhone 15, iPhone 15 Pro Max, iPad Pro). Resulta: XCResult Bundle na may mga attachment. Ang Xcode Cloud ay hindi naka-integrate sa GitHub/GitLab — gamitin ang Xcode Cloud Webhooks para sa integration. Alternatibo: GitHub Actions na may macos-14 at xcodebuild.

Comparison frameworks — ang iOSSnapshotTestCase (Uber) ay gumagana rin para sa screenshot test kung tatakbuhin sa simulator. Ang SwiftSnapshotTesting (pointfree) ay mas nakatuon sa golden test ng component. Para sa screenshot test sa iOS gamitin ang built-in na tool na XCUITest + XCTAttachment + custom ImageComparator (Pixelmator o AImage). Sa CI gamitin ang simulator — sa tunay na device, ang screenshot test ay gumagana lamang sa pamamagitan ng Device Farm (AWS Device Farm).

Proseso ng automation ng screenshot test sa CI

Pamamahala ng baseline — ang reference screenshot ay iniimbak sa repository (Git LFS) o sa S3. Bawat screenshot ay pinangalanan ayon sa template: {testName}_{device}_{orientation}_{locale}.png. Halimbawa: loginScreenPixel7PortraitRu.png. Sa pagdaragdag ng bagong device o locale, nalikha ang bagong baseline. Sa pagbabago ng UI, ang lumang baseline ay pinapalitan ng bago pagkatapos ng code review. Ang baseline ay bahagi ng codebase, tulad ng source ng test.

CI Pipeline — (1) Pagbuo ng application. (2) Pagpapatakbo ng screenshot test sa emulator/simulator. (3) Paghahambing ng screenshot sa baseline. (4) Kung hindi tugma — pagbuo ng diff image. (5) Pag-upload ng diff artifact (actual, expected, diff — tatlong file). (6) Pag-publish ng HTML report na may table ng resulta. (7) Kung nalagpasan ang threshold — babagsak ang test. (8) Sinusuri ng reviewer ang diff artifact at gumagawa ng desisyon: aprubahan (i-update ang baseline) o tanggihan (ayusin ang code).

Threshold at tolerance — ang absolute pixel-by-pixel na paghahambing ay masyadong mahigpit. Gumamit ng SSIM (Structural Similarity Index) o MSE (Mean Squared Error). SSIM 0.98 = 98% structural similarity — mabuting threshold. Para sa iba't ibang screen maaaring kailanganin ang iba't ibang threshold: dark theme (mas maraming itim — mas mataas na accuracy), gradient (mas maraming noise — mas mababang accuracy). I-configure ang threshold per-test sa pamamagitan ng parameter: @ScreenshotTest(threshold = 0.99).

Device Farm vs Simulator — test sa tunay na device (Firebase Test Lab, AWS Device Farm) ay nagbibigay ng maximum realism, ngunit mabagal at may bayad. Test sa simulator/emulator — mabilis at libre, ngunit hindi nagpapakita ng tunay na device characteristics (iba't ibang GPU, color reproduction ng display, pixel density). Istratehiya: simulator para sa pre-merge check (5 minuto), Device Farm para sa nightly (30 minuto, 20 device). Sa IT Sectr ginagamit namin ang Firebase Test Lab para sa nightly run sa top-10 Android device.