Appium مقابل الأطر الأصلية: مقارنة

بقلم كوروس عليبادي وروهان جانجوا

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

هناك أدوات تلقائية بديلة هناك ، ولكن في سياق منشور المدونة هذا ، سنقوم بتقييد أنفسنا على هذا Appium والأدوات الأصلية الافتراضية لنظامي iOS و Android: XCUITests و Espresso على التوالي.

Appium:

كانت Appium أداة defacto لأتمتة الأجهزة المحمولة على مدار السنوات القليلة الماضية ، حيث توفر تجربة تشبه السيلينيوم. حتى الآن كانت واحدة من أكثر الخيارات قابلية للتطبيق من الناحية المهنية بسبب عدد من الأسباب.

  1. أولاً ، أنها لغة لا أدرية ، تأتي مع دعم لمجموعة واسعة من اللغات الشائعة. إذا كانت لغتك المفضلة بها عميل webdriver ، فيمكنك استخدام Appium. هذا يرجع إلى jsonWireProtocol المشتركة. هذا مريح للغاية لأنه يتيح لمطوري الاختبار التقاط الأداة بسرعة. تشمل اللغات المدعومة ، على سبيل المثال لا الحصر ، Java و C # و JavaScript و Python و ruby.
  2. الأمر بسيط للغاية لالتقاط الصور والبدء فيها بسهولة. على غرار النقطة السابقة ، فإن Appium لديها الكثير من أوجه التشابه مع webdriver السيلينيوم. فائدة ذلك هي أنه إذا تم استخدام مطوري الاختبار لكتابة اختبارات ويب السيلينيوم webdriver ، فيجب أن يكون Appium بسيطًا نسبيًا لالتقاط الصور وبديهية للغاية.
  3. يتيح Appium اختبار منصات متعددة من نفس قاعدة رمز الاختبار. بالنسبة لأولئك الذين يعملون في فريق اختبار مركزي أو فريق يعمل عبر كل من نظامي التشغيل iOS و Android ، يمكن أن يقلل من مقدار شفرة الغلاية المطلوبة للعمل مع البنية التحتية للاختبار ومحاكاتها.
  4. بالإضافة إلى ذلك ، في تجربة بعض مهندسي الاختبار لدينا ، يكون دعم التطبيقات المحلية التي تستخدم مقابلات الويب أفضل على Appium من معظم المنافسين الآخرين. يمكن أن يكون الدعم المقدم من Appium لا يقدر بثمن عندما يتعلق الأمر بأتمتة التطبيقات الهجينة.

هناك أيضًا بعض عيوب استخدام Appium:

  1. في تجربتنا ، تعمل اختبارات Appium أبطأ بكثير من الاختبارات المكتوبة في XCUITests أو Espresso
  2. رمز الاختبار لا يتماشى مع شفرة التطوير. الآن قد يكون هذا الأمر للنقاش ، لكننا نشعر بقوة أن كود الاختبار ورمز ديف يجب أن يعيشا بالقرب من بعضهما البعض.
  3. لاختبار تطبيقات النظام الأساسي ، سيكون هناك دائمًا درجة من التعقيد التقني في Appium. عليك إما:
  4. احتفظ بمجموعتين من PageObjects / ScreenObjects التي تلتزم بعقد واحد بحيث يمكن استدعاؤها من مجموعة واحدة فقط من الاختبارات.
  5. اكتب 2 مجموعات من الاختبارات
  6. تأكد من أن المطورين يستخدمون نفس المعرف في كلتا التطبيقات

الأدوات الأصلية:

أصبح النظامان الرئيسيان لتطوير التطبيقات الآن أدوات أتمتة واجهة مستخدم تنافسية للغاية: XCUITest و Espresso. تحسن نضج هاتين الأداتين بشكل كبير وفي حديث حديث في WWDC 2017Apple أوضحت أنها نشطة للغاية في العمل على تحسين أدوات أتمتة واجهة المستخدم الخاصة بها.

  1. هناك ميزة أساسية لاستخدام XCUITest و Espresso: يتم إنشاؤها بواسطة موفري النظام الأساسي: Apple و Google. ستكون هذه الأدوات دائمًا في مقدمة اختبار iOS و Android. أي ميزة جديدة من Appium ستُبنى في معظم الحالات على وظيفة الأداة الأصلية الحالية.
  2. فائدة رئيسية أخرى في أعيننا هي أنك ستضمّن رمز الاختبار مع الكود المصدري لمشروعك. ربما يكون هذا للمناقشة قليلاً لكننا سنناقش هذا في منشور مستقبلي. في الوقت الحالي ، سنذكر فقط أننا نعتقد أن تضمين شفرة الاختبار الخاصة بك في نفس المشروع وباللغة نفسها التي يستخدمها مطوروك لها فوائد كبيرة. يوفر حافزًا أكبر للتعاون داخل الفريق ويسمح للجميع بالمساهمة بسهولة في هذا الجانب من تطوير البرمجيات.
  3. في بعض الأحيان ، من المفترض أن تكون تجربة Android مختلفة عن تجربة iOS ، وذلك بكتابة اختباراتك لكل منصة لا تحتاج إلى تعقيد إطار الاختبار الخاص بك للتعامل مع هذه المواقف.
  4. أقل بكثير قشاري. الأدوات المحلية فقط أقل تقلبًا. قد يكون له علاقة مع عدد أقل من الأجزاء المتحركة وأقل طبقات الاتصال بين رمز الاختبار والأجهزة ، ولكن يبدو أن الاختبارات المكتوبة باستخدام الأدوات الأصلية أقل تقلبًا.
  5. يمكنك استخدام مجموعة أدوات أكبر بكثير مما إذا كنت تستخدم أداة مثل Appium. على سبيل المثال مع Android ، يمكنك الوصول إلى كل من مكتبة UiAutomator ومكتبة Espresso.

إسبرسو:

تحتوي أداة اختبار Google التي تعمل بنظام أندرويد من Google على بعض الميزات الرائعة التي تستحق الذكر.

  1. الإسبريسو سريع للغاية ، لم نر شيئًا سريعًا في أتمتة واجهة المستخدم. إنه يشبه أتمتة Flash of UI ، ولا تقترب أي أداة أخرى من سرعتها.
  2. لا داعي للقلق بشأن انتظار حدوث الأشياء أو إنهاؤها في شفرة الاختبار الخاصة بك ، حيث يقوم Espresso بمعالجة ذلك نيابةً عنك ، باستثناء بعض الحالات الاستثنائية. هذا بشكل أساسي يأخذ الشيء الأكثر هشاشة حول أتمتة واجهة المستخدم خارج المعادلة.
  3. تتخذ شركة اسبريسو مقاربة "الصندوق الرمادي". ليس الصندوق الأسود تماما ، وليس أبيض تماما. مع espresso ، يمتلك المختبر تحكمًا كبيرًا في التطبيق أكثر من أداة الصندوق الأسود مثل appium.
  4. يتيح Espresso للمختبر الاستفادة من أدوات مثل Robolectric ، وهو إطار لتشغيل Android SDK دون بدء تشغيل جهاز محاكاة أو توصيل جهاز. ما يعنيه هذا هو أن اختباراتك تبدأ بشكل أسرع ، وتعمل بشكل أسرع أيضًا.

يوجد إطار مشابه لإسبرسو ، الذي أنشأته Google أيضًا ، لاختبار iOS الذي يستحق الذكر هنا: EarlGrey. لم نستخدمها ، ولكن إذا جلبت بعض فوائد Espresso إلى نظام iOS ، فهذا أمر يستحق الاستكشاف.

هناك أيضًا بعض عيوب استخدام أدوات الاختبار الأصلية:

  1. إذا كنت تقوم بتطوير تطبيق عبر منصة ، فمن المحتمل أن تضطر إلى الحفاظ على ضعف عدد الاختبارات مقارنة بما إذا كنت تستخدم أداة مثل Appium.
  2. إذا كنت تقوم بتطوير تطبيق عبر النظام الأساسي ، فستحتاج إلى معرفة لغتين.
  3. مزيد من التعقيد يمكن أن تشارك في هذا النهج. هذا هو أحد الآثار الجانبية لقدرة الوصول والوصول الإضافية التي يمكن أن تقدمها أداة مثل Espresso للاختبار. على سبيل المثال ، ينتظر Espresso تلقائيًا استكمال الأحداث في التطبيق قيد الاختبار باستخدام IdlingResource. ولكن في بعض الحالات ، سيتعين على المختبر تطبيق IdlingResource يدويًا.
  4. باستخدام أداة مثل Espresso ، يمكن للمختبر وضع التطبيق في حالة قد يتعذر عليه الوصول إليها من منظور المستخدم. مرة أخرى ، هذا هو الجانب الآخر من الطاقة الإضافية التي تحصل عليها.