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

ماذا تؤتمت على الجوال

ينطبق هرم الاختبار (Test pyramid) على الجوال كما على أي منتج (يشرح دليل الاختبار اليدوي مقابل الآلي السبب): معظم الفحوص مكانها تحت الواجهة، حيث تكون سريعة ومستقرة. في Android تعمل اختبارات الوحدة المحلية على JVM في جهاز التطوير خلال ثوانٍ، بينما تعمل الاختبارات المُجهَّزة (Instrumented) على جهاز أو محاكٍ؛ وفي iOS يشغّل XCTest اختبارات الوحدة واختبارات الواجهة من مشروع Xcode نفسه. قواعد العمل والتحقق والحسابات مكانها اختبارات الوحدة واختبارات API على الواجهة الخلفية. أما اختبارات الواجهة فللرحلات التي يجب ألا تنكسر أبداً — تسجيل الدخول، والتهيئة الأولى، والبحث، وإتمام الشراء، والميزة الأساسية للتطبيق — وللربط بين الشاشات.

• اختبارات الوحدة — نماذج العرض، والمنسّقات، والتحقق، واستعلامات قاعدة البيانات المحلية؛ تعمل مع كل إيداع.
• الاختبارات المُجهَّزة أو التكاملية — الشيفرة التي تحتاج المنصة: التخزين، وقاعدة البيانات المحلية، والعمل في الخلفية؛ تعمل على المحاكيات.
• اختبارات API — الواجهة الخلفية التي يستدعيها التطبيق، بما في ذلك استجابات الأخطاء والتوافق مع العملاء القدامى.
• اختبارات الواجهة — مجموعة صغيرة من الرحلات الحرجة لكل منصة، تعمل في CI على المحاكيات وعلى أجهزة حقيقية قبل الإصدار.
• الاختبار اليدوي والاستكشافي — الإيماءات، والمقاطعات الحقيقية، والمظهر والإحساس، وسلوك الأجهزة الحقيقية (انظر قسم ما يبقى يدوياً).

مقارنة Espresso وXCUITest وAppium

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

