🚐 🤘🏽 💆🏿 فقط قل لا لاختبارات نهاية طرفين 🧝🏿 🌿 👩🏾‍🤝‍👨🏻

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

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

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

مصدر

اختبارات نهاية 2-نهاية نظريا

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

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

المطورين يحبون هذه الإستراتيجية ، لأنه يمكنك نقل معظم الاختبارات ، إن لم يكن كلها ، إلى الآخرين.
, , , , , , .
, , ; .

End-2-end

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

افترض أن فريقًا ينشئ خدمة لتحرير المستندات عبر الإنترنت (على سبيل المثال ، محرر مستندات Google). لنفترض أن الفريق لديه بالفعل بنية أساسية رائعة للاختبار. كل ليلة:

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

الموعد النهائي يقترب بسرعة. للحفاظ على مستوى عالٍ من جودة المنتج ، لنفترض أننا قررنا أن 90٪ على الأقل من الاختبارات الناجحة من طرفين إلى نهاية مطلوبة حتى نعتبر أن الإصدار جاهز. لنفترض أن الموعد النهائي يأتي في يوم واحد.

على الرغم من المشاكل العديدة ، كشفت الاختبارات في النهاية عن أخطاء حقيقية.

ما سارت على ما يرام

الأخطاء التي تؤثر على المستخدم تم تحديد وتصحيح قبل أن يصلوا إليه.

هناك خطأ ما

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

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

القيمة الحقيقية للاختبارات

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

هنا الجواب: "اختبار فاشل لا يفيد المستخدم مباشرة".

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

إصلاحات الأخطاء تفيد المستخدم مباشرة.

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

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

بناء التعليقات الصحيحة

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

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

فكر في الحجم الصغير وليس الكبير

فكيف ننشئ حلقة التغذية الراجعة المثالية هذه؟ أفكر في الصغير وليس الأكبر.

اختبار

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

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

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

اختبارات الوحدة مقابل اختبارات النهاية من طرفين

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

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

اختبارات

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

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

هرم الاختبار

حتى مع كل من اختبارات الوحدة والتكامل ، ستحتاج على الأرجح إلى عدد صغير من اختبارات النهاية من طرفين لاختبار النظام ككل. للعثور على التوازن الصحيح بين جميع أنواع الاختبارات الثلاثة ، من الأفضل استخدام هرم الاختبار البصري. فيما يلي نسخة مبسطة من هرم الاختبار من الخطاب الافتتاحي لمؤتمر 2014 Google Automation Automation .

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

بطريقة جيدة ، تقدم Google الفصل 70/20/10: 70٪ من اختبارات الوحدة ، و 20٪ من اختبارات التكامل و 10٪ من اختبارات النهاية من طرفين. ستختلف النسبة الدقيقة لكل فريق ، ولكن بشكل عام يجب أن تحتفظ بشكل الهرم. حاول تجنب "النماذج" التالية:

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

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

وظائف

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

فقط قل لا لاختبارات نهاية طرفين