هل أحتاج إلى الاختبار التلقائي؟ متى تكون هناك حاجة؟ ما هي القيمة التي تجلبها؟
يناقش المقال متى ولماذا هناك حاجة إلى الاختبار على هذا النحو وفي الحالات التي يحتاج إلى أتمتة.
خلال النقاش حول هذا الموضوع الذي عقد في النادي لهم. فرانسيس بيكون ("KifB Web-Meetings" في teleram) ، تبادل الزملاء الخبرات وكتبوا أفكارهم.
هناك حاجة إلى أتمتة الاختبار إذا كان يجلب القيمة. متى يجلب الاختبار نفسه قيمة؟ تم تحديد حالتين.
إذا كانت العملية مصيدة أخطاء في البرنامج قبل الخروج للمعركة
إذا كشف اختبار الإصدار الجديد عن الأخطاء التي تم إصلاحها لاحقًا ، فإن هذا الاختبار لم يذهب سدى.
ولكن ماذا لو عكس الوضع؟ إذا كان الاختبار لم يجد خطأ ، لكنهم ظهروا في المعركة؟ إذا تم اكتشاف أخطاء على طاولة الاختبار (بما في ذلك مقعد الاختبار الذي تم تكوينه بشكل أقرب إلى المعركة).
يزعم أنه في هذه الحالة تم إجراء الاختبار بشكل سيء.
كيفية قياس جودة الاختبار؟ في هذه الحالة ، يكون القياس مناسبًا = عدد الأخطاء في بيئة الاختبار / (عدد الأخطاء في بيئة الاختبار + القتالية). علاوة على ذلك ، يتم قياس عدد الأخطاء بمستوى الأهمية.
ولكن ماذا لو لم يعثر الاختبار على أخطاء ولم يتم العثور عليه على خادم المعركة؟
يُزعم أنه في هذه الحالة ، فإن الاختبار ، على هذا النحو ، لم يحقق قيمة وأن هذه الأعمال تمت دون جدوى (باستثناء الحالة التالية ، والتي سنناقشها لاحقًا). من وجهة نظر ليان ، هذه خسارة.
متى يكون هذا ممكنًا؟ عندما الوحدة النمطية تحت الاختبار لم يتغير. ما يمكن تغيير وحدة؟
- تعديل رمز الوحدة.
- تغيير إصدار المكتبات المستخدمة (بما في ذلك نظام التشغيل وقاعدة البيانات ، وما إلى ذلك). قد يكون التغيير بسبب متطلبات المنظمين ، ولهذا السبب يجب تحديث المكتبة في إطار زمني محدد.
- تغيير الإعدادات أو البيانات التي تؤثر بشكل خطير على سلوك وظيفة عالمية ، والتي يصعب إجراء اختبار شامل لها ، ونتيجة لذلك ، تم التخلي عن الاختبار. الأمثلة على ذلك:
- يمكن أن يؤدي تعيين العروض الترويجية في حلول مثل Siebel CRM أو Oracle ATG إلى تدهور أداء وظائف الحساب الترويجي ، كما أن إمكانية التحقق الشامل غير ممكنة في وقت معقول بسبب المرونة المفرطة في هذه الحلول وتنوعها
- قد يحتوي وصف html لبطاقة المنتج على بنية مستند مكسورة أو أخطاء في وصف رمز js المكتوب بداخله ، والذي يكسر صفحة بطاقة المنتج
- استخدام وظيفة غير مخصص لهذا الغرض (المسامير المطرقة مع المجهر). على سبيل المثال ، أي تغيير في نوع الحمل غير الملازم للمتطلبات ، ونتيجة لذلك ، لا يؤخذ في الاعتبار أثناء الاختبار. على سبيل المثال ، قبل يوم الجمعة الأسود ، يجدر إجراء اختبار حمل منفصل للصفحة المقصودة ، حيث ستذهب الحركة إذا لم تكن هناك متطلبات تحميل من هذا النوع من الصفحات.
- تغيير سلوك API للوحدات النمطية الأخرى التي تستخدمها الوحدة النمطية قيد التطوير. خاصة إذا لم يتم تغطية وظيفة API عن طريق اختبار الانحدار.
نظرًا لأن خيارات التغييرات قد تكون مختلفة ، وإجراء اختبار الانحدار الكامل يكلف مالًا ، فإنه لا يستحق كل الاختبارات. يتمثل أحد خيارات التحكم في تمييز الاختبارات بالعلامات وقبل الاختبار. يحدد مدير الاختبار مجموعة الاختبار التي يجب إرسالها للتنفيذ لجزء معين من التغييرات.
متى أحتاج إلى كتابة اختبارات تلقائية في هذه الحالة؟
بادئ ذي بدء ، لا يلغي الاختبار الآلي إعداد الاختبار ، واختبار التصميم ، وكتابة حالات إعداد الاختبار! ولا يحل محلهم. إذا لم يكن الأمر كذلك ، فلا ينبغي التعامل مع الأتمتة. في الوقت نفسه ، يجب أن لا تُفهم الاختبارات التلقائية على أنها النص نفسه فحسب ، بل وأيضًا التحضير لتشغيلها واستخدام النتائج.
إذا كتبت اختبارات تلقائية بعد إنشاء الرمز ، فسيؤدي ذلك إلى زيادة في time2market (مما سيؤدي تلقائيًا إلى زيادة في رأس المال المتصل). لذلك ، إذا تقرر تغطية الكود باستخدام اختبارات تلقائية ، فعليك كتابة هذه الاختبارات بالتوازي مع الكود الرئيسي ، في نموذج تطوير "TestFirst" أو "TDD".
تتمثل القيمة الرئيسية التي تم إنشاؤها بواسطة اختبار التشغيل الآلي في تقليل time2market بسبب سرعة تحميل الإصدار الجديد.
هناك حاجة إلى اختبارات لضمان أداء العمليات الحرجة.
على الرغم من حقيقة أن السيارة لم تشتعل فيها النيران مطلقًا ، إلا أن وجود مطفأة حريق فيها لا فائدة منه.
يمكن أن يؤدي حدوث خطأ على موقع به عدد كبير من الزيارات لا يسمح بإضافة عنصر إلى السلة إلى خسائر أكبر من تكلفة تطوير واختبار هذه الميزة على مدار العام.
لذلك ، من الضروري تسليط الضوء على العمليات الحرجة التي ستخضع لعمليات الفحص المنتظمة (والتي تستحق القيام بها في حالة حدوث نوع من التغيير). يجب أن تكون الزميلة:
- الخسارة من توقف الوظيفة من وقت الكشف إلى تصحيحها ،
- نفقات الاختبار الدوري اليدوي أو الأتمتة وتنفيذها لاحقا خلال فترة الاسترداد.
ولكن ماذا لو كان الاختبار الدوري لا يجد أخطاء لفترة طويلة ولم تحدث في المعركة؟ ثم الاختبار لا يحقق قيمة ، وبالتالي فإنه ليس من الضروري. متى يكون هذا ممكنًا؟
- الوحدة النمطية قيد التطوير ليست كبيرة جدًا.
- مستقرة ، فريق المختصة للغاية.
- يتم إغلاق التكامل من خلال الاختبارات أو على الجانب الآخر لا توجد تغييرات.
هل من الممكن عدم إجراء الاختبارات على الإطلاق؟
هذا ممكن من خلال إطلاق العديد من عمليات التثبيت للحل واختبار الإصدارات التجريبية الجديدة على القطط ، إذا كان ذلك ممكنًا من الناحية الفنية وإذا تم العثور على هؤلاء المتطوعين. بعد وضع الإصدار الجديد ، تتم مراقبة القياس عن بُعد ويتم إجراء الاستعادة في حالة تدهور المؤشرات. (تذكر أن القياس عن بعد في المعركة يجب أن يكون مستقلاً عن توفر الاختبار).
حالة أخرى من فائدة الاختبار التلقائي للانحدار هي اختبار واجهة برمجة التطبيقات (اختبار عقد واجهة برمجة التطبيقات) ، إذا كانت واجهة برمجة التطبيقات هذه مطلوبة لدعم العملية الحرجة. هذا مهم بشكل خاص إذا غير مطورو وحدة نمطية أخرى شيئًا ما ولم يقوموا باختبار جودة التغييرات من جانبهم.
عندما لا تكون هناك حاجة أتمتة الاختبار
إذا حصلت على كمية كبيرة من الكود الموروث وليس عالي الجودة. تغطية autotests مع مثل هذه الفوضى يزيد الفوضى.
في هذه الحالة ، يجدر تسليط الضوء على الوحدة المنطقية من هذا الحل. بعد تحديد طبقة التفاعل في هذه الوحدة مع باقي الكود ، تحتاج إلى تغطية التفاعل مع الاختبارات التلقائية. سيوفر ذلك ضمانات لسلامة سلوك الوحدة ونزاهتها بعد إعادة ترميزها.
لا تحل الاختبارات التلقائية محل الاختبار اليدوي. يتم إجراء الاختبار اليدوي في أغلب الأحيان بشكل أسرع وأرخص من الكتابة وبعد ذلك يصاحب الاختبارات الذاتية. على وجه الخصوص ، إذا تم إجراء الاختبار بعد تطوير الكود ، عندئذٍ فقط من هذا الاختبار يجب أن تتم أتمتة القطعة التي ستخضع للاختبار المنتظم للوظائف الحيوية.
وأخيراً - قائمة مرجعية لاستعداد الشركة لإجراء الاختبارات الذاتية
لنقم بالحجز على الفور ، هذه القائمة المرجعية ليست للجميع ، بل هي مكتوبة لمختبري الشركات التي يعد تطوير البرمجيات المصدر الرئيسي للدخل فيها.
المرجعية
- ترسم الشركة عملية تسليم الأعمال الرئيسية وتتفهم المكان الذي تتواجد فيه.
- وضعت الشركة عملية تقديم القيمة للعملاء.
- تم إعداد إدارة المهام ، مما يعني أن جميع المعنيين يأخذون المهام إلى الحالة المطلوبة. ويتم تصنيف المهام.
- وضعت الشركة أهداف الاختبار.
- يتم "تمشيط" عناوين المهام في المتعقب ، وبمعنى آخر ، حسب العنوان ، يمكنك فهم نوع المهمة.
- يمكن التحكم في سجل المهام ، في أي وقت يعكس الحالة والسياسة الحالية للمشروع / المنتج.
- هناك سجل للمتطلبات وهو سهل الإدارة.
- هناك تتبع لمتطلبات المهمة.
- هناك تتبع لمتطلبات الاختبار. ومن المعروف ما هي المتطلبات التي تغطيها ما الاختبارات.
- هناك تتبع اختبارات المهمة. ومن المعروف أنه قد تم بالفعل اختبارها أين وكيف.
- هناك مصفوفة لتأثير المكونات على بعضها البعض.
- يتم تتبع المهام إلى المكونات.
- كل شيء على التحكم في الإصدار.
- هناك سياسة معممة لمن وكيف ولماذا. هناك فهم لماذا تدفق git هو نموذج سيء.
- المعايير الحالية: الترميز وغيرها
- هناك ci
- هناك سياسة إطلاق ، حيث يتم تحديد طرق معينة في إصدار معين ، كل ما هو مطلوب.
- يوجد مستودع للأدوات التي يمكنك من خلالها إخراج منتج جاهز للتركيب بشكل فريد.
- هناك سياسة لتمييز القطع الأثرية وفقًا لمعايير مختلفة. تحليل رمز ثابت لا ينسى.
- المنتج اكتساح المتوسطة يرتفع بنقرة إصبع. البيئة هي أيضا على التحكم في الإصدار.
- البيئة مؤتمتة بالكامل للتحقق من صحتها. المنافذ ، إصدار جافا ، ...
- المنتج تتكشف عند النقر مع الاختيار
- تم تكوين المنتج تلقائيًا بالكامل للمهمة المطلوبة. بالمناسبة ، ينطبق هذا أيضًا على تكوينات الأعمال. ويتم فحص هذا أيضًا تلقائيًا.
- لديك طريقة لتوليد جميع بيانات الاختبار اللازمة بشكل متكرر وتلقائي. البرامج النصية الجيل هي أيضا على التحكم في الإصدار وترتبط مع التحف المنتج.
- كل ما سبق يعمل مع أي إصدار من المنتج.
- لديك خط أنابيب للتسليم مسجل داخل سياسة الإصدار.
أخيرًا ، شكرًا لأعضاء المجموعة للمناقشة وساعد في إعداد المقال.