برمجة اختبارات واجهة المستخدم

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

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

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

اختبارات واجهة المستخدم المعدّة في "استوديو Android"

لإجراء اختبارات واجهة المستخدم الآلية باستخدام "استوديو Android"، يجب تنفيذ رمز الاختبار في مجلد اختبار منفصل لنظام التشغيل Android - src/androidTest/java. ينشئ المكوِّن الإضافي Android لـ Gradle تطبيقًا تجريبيًا استنادًا إلى رمز الاختبار، ثم يحمِّل التطبيق التجريبي على الجهاز نفسه مثل التطبيق المستهدف. وفي الرمز التجريبي، يمكنك استخدام إطارات عمل اختبار واجهة المستخدم لمحاكاة تفاعلات المستخدمين على التطبيق المستهدف من أجل تنفيذ مهام الاختبار التي تتناول سيناريوهات استخدام محددة.

إطارات عمل Jetpack

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

  • يوفّر إطار عمل اختبار Espresso (Android 4.0.1، أو المستوى 14 لواجهة برمجة التطبيقات أو الإصدارات الأحدث) واجهات برمجة تطبيقات لكتابة اختبارات واجهة المستخدم لمحاكاة تفاعلات المستخدم مع العروض ضمن تطبيق مستهدَف واحد. تتمثل إحدى الفوائد الرئيسية لاستخدام Espresso في أنّه يوفّر مزامنة تلقائية لإجراءات الاختبار مع واجهة مستخدم التطبيق الذي تختبره. يرصد الإسبريسو عندما تكون سلسلة التعليمات الرئيسية غير نشطة، وبالتالي يمكنه تشغيل أوامر الاختبار في الوقت المناسب، ما يحسّن موثوقية اختباراتك.
  • يوفّر نظام Jetpack Compose (الإصدار 5.0 من نظام التشغيل Android، المستوى 21 من واجهة برمجة التطبيقات أو الإصدارات الأحدث) مجموعة من واجهات برمجة التطبيقات للاختبار لإطلاق شاشات "إنشاء" والتفاعل معها. تتم مزامنة التفاعلات مع عناصر Compose مع الاختبارات ويتم التحكم فيها بشكل كامل بمرور الوقت، والرسوم المتحركة وعمليات إعادة التركيب.
  • واجهة المستخدم التلقائية (Android 4.3، المستوى 18 من واجهة برمجة التطبيقات أو الإصدارات الأحدث) هي إطار عمل لاختبار واجهة المستخدم مناسب لاختبار واجهة المستخدم على جميع التطبيقات على مستوى النظام والتطبيقات المثبّتة. تتيح لك واجهات برمجة التطبيقات UI Automator API إجراء عمليات مثل فتح قائمة الإعدادات أو مشغّل التطبيقات على جهاز اختباري.
  • تتيح لك Robolectric (الإصدار 4.1 من نظام التشغيل Android، المستوى 16 من واجهة برمجة التطبيقات أو الإصدارات الأحدث) إنشاء اختبارات محلية يتم تشغيلها على محطة العمل أو بيئة دمج متواصل في جهاز JVM عادي، بدلاً من المحاكي أو الجهاز. يمكنها استخدام واجهات برمجة تطبيقات الاختبار Espresso أو Compose للتفاعل مع مكونات واجهة المستخدم.

عدم الاستقرار والمزامنة

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

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

اختبار المزامنة

قد تستمر المشكلات في الظهور عند تشغيل عمليات غير متزامنة أو عمليات في الخلفية غير معروفة للاختبار، مثل تحميل البيانات من قاعدة بيانات أو عرض رسوم متحركة لا حصر لها.

مخطط للتدفق يوضح حلقة تتحقق مما إذا كان التطبيق في وضع عدم النشاط قبل إجراء اختبار
الشكل 1: اختبار المزامنة.

لزيادة موثوقية مجموعة الاختبار، يمكنك تثبيت طريقة لتتبُّع العمليات التي يتم إجراؤها في الخلفية، مثل Espresso Idling Resources. يمكنك أيضًا استبدال الوحدات الخاصة بإصدارات الاختبار التي يمكنك طلبها لتحديد أوقات عدم النشاط أو التي تعمل على تحسين المزامنة، مثل TestDispatcher للكوروتيين أو RxIdler لنظام RxJava.

رسم بياني يوضّح إخفاق الاختبار عندما تستند المزامنة إلى الانتظار لفترة ثابتة
الشكل 2: يؤدي استخدام النوم في الاختبارات إلى بطء الاختبارات أو استقرارها.

البنية والإعداد التجريبي

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

مخططات الإنتاج والاختبار المعمارية. يُظهر مخطط الإنتاج مصادر البيانات المحلية والبعيدة التي توفر البيانات إلى المستودع، وبالتالي يتم توفيرها بشكل غير متزامن لواجهة المستخدم. يعرض الرسم التخطيطي للاختبار مستودعًا مزيّفًا يوفّر بياناته بشكل متزامن مع واجهة المستخدم.
الشكل 3: اختبار واجهة مستخدم عن طريق استبدال العناصر الاعتمادية التابعة لها بعناصر مزيفة.

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

لماذا يتم الاختبار تلقائيًا؟

يمكن لتطبيق Android استهداف آلاف الأجهزة المختلفة عبر العديد من مستويات واجهة برمجة التطبيقات وعوامل الشكل، ويعني مستوى التخصيص العالي الذي يجلبه نظام التشغيل للمستخدم أنه قد يتم عرض تطبيقك بشكل غير صحيح أو حتى يتعطل على بعض الأجهزة.

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

  • مستوى واجهة برمجة التطبيقات: 21 و25 و30.
  • اللغة: الإنجليزية والعربية والصينية.
  • الاتجاه: عمودي، أفقي.

بالإضافة إلى ذلك، يجب أن تتحقّق التطبيقات من السلوك خارج نطاق الهواتف. ينبغي لك الاختبار على الأجهزة اللوحية والأجهزة القابلة للطي والأجهزة الأخرى.

مراجع إضافية

لمزيد من المعلومات حول إنشاء اختبارات واجهة المستخدم، ارجع إلى الموارد التالية.

المستندات

الدروس التطبيقية حول الترميز