من العصر الجليدي إلى المنتقمون باستخدام Appium

دروس من طريقة Kite's Robot

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

هذا هو المكان الذي تأتي فيه الأتمتة في الصورة. ماذا لو قضينا وقتًا في كتابة رمز من شأنه أن يفعل كل هذا العمل الممل لنا؟ ماذا لو نجحت هذه العملية أيضًا بدقة؟

أجرى فريق QA في Kite قدرًا كبيرًا من البحث والتطوير للعثور على الأدوات المناسبة. قررنا Appium ، لأنه:

  1. مفتوح المصدر
  2. لا يتطلب كود المصدر
  3. لا تحتاج إلى أي أجهزة
  4. تتوفر أطنان من مواد الدعم بسهولة

قد يبدو Appium ، بغض النظر ، وكأنه علم الصواريخ لمعظمنا. ومع ذلك ، إذا اتبعت نهجًا مناسبًا ، فمن الممكن الاستفادة الكاملة من قدراته.

في هذا المنشور ، سوف أسلط الضوء على عيوب النهج الكلاسيكي لـ Appium ، وكيف أن نهجنا في الروبوت في Kite يجعل Appium تجربة خالية من المتاعب نسبيًا. استخدمنا نهج الروبوت في تطبيق Kite الأول ، Kite Cash. تم إطلاقه لأغراض التجارب ، وتضخم بشكل عضوي في شبكة تضم أكثر من 100000 مستخدم في أكثر من 1100 مدينة.

النهج التقليدي

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

مع وضع هذه القيود في الاعتبار ، فلنقترب من Appium كقصة.

السيناريو الكلاسيكي

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

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

ما يجب تحقيقه: تمرير اسم المستخدم / كلمة المرور الصحيحة يجب أن يأخذ المستخدم إلى شاشة لوحة التحكم.

  • أدخل اسم المستخدم "hulk@spiderman.com"
  • أدخل كلمة المرور “HS @ 1235”
  • اضغط على زر "تسجيل الدخول"
  • تأكد من ظهور شاشة لوحة القيادة

خذ بعين الاعتبار الرمز:

دعونا نرى ما هي المشاكل الموجودة في هذا النهج:

  1. هناك مستوى عالٍ من تكرار التعليمات البرمجية ، مما يزيد من تدهور أداء الأتمتة.
  2. الرمز أعلاه غير قابل للقراءة. في الشركات سريعة النمو مثل Kite (والعديد غيرها) ، ينضم الأعضاء الجدد إلى فرق فردية طوال الوقت. لن يفهم العضو الجديد هذا الرمز والغرض منه إذا انضم بعد كتابة الرمز.
  3. لن نكون مرتاحين في إدارة هذا النوع من التعليمات البرمجية في المستقبل القريب ، عندما يزيد سير عمل التطبيق.
  4. من الصعب تضمين أي تغييرات جديدة في واجهة المستخدم مضمنة في هذا النوع من التعليمات البرمجية ، لأن الكثير من عمليات إعادة الهيكلة - في نقاط متعددة - يجب أن تتم حتى تعمل مرة أخرى.

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

نهج الروبوت

ماذا لو اتبعنا نهجاً ركزنا فيه فقط على ما نريد تحقيقه؟ وليس كيف نريد تحقيقه؟ سنقوم بعد ذلك بإنشاء فئات مختلفة لـ How and What. وبهذه الطريقة ستكون الفئات كيف وماذا مستقلة عن بعضها البعض.

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

نعتمد حاليًا على مستخدم يدوي لتنفيذ الإجراءات. ماذا لو فعلت الروبوتات كل هذا لنا؟ في نهج الروبوت ، نعلم أن الشاشة تسمح لنا بإدخال اسم مستخدم / كلمة مرور دون الاهتمام بأنفسنا إلى أين تذهب هذه القيم.

سيناريو الروبوت

يوجد روبوت على UsernamePasswordScreenBot ، والذي يمرر القيم في حقول اسم المستخدم / كلمة المرور ، وينقر فوق "تسجيل الدخول". الآن ، تتغير الشاشة ولا يتحكم هذا الروبوت إلا في فئة UsernamePasswordScreenBot. من هنا ، يأخذ روبوت آخر ، على سبيل المثال ، ResultScreenBot لتنفيذ الإجراءات بشكل أكبر على الشاشة التالية.

بمعنى آخر ، قم بإنشاء روبوت لكل شاشة ، وسوف يقوم بتنفيذ الإجراءات المطلوبة.

اجلس واسترخ ودع الروبوتات تعمل من أجلك.

يشرح هذا الرمز ما نريد ، أي أن نتمكن من إدخال اسم مستخدم وكلمة مرور يجب أن يسجلا دخول المستخدم.

مقارنة

دعنا نقارن المقاييس وتغييرات الأداء في النهج الكلاسيكي ونهج الروبوت:

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

نطاق اختبار الروبوت

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

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

توفير الوقت وبناء القدرات

لقد وفرنا قدرًا ملحوظًا من الوقت وزدنا قدراتنا من خلال الانتقال إلى نهج الروبوت.

  1. زادت تغطية اختبارنا مقارنة بالاختبار اليدوي.
  2. لقد قللنا الوقت الذي يستغرقه إكمال العقل من يوم كامل إلى 5-10 دقائق.
  3. لقد قللنا وقت إنشاء النص البرمجي بنسبة 50٪ ، وقمنا بحل مشكلة قابلية التوسع.
  4. باستخدام نهج البرنامج النصي ، يمكننا إنشاء مجموعة انحدار تجعل الاختبار أبسط وأكثر دقة.

استنتاج

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