Get best of the week

لماذا انتقلنا إلى Selenide بكتابة أكثر من 200 اختبار آلي جديد على طول الطريق

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

صورة

قبل أن نصل إلى النقطة ، القليل عن المهمة ككل.

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

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

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

تحديث المكدس


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

Selenide هي أداة شائعة إلى حد ما يوجد بها العديد من الحلول الجاهزة. بعض ميزات Selenide متاحة أيضًا للنظائر - Atlas ، Selenium ، HTMLElements ، إلخ. لكن كل واحد منهم بطريقته الخاصة لم يناسبنا.

السيلينيوم هو أساس السيلينيوم. ولكن لأغراضنا هو مستوى منخفض للغاية. ليس من المنطقي إعادة اختراع العجلة عندما يكون هناك حل جاهز.

ظهر أطلس مؤخرًا. إنه خام بما فيه الكفاية وليس لديه دعم Groovy.
يعد HtmlElements جيدًا للجميع ، ولكنه مهمَّل وغير مدعوم. هناك أيضًا JDI ، ولكن بها مشكلات في سلاسل المهام المتعددة.

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

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

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

بشكل ملائم ، يحتوي Selenide على مجموعة كاملة من الطرق الجاهزة المختلفة.

نظرًا لأنني كنت وحيدًا في الفريق في بداية الانتقال من Serenity إلى Selenide ، كانت الميزة الإضافية هي أن لدي بالفعل خبرة كافية مع Selenide و Groovy ، لذلك يمكنني تنفيذ حلول جاهزة بسرعة وقضاء وقت أقل في دعمها.

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

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

تحديث الاختبار


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

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

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

نظرًا لوجود موارد زمنية غير محدودة ، نحاول دائمًا توجيه الجهود إلى ما سيسمح لنا بتقليل تكاليف العمالة للدعم ، وتغطية الوظائف قدر الإمكان. الآن تجاوزت تغطية الاختبارات الذاتية قليلاً 50٪.


أصبحت الاختبارات المعاد كتابتها على Selenide أكثر إحكاما ودقة بسبب إعادة الاستخدام المتكرر للكود - كل ذلك بفضل قدرات المكتبة نفسها.

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

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


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

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

بالفعل فريق كامل ، تمكنا من تحسين اختبار الانحدار. إذا استغرق الانحدار في وقت سابق 7 أيام من الفريق ، يتم الآن تنفيذ نفس المهام لمدة 4 أيام ، أي قللنا وقت الاختبارات بما يقرب من مرتين.

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

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

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

كاتب المقالة: يوري كودريافتسيف ، متخصص في اختبار البرمجيات المؤتمتة.

ملحوظة: نحن ننشر مقالاتنا على عدة مواقع في Runet. الاشتراك في صفحاتنا على VK ، FB ، إينستاجرام أو قناة برقية للتعرف على كل من المنشورات وغيرها من الأخبار Maxilect.

More articles:


All Articles