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

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

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

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

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

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

إطارات عمل Jetpack

يتضمّن Jetpack إطارات عمل متنوعة توفِّر واجهات برمجة تطبيقات لكتابة اختبارات واجهة المستخدم:

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

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

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

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

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

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

رسم تخطيطي للتدفق يوضح حلقة تتحقق مما إذا كان التطبيق غير نشِط لفترة قصيرة قبل تقديم اختبار
الشكل 1: اختبار المزامنة.

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

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

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

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

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

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

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

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

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

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

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

مراجع إضافية

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

المستندات

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