يساعد اختبار التشغيل الآلي على حل العديد من المشكلات في وقت واحد - بما في ذلك عندما يتعلق الأمر بالتطبيقات المحمولة. بدلاً من تنفيذ الإجراءات الروتينية الكثيفة العمالة يدويًا ، يمكن للمتخصصين تفويض جزء كبير منها إلى الأطر. يعمل التنفيذ التلقائي على تبسيط الاختبار ويساعد على تسريع اختبار الانحدار ، كما يتيح استخدام أنواع من الاختبارات التي يتعذر الوصول إليها سابقًا.
سنقوم بمقارنة العديد من الأدوات التي وضعت نفسها في السوق ومواصلة التطوير. ستساعدك هذه المعرفة في اختيار الحل الذي تريد استخدامه لاختبار تطبيق جوال معين.
من غير المحتمل أن تفتح هذه المقالة آفاقًا جديدة للمحترفين ، ولكنها قد تكون مفيدة للمبتدئين الذين قرروا تعلم أساسيات اختبار الأجهزة المحمولة ، وإلى حد ما ، المتخصصين من المستوى المتوسط.
تصنيف الأداة
أول شيء يجب أن تبنيه عليه هو النظام الأساسي الذي يعمل عليه التطبيق. بناءً على ذلك ، نقوم بتصنيف قائمة الأدوات على النحو التالي:
الروبوت- إسبرسو
- واجهة المستخدم الآلي
دائرة الرقابة الداخليةعالمي- التخلص من السموم
- Appium
- رانوريكس
- TestComplete موبايل
أتمتة اختبار تطبيق Android
واجهة المستخدم الآلي
أداة اختبار قوية مع التكامل الخارجي المتقدم. هذا يعني أن هذا الإطار لا يسمح لك فقط باختبار التطبيق نفسه ، بل يمكنه أيضًا "التواصل" مع نظام التشغيل والتطبيقات الأخرى - على سبيل المثال ، تنشيط وإلغاء تنشيط Wi-Fi و GPS وفتح قائمة الإعدادات أثناء الاختبار وإجراء تفاعلات خارجية أخرى.
الغرض من واجهة المستخدم الآلي هو اختبار الصندوق الأسود. هذا يعني أنه يتم إجراء التحليل من موضع المستخدم الخارجي دون الوصول إلى الكود.
وتشمل الميزات الرئيسية:
- UI Automator Viewer لتتبع وتحليل المكونات المعروضة على الشاشة أثناء الاختبار. يوفر معلومات حول العناصر وخصائصها ، مما يسهل إنشاء المزيد من الاختبارات ذات الصلة.
- واجهة برمجة التطبيقات للحصول على معلومات حول حالة الجهاز وتشغيل العمليات عليه.
- واجهات برمجة تطبيقات UI Automator للاختبار عبر النظام الأساسي.
رابط إلى الوثائق .
إسبرسو
أداة أفتح من أداة UI Automator ، وهي ليست مناسبة للتفاعل مع التطبيقات الخارجية ، ولكنها ملائمة لاختبار الصندوق الأبيض مع إمكانية الوصول إلى الكود المصدر لتطبيق معين أو اختبار صندوق رمادي ، الذي لديه حق الوصول إلى بعض العمليات الداخلية والهيكل.
ومع ذلك ، تبرز Espresso مع واجهة برمجة التطبيقات API
https://github.com/hamcrest القوية. تضيف الواجهة طرقًا مريحة للفحوصات التلقائية ، على سبيل المثال:
assert_that (1 ، less_or_equal (2)). لاختبار عرض الويب ، وتستخدم أساليب
خاصة .
UI Automator و Espresso يكمل كل منهما الآخر ويمكن استخدامه معًا في نفس المشروع.
رابط إلى الوثائق .
أتمتة الاختبار لتطبيقات iOS
XCUITest
أداة لاختبار الصندوق الأسود دون الوصول إلى رمز التطبيق. إنه يعمل فقط مع المنتجات المحلية - لسوء الحظ ، لن تعمل اختبارات التطبيق المتقاطع.
من ناحية أخرى ، فإن الطبيعة الأصلية للإطار هي ميزة من وجهة نظر أنه عند استخدام XCUITest ، تكون درجة الفهم المتبادل للمطورين والمختبرين في مستوى أعلى بكثير من الحالات التي يستخدم فيها الآخر والآخر لغات مختلفة.
إضافة مفيدة هي مسجل الاختبار ، الذي يجعل من الممكن كتابة الاختبارات من خلال تسجيل الإجراءات في التطبيق حتى لأولئك الذين لا يعملون مع الكود.
تتيح لك الأداة تجنب الأخطاء الشائعة وغير الضرورية ، والتي يتعذر على المستخدم التلاعب بها. ومع ذلك ، XCUITest لديها أيضا بعض العيوب.
XCUITest ، على عكس Espresso ، يعمل في سلسلة رسائل منفصلة ، أثناء الاختبار ، تحتاج إلى انتظار ظهور بعض العناصر والمعلمات. لا تتم قراءة الحالة الحالية للتطبيق ، وقد يؤدي التأخير في تحديث البيانات إلى عدم القدرة على اكتشاف العناصر المطلوبة.
وثائق XCTest و XCUITest .
EarlGrey
ينصب تركيز EarlGrey على إعادة إنتاج تجربة المستخدم. طالما لم يتم عرض العناصر الموجودة على الشاشة بشكل مرئي ، فلا تبدأ محاكاة العمل مع التطبيق.
في الوقت نفسه ، يتم الإشارة إلى عدد من وسائل الراحة والمزايا. بادئ ذي بدء ، يحب الخبراء الطريقة التي يقوم بها إطار العمل بمزامنة الطلبات ومعرفات المستخدمين والخيوط. لا حاجة للانتظار و الانتظار.
ثانياً ، كما سبق ذكره ، يتم إيلاء اهتمام خاص لتتبع رؤية العناصر. تحتوي الأداة على طبقة إضافية للتحقق من تحميل الواجهة وتعيد إيماءات المستخدم - انتقاد ، نقرات - مباشرة على مستوى حدث التطبيق.
روابط المستودع:
github.com/google/EarlGrey و
google.imtqy.com/EarlGrey .
أدوات عالمية
تتيح لك الأدوات العالمية (أو "يجمع") عدم قصر اختيارك على Android أو iOS فقط ، ولكن أيضًا العمل مع كلتا المنصتين.
هذه الأدوات قابلة للتطبيق لاختبار التطبيقات من الأنواع التالية:
- التطبيقات الأصلية (التطبيقات الأصلية) - تتم كتابتها مباشرةً تحت Android و iOS و Windows SDK.
- تطبيقات الويب للجوال - متوفرة من خلال متصفح للجوال ، مثل Safari أو Chrome.
- التطبيقات الهجينة (التطبيقات الهجينة) - يعمل المستخدم مع غلاف تطبيق الويب ، أي أنه يتفاعل مع محتوى الويب من خلال واجهة التطبيق الأصلي.
التخلص من السموم
في رأينا ، Detox مناسب للتطبيقات المكتوبة في React Native. تتم كتابة الاختبارات في JavaScript ، بينما يتم إنشاء تطبيقات iOS و Android من نفس كود JavaScript وهي متشابهة قدر الإمكان. هذا يسمح لك باستخدام نفس الاختبارات لكل المنصات.
الميزة الرئيسية لـ Detox هي اختبار الصندوق الرمادي. في هذه الحالة ، يتمتع الإطار ببعض الوصول إلى الآليات الداخلية ، مما يسمح لك بربط السلوك الخارجي للتطبيق بما يحدث على مستوى أعمق.
يمكن التخلص من السموم الذاكرة وتتبع العمليات الجارية. يساعد مبدأ المربع الرمادي على مكافحة عدم الاستقرار ، وهو ما ينعكس في حقيقة أنه خلال الاختبار الشامل:
- يمكن أن يتعطل الاختبار بشكل عشوائي حتى بدون تغييرات في الكود ؛
- النتائج ليست حتمية - نظرًا للعدد الكبير من الوظائف والعمليات غير المتجانسة داخل التطبيق ، يمكن أن تختلف نتائج كل عملية إطلاق عن بعضها البعض بشكل غير متوقع.
- يجبر المختبرون على المزامنة يدويًا ، مما يستلزم انخفاضًا في موثوقية وجودة النتائج.
ومن الغريب أن "الصندوق الرمادي" لا يُظهر ثباتًا أفضل فحسب ، بل أيضًا سرعة أعلى مقارنةً بـ "الصندوق الأسود". تجنب جميع أنواع الإيقاف المؤقت ، waitUntil ، يمكن أن يكون الصندوق الرمادي أسرع 5-10 مرات.
لا يحتاج Detox إلى WebDriver ، حيث يعمل مع برنامج التشغيل الأصلي من خلال JSON. ويستخدم الطرق الأصلية مباشرة على الجهاز. داخل هذا الإطار ، يتم استخدام EarlGrey for iOS و Espresso لنظام Android.
يعمل الإطار مع كل من المحاكيات والأجهزة المادية.
رابط إلى الوثائق .
Appium
ميزة Appium هي أنه من الممكن كتابة اختبارات لكل منصة باستخدام واجهة برمجة تطبيقات واحدة ، دون اللجوء إلى تحويل التطبيق إلى أي نموذج خاص متوافق مع الإطار.
عند الاختبار ، يتم استخدام أطر عمل من الموردين - أي أنك تعمل مع التطبيق الأصلي. بالنسبة لنظام التشغيل Android 4.2+ ، على التوالي ، يتم استخدام UiAutomator / UiAutomator2 ، ولإصدار iOS 9.3+ - XCUITest. WebDriver (ويعرف أيضا باسم السلينيوم WebDriver) يستخدم كإطار عمل إطاري.
مبادئ Appium:
- لا حاجة لإعادة ترجمة التطبيق أو تعديله لأتمتة الاختبار.
- ليس من الضروري أن يتم إرفاقك بلغة واحدة أو إطار عمل واحد.
- ليس من الضروري إعادة اختراع العجلة عندما يتعلق الأمر بواجهات برمجة تطبيقات الأتمتة.
يكون استخدام Appium مبررًا عندما تحتاج إلى أداة لأتمتة الاختبار على منصات متعددة مرة واحدة. يكون هذا مفيدًا إذا كان لديك متخصصون لديهم خبرة في اختبار تطبيقات الويب ، ولكن ليس لديهم خبرة في أتمتة اختبار تطبيقات الأجهزة المحمولة.
بشكل عام ، هذه أداة مرنة يمكن تعديلها لتناسب احتياجات المشروع دون الحاجة إلى التكيف مع مجموعة محدودة من لغات التطوير.
رابط إلى الوثائق .
رانوريكس
أداة شاملة مدفوعة الأجر لاختبار تطبيقات سطح المكتب والجوال وتطبيقات الويب. انها تتيح اختبار كل من استخدام البرمجة ودون استخدام البرامج النصية على الإطلاق. يوفر القدرة على الاختبار ليس فقط من خلال المحاكيات ، ولكن أيضًا على الأجهزة الحية.
تتيح لك الأداة إنشاء الاختبارات وتهيئتها ، بالإضافة إلى إدارتها مركزيًا. يمكنك إنشاء اختبار في مركز التحكم وتشغيله في بيئات خارجية مختلفة وعلى أي أجهزة.
يدمج بسهولة مع بيئة CI الحالية الخاصة بك: مع أنظمة إدارة التطبيقات مثل Jira و TFS ، بالإضافة إلى أنظمة التحكم في الإصدار مثل Git و SVN.
لدى Ranorex اختبارات تعتمد على البيانات مع تحميل البيانات من SQL و CSV و Excel.
الأداة مناسبة تمامًا لأي جهاز ، وتدعم الاختبار الموازي على كل جهاز منها.
فهو يجمع بين جميع طرق الاختبار الثلاثة: الصندوق الأسود ، الصندوق الأبيض والرمادي الصندوق.
رابط إلى الوثائق .
TestComplete
بيئة مدفوعة لاختبار التشغيل الآلي لتطبيقات الهاتف المحمول والويب وسطح المكتب. وهو يدعم Android و iOS ، وفي سياق أنواع التطبيقات: التطبيقات الأصلية وتطبيقات الويب والهجين.
تركز الأداة بشكل أساسي على الاختبار الوظيفي والوحدة ، كما توفر القدرة على إجراء العديد من أنواع الاختبارات الأخرى:
- الانحدار.
- اختبار يحركها البيانات.
- اختبار الموزعة وأكثر من ذلك.
يوجد مسجل في TestComplete - يتم فيه إنشاء الاختبارات من خلال تسجيل الإجراءات وإعداد الأوامر في المحرر. ثم يمكن إطلاقها إما مباشرة في الأداة نفسها أو تصديرها إلى تطبيقات الطرف الثالث.
تتعرف هذه الأداة على الكائنات وعناصر التحكم من خلال تقديم أوامر خاصة لمحاكاة تفاعل المستخدم معها. يتكامل مع Jenkins و Git و Jira ، مما يسمح لك بإجراء اختبار سلس مستمر.
رابط إلى الوثائق .
لتلخيص
عند التخطيط لاختبار هذا التطبيق المحمول أو ذاك ، انتبه للأدوات المذكورة أعلاه. كل واحد منهم لديه خصائصه الخاصة ، وأحيانا القيود.
لنلقِ نظرة على مثال. إذا كنت تواجه مهمة اختبار تطبيق صغير في وقت قصير ، فأولًا ، عليك أن تأخذ في الاعتبار عوامل مثل نوع التطبيق الذي يتم اختباره وتجربة المتخصصين لديك. إذا كتب مطور اختبارات ، فمن الأفضل اختيار لغة أصلية وأداة لمنصتها (انظر الجدول أدناه). إذا تم إجراء الاختبارات من قبل متخصصي SDET الذين لديهم دراية بلغات أخرى (Java و JavaScript و Python وما إلى ذلك) وعملوا مع Selenium ، فمن المريح استخدام Appium. إذا لم يكن هناك فريق عمل فني ذو خبرة في الفريق ، وسيقوم خبراء ضمان الجودة بكتابة الاختبارات ، فمن الأفضل اختيار أطر عمل مدفوعة الأجر ، حيث لديهم أدوات لتسجيل الاختبارات ودعم فني أكثر ثباتًا من أطر عمل مفتوحة المصدر.
من ممارستنا:
لقد عملنا مع متجر واحد على الإنترنت يحتوي على تطبيقين للهاتف المحمول - على نظامي iOS و Android. لاختبار سيناريوهات المستخدم الرئيسية مع الاختبارات ، اخترنا Appium لعدة أسباب:
- عبر منصة ، والقدرة على إعادة استخدام رمز جزئيا
- مناسبة للاختبارات نهاية إلى نهاية ، يمكن أن تعمل مع شبكة الإنترنت
- وجود في فريق من المتخصصين الذين يدركون جيدا السيلينيوم ، الذي بمثابة قذيفة من هذا الإطار.
نتيجة لذلك ، حقق Appium توقعاته بالكامل ، لقد نجحنا في إجراء اختبارات لنظامي التشغيل iOS و Android. يجب أن يؤخذ في الاعتبار أن مثل هذه الاختبارات الشاملة مع Appium لا يتم تنفيذها على كل طلب دمج ، لأنه يأخذ الكثير من الوقت.في الختام ، نلفت انتباهك إلى جدول يساعدك في اختيار الأداة لمشروعك. تجدر الإشارة إلى أنه في بعض الحالات ، يكون الانقسام في الجدول مشروطًا. في مكان ما للبساطة ، يتم التعميم ويتم إعطاء المعلمات الأساسية فقط. تتطور أدوات الاختبار باستمرار ، لذلك عند اختيار إطار عمل ، من المهم التحقق من الوثائق الحالية.
شكرا لاهتمامكم!