هناك حاجة إلى اختبارات السيارات على المشاريع. ولكن ، كما يقولون ، يمكن أن تكون الأتمتة حسب الذوق واللون مختلفة. لقد جئنا إلى مشروع حيث كانت هناك اختبارات تلقائية بالفعل ، وتمكنا من تحسين التغطية وتسريع مرور الاختبارات دون حدوث ثورة أساسية. تحت القط حول كيف فعلنا ذلك.
بضع كلمات عن المشروع
على الرغم من أننا لا نستطيع الكشف عن تفاصيل المشروع بسبب NDA ، بعبارات عامة ، كانت المهمة على النحو التالي. لقد انضممنا إلى تطوير خدمة API fintech ، والتي تفاعلت مع قاعدة البيانات ، وأعادت الأشياء المالية اللازمة (الأسعار ، التعريفات ، وما إلى ذلك). كانت مهمتنا هي اختبار عملاء الأجهزة المحمولة لهذه الخدمة - سواء على الويب أو تطبيقات الهاتف المحمول المحلية.
اختبار الأتمتة في هذا المشروع تم تطويره تدريجيًا ، جنبًا إلى جنب مع تعقيد الخدمة. ربما هذا هو الوقت الذي ظهرت فيه الاختبارات من البداية إلى النهاية في وقت واحد ، والتي وجدناها في المشروع. معظمهم لم يعمل بحلول ذلك الوقت ، لأن الخدمة قد تغيرت ، ولم يكن هناك أحد لدعم الاختبارات - مهندس الأتمتة الوحيد غادر المشروع قبل وقت طويل من وصولنا.
حتى تلك الاختبارات التي يبدو أنها تتوافق مع الوظيفة قد انخفضت أحيانًا بسبب الارتباك مع الإصدارات أو عدم إمكانية الوصول إلى الموارد الخارجية. للاختبار ، تم استخدام بنية أساسية منفصلة - مقاعد الاختبار ، حيث تم نشر الإصدارات اللازمة للتجارب. تمكنت مجموعات العمل المختلفة من الوصول إليها ، ولم تتصرف دائمًا بشكل جماعي. نتيجة لإجراءات مجموعة واحدة ، قد تسقط بعض واجهات برمجة التطبيقات المهمة التي تستخدمها خدمتنا ، بسبب توقف اختبار عملي عن النجاح. أي لم يعد الاختبار يُظهر قابلية الخدمة للخدمة نفسها ، بل يتعلق بالبنية التحتية للاختبار ككل.
كيف وصلنا إلى الفوضى
يبدو أنه في هذه الحالة ، من الضروري التخلي عن جميع الإنجازات القديمة وبناء الاختبار من جديد. لكننا تصرفنا أكثر "إنسانية". تم الحفاظ على هيكل الاختبار نفسه ، مع التركيز على حل مشاكل محددة - بطء مرور الاختبارات ، وعدم استقرارها وعدم كفاية تغطية حالات الاختبار. لكل منهم كان هناك حل.
إعادة بيع ديون
بادئ ذي بدء ، أعدنا جزئياً كود الاختبارات القديمة ، بالاعتماد على أنماط تصميم أكثر حداثة.
يجب إزالة جزء من الشفرة القديمة - كان من الصعب للغاية الحفاظ عليه. في جزء آخر ، اكتشفنا جميع نقاط الضعف - فقد استبدلنا النوم الافتراضي بنوادل انتظار عادية ، وأعدنا الاستعدادات لجميع الاختبارات في الإعداد العالمي عبر التعليقات التوضيحية لمرشحي الاختبار ، إلخ. خفضت العديد من الخطوات الصغيرة متوسط تمرير الاختبار من النهاية إلى النهاية من 3-4 إلى 1-2 دقائق.
النهج الذري
لتسريع إنشاء اختبارات جديدة وتبسيط دعم الاختبارات القديمة ، انتقلنا من حالات نهاية إلى نهاية مرهقة.
أنا شخصياً ، ليس لدي أي شيء ضدّ الاختبار الشامل ، ولكن في حالة الحاجة إلى فحص شاشة واحدة محددة (أو حتى جزء من المعلومات الموجودة عليها) ، فإن متابعة جميع الخطوات ، بدءًا من ترخيص المستخدم ، باهظ الثمن. تخيل أننا نختبر متجراً عبر الإنترنت ونحتاج فقط إلى التحقق من الشيك الذي سيتم إرساله إلى المشتري بعد شراء منتج معين. بدلاً من إحضار شاشة واحدة فقط من النظام ، سنعمل على تسجيل الدخول وكلمة المرور واختيار المنتج وتأكيد الشراء وما إلى ذلك. - ستقوم بالعديد من الخطوات التي لا تتعلق بمهمة اختبار محددة. ولكن كل خطوة تستغرق وقتا. حتى مع إجراء كل التحسينات ، استغرق إطلاق الاختبار الشامل حتى دقيقتين ، بينما استغرق التحقق من شاشة معينة 10 ثوانٍ فقط. لذلك ، حيثما كان ذلك ممكنًا ، انتقلنا إلى عمليات الفحص "الذرية" هذه ، بالإشارة فقط إلى الشاشة التي تهمنا كجزء من حالة الاختبار.
على طول الطريق ، لمقارنة الشاشة فقط ، قمنا بتنفيذ اختبار اللقطة ، والذي يسمح لك بالتحقق من نصيب الأسد من واجهة المستخدم. بعد إجراء الاختبارات ورمز التطبيق في مستودع واحد ، يمكننا استخدام طرق هذا التطبيق في الاختبارات ، أي رفع أي شاشات اللازمة في هذه العملية. حتى نتمكن من العثور على أخطاء في مقارنة لقطات اختبار مع تلك المرجعية.
لدينا الآن حوالي 300 اختبار لقطة ، وعددهم ينمو تدريجياً ، لأن هذا النهج يمكن أن يقلل بشكل كبير من الوقت الذي يستغرقه للتحقق من الإصدار النهائي قبل إرساله إلى الإنتاج. تبدأ هذه المجموعة الكاملة من الاختبارات تلقائيًا عند فتح طلب السحب وتشغيله في غضون 40 دقيقة - حتى يتلقى المطورون تعليقات حول المشكلات في الفرع الحالي بسرعة.
بالطبع ، تم الحفاظ على عدد من الاختبارات الشاملة. لا يمكنك الاستغناء عنها حيث تحتاج إلى التحقق من سيناريوهات الأعمال الكبيرة ، ولكن من المنطقي تشغيلها عندما يتم التحقق من جميع التفاصيل بالفعل.
Mokirovanie
لاستبعاد تأثير طاولة الاختبار غير المستقرة على نتيجة إطلاق اختباراتنا ، أطلقنا خادمًا وهمية. حول القرارات التي درسناها بعد ذلك ولماذا اخترت Okhttpmockwebserver ،
لقد كتبت بالفعل على حبري .
نتيجة لذلك ، انخفضت حصة السقوط العرضي بسبب الأسباب الخارجية للاختبارات بشكل كبير.
Kotlin DSL
في موازاة ذلك ، جعلنا الاختبارات أكثر قابلية للقراءة.
يعرف المشاركون في اختبار واجهة المستخدم مدى صعوبة العثور على الحقيقة بين مجموعة من المواقع في "قاعدة القدم" الطويلة للاختبار (خاصة في المرحلة التي كان لا يزال فيها الاختبارات من النهاية إلى النهاية). من السهل التنقل فيها عندما كنت في مشروع لمدة عامين وحتى في منتصف الليل يمكنك تذكر ما هو. لكن إذا جئت للتو ، فإن الانتقال إلى ما يحدث هو مهمة كبيرة منفصلة. حتى لا يضطر الأشخاص الجدد للتعامل معها في كل مرة ، قررنا التبديل إلى Kotlin DSL. يتم تنفيذه بكل بساطة وله بنية بسيطة ومفهومة. في السابق ، كانت الاختبارات تتألف من مجموعة من المكالمات ذات المستوى المنخفض المتطابقة - النقرات ، إدخال النص ، مخطوطات ، ولكن كل هذا تحول الآن إلى شيء أكثر "نشاط تجاري" - شيء يشبه نهج BDD. كل شيء مرئي ومفهوم.
في رأيي ، هذا جعلنا احتياطي معين للمستقبل. واجه هذا المشروع بالفعل رحيل مهندس أتمتة واحد. بالنسبة للاختبارات ، لم ينتهي هذا بأفضل طريقة - لقد توقفوا ببساطة عن دعمهم ، لأن عتبة الدخول كانت مرتفعة للغاية. فهم مثل هذا الرمز الجاف يتطلب الكثير من الوقت ومؤهلات معينة. لقد أعدنا تصميم الاختبارات بحيث يكون من الممكن نقل الأشخاص بسرعة من مشاريع أخرى أو من الاختبار اليدوي إلى التشغيل الآلي في أي وقت. يمكن لأي شخص تقريبًا كتابة أبسط الاختبارات على Kotlin DSL. لذلك يمكن للأتمتة أن تترك التنفيذ على مستوى منخفض ، وأن تكتب بسرعة اختبارات بسيطة جديدة لتوصيل الأشخاص من الفريق الوظيفي. لديهم معرفة كافية بمنطق الأعمال ، وسوف يستفيد المشروع من حقيقة أنهم سيكونون أكثر مشاركة في عملية كتابة الاختبارات الذاتية. يسمح لك Kotlin DSL بوصف حالات الاختبار تمامًا كما يرغبون في رؤية جميع عمليات الفحص ، مما يترك تنفيذ أساليب منخفضة المستوى خارج نطاق عملهم.
بشكل عام ، كل هذا جعل من الممكن زيادة تغطية الاختبارات الذاتية بشكل أسرع. إذا تطلب الأمر في وقت مبكر من 16 إلى 20 ساعة لتنفيذ مجموعة الاختبار الجديدة ، ثم مع النهج الجديد ، وهذا يتوقف على مدى تعقيد الاختبارات ، ويستغرق الأمر من 4 إلى 12 ساعة (وتم تخفيض تكاليف العمالة للدعم من 16-24 إلى 8-12 ساعات في الأسبوع).
مؤلف المقال: رسلان عبدالدين.
ملاحظة: ننشر مقالاتنا على عدة مواقع من Runet. اشترك في صفحاتنا على
VK أو
FB أو
Instagram أو
قناة Telegram للتعرف على جميع منشوراتنا وغيرها من أخبار Maxilect.
PPS ساعدنا في جعل مقالات المدونة الخاصة بنا أكثر إثارة:
docs.google.com/forms/d/e/1FAIpQLSeqnPceNuK-JopYVxgF15gNWLIi5oM_AZesioCDGXhvr7Y7tw/viewform .