كيفية خفض التكاليف على الاختبارات الآلية

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



اسمي ماريا سنوبوك ، أنا مدير اتجاه الأتمتة في قسم الاختبار بقسم التطوير والدعم لمنتجات البيانات الضخمة لمجموعة X5 Retail Group. في هذه المقالة ، سوف أشارك تجربتنا في تنفيذ الاختبارات التلقائية وتقليل التكاليف المرتبطة بها. نأمل أن تكون هذه المعلومات مفيدة للفرق التي تكافح من أجل الانتقال إلى الاختبار الآلي.

كيف وصلنا إلى الاختبارات التلقائية

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

• تمكن المطورون الذين سبق لهم التعامل مع وظائفهم المنفصلة من رؤية المنتج بالكامل ؛
• لقد جعلنا الانحدار أسرع وأصدرنا في كثير من الأحيان بسبب هذا ؛
• لم نحد من اللجوء بعد الآن - تحسنت الجودة.

لكنها كانت باهظة الثمن ، لأن الاختبارات تم إجراؤها من قبل متخصصين باهظ الثمن - مطورين ومحللين ، وبدأنا في التحرك نحو الأتمتة.



كانت اختبارات الدخان هي الأولى من نوعها - فحوصات بسيطة للتأكد من فتح الصفحات وتحميلها وعدم تعطلها وأن جميع الوظائف الأساسية متاحة (حتى الآن دون التحقق من المنطق والقيم).



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



وأخيراً وصلنا إلى أتمتة فحوصات الانحدار المتقدمة والسيناريوهات البديلة.







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

أربع طرق لخفض التكاليف على الاختبارات التلقائية

1. الاتفاق على تنسيقات سمات الاختبار على الشاطئ

يحتاج المطورون والمختبرين الآليين إلى الاتفاق مسبقًا على قواعد تسمية عناصر HTML لاستخدامها اللاحق كمحددات مواقع في الاختبارات التلقائية. من المستحسن أن يكون لديك نفس التنسيق لجميع المنتجات. لقد وضعنا متطلبات لفهم كيفية تسمية السمات ، حتى قبل نقل الميزة إلى التطوير ؛ يوجد هذا الفهم من جانب المطورين ومن جانب المختبرين. اتفقنا على أن كل عنصر html مرئي يتم تعيين سمة مخصصة data-qa بواسطتها سيبحث المختبر عنه. تتم تسمية السمة وفقًا للنمط التالي:



[اسم الشاشة] [اسم النموذج / الجدول / عنصر واجهة المستخدم] [اسم العنصر]



مثال:

data-qa = "plu-list_filter-popover_search-input"

data-qa = "common_toolbar_prev-state"



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



أتاح لنا إدخال سمات الاختبار تقليل تكاليف تطوير الاختبارات التلقائية ودعمها بمتوسط ​​23٪ مقارنة بالفترة السابقة من خلال تقليل تكاليف تحديث الاختبارات وتوطين العناصر للاختبارات التلقائية.

2. نكتب الاختبارات اليدوية بحيث يسهل تشغيلها آليًا

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



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



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

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



المشكلة الأولى: تبسيط الحالات اليدوية.



الحل: تفصيل الحالات.



لنتخيل وصفًا لحالة يدوية:

• افتح صفحة قائمة إصدارات المراجعة
• انقر فوق زر إنشاء
• املأ النموذج
• انقر فوق الزر "إنشاء"
• تأكد من إنشاء نسخة المراجعة

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



المشكلة 2: حالة التفريع.



الحل: يجب أن يكون للقضية سيناريو خطي فقط.



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



المشكلة 3: القضية غير ذات صلة.



الحل: فحص الحالات قبل عرضها على الأتمتة.



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



المشكلة 4: الشروط المسبقة غير كافية.



القرار:كومة كاملة من البيانات المساعدة لتنفيذ القضية.



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

الخلاصة: في الشروط المسبقة ، من الضروري كتابة قائمة شاملة بالإجراءات التي يجب القيام بها قبل بدء الاختبار.



المشكلة الخامسة: عمليات تحقق متعددة في سيناريو واحد.



القرار:ما لا يزيد عن ثلاث عمليات تحقق لكل سيناريو (باستثناء السيناريوهات المكلفة والتي يصعب إعادة إنتاجها).



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



المشكلة 6: الشيكات المكررة.



الحل: ليست هناك حاجة لأتمتة نفس الوظيفة مرارًا وتكرارًا.



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



سمح لنا حل المشكلات المذكورة أعلاه بتقليل تكلفة تطوير الاختبارات التلقائية بنسبة 16٪.

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

في قسم البيانات الضخمة لدينا ، حيث تم تطوير 13 منتجًا ، هناك مجموعتان من الأتمتة:

1. الأتمتة مباشرة في فرق المنتج ؛
2. خدمة تدفق الأتمتة خارج فرق المنتج ، وتشارك في تطوير إطار العمل والمكونات المشتركة والعمل على الطلبات الواردة من المنتجات ذات الاختبارات الوظيفية الجاهزة.

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



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



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



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

4. ترقية جهاز اختبار يدوي إلى مهندس أتمتة

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



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



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

النتيجة

الآن قمنا بأتمتة حوالي 30٪ من الاختبارات على خمسة منتجات ، مما أدى إلى تقليل وقت اختبار الانحدار بمقدار الضعف.



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