• Espresso — لـ Android فقط؛ الاختبارات بلغة Kotlin أو Java؛ يعمل داخل عملية التطبيق كاختبار مُجهَّز. يتزامن تلقائياً مع خيط واجهة التطبيق، فلا يتصرف إلا حين تكون الواجهة خاملة؛ والعمل في الخلفية الذي لا يراه يُسجَّل عبر موارد الخمول (Idling resources). سريع ومستقر؛ ويكتبه عادةً مطورو Android بجوار الشيفرة. ولا يستطيع الوصول إلى واجهة النظام خارج التطبيق — وهذا ما يغطيه UI Automator.
• XCUITest — لـ iOS فقط؛ الاختبارات بلغة Swift أو Objective-C، تُكتب في Xcode مع XCTest (وتوثّق Apple الآن واجهة اختبار الواجهة باسم XCUIAutomation). مشغّل الاختبار عملية منفصلة تقود التطبيق عبر طبقة إمكانية الوصول، كما يفعل المستخدم. ينتظر استقرار التطبيق قبل التفاعل ويستطيع التعامل مع تنبيهات النظام. ويكتبه عادةً مطورو iOS أو مهندسو أتمتة يعملون في Xcode.
• Appium — لـ Android وiOS ومنصات أخرى؛ الاختبارات بأي لغة لها عميل WebDriver (Java وPython وJavaScript وC# وRuby…). يرسل العميل أوامر W3C WebDriver إلى خادم Appium، الذي يستخدم مشغّل منصة (Driver) — مثل مشغّل UiAutomator2 على Android ومشغّل XCUITest على iOS — للتصرف على الجهاز. يعامل التطبيق كصندوق أسود، ويستطيع الانتقال إلى سياقات WebView في التطبيقات الهجينة، ويستطيع أتمتة متصفحات الجوال. كل خطوة تعبر طبقات أكثر، فهو أبطأ من الأطر الأصلية.

Espresso: داخل العملية ومتزامن

يجد اختبار Espresso عنصراً بواسطة مُطابِق (Matcher)، وينفّذ عليه إجراءً، ثم يتحقق من تأكيد. وقبل كل إجراء وكل تأكيد ينتظر Espresso حتى يخلو طابور رسائل خيط الواجهة، وهذا يزيل معظم شيفرة الانتظار التي تحتاجها الأدوات الأخرى. أما العمل الذي يجري في مكان آخر — مجمّع خيوط مخصص، أو مكتبة شبكة لا يعرفها Espresso — فيجب تسجيله كمورد خمول، وإلا تسابق معه الاختبار. والشاشات المبنية بـ Jetpack Compose تُختبر بواجهات الاختبار الخاصة بـ Compose، التي تتبع المبدأ نفسه.

@RunWith(AndroidJUnit4::class)
class LoginTest {
    @get:Rule
    val activityRule = ActivityScenarioRule(LoginActivity::class.java)

    @Test
    fun wrongPasswordShowsError() {
        onView(withId(R.id.email)).perform(typeText("layla.h@example.com"), closeSoftKeyboard())
        onView(withId(R.id.password)).perform(typeText("wrong-pass-1"), closeSoftKeyboard())
        onView(withId(R.id.sign_in)).perform(click())
        onView(withText(R.string.error_invalid_credentials)).check(matches(isDisplayed()))
    }
}

XCUITest: صندوق أسود عبر إمكانية الوصول

يشغّل اختبار XCUITest التطبيق كعملية منفصلة ويستعلم عن شجرة عناصره حسب النوع والمعرّف: الأزرار وحقول النص والنصوص الثابتة. يضع المطورون accessibilityIdentifier على كل عنصر تحتاجه الاختبارات؛ وعلى خلاف تسمية إمكانية الوصول (Accessibility label)، لا ينطق VoiceOver المعرّف، فيمكن أن يكون اسماً تقنياً ثابتاً. وتضع وسائط التشغيل ومتغيرات البيئة التطبيقَ في حالة اختبار — عنوان خادم وهمي، أو مخزن بيانات مُعاد ضبطه، أو حركات معطّلة — دون بناءات خاصة. استخدم waitForExistence(timeout:) للعناصر التي تظهر بعد عمل غير متزامن بدلاً من الانتظار الثابت.

final class LoginUITests: XCTestCase {
    func testWrongPasswordShowsError() {
        let app = XCUIApplication()
        app.launchArguments += ["-uiTesting", "-resetState"]
        app.launch()

        let email = app.textFields["login.email"]
        email.tap()
        email.typeText("layla.h@example.com")

        let password = app.secureTextFields["login.password"]
        password.tap()
        password.typeText("wrong-pass-1")

        app.buttons["login.submit"].tap()

        XCTAssertTrue(app.staticTexts["login.error"].waitForExistence(timeout: 5))
    }
}

Appium: بروتوكول WebDriver للجوال

Appium خادم. يفتح اختبارك، المكتوب بمكتبة عميل WebDriver، جلسةً بإرسال القدرات (Capabilities) — أي منصة، وأي مشغّل أتمتة، وأي تطبيق، وأي جهاز — ثم يرسل أوامر مثل إيجاد عنصر والنقر وإرسال المفاتيح. ومنذ Appium 2 تُثبَّت المشغّلات منفصلة عن الخادم، فيحدد المشروع بدقة إصدارات المشغّلات التي يستخدمها. والقدرات غير الواردة في معيار W3C تحمل البادئة appium:. ولأن Appium يقود التطبيق من الخارج، يمكن تشغيل الاختبار نفسه على بناء تصحيح في محاكٍ وعلى مرشّح إصدار في هاتف من مزرعة أجهزة.

from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

caps = {
    "platformName": "Android",
    "appium:automationName": "UiAutomator2",
    "appium:deviceName": "Pixel_Test",
    "appium:app": "/builds/shop-4.0.0-debug.apk",
    "appium:autoGrantPermissions": True,
}
driver = webdriver.Remote("http://127.0.0.1:4723", options=UiAutomator2Options().load_capabilities(caps))
try:
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login.email").send_keys("layla.h@example.com")
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login.password").send_keys("wrong-pass-1")
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "login.submit").click()
    WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((AppiumBy.ACCESSIBILITY_ID, "login.error")))
finally:
    driver.quit()

المحددات على الجوال

المحدد (Locator) هو الطريقة التي يجد بها الاختبار عنصراً، وعلى الجوال يحدد اختياره الاستقرار والسرعة معاً. اتفق مع المطورين على اصطلاح للمعرّفات (مثلاً screen.element: login.submit)، وضع المعرّفات على كل عنصر تلمسه الاختبارات، واجعل «وجود معرّفات الاختبار» جزءاً من تعريف الإنجاز (Definition of done). المبادئ العامة في دليل استراتيجيات المحددات؛ وفيما يلي خصوصيات الجوال.

