Screenshot Test: ما هو، أنواعه وكيف يعمل في الاختبارات

ما هو اختبار لقطة الشاشة ولماذا هو مطلوب؟

اختبار لقطة الشاشة هو اختبار شامل لواجهة المستخدم حيث يفتح الاختبار شاشة التطبيق، وينفذ إجراءات (نقر، إدخال نص، تمرير) ويلتقط لقطة شاشة للحالة الناتجة. تتم مقارنة لقطة الشاشة مع مرجع (baseline) مخزن في المستودع. إذا اختلفت لقطات الشاشة — يفشل الاختبار. تكتشف اختبارات لقطة الشاشة الانحدارات البصرية التي لا تستطيع اختبارات الوحدة رؤيتها: هوامش غير صحيحة، عناصر متداخلة، ألوان خاطئة.

لماذا نحتاج اختبارات لقطة الشاشة إذا كان لدينا اختبارات golden — تفحص اختبارات golden المكونات بشكل منفصل: زر واحد، بطاقة واحدة، نص واحد. تفحص اختبارات لقطة الشاشة شاشة كاملة في بيئة أقرب ما يكون إلى الإنتاج: تنقل حقيقي، بيانات حقيقية (أو محاكاة واقعية قدر الإمكان)، خطوط نظام حقيقية، شريط حالة حقيقي. فقط اختبار لقطة الشاشة سيظهر أن زراً يتداخل مع عنصر آخر على جهاز حقيقي.

القيمة التجارية لاختبارات لقطة الشاشة

القيمة التجارية — وفقاً لـ Google (2023)، تشكل الأخطاء البصرية 15-25% من جميع أخطاء التطبيقات المحمولة. تؤتمت اختبارات لقطة الشاشة فحص الجودة البصرية الذي كان يتم يدوياً بواسطة مهندسي ضمان الجودة. اختبار لقطة شاشة واحد يحل محل 5-10 دقائق من الاختبار اليدوي لشاشة واحدة. لتطبيق يحتوي على 50 شاشة، التوفير: 4-8 ساعات عمل لكل تشغيل اختبار انحداري. تسترد اختبارات لقطة الشاشة تكلفتها في 2-3 دورات إصدار.

مقارنة اختبار لقطة الشاشة واختبار golden: مقارنة الأساليب

اختبارات golden أسرع وأبسط: عرض المكون في مخزن خارج الشاشة يستغرق ميلي ثانية، لا يتطلب جهازاً، ومستقر على CI. اختبارات لقطة الشاشة أكثر واقعية: تلتقط شاشة حقيقية مع عناصر النظام، تدعم الرسوم المتحركة والتنقل، وتعمل على أجهزة حقيقية. يعتمد الاختيار على الهدف: ردود فعل سريعة للمطور (golden) أو أقصى واقعية قبل الإصدار (لقطة شاشة).

استراتيجية التغطية: golden + لقطة شاشة

Golden + Screenshot — استخدم اختبارات golden لكل مكون واجهة مستخدم في مكتبة المكونات (Design System). 80% من الانحدارات البصرية تُكتشف على مستوى المكونات. اختبارات لقطة الشاشة — للمسارات الحرجة للمستخدم: الإعداد، تسجيل الدخول، تدفق الدفع، سلة التسوق. 20% من الانحدارات المتعلقة بتكامل المكونات على شاشة حقيقية تُكتشف فقط بواسطة اختبارات لقطة الشاشة. في IT Sectr نستخدم نسبة 80/20: 400 golden + 100 لقطة شاشة.

متى لا تكون اختبارات لقطة الشاشة ضرورية — إذا كانت الشاشة تتكون من محتوى ثابت دون تفاعل، فإن اختبار golden للمكون يعطي نفس مستوى الفحص بتكلفة أقل. إذا تغيرت الشاشة ديناميكياً (تغذية، محادثة)، يتطلب اختبار لقطة الشاشة إعداد بيانات معقد وأوقات انتظار. في هذه الحالات، استخدم لقطة شاشة للحالة الأساسية (قائمة فارغة، تحميل) وgolden للبطاقات الفردية في القائمة.

UI Automator وFirebase Test Lab لنظام Android

UI Automator هو إطار عمل Android لاختبار واجهة المستخدم عبر التطبيقات. يسمح بالتقاط لقطات شاشة عبر UiDevice.takeScreenshot(). على عكس Espresso (يعمل داخل تطبيق واحد)، يمكن لـ UI Automator التفاعل مع حوارات النظام (الأذونات، الإشعارات) والتطبيقات الأخرى. اختبار لقطة شاشة على 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 لتشغيل الاختبارات الآلية على مئات الأجهزة الحقيقية بالتوازي. تلتقط اختبارات لقطة الشاشة على Firebase Test Lab لقطات شاشة على أجهزة مختلفة (Pixel 7، Galaxy S24، Xiaomi 14) وتقارنها بالمراجع. الميزة: اختبار واحد يفحص واجهة المستخدم على 20 جهازاً في 10-15 دقيقة. العيب: التكلفة (1-5 دولارات لكل اختبار على 20 جهازاً). يتكامل Firebase Test Lab مع CI عبر gcloud CLI أو إضافة Gradle.

