اختبار مقاومة الأتمتة

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

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

جمعت كل الاعتراضات في هرم برمجة موثوقة ، والتي تتضمن أربعة مستويات:

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

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

اعتراضات ثقافية

"برامجي لا تنكسر. لا أرى حاجة للاختبار ".

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

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

في إحدى المقابلات التي أجريت ، جرى الحوار التالي:

- هل لديك مهارات الاختبار التلقائي؟
- لا ، لقد كتبت برامج بسيطة ، لم يكن هناك شيء للكسر.
- ما هو دافعك لتغيير الوظائف؟
- أريد أن أكتب تطبيقات معقدة.

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

عدم الرغبة في تحمل مسؤولية جودة الشفرة للاختبار.

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

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

"اكتب الآن بدون أخطاء"

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

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

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

اعتراضات الإدارة

"مع الاختبارات ، تعد كتابة البرنامج ضعف المدة. لن نلتزم بالمواعيد النهائية ".

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

الاختبارات الآلية لها عدة وظائف:

1. التحقق .
   1.1. تتحقق الاختبارات من أن كائن الاختبار يعمل بشكل صحيح.
   1.2. تتحقق الاختبارات من جودة عمل المبرمج: سواء تم حل المهمة ، وما إذا كانت هناك أي آثار جانبية في شكل الانحدارات.
2. التشخيص . يمكن أن تقلل الاختبارات التشخيصية بشكل كبير من وقت البحث عن العيب. تسمح لك الاختبارات بتحديد موقع الخطأ بدقة للفئة والطريقة ، وأحيانًا دقيقة لسطر التعليمات البرمجية.
3. أتمتة . تسمح لك الاختبارات بإدخال كائن الاختبار بسرعة وسهولة في الحالة المطلوبة لتصحيح الأخطاء.
4. التوثيق .
   4.1. تسجل اختبارات القبول متطلبات العميل للمنتج قيد التطوير.
   4.2. تظهر الاختبارات أمثلة على استخدام المكون المطور ، مما يقلل من الوقت الذي يقضيه مبرمج آخر في دراسة عمل النظام.

في إحدى المنظمات التي استشرتها ، قاوم المدير إدخال ثقافة الاختبار التلقائي:

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

مؤسستنا تفترض: "مع الاختبارات ، كتابة البرنامج أسرع مرتين!" ولم يتم مناقشة هذه الفرضية. تتم مناقشة المعامل 2 فقط - في بعض الأحيان يكون هناك 3 و 4. وبعض المشاريع ببساطة لا يمكن إكمالها بدون اختبار تلقائي كفء (انظر المشروع المثقل).

"لدينا بالفعل قسم اختبار يدوي ، دعهم يختبرون."

للوهلة الأولى ، يبدو الفصل بين التخصصات في الاختبار والبرمجة منطقيًا.

ولكن دعونا نلقي نظرة على عيوب الاختبار اليدوي:

• إنه مكلف للغاية.
• يستغرق وقتا طويلا جدا. على سبيل المثال: نص الاختبار الخاص بأداة اختبار "Mobile Cinema" لتطبيقات الهاتف المحمول يستغرق 40 ساعة. وهذا فقط لمنصة واحدة! إذا كنت بحاجة إلى اختبار التطبيق على iPhone و iPad و Apple TV و Android و Fire TV ، فأنت بحاجة إلى قضاء 40 × 6 = 240 ساعة من وقت العمل ، هذا شهر ونصف ، وهو أمر غير مقبول لدورات التطوير القصيرة.
• يخضع الاختبار اليدوي لأخطاء بشرية شائعة - لا يعطي نتيجة موضوعية وحقيقية.

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

1. وظيفة لاستيراد ملفات CSV.
2. موزعي المستندات النصية.
3. الأدوات المالية.

اعتراضات مستوى الأسلوب

جهل طرق الاختبار الآلي.

بسبب أزمة التعليم ، لا توجد تخصصات للاختبار التلقائي في أي مكان في الجامعات. هناك عدد قليل جدًا من هذه الدورات التدريبية في مدارس تكنولوجيا المعلومات التجارية. والدورات الحالية سطحية وذات نوعية رديئة. لذلك ، غالبًا ما قابلت ذهولًا بين المبرمجين: فهم لا يعرفون كيفية اختبار التطبيقات غير العادية (أكثر صعوبة من 2 + 2 = 4).

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

المبرمجون لا يعرفون ما يكتبون ، وكيف يبدو ، وما هي الوظائف والواجهات.

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

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

رمز غير لائق.

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

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

في مواجهة نظام غير مناسب ، يستسلم المبرمج ويتجنب اختبار مثل هذا النظام.

إعداد بيانات الاختبار.

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

الحل:

• تطوير القيم والأمثلة المرجعية في مرحلة تطوير اختبارات القبول - ستساعد أيضًا في حل النزاعات مع العميل في مرحلة قبول العمل ؛
• تطوير القيم المرجعية في مرحلة تصميم النظام. على سبيل المثال ، طلبات واستجابات HTTP القياسية - ستساعد على دمج العميل والخادم بشكل أسهل ؛
• تطوير إجراءات خاصة لتجميع قواعد البيانات ، حيث يتم إنشاء الحالة المطلوبة لقاعدة البيانات تلقائيًا ، وليس يدويًا
• استخدام قالب Object Object [Fowler و Schuh و Peter و Stephanie Punke. "تسهيل إنشاء كائن اختبار في XP." XP الكون. 2003] ، مما يساعد على تخصيص الكائنات وتهيئتها بسهولة في الحالة المطلوبة.

خدمة الاختبار.

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

الحل:

• استخدام قالب "المحول" لفصل منطق الاختبار من الواجهة التي يتم اختبارها ؛
• استخدام اختبارات عالية المستوى (غيركين ، خيار ، معطى وقت-ثم) ؛
• انظر حل المقاومة "إعداد بيانات الاختبار".

الخلاصة

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

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

توضح المقالة فقط المشاكل ولا تكاد تلامس طرق حلها. بشكل عام ، تبدو لي استراتيجية حل هذه المشاكل كما يلي:

1. تشكيل وتعزيز ثقافة جديدة لتصميم تكنولوجيا المعلومات ، وهي الموثوقية والفخر والمسؤولية الشخصية عن النتيجة.
2. تطوير معايير عالية جديدة لاختبار الكود.
3. تطوير وتنفيذ الدورات التدريبية.
4. إدخال الحافز في مهنة المبرمجين والمديرين ، المرتبط بجودة منتجات البرمجيات التي يتم تطويرها ، بالإضافة إلى مهارات الاختبار التلقائي.

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

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