اختبار جيد مع قدرات التفكير النقدي لا يمكن استبداله بالكامل بالأتمتة. جعلها تعمل بشكل أكثر كفاءة أمر سهل. مع هذا الاقتناع ، ذهبت إلى قسم الاختبار الخاص بنا بمهمة جديدة ، حيث قمنا مع Pavel بتنفيذها. دعونا نرى ما جاء منه.بالتعاون مع شركائنا ، نعمل بنشاط على تطوير واختبار ودعم مجموعة من التطبيقات لمنصات مختلفة: Android و iOS و Windows. تتطور التطبيقات بنشاط ، إلى جانب زيادة حجم الاختبار ، في المقام الأول الانحدار.
قررنا محاولة تسهيل وتسريع الاختبار من خلال أتمتة معظم سيناريوهات الاختبار. في الوقت نفسه ، لم نرغب في التخلي تمامًا عن عملية الاختبار اليدوي ، بل تعديلها.
بدأ تنفيذ هذا النهج بإحدى تطبيقات Android ، والتي سأتحدث عنها. ستكون هذه المقالة ذات أهمية لكتاب مؤلفي اختبارات واجهة المستخدم ، خاصة لتطبيقات الأجهزة المحمولة ، بالإضافة إلى أولئك الذين يريدون أتمتة عملية الاختبار اليدوي إلى حد ما.
دعنا نذهب!
نقطة الانطلاق
لكل منصة ، لدينا العديد من الأنظمة المماثلة التي تؤدي نفس العملية التجارية للتطبيقات. ومع ذلك ، فإنها تختلف عن بعضها البعض في مجموعة من الوظائف المساعدة الصغيرة ، والتي يتم إجراؤها تحت علامات تجارية مختلفة حسب العميل (بسبب تغيير الواجهة من تطبيق إلى تطبيق) ، ويمكن تخصيص عملية الأعمال بإضافة خطوات إضافية.
نحن نواجه بعض المشاكل التي تحتاج إلى معالجة. قد تنشأ صعوبات مماثلة في موقف مختلف عن وضعنا. على سبيل المثال ، إذا كان لديك أحد التطبيقات الضخمة ذات المنطق التجاري الصعب ، فقد امتلأت بالعديد من الاختبارات.
المشكلة رقم 1: الكثير من اختبارات الانحدار
تتشابه مجموعات سيناريوهات الاختبار لكل تطبيق في نفس الوقت وتختلف عن بعضها البعض ، مما يساهم في زيادة الانحدار ويجعله أكثر مملة. ومع ذلك ، تحتاج إلى اختبار جميع التطبيقات بشكل فردي.
بالنظر إلى أن التطبيقات التي يتم تشغيلها بالفعل يتم تحديثها بانتظام ، وفي المستقبل سيكون هناك المزيد فقط ، فإن العدد الإجمالي للاختبارات سوف ينمو بشكل لا يطاق.
المشكلة رقم 2: تحتاج إلى اختبار على جميع إصدارات نظام التشغيل المحمول
أحد المتطلبات المهمة هو توفر تطبيقات الهاتف المحمول الخاصة بنا على مجموعة واسعة من إصدارات نظام التشغيل. على سبيل المثال ، في حالة Android في وقت كتابة هذا التقرير ، فإن هذه هي مستويات API من 17 إلى 28.
من الناحية المثالية ، يجب أن نختبر كل إصدار من Android ، مما يزيد من تعقيد الانحدار لدينا. تكتسب عملية الاختبار المباشر للتطبيق روتينًا إضافيًا مضروبًا في عدد الأجهزة: تثبيت التطبيق وتشغيله ، وبذلك يصبح حالته الأصلية بعد كل اختبار فردي ، الإزالة. في الوقت نفسه ، تعد صيانة مزرعة الأجهزة الخاصة بك كثيفة العمالة.
الحل: دمج الأتمتة في عملية الاختبار اليدوي
تتمثل المهمة النموذجية لأتمتة الاختبار في أتمتة اختبارات الانحدار. لذلك نحن نريد تحسين كفاءة عملية الاختبار اليوم ومنع النتائج المحتملة للنمو غدا.
في الوقت نفسه ، نحن ندرك جيدًا أنه من المستحيل وغير الضروري القضاء تمامًا على الاختبارات اليدوية عن طريق التشغيل الآلي. من الصعب استبدال التفكير الناقد والعين البشرية بشيء ما. يوجد مقال جيد حول هذا الموضوع في مدونة مايكل بولتون بعنوان "
نهاية الاختبار اليدوي" (أو
الترجمة من آنا روديونوفا).
لقد اعتقدنا أنه سيكون من المفيد الحصول على مجموعة من الاختبارات الآلية التي تغطي الأجزاء المستقرة من التطبيق ، وفي المستقبل اختبارات الكتابة عن الأخطاء التي تم العثور عليها والوظائف الجديدة. في الوقت نفسه ، نريد ربط الاختبارات التلقائية بمجموعات الاختبار الموجودة في نظام إدارة الاختبار لدينا (نستخدم TestRail) ، ونمكّن أيضًا المختبرين من تشغيل الاختبارات التلقائية بسهولة على الأجهزة المادية السحابية (اخترنا Firebase Test Lab كالبنية التحتية السحابية).
للبدء والمحاولة ، أخذنا أحد تطبيقات Android الخاصة بنا. كان من المهم مراعاة أنه إذا كان الحل ناجحًا ، يمكن تطبيق أفضل ممارساته على تطبيقاتنا الأخرى ، بما في ذلك على منصات أخرى.
ما نريد الحصول عليه نتيجة:
- أتمتة اختبار الانحدار.
- التكامل مع نظام إدارة الاختبار.
- إمكانية بدء التشغيل اليدوي للمعاملات التلقائية على الأجهزة السحابية.
- إمكانية إعادة استخدام الحل في المستقبل.
بعد ذلك ، سأتحدث بشكل منفصل عن تنفيذ كل نقطة من هذه النقاط مع القليل من الانغماس في المكون الفني.
مخطط تنفيذ الحل العام
لكن أولاً ، مخطط عام لما حصلنا عليه:
تعمل الاختبارات التلقائية بطريقتين:
- من CI بعد دمج أو سحب طلب لإتقان.
- اختبر يدويًا من واجهة Jenkins Job على الويب.
في حالة التشغيل اليدوي ، يجب أن يشير المختبر إما إلى رقم البنية المقابلة ، أو تنزيل 2 APKs من الكمبيوتر: مع التطبيق ومع الاختبارات. هذه الطريقة ضرورية حتى تتمكن من إجراء الاختبارات اللازمة في أي وقت على أي أجهزة متوفرة.
أثناء الاختبارات ، يتم إرسال نتائجها إلى TestRail. يحدث هذا بنفس الطريقة كما لو أن الفاحص أجرى الاختبار يدويًا وأدخل النتائج بطريقة مألوفة لديه.
وهكذا ، تركنا العملية المحددة للاختبار اليدوي ، لكننا أضفنا إليه التشغيل الآلي ، والذي يؤدي مجموعة محددة من الاختبارات. يقوم المختبر "بالتقاط" ما تم تلقائيًا ، و:
- يرى نتيجة حالات الاختبار على كل جهاز تم اختياره ؛
- يمكن التحقق من أي حالة اختبار يدويا.
- إجراء حالات اختبار لم يتم تشغيلها تلقائيًا بعد ، أو لا يمكن تحسينها لأي سبب ؛
- يجعل القرار النهائي على المدى الاختبار الحالي.
الآن دعنا ننتقل إلى الوصف الموعود للتنفيذ.
1. اختبارات السيارات
الأدوات
استخدمنا 3 أدوات للتفاعل مع واجهة المستخدم:
- اسبريسو
- باريستا.
- واجهة المستخدم الآلي.
الأداة الرئيسية والأداة التي بدأناها هي Espresso. كانت الحجة الرئيسية لصالح اختياره هي أن Espresso يسمح لك باختبار استخدام طريقة الصندوق الأبيض ، مما يتيح الوصول إلى Android Instrumentation. رمز الاختبار في نفس المشروع مثل رمز التطبيق.
يلزم الوصول إلى رمز تطبيق Android للاتصال بأساليبه في الاختبارات. يمكننا إعداد طلبنا لاختبار محدد مقدمًا عن طريق تشغيله في الحالة الصحيحة. خلاف ذلك ، نحن بحاجة إلى تحقيق هذه الحالة من خلال الواجهة ، التي تحرم اختبارات الذرية ، وجعلها تعتمد على بعضها البعض ، ويستهلك ببساطة الكثير من الوقت.
أثناء التنفيذ ، تمت إضافة أداة أخرى إلى Espresso - UI Automator. يعد كلا الإطارين جزءًا من
مكتبة دعم اختبار Android من
Google . باستخدام UI Automator ، يمكننا التفاعل مع مختلف مربعات حوار النظام أو ، على سبيل المثال ، درج الإشعارات.
وكان الأخير في ترسانة لدينا إطار باريستا. إنها عبارة عن مجمّع حول Espresso ، مما يوفر لك رمز boilerplate عند تنفيذ إجراءات المستخدم الشائعة.
مع الأخذ في الاعتبار الرغبة في التمكن من إعادة استخدام الحل في التطبيقات الأخرى ، من المهم الإشارة إلى أن الأدوات المدرجة مخصصة حصريًا لتطبيقات Android. إذا لم تكن بحاجة إلى الوصول إلى رمز التطبيق قيد الاختبار ، فربما تفضل استخدام إطار عمل مختلف. على سبيل المثال ، Appium شعبية جدا اليوم. على الرغم من أنه يمكنك أيضًا محاولة الوصول إلى رمز التطبيق بمساعدة backdoors به ، وهو
مقال جيد في مدونة Badoo. الخيار لك.
التنفيذ
كنمط تصميم ، اخترنا اختبار الروبوتات ، الذي اقترحه جيك وارتون في
تقرير مسمى. تشبه فكرة هذا الأسلوب نمط تصميم كائن الصفحة الشائع المستخدم في اختبار أنظمة الويب. لغة البرمجة هي جافا.
لكل جزء مستقل من التطبيق ، يتم إنشاء فئة روبوت خاصة يتم فيها تطبيق منطق الأعمال. يوصف التفاعل مع كل عنصر من عناصر الجزء بطريقة منفصلة. بالإضافة إلى ذلك ، تم توضيح جميع التأكيدات التي تم تنفيذها في هذا الجزء أيضًا.
النظر في مثال بسيط. يحتوي الجزء الموصوف على عدة حقول لإدخال البيانات وزر الإجراء:
اختبار وظيفة تسجيل الدخول نفسها:
نحن هنا نتحقق من السيناريو الإيجابي عندما تكون بيانات المصادقة المدخلة صحيحة. يتم إرسال البيانات نفسها إلى اختبارات الإدخال ، أو يتم استخدام القيم الافتراضية. وبالتالي ، فإن المختبر لديه القدرة على تحديد معلمات من حيث بيانات الاختبار.
يعطي هذا الهيكل في المقام الأول الاختبارات إمكانية قراءة ممتازة عندما يتم تقسيم البرنامج النصي بالكامل إلى خطوات التنفيذ الرئيسية. لقد أحببنا حقًا فكرة نقل التأكيدات إلى الأساليب الفردية للروبوت المقابل. يصبح التأكيد هو نفس الخطوة ، دون كسر السلسلة العامة ، ولا تزال اختباراتك لا تعرف شيئًا عن التطبيق.
في التقرير المذكور أعلاه ، يقدم Jake Wharton تطبيقًا في Kotlin ، حيث أنه محدود. لقد جربناه بالفعل في مشروع آخر وقد أحببنا ذلك حقًا.
2. التكامل مع نظام إدارة الاختبار
قبل إدخال التشغيل الآلي ، أجرينا جميع اختباراتنا في نظام إدارة اختبار TestRail. كان الخبر السار هو وجود
واجهة برمجة تطبيقات TestRail جيدة إلى حد ما ، والتي تمكنا من توصيل حالات الاختبار التي تم إنشاؤها بالفعل في النظام مع الاختبارات التلقائية.
أثناء تشغيل الاختبار باستخدام JUnit
RunListener ، يتم
اكتشاف أحداث مختلفة ، مثل
testRunStarted و
testFailure و
testFinished ، والتي نرسل فيها النتائج إلى TestRail. إذا كنت تستخدم AndroidJUnitRunner ، فهو بحاجة إلى إبلاغ RunListener الخاص بك بطريقة معينة ، كما هو موضح في
الوثائق الرسمية
.تحتاج أيضًا إلى التواصل مع مختلف كيانات TestRail بمعرفها. لذلك ، لربط الاختبار بحالة الاختبار المقابلة ، أنشأنا
@CaseId بسيطًا
@CaseId ، يظهر استخدامه في مثال تنفيذ الاختبار أعلاه.
رمز لتطبيق التعليق التوضيحي نفسه:
يبقى فقط الحصول على قيمتها في المكان المناسب من الوصف:
3. التشغيل اليدوي ل autotests على الأجهزة السحابية
بدء تشغيل المعلمة في جنكينز الوظيفة
لتنظيم التشغيل اليدوي للاختبارات التلقائية ، نستخدم
Jenkins Job ذو الطراز الحر . تم اختيار هذا الخيار لأن الشركة لديها بالفعل بعض الخبرة في عمل مماثل مع Jenkins Job في مجالات أخرى ، لا سيما مع مهندسي DevOps ، الذين شاركوه بكل سرور.
Jenkins Job تنفذ نصًا بناءً على البيانات المنقولة من واجهة الويب. وبالتالي ، يتم تطبيق المعلمة من تشغيل الاختبار. في حالتنا ، يبدأ البرنامج النصي Bash في إطلاق الاختبارات على الأجهزة السحابية Firebase.
تشمل المعلمة:
- تحديد ملف APK المرغوب عن طريق تحديد عدد البناء المقابل أو تنزيله يدويًا.
- أدخل جميع أنواع بيانات الاختبار.
- إدخال بيانات مخصصة إضافية لـ TestRail.
- حدد الأجهزة الفعلية المستندة إلى مجموعة النظراء والتي سيتم تشغيل الاختبارات عليها من القائمة المتوفرة في Firebase Test Lab.
- اختيار مجموعات الاختبار التي يتعين القيام بها.
دعونا نلقي نظرة على جزء من صفحة الويب الخاصة بـ Jenkins Job باستخدام مثال لواجهة اختيار الجهاز ومجموعات الاختبار:
كل عنصر حيث يمكنك إدخال أو تحديد أي بيانات يتم تنفيذه بواسطة إضافات Jenkins الخاصة. على سبيل المثال ، يتم إنشاء واجهة اختيار الجهاز باستخدام
المكون الإضافي لـ Active Choices . باستخدام برنامج نصي رائع من Firebase ، يتم الحصول على قائمة بالأجهزة المتاحة ، والتي يتم عرضها بعد ذلك في النموذج المطلوب على صفحة الويب.
بعد إدخال جميع البيانات اللازمة ، يتم إطلاق البرنامج النصي المقابل ، الذي يمكننا ملاحظة تقدمه في قسم إخراج وحدة التحكم:
من هنا ، يمكن للاختبار الذي بدأ تشغيل الاختبار الانتقال إلى TestRail أو إلى وحدة التحكم Firebase باستخدام عناوين URL المستلمة ، والتي تحتوي على الكثير من المعلومات المفيدة حول تشغيل الاختبارات على كل جهاز من الأجهزة المحددة.
مصفوفة الاختبار النهائية في مختبر اختبار Firebase
تحتوي مصفوفة الجهاز في Firebase على توزيع الاختبارات حسب الأجهزة التي تم تشغيلها عليها:
لكل جهاز ، يمكنك عرض السجل الكامل ، والفيديو لتشغيل الاختبار ، ومؤشرات الأداء المختلفة. بالإضافة إلى ذلك ، يمكنك الوصول إلى جميع الملفات التي قد تم إنشاؤها أثناء تنفيذ الاختبارات. نستخدم هذا لتنزيل مؤشرات تغطية الاختبار من الجهاز.
لقد اخترنا Firebase ، حيث استخدمنا هذه الخدمة بالفعل لحل المشكلات الأخرى ، ونحن راضون عن سياسة التسعير. إذا كنت تقابل 30 دقيقة من الوقت الصافي للاختبار يوميًا ، فلن تحتاج إلى الدفع على الإطلاق. قد يكون هذا سببًا إضافيًا وراء أهمية إجراء اختبارات معينة فقط.
قد تفضل بنية أساسية سحابية مختلفة تتناسب أيضًا مع عملية الاختبار.
4. إعادة الاستخدام
كيف يمكن استخدام كل هذا في المستقبل؟ من وجهة نظر قاعدة الكود ، ينطبق هذا الحل فقط على تطبيقات Android. على سبيل المثال ، أثناء التنفيذ ، قمنا بإضافة فصول المساعدة
EspressoExtensions و
UiAutomatorExtensions ، حيث نقوم بتغليف خيارات متنوعة للتفاعل مع الواجهة وننتظر أن تكون العناصر جاهزة. يتضمن هذا أيضًا فئة RunListener ، المسؤولة عن التكامل مع TestRail. لقد وضعناها بالفعل في وحدات منفصلة ونستخدمها لأتمتة التطبيقات الأخرى.
إذا تحدثنا عن منصات أخرى ، فإن الخبرة المكتسبة يمكن أن تكون مفيدة للغاية من أجل بناء وتنفيذ عمليات مماثلة. نحن نقوم بهذا بنشاط في منطقة iOS ونفكر في Windows.
الخاتمة
هناك العديد من الخيارات لتنفيذ واستخدام اختبار التشغيل الآلي. نحن نرى أن الأتمتة هي في المقام الأول أداة مصممة لتسهيل العملية التقليدية للاختبار "البشري" ، وليس للقضاء عليها.