Shot: مكتبة لتبسيط اختبارات لقطة الشاشة

Shot هي مكتبة لاختبار لقطة الشاشة على Android تسهل إنشاء ومقارنة لقطات الشاشة. تعمل Shot فوق Espresso وUI Automator، وتضيف إدارة golden (إنشاء، تحديث، حذف)، ومقارنة مع حد (بكسل أو نسب مئوية) وتوليد تقارير HTML. Shot مناسبة للمشاريع التي تريد تنفيذ اختبار لقطة الشاشة بسرعة دون كتابة بنيتها التحتية الخاصة لمقارنة الصور.

XCUITest وXcode Cloud لنظام iOS

XCUITest هو إطار عمل Apple لاختبار واجهة المستخدم لتطبيقات iOS وiPadOS وtvOS. تستخدم اختبارات لقطة الشاشة على XCUITest XCUIScreen.main.screenshot() لالتقاط الشاشة وXCAttachment لحفظ لقطات الشاشة. يحاكي XCUITest إجراءات المستخدم: النقر، السحب، كتابة النص، ويلتقط لقطات شاشة بعد كل خطوة. في 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 هو CI سحابي من Apple لبناء واختبار تطبيقات iOS. يدعم Xcode Cloud تشغيل اختبارات XCUITest على المحاكيات. يمكن تشغيل اختبارات لقطة الشاشة على محاكيات متعددة بالتوازي (iPhone 15، iPhone 15 Pro Max، iPad Pro). النتائج: XCResult Bundle مع المرفقات. Xcode Cloud غير مدمج في GitHub/GitLab — استخدم Xcode Cloud Webhooks للتكامل. البديل: GitHub Actions مع macos-14 وxcodebuild.

أطر المقارنة — iOSSnapshotTestCase (Uber) يعمل أيضاً لاختبارات لقطة الشاشة إذا تم تشغيله على محاكي. SwiftSnapshotTesting (pointfree) موجه أكثر لاختبارات golden للمكونات. لاختبارات لقطة الشاشة على iOS، استخدم الأدوات المدمجة لـ XCUITest + XCTAttachment + ImageComparator مخصص (Pixelmator أو AImage). على CI استخدم محاكي — على الأجهزة الحقيقية تعمل اختبارات لقطة الشاشة فقط عبر Device Farm (AWS Device Farm).

عملية أتمتة اختبارات لقطة الشاشة في CI

إدارة المراجع — تُخزن لقطات الشاشة المرجعية في المستودع (Git LFS) أو في S3. تُسمى كل لقطة شاشة وفق القالب: {testName}_{device}_{orientation}_{locale}.png. مثال: loginScreenPixel7PortraitRu.png. عند إضافة جهاز أو لغة جديدة، يتم إنشاء مرجع جديد. عند تغيير واجهة المستخدم، تُستبدل المراجع القديمة بأخرى جديدة بعد مراجعة الكود. المرجع هو جزء من قاعدة الكود، مثل مصادر الاختبارات.

خط أنابيب CI — (1) بناء التطبيق. (2) تشغيل اختبارات لقطة الشاشة على المحاكيات. (3) مقارنة لقطات الشاشة مع المراجع. (4) عند عدم التطابق — توليد صورة الفرق. (5) رفع مخرجات الفرق (فعلي، متوقع، فرق — ثلاثة ملفات). (6) نشر تقرير HTML مع جدول النتائج. (7) إذا تجاوز الحد — يفشل الاختبار. (8) يراجع المراجع مخرجات الفرق ويتخذ قراراً: موافقة (تحديث المرجع) أو رفض (إصلاح الكود).

الحد والتسامح — المقارنة المطلقة بكسل بكسل صارمة جداً. استخدم SSIM (مؤشر التشابه الهيكلي) أو MSE (متوسط مربع الخطأ). SSIM 0.98 = 98% تشابهاً هيكلياً — حد جيد. قد تتطلب الشاشات المختلفة حدوداً مختلفة: السمة الداكنة (أسود أكثر — دقة أعلى)، التدرجات (ضوضاء أكثر — دقة أقل). اضبط الحد لكل اختبار عبر المعامل: @ScreenshotTest(threshold = 0.99).

Device Farm مقابل محاكي — الاختبارات على الأجهزة الحقيقية (Firebase Test Lab، AWS Device Farm) توفر أقصى واقعية لكنها بطيئة ومدفوعة. الاختبارات على المحاكيات سريعة ومجانية لكنها لا تظهر خصائص الأجهزة الحقيقية (GPU مختلفة، إعادة إنتاج الألوان للشاشة، كثافة البكسل). الاستراتيجية: محاكي للفحص قبل الدمج (5 دقائق)، Device Farm للاختبارات الليلية (30 دقيقة، 20 جهازاً). في IT Sectr نستخدم Firebase Test Lab للتشغيل الليلي على أفضل 10 أجهزة Android.