اختبار Android: AWS Device Farm و Firebase TestLab

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

كانت مهمتنا هي أتمتة اختبارات E2E فقط. أحد القرارات الأولى التي اتخذناها ، هو اختيار شركة جادة بما فيه الكفاية توفر خدمة "تأجير" جميع أنواع الأجهزة المادية لأغراض الاختبار. أولاً ، فكرنا في حل الاستضافة الذاتية الذي يمكن توصيله بخط أنابيب Cl ، ولكن لم نتمكن من توفير تنوع الأجهزة بشكل كافٍ. لذلك ، بدأنا نبحث عن حلول سحابة.

نظرًا لأننا كنا بحاجة إلى حل يدعم كلاً من نظامي Android و iOS ، مع وجود عدد كبير من الأجهزة المختلفة ، فقد تم اختيار AWS DeviceFarm ، كحل يمكننا الوثوق به لتكون مستقرة بما فيه الكفاية ، مع دعم استجابة وسهولة الاستخدام بشكل عام.

AWS DeviceFarm

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

  • اختيار نوع الاختبار: الأجهزة
  • تحميل اختبار apk
  • تحميل التطبيق apk
  • اختيار الأجهزة (إنشاء ما يسمى تجمع الأجهزة)
  • إذا كنت لا تحتاج إلى توفير أي حزمة بيانات إضافية ، فانقر فوق "تشغيل".

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

لكل اختبار ، ستتمكن من الحصول على سجل الأجهزة وتسجيل logcat وتسجيل الفيديو بشكل افتراضي.

ومع ذلك ، لا يتم استخدام واجهة المستخدم على الويب كثيرًا عند استخدام خط أنابيب CI ، لذلك يتعين علينا استخدام AWS CLI أو بعض المكونات الإضافية لخادم التصميم. كنا نستخدم Jenkins الذي يحظى بدعم اتصالات AWS DeviceFarm (من خلال البرنامج المساعد بالطبع).

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

JUnit4 الدعم - صفقة الكسارة

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

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

كجزء ثانٍ ، اضطررنا إلى طلب الاختبارات داخل فصول الاختبار أيضًا ، وهو ما قمنا به من خلال الخيار الوحيد المتاح: تعليق توضيحيFixMethodOrder.

وكانت تلك هي نهاية الرحلة بالنسبة لنا باستخدام AWS DeviceFarm لأنها تقوم بتطبيق JUnit4 جزئيًا فقط ، دون أي دعم لتعريف مجموعات الاختبار ، ولا FixMethodOrder! نظرًا لأنه تم استبعادنا من الخيارات ، فقد اضطررنا إلى التخلي عن الخدمة لأننا لم نتمكن من إجراء الاختبارات كما أردنا.

Firebase TestLab

قبل التخلي عن AWS ، كان علينا التأكد من أنه يمكننا العثور على خدمة ، لا تزال خطيرة بما يكفي وبدعم جيد لا توجد به قيود JUnit4. لقد جربنا Firebase ونجح.

من خلال واجهة مستخدم الويب ، تكون خطوات إجراء الإعداد مطابقة تقريبا لـ AWS:

  • اختيار نوع الاختبار: (أيضا الأجهزة)
  • قم بتحميل كل من apk
  • اختيار جهاز
  • يركض.
  • راقب نتائج الاختبار لكل جهاز وكل اختبار مع إمكانية الوصول إلى تسجيل الفيديو والسجلات.

بالطبع ، لا يمكننا استخدام واجهة المستخدم على الويب ، لذلك ننتهي باستخدام حل CLI في Firebase: gcloud.

من خلال gcloud ، يمكننا تحديد نوع الاختبار والمسارات إلى ملفات apk ودليل النتائج والجرد على Google Cloud Storage والهدف من الاختبار الذي بالإضافة إلى جميع الخيارات القياسية مثل حزمة الاختبار أو الاختبار الفردي ، يقبل أيضًا مجموعة اختبار كهدف ، واحترام ترتيب التنفيذ.

على الرغم من أنه يعمل بطريقة مشابهة لـ AWS DeviceFarm ، إلا أن Firebase TestLab يعتمد على مكدس Google وبالتالي يحفظ جميع نتائج الاختبار في المجموعة على Google Cloud Storage ، وهو أمر رائع حيث أننا قادرون على الوصول إلى الملفات مباشرة.

ملاحظة صغيرة هنا: من أجل تحديد المجموعة المخصصة والمسار لكل عملية تنفيذ اختبار ، يلزم الوصول المدفوع إلى Google Cloud Storage. في حالة الاستخدام المجاني للتخزين ، سيتم حفظ نتائج الاختبار تحت دليل testlab / random-hash ، وستتم إزالتها بعد 90 يومًا.

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

مهلة:

على الرغم من أن Firebase يمنحنا إمكانية تشغيل مجموعات الاختبار ، إلا أنها لم تقدم مجانًا. المهلة القصوى لتنفيذ الاختبار هي 30 دقيقة. هذا أكثر من 90٪ من حالات الاستخدام ، ولكن في حالتنا ، ثبت أن وجود مجموعة اختبار واحدة تحتوي على جميع فئات الاختبار يمثل حلاً إشكاليًا لأن اختبارات E2E لدينا تنفذ 60+ دقيقة.

السبب وراء هذا الحد الأقصى البالغ 30 دقيقة ، وفقًا للمناقشات في منتديات Google و Slack ، هو استقرار النظام ، لذلك وجدوا الحل الوسط في 30 دقيقة. تنفيذ أي شيء أطول من ذلك سوف يتوقف دون أي نتائج.

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

مقارنة:

سنحاول هنا تلخيص إيجابيات وسلبيات كلتا الخدمتين:

  1. CLI البساطة: Firebase
  2. البرنامج المساعد الوصول: AWS
  3. تقارير النظام (القائمة البريدية): لا شيء
  4. تقارير إمكانية الوصول: Firebase
  5. تقرير هضم: Firebase
  6. اختيار الأجهزة: AWS (يحتوي Firebase على 15-20 جهازًا مختلفًا)
  7. ما يصل إلى تاريخ التوافق: Firebase
  8. إمكانية الوصول إلى الدعم: Firebase (تقريبًا عبر Slack)
  9. جهاز التحكم عن بعد: AWS
  10. استقرار النظام: AWS (في Firebase ، كان لدينا الكثير من "فشل البنية التحتية" على أجهزة معينة)
  11. التكامل IDE: Firebase
  12. دعم iOS: كلاهما (مع ميزة بسيطة لـ AWS مثل دعم Firebase XCUITest في مرحلة تجريبية مغلقة في وقت كتابة هذا التقرير)

يمكن لهذه القائمة أن تستمر ، لكن هدفها ليس إخبارك "يجب ألا تستخدم خدمة X أبدًا". أردت أن أشير إلى القضايا والمزايا من مثال العالم الحقيقي.

استنتاج

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

ملاحظة: تُستخدم هذه الخدمات في خطط مدفوعة غير محدودة ، بما في ذلك حركة المرور الناتجة على Google Cloud Storage. لم يكن هناك قيود على الخدمة بسبب الاستخدام المجاني أو التجريبي.

كن حذرا!