• معرّف إمكانية الوصول (Accessibility id) — الاستراتيجية المفضلة في Appium. على iOS يطابق accessibilityIdentifier، الذي لا يقرؤه VoiceOver، فيمكن أن يكون اسماً تقنياً. وعلى Android يطابق وصف المحتوى (Content description)، الذي يقرؤه TalkBack بصوت عالٍ — لذا يجب أن يكون على Android تسمية بشرية حقيقية، أو أن تستخدم معرّف المورد بدلاً منه.
• معرّف المورد (Resource id) في Android — مثل com.example.shop:id/sign_in؛ ثابت ما دام المطورون لا يغيّرون المعرّفات.
• الاستعلامات الأصلية للمنصة — UiSelector في UiAutomator2، وسلاسل Predicate وClass chain في iOS — حين لا يناسب ما سبق؛ وهي أسرع من XPath.
• النص الظاهر — ينكسر حين يُوطَّن التطبيق (بناءات العربية والإنجليزية تعرض نصوصاً مختلفة)؛ لا تستخدمه إلا مع موارد لكل لغة.
• XPath — الملاذ الأخير: بطيء على الجوال لأن شجرة العرض كلها يجب أن تُسلسَل، وهشّ حين يتغير التخطيط.
• الأطر متعددة المنصات (React Native وFlutter) توفر خاصية معرّف اختبار خاصة بها؛ تحقق مما تُطابقه على كل منصة قبل بناء المحددات عليها.

لماذا تتذبذب اختبارات واجهة الجوال — وماذا تفعل

الاختبار المتذبذب (Flaky test) ينجح ويفشل على الشيفرة نفسها. ويضيف الجوال أسبابه الخاصة إلى الأسباب المعتادة (عدم التزامن، والحالة المشتركة، والخدمات البعيدة، والوقت)، والحزمة التي تفشل عشوائياً سرعان ما تُهمَل. يغطي دليل الاختبارات المتذبذبة الاكتشاف والحجر؛ وهذه هي المصادر الخاصة بالجوال.

• الحركات والانتقالات — عطّلها على أجهزة الاختبار والمحاكيات (إعدادات مقياس الحركة الثلاثة أدناه)، أو عبر وسائط التشغيل في iOS.
• عدم تزامن لا يراه الإطار — سجّل موارد الخمول في Espresso، وانتظر الشروط (العنصر موجود، ومفعّل) في كل مكان آخر؛ ولا تستخدم الانتظار الثابت أبداً.
• حوارات النظام — طلبات الأذونات، و«التطبيق لا يستجيب»، وتلميحات لوحة المفاتيح، وطلبات تحديث النظام. امنح الأذونات مسبقاً حيث لا يكون الاختبار عنها، وتعامل صراحةً مع تنبيهات النظام المتوقعة.
• تسرّب الحالة بين الاختبارات — جلسة مسجّلة، وبيانات محلية، وأعلام ميزات. أعد الضبط لكل اختبار: امسح بيانات التطبيق (يستطيع Android Test Orchestrator مسح بيانات الحزمة بين الاختبارات) أو شغّل بوسيط إعادة ضبط في iOS.
• الشبكة الحقيقية وواجهة خلفية مشتركة — استخدم خادماً وهمياً أو بيئة اختبار مُهيّأة ببيانات، وولّد بيانات فريدة لكل تشغيل.
• لوحة المفاتيح التي تغطي العنصر التالي، والعناصر التي تحتاج تمريراً لتظهر.
• صحة الأجهزة والمحاكيات — إقلاع بطيء، وتخزين ممتلئ، وبطارية منخفضة، أو أجهزة مزرعة ساخنة. أضف فحوص صحة؛ وأعد المحاولة على مستوى البنية التحتية فقط، لا لإخفاء إخفاق حقيقي.
• فروق اللغة والمنطقة الزمنية والساعة بين أجهزة المصفوفة.

# Android — turn off animations on a test device or emulator
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0

جرّبها: مولّد استجابات API وهمية جرّبها: محاكي رموز حالة API جرّبها: مولّد استجابات خطأ وهمية جرّبها: مولّد مستخدمين وهميين

مزارع الأجهزة وخطوط CI

تعمل محاكيات Android على أجهزة CI بنظام Linux أو Windows أو macOS، وتحتاج تسريعاً عتادياً لتكون سريعة (KVM على Linux)؛ أما محاكيات iOS فتتطلب macOS. قسّم الحزم الطويلة إلى أجزاء (Shards) تعمل بالتوازي على عدة محاكيات أو أجهزة. وتأخذ مزرعة الأجهزة السحابية تطبيقك وحزمة اختباراته، وتشغّلها على الأجهزة الحقيقية التي تختارها، وتعيد النتائج مع مقاطع فيديو ولقطات شاشة وسجلات؛ والأجهزة نفسها متاحة عادةً لجلسات يدوية. اختر أجهزة المزرعة من مصفوفة أجهزتك، واستخدم الاختيار الثنائي (Pairwise) للمعاملات الثانوية (اللغة والاتجاه وحجم الخط) بدلاً من مضاعفة التشغيلات.

انشر النتائج بصيغة يفهمها خادم CI (وJUnit XML هي الشائعة) واحتفظ بمخرجات كل اختبار فاشل. البناء الأحمر الذي لا يرافقه فيديو وسجل جهاز هو بناء سيعيد أحدهم تشغيله بدلاً من إصلاحه.

ويعرض المثال التوضيحي أدناه إيقاعاً ممكناً للخط: مع كل طلب دمج (Pull request) تعمل اختبارات الوحدة، ويُبنى التطبيق وحزمة الاختبار، وتعمل حزمة دخان من 10 إلى 20 اختباراً حرجاً على محاكٍ واحد لكل منصة، واختبارات عقود API مقابل الواجهة الخلفية في بيئة Staging. وكل ليلة تعمل حزمة الواجهة كاملة مقسّمة على المحاكيات، مع أجهزة الطبقتين 1 و2 (Tier 1 وTier 2) في مزرعة أجهزة. وقبل الإصدار يُختبر مرشّح الإصدار على أجهزة الطبقتين 1 و2 (والطبقة 3 أيضاً قبل الإصدارات الكبرى) مع جلسة استكشافية على أجهزة حقيقية، ويُشغَّل أقدم إصدار مدعوم من التطبيق مقابل الواجهة الخلفية الجديدة. والطبقات هي طبقات مصفوفة الأجهزة النموذجية في الدليل المحوري لاختبار الجوال. ولكل اختبار فاشل: فيديو ولقطات شاشة وسجل الجهاز وJUnit XML.

Example mobile pipeline

on every pull request
  1. unit tests (JVM / XCTest unit)
  2. build the app and the test package (test APK / UI test bundle)
  3. UI smoke: 10–20 critical tests on one Android emulator and one iOS simulator
  4. API contract tests against the staging back end
nightly
  5. full UI suite, sharded across emulators and simulators
  6. Tier 1 and Tier 2 real devices in a device farm
before release
  7. release candidate on the Tier 1 and Tier 2 devices (Tier 3 too before a major release)
     + exploratory session on real devices
  8. oldest supported app version against the new back end (API smoke)
for every failed test: video, screenshots, device log, JUnit XML

جرّبها: مولّد الاختبار الزوجي (Pairwise) جرّبها: مدقّق مخططات API

ما يبقى يدوياً

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

• جلسات استكشافية على أجهزة حقيقية لكل مرشّح إصدار.
• مقاطعات حقيقية: مكالمات، وBluetooth، وإشعارات من تطبيقات أخرى.
• مراجعة بصرية عبر الأجهزة، ما لم تكن تصون اختبارات لقطات الشاشة.
• جلسات قارئ الشاشة والنص الكبير.
• البطارية والحرارة والأداء على أضعف جهاز.
• بناءات المتجر: التثبيت من المتجر أو القناة التجريبية تماماً كما يفعل المستخدمون.

جرّبها: مصنع بيانات الاختبار

الأسئلة الشائعة

المراجع

• Appium DocumentationAppium (OpenJS Foundation)التوثيق الرسمي لأتمتة التطبيقات الأصلية والهجينة وتطبيقات الويب على iOS وAndroid.
• EspressoAndroid Developers (Google)إطار اختبار واجهات Android الذي يزامن إجراءات الاختبار مع خيط واجهة التطبيق تلقائياً.
• XCUIAutomationAppleواجهة Apple البرمجية لاختبارات الواجهة التي تشغّل التطبيق وتتفاعل مع عناصره كما يفعل المستخدم (أساس XCUITest).
• XCTestAppleإطار Apple لاختبارات الوحدة والأداء والواجهة لمشاريع Xcode على iOS وبقية منصات Apple.
• Test apps on AndroidAndroid Developers (Google)إرشادات Android الرسمية للاختبار: أنواع الاختبارات ونطاقاتها، والاختبارات المحلية مقابل المُجهَّزة على الجهاز، وأفضل الممارسات.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019منهج ISTQB التخصصي لاختبار تطبيقات الجوال: أنواع التطبيقات وتحديات الأجهزة والمنصات وأنواع الاختبار والأدوات.