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

الدروس المستفادة من نهج Kite’s Robot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

النظر في الكود:

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

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

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

نهج الروبوت

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

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

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

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

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

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

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

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

مقارنة

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

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

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

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

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

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

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

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

خاتمة

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