اختبار واجهة المستخدم في تطبيقات الجوال: ما هو، أنواعه وكيف يتم

ما هو اختبار UI؟

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

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

وفقاً لاستطلاع JetBrains Developer Ecosystem 2023، 58% من فرق الجوال تستخدم اختبارات UI في خط أنابيب CI/CD الخاص بها. متوسط تغطية اختبارات UI في المشاريع التجارية هو 30–40% من شاشات التطبيق. المشاريع التي تحتوي على اختبارات UI تحصل على تقييمات سلبية أقل بنسبة 25% في متاجر التطبيقات المتعلقة بأعطال الواجهة.

الفرق بين اختبار UI والاختبار الوحدوي

الفرق الرئيسي بين اختبارات UI والاختبارات الوحدوية هو مستوى التجريد. الاختبارات الوحدوية تعمل مع فئات ووظائف فردية معزولة عن إطار عمل Android أو iOS. يتم تنفيذها على JVM (لـ Android) بدون تشغيل محاكي وتستغرق أجزاء من الثانية. يتم تشغيل اختبارات UI على جهاز حقيقي أو محاكي، وتتفاعل مع خدمات النظام وتتطلب ثوانٍ أو دقائق لكل سيناريو.

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

وفقاً لمدونة Google للاختبارات (2020)، النسبة المثلى للاختبارات في المشروع تتبع قاعدة هرم الاختبارات: 70% اختبارات وحدوية، 20% اختبارات تكامل و 10% اختبارات UI. انتهاك هذه النسبة لصالح اختبارات UI يؤدي إلى زيادة وقت التشغيل وهشاشة مجموعة الاختبارات، حيث أن اختبارات UI حساسة للتغييرات في تخطيط الشاشات.

أطر عمل اختبار UI

لـ Android، الإطار المهيمن هو Espresso — مكتبة من Google مدمجة في AndroidX Test. يقوم Espresso بالمزامنة تلقائياً مع مسار UI، منتظراً اكتمال الرسوم المتحركة والمهام الخلفية قبل تنفيذ الفحص التالي. لـ Jetpack Compose، يتم استخدام ملحق Compose UI Test الذي يعمل من خلال العقد الدلالية بدلاً من معرفات العرض التقليدية.

لـ iOS، الأداة الرئيسية هي XCUITest المضمنة في Xcode. تُكتب الاختبارات بلغة Swift وتستخدم معرفات الوصول للعثور على العناصر. يدعم XCUITest تسجيل الاختبارات من خلال وظيفة التسجيل والتكامل مع أنظمة CI عبر xcodebuild. للمشاريع متعددة المنصات، يُستخدم Appium المبني على بروتوكول WebDriver والذي يسمح بتشغيل نفس الاختبارات على Android و iOS مع تغييرات طفيفة في الكود.

Espresso و Compose UI Test

Espresso يعمل مع نظام العرض التقليدي من خلال onView ومعرفات الموارد. يستخدم Compose UI Test طبقة دلالية، مما يجعل الاختبارات أقل اعتماداً على تسلسل العروض. على سبيل المثال، البحث عن زر في Espresso: onView(withId(R.id.submit))، في Compose: onNodeWithTag(“submit”). تتعامل اختبارات Compose تلقائياً مع إعادة التركيب ولا تتطلب انتظارات صريحة لحالة الخمول.

XCUITest لـ iOS

XCUITest يستخدم XCUIApplication كنقطة دخول. يتم البحث عن كل عنصر واجهة من خلال خصائص الوصول: accessibilityIdentifier للوصول البرمجي و accessibilityLabel لـ VoiceOver. يدعم الإطار تسجيل الاختبارات من خلال وظيفة التسجيل في Xcode — يقوم المطور بتنفيذ إجراءات على المحاكي، ويقوم Xcode بتوليد كود الاختبار. يتم تشغيل الاختبارات الجاهزة عبر xcodebuild test.

الحلول متعددة المنصات

Appium مبني على بروتوكول WebDriver ويدعم أي لغة: Java، Python، JavaScript. استراتيجيات البحث عن العناصر تشمل id، xpath، class name و accessibility id. يتطلب Appium تثبيت الخادم وإعداد Desired Capabilities — platformName، deviceName، appPackage. البديل هو Maestro الذي يستخدم سيناريوهات YAML ولا يتطلب ترجمة كود الاختبار.

• Espresso — onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))
• XCUITest — app.buttons[“loginButton”].tap(); XCTAssertTrue(app.staticTexts[“welcome”].exists)
• Appium — driver.findElement(By.id(“com.example:id/button”)).click()
• Detox — إطار عمل من Wix لـ React Native، يتزامن مع مسار JS
• Maestro — أداة حديثة مع سيناريوهات YAML لا تتطلب كتابة كود

أمثلة كود لاختبارات UI

دعنا ننظر إلى اختبارات UI لنفس السيناريو — تسجيل الدخول إلى التطبيق — على ثلاثة أطر عمل مختلفة: Espresso لـ Android، XCUITest لـ iOS و Appium للنهج متعدد المنصات. السيناريو: إدخال اسم المستخدم وكلمة المرور، الضغط على زر تسجيل الدخول، التحقق من ظهور رسالة الترحيب.

Android: Espresso

اختبار Espresso يستخدم onView للبحث عن عنصر بواسطة معرفه و perform لتنفيذ إجراء. تؤكد طريقة check مع المطابق isDisplayed أن العنصر مرئي على الشاشة.

@RunWith(AndroidJUnit4::class)
class LoginUiTest {

    @Rule
    @JvmField
    val composeTestRule = createComposeRule()

    @Test
    fun login_withValidCredentials_showsWelcome() {
        composeTestRule
            .onNodeWithTag("emailField")
            .performTextInput("user@example.com")
        composeTestRule
            .onNodeWithTag("passwordField")
            .performTextInput("secret123")
        composeTestRule
            .onNodeWithTag("loginButton")
            .performClick()
        composeTestRule
            .onNodeWithText("مرحبًا، المستخدم!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest يستخدم XCUIApplication للوصول إلى عناصر الواجهة من خلال معرفات الوصول. توفر الطريقتان tap() و exists التفاعل والتحقق.

class LoginUITests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLogin_withValidCredentials_showsWelcome() {
        app.textFields["emailField"].tap()
        app.textFields["emailField"].typeText("user@example.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("secret123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

أفضل ممارسات اختبار UI

المبدأ الأول — استخدم معرفات الوصول بدلاً من تسميات النص للبحث عن العناصر. قد يتغير نص الزر أثناء الترجمة، بينما يبقى المعرف ثابتاً. في Android، هذه هي الخاصية contentDescription؛ في iOS — accessibilityIdentifier. هذا النهج يجعل الاختبارات مستقلة عن لغة الواجهة ويقلل تكاليف الصيانة عند تغيير كتابة المحتوى.

تجنب sleep() والتأخيرات الثابتة — استخدم آليات الانتظار المضمنة في الإطار. ينتظر Espresso تلقائياً اكتمال الرسوم المتحركة والمهام الخلفية. يوفر XCUITest XCTAssertTrue مع timeout. التوقفات الصريحة تجعل الاختبارات أبطأ وأقل استقراراً، خاصة على الأجهزة البطيئة في بيئة CI.

جمّع الاختبارات حسب الأهمية: اختبارات الدخان (3–5 سيناريوهات رئيسية) تُشغّل عند كل commit، ومجموعة اختبارات UI الكاملة تُشغّل قبل الإصدار. وفقاً لمدونة Google للاختبارات (2022)، اختبارات UI التي تستغرق أكثر من 30 دقيقة في CI تقلل تكرار التشغيل بنسبة 40%، مما يقلل فعاليتها كأداة للكشف المبكر عن الانحدار.

قيود اختبارات UI وكيفية تجاوزها

اختبارات UI لديها عدة قيود. الحساسية لتغييرات التخطيط: تغيير معرف، تسلسل أو نوع العنصر يكسر الاختبار حتى لو بقيت الوظيفة دون تغيير. الحل هو استخدام نمط Page Object الذي يمركز محددات العناصر في فئات منفصلة. عند تغيير التخطيط، يتم تعديل ملف واحد لـ Page Object، وليس عشرات الاختبارات.

وقت التنفيذ: التشغيل على جهاز حقيقي أو محاكي يستغرق 10–50 ضعف وقت الاختبار الوحدوي. الحل هو تشغيل اختبارات UI بالتوازي على أجهزة متعددة من خلال Firebase Test Lab أو AWS Device Farm. عدم الاستقرار مشكلة شائعة في تشغيل CI ناتجة عن الرسوم المتحركة، تأخيرات الشبكة أو حالة المحاكي. لمكافحة عدم الاستقرار، تُستخدم إعادة المحاولة التلقائية للاختبارات الفاشلة وتحليل استقرار كل سيناريو اختبار.