Screenshot Test: τι είναι, τύποι και πώς λειτουργεί στον έλεγχο

Τι είναι το Screenshot Test και γιατί χρειάζεται;

Screenshot Test — είναι ένας end-to-end έλεγχος της διεπαφής χρήστη, κατά τον οποίο το test ανοίγει την οθόνη της εφαρμογής, εκτελεί ενέργειες (πατήματα, εισαγωγή κειμένου, κύλιση) και λαμβάνει ένα σκρινστ της κατάστασης που προέκυψε. Το σκρινστ συγκρίνεται με μια αναφορά (baseline) που αποθηκεύεται στο αποθετήριο. Αν τα σκρινστ διαφέρουν — το test αποτυγχάνει. Τα screenshot test εντοπίζουν οπτικές υποχωρήσεις που δεν είναι ορατές στις μοναδικές δοκιμές: λανθασμένα περιθώρια, επικαλύψεις στοιχείων, λανθασμένα χρώματα.

Γιατί χρειάζονται τα screenshot test όταν υπάρχουν τα golden test — τα golden test ελέγχουν τα στοιχεία μονωμένα: ένα κουμπί, μία κάρτα, ένα κείμενο. Τα screenshot test ελέγχουν ολόκληρη την οθόνη σε ένα περιβάλλον όσο το δυνατόν πιο κοντά στην παραγωγή: πραγματική πλοήγηση, πραγματικά δεδομένα (ή όσο το δυνατόν πιο ρεαλιστικά mock), πραγματικές γραμματοσειρές συστήματος, πραγματική γραμμή κατάστασης. Μόνο ένα screenshot test θα δείξει ότι το κουμπί επικαλύπτει ένα άλλο στοιχείο σε μια πραγματική συσκευή.

Επιχειρηματική αξία των screenshot test

Επιχειρηματική αξία — σύμφωνα με τα δεδομένα της Google (2023), τα οπτικά σφάλματα αποτελούν το 15-25% όλων των σφαλμάτων σε εφαρμογές κινητών. Τα screenshot test αυτοματοποιούν τον έλεγχο οπτικής ποιότητας, ο οποίος προηγουμένως γινόταν με χειρότερνα τρόπο από μηχανικούς QA. Ένα screenshot test αντικαθιστά 5-10 λεπτά χειρονακτικού ελέγχου μίας οθόνης. Για μια εφαρμογή με 50 οθόνες, εξοικονόμηση: 4-8 ανθρωποώρες ανά εκτέλεση υποχώρησης. Τα screenshot test αποσβήνονται σε 2-3 κύκλους έκδοσης.

Screenshot Test vs Golden Test: σύγκριση προσεγγίσεων

Τα golden test είναι πιο γρήγορα και απλά: η απόδοση του στοιχείου σε off-screen buffer διαρκεί χιλιοστά δευτερολέπτου, δεν απαιτεί συσκευή, είναι σταθερά στο CI. Τα screenshot test είναι πιο ρεαλιστικά: λαμβάνουν πραγματική οθόνη με συστημικά στοιχεία, υποστηρίζουν κινήσεις και πλοήγηση, λειτουργούν σε πραγματικές συσκευές. Η επιλογή εξαρτάται από τον σκοπό: γρήγορη ανατροφοδότηση για τον προγραμματιστή (golden) ή μέγιστη ρεαλισμικότητα πριν την έκδοση (screenshot).

Στρατηγική κάλυψης: golden + screenshot

Golden + Screenshot — χρησιμοποιείτε golden test για κάθε στοιχείο UI στη βιβλιοθήκη στοιχείων (Design System). Το 80% των οπτικών υποχωρήσεων εντοπίζονται σε επίπεδο στοιχείου. Τα screenshot test — για κρίσιμες διαδρομές χρήστη: onboarding, σύνδεση, ροή πληρωμής, καλάθι. Το 20% των υποχωρήσεων που σχετίζονται με την ενσωμάτωση στοιχείων σε πραγματική οθόνη εντοπίζονται μόνο από τα screenshot test. Στο IT Sectr χρησιμοποιούμε την αναλογία 80/20: 400 golden + 100 screenshot.

Πότε δεν χρειάζεται screenshot test — αν η οθόνη αποτελείται από στατικό περιεχόμενο χωρίς διαδραστικότητα, το golden test του στοιχείου παρέχει το ίδιο επίπεδο ελέγχου με χαμηλότερο κόστος. Αν η οθόνη αλλάζει δυναμικά (feed, chat), το screenshot test απαιτεί πολύπλοκη παραμετροποίηση δεδομένων και χρόνο αναμονής. Σε τέτοιες περιπτώσεις, χρησιμοποιείτε screenshot για τη βασική κατάσταση (κενή λίστα, φόρτωση) και golden για μμονωμένες κάρτες στη λίστα.

UI Automator και Firebase Test Lab για Android

UI Automator — πλαίσιο Android για διαφυλεύς δοκιμές UI. Επιτρέπει τη λήψη σκρινστ μέσω UiDevice.takeScreenshot(). Σε αντίθεση με το Espresso (λειτουργεί μέσα σε μία εφαρμογή), το UI Automator μπορεί να αλληλεπιδρά με συστημικά παράθυρα (άδειες, ειδοποιήσεις) και άλλες εφαρμογές. Screenshot test σε UI Automator: ανοίξτε την εφαρμογή, περιμένετε τη φόρτωση, λάβτε ένα σκρινστ, συγκρίνετε με την αναφορά.

class LoginScreenScreenshotTest {

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

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

        // Περιμένουμε τη φόρτωση της οθόνης
        IdlingRegistry.getInstance().waitForIdle()

        // Λαμβάνουμε στιγμιότυπο οθόνης
        val screenshot = device.takeScreenshot()
        val golden = loadGolden("login_default.png")

        // Συγκρίνουμε με το πρότυπο
        val diff = ImageComparator.compare(screenshot, golden)
        assertTrue(diff.similarity > 0.98)
    }
}

Firebase Test Lab — υπηρεσία Google Cloud για την παράλληλη εκτέλεση δοκιμών σε εκατοντάδες πραγματικές συσκευές. Τα screenshot test στο Firebase Test Lab λαμβάνουν σκρινστ σε διαφορετικές συσκευές (Pixel 7, Galaxy S24, Xiaomi 14) και τα συγκρίνουν με τις αναφορές. Πλεονέκτημα: ένα test ελέγχει το UI σε 20 συσκευές σε 10-15 λεπτά. Μειονέκτημα: κόστος ($1-5 ανά test σε 20 συσκευές). Το Firebase Test Lab ενσωματώνεται με το CI μέσω gcloud CLI ή του plugin Gradle.

Shot: βιβλιοθήκη για απλοποίηση των screenshot test

Shot — βιβλιοθήκη για screenshot testing σε Android που διευκολύνει τη δημιουργία και σύγκριση σκρινστ. Το Shot λειτουργεί πάνω από τα Espresso και UI Automator, προσθέτοντας διαχείριση golden (δημιουργία, ενημέρωση, διαγραφή), σύγκριση με κατώφλι (πικσέλ ή ποσοστά) και δημιουργία αναφοράς HTML. Το Shot είναι κατάλληλο για έργα που θέλουν να εφαρμόσουν γρήγορα το screenshot testing χωρίς να γράψουν δική τους υποδομή σύγκρισης εικόνων.

XCUITest και Xcode Cloud για iOS

XCUITest — πλαίσιο Apple για UI testing εφαρμογών iOS, iPadOS και tvOS. Τα screenshot test σε XCUITest χρησιμοποιούν XCUIScreen.main.screenshot() για λήψη οθόνης και XCAttachment για αποθήκευση σκρινστ. Το XCUITest προσομοιώνει τις ενέργειες χρήστη: tap, swipe, typeText, και λαμβάνει σκρινστ μετά από κάθε βήμα. Στο Xcode 16+ προστέθηκε ενσωματωμένη υποστήριξη για σύγκριση σκρινστ με αναφορές μέσω 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)

        // Λαμβάνουμε στιγμιότυπο οθόνης
        let screenshot = app.screenshot()
        let attachment = XCTAttachment(screenshot: screenshot)
        attachment.name = "Login-Screen-Initial"
        attachment.lifetime = .keepAlways
        add(attachment)

        // Σύγκριση με το πρότυπο (απαιτεί XCTAttachment + golden)
        assertScreenshot(
            screenshot: screenshot,
            goldenName: "login_initial_state"
        )
    }
}

Xcode Cloud — cloud CI από την Apple για την κατασκευή και δοκιμή εφαρμογών iOS. Το Xcode Cloud υποστηρίζει την εκτέλεση δοκιμών XCUITest σε προσομοιωτές. Τα screenshot test μπορούν να εκτελούνται σε πολλά προσομοιωτές παράλληλα (iPhone 15, iPhone 15 Pro Max, iPad Pro). Αποτελέσματα: XCResult Bundle με συνημμένα. Το Xcode Cloud δεν είναι ενσωματωμένο στο GitHub/GitLab — χρησιμοποιείτε Xcode Cloud Webhooks για ενσωμάτωση. Εναλλακτική: GitHub Actions με macos-14 και xcodebuild.

Πλαίσια σύγκρισης — το iOSSnapshotTestCase (Uber) λειτουργεί και για screenshot test αν εκτελείται σε προσομοιωτή. Το SwiftSnapshotTesting (pointfree) είναι περισσότερο οριενταρισμένο προς τα golden test στοιχείων. Για screenshot test σε iOS χρησιμοποιείτε τα ενσωματωμένα εργαλεία XCUITest + XCTAttachment + προσαρμοσμένο ImageComparator (Pixelmator ή AImage). Στο CI χρησιμοποιείτε προσομοιωτή — σε πραγματικές συσκευές τα screenshot test λειτουργούν μόνο μέσω Device Farm (AWS Device Farm).

Διαδικασία αυτοματοποίησης screenshot test στο CI

Διαχείριση baseline — οι εικόνες αναφοράς αποθηκεύονται στο αποθετήριο (Git LFS) ή στο S3. Κάθε σκρινστ ονομάζεται σύμφωνα με το πρότυπο: {testName}_{device}_{orientation}_{locale}.png. Παράδειγμα: loginScreenPixel7PortraitRu.png. Κατά την προσθήκη μιας νέας συσκευής ή locale, δημιουργείται ένα νέο baseline. Κατά την αλλαγή UI, τα παλιά baseline αντικαθίστανται από νέα μετά από code review. Το baseline αποτελεί μέρος της βάσης κώδικα, όπως και οι πηγές των δοκιμών.

CI Pipeline — (1) Κατασκευή εφαρμογής. (2) Εκτέλεση screenshot test σε εμυλαιοτές/προσομοιωτές. (3) Σύγκριση σκρινστ με baseline. (4) Σε περίπτωση ασυμφωνίας — δημιουργία diff εικόνας. (5) Μεταφόρτωση diff τεχνημάτων (actual, expected, diff — τρία αρχεία). (6) Δημοσίευση αναφοράς HTML με πίνακα αποτελεσμάτων. (7) Αν το κατώφλι ξεπεραστεί — το test αποτυγχάνει. (8) Ο αξιολογητής εξετάζει τα diff τεχνήματα και λαμβάνει απόφαση: έγκριση (ενημέρωση baseline) ή απόρριψη (διόρθωση κώδικα).

Κατώφλι και ανοχή — η απόλυτη σύγκριση pixel προς pixel είναι υπερβολική. Χρησιμοποιείτε SSIM (Structural Similarity Index) ή MSE (Mean Squared Error). SSIM 0.98 = 98% δομική ομοιότητα — ένα καλό κατώφλι. Για διαφορετικές οθόνες μπορεί να χρειαστούν διαφορετικά κατώφλια: σκουρό θέμα (περισσότερο μαύρο — υψηλότερη ακρίβεια), διαβαθμίσεις (περισσότερος θόρυβος — χαμηλότερη ακρίβεια). Ρυθμίζετε το κατώφλι per-test μέσω παραμέτρου: @ScreenshotTest(threshold = 0.99).

Device Farm vs Προσομοιωτής — οι δοκιμές σε πραγματικές συσκευές (Firebase Test Lab, AWS Device Farm) παρέχουν μέγιστη ρεαλισμικότητα, αλλά είναι αργές και πληρώνονται. Οι δοκιμές σε προσομοιωτές/εμυλαιοτές — γρήγορες και δωρεάν, αλλά δεν εμφανίζουν τα χαρακτηριστικά πραγματικών συσκευών (διαφορετικές GPU, απόδοση χρωμάτων οθόνης, πυκνότητα pixel). Στρατηγική: προσομοιωτής για έλεγχο pre-merge (5 λεπτά), Device Farm για nightly (30 λεπτά, 20 συσκευές). Στο IT Sectr χρησιμοποιούμε Firebase Test Lab για νυχτερινές εκτελέσεις στις κορυφαίες 10 συσκευές Android.