ما هو الاختبار التلقائي؟
في هذه الوحدة، ستتعرف على ميزات الاختبار التلقائي وأنواع الاختبارات التي يمكنك إجراؤها. ستتعلم أيضاً ما الذي يجعل الاختبار ناجحاً وتتعرف على بعض أدوات الاختبار المتوفرة لك.
ما هو الاختبار التلقائي؟
يستخدم الاختبار التلقائي البرامج لتنفيذ التعليمات البرمجية ومقارنة النتائج الفعلية بالنتائج التي تتوقعها. قارن هذا بالاختبار الاستكشافي أو اليدوي، حيث يتبع الإنسان عادة الإرشادات في خطة الاختبار للتحقق من أن البرنامج يعمل كما هو متوقع.
الاختبار اليدوي له فوائده. ولكن مع نمو قاعدة التعليمات البرمجية الخاصة بك في الحجم، يمكن أن يصبح اختبار جميع الميزات يدويا (بما في ذلك حالات الحافة) متكررا ومملا وعرضة للخطأ. يمكن أن يساعد الاختبار التلقائي في التخلص من بعض هذا العبء وتمكين المختبرين اليدويين من التركيز على ما يفعلونه على أفضل نحو: ضمان حصول المستخدمين على تجربة إيجابية مع برنامجك.
هرم الاختبار
عندما نفكر في الاختبار التلقائي، من الشائع فصل الاختبارات إلى طبقات. يقترح مايك كون هذا المفهوم، المعروف باسم هرم الاختبار، في كتابه نجاح مع Agile.
على الرغم من أن هذا نسخة مبسطة من نموذج Cohn، إلا أن المفهوم يوضح أنك تركز معظم جهودك على كتابة الاختبارات التي تتحقق من المستويات الأساسية لبرنامجك (وسيلة الشرح 1 في الهرم)، مثل الوظائف والفئات والأساليب. يمكنك التركيز تدريجيا على جهد أقل حيث يتم دمج الميزات، مثل طبقة واجهة المستخدم (UI) (وسيلة ال شرح 2 في الهرم). الفكرة هي أنه إذا كان يمكنك التحقق من أن كل مكون من مكونات المستوى الأدنى يعمل كما هو متوقع في عزلة، فإن الاختبارات على المستويات الأعلى تحتاج فقط إلى التحقق من أن مكونات متعددة تعمل معا للحصول على النتيجة المتوقعة.
متى يجب كتابة الاختبارات؟
تعتمد الإجابة بشكل أساسي على احتياجاتك وخبراتك في كتابة الاختبارات.
لم يفت الأوان أبدا لبدء إضافة اختبارات للتعليمات البرمجية التي كتبتها ونشرتها بالفعل. ينطبق هذا بشكل خاص على الميزات التي غالبا ما تقطع أو تتطلب أقصى جهد من فريق الاختبار الخاص بك.
عند ربط الاختبار بالتكامل المستمر والبنية الأساسية لبرنامج ربط العمليات التجارية للتسليم المستمر، فإن مفهومين ستسمعهما هما الاختبار المستمر والتحول إلى اليسار.
يعني الاختبار المستمر إجراء الاختبارات في وقت مبكر من عملية التطوير ومع تحرك كل تغيير عبر البنية الأساسية لبرنامج ربط العمليات التجارية. يعني التحول إلى اليسار النظر في جودة البرامج والاختبار في وقت سابق من عملية التطوير.
على سبيل المثال، غالبا ما يضيف المطورون حالات اختبار أثناء تطويرهم لمميزاتهم وتشغيل مجموعة كاملة من الاختبارات قبل إرسال التغيير إلى البنية الأساسية لبرنامج ربط العمليات التجارية. يساعد هذا الأسلوب في التأكد من أن الميزة التي يقومون بإنشائها تتصرف كما هو متوقع وأنها لا تقاطع الميزات الحالية.
فيما يلي فيديو قصير يشرح فيه أبيل وانغ، مساعد السحابة لدى Microsoft، كيفية ضمان الحفاظ على الجودة في خطة DevOps.
اسأل هابيل
غالبا ما يتطلب التحول إلى اليسار من المختبرين المشاركة في عملية التصميم، حتى قبل كتابة أي تعليمة برمجية للميزة. قارن هذا بنموذج "التسليم"، حيث يتم تقديم ميزات جديدة لفريق الاختبار للاختبار فقط بعد تصميم البرنامج وكتابته. يمكن أن يؤثر الخطأ المكتشف في وقت متأخر من العملية على جدول تسليم الفريق، وقد يتم اكتشاف الأخطاء بعد أسابيع أو حتى أشهر من إنشاء المطور للميزة في الأصل.
المفاضلة
مع الاختبار التلقائي، هناك مقايضة. على الرغم من أن الاختبار التلقائي يسمح للمختبرين بتركيز وقتهم في التحقق من تجربة المستخدم النهائي، فقد يحتاج المطورون إلى تخصيص المزيد من الوقت لكتابة التعليمات البرمجية للاختبار وصيانتها.
ومع ذلك، فإن نقطة الاختبار التلقائي هي المساعدة في ضمان أن المختبرين يتلقون التعليمات البرمجية الأعلى جودة فقط، وهي التعليمات البرمجية التي ثبت أنها تعمل كما هو متوقع. لذلك، يمكن للمطورين استعادة بعض وقتهم من خلال الاضطرار إلى معالجة أخطاء أقل أو تجنب إعادة كتابة التعليمات البرمجية بسبب حالة حافة لم ينظروا فيها في الأصل.
مزايا إضافية
التوثيق والقدرة على إعادة بناء التعليمات البرمجية بسهولة أكبر هما ميزتان إضافيتان للاختبار التلقائي.
الوثائق
يمكن أن تكون خطط الاختبار اليدوي بمثابة نوع من الوثائق حول كيفية تصرف البرامج وسبب وجود ميزات معينة.
يمكن أن تخدم الاختبارات التلقائية نفس الغرض. غالبا ما تستخدم التعليمات البرمجية للاختبار التلقائي تنسيقا يمكن للبشر قراءته. تمثل مجموعة المدخلات التي تقدمها القيم التي قد يدخلها المستخدمون. يحدد كل إخراج مقترن النتيجة التي يجب أن يتوقعها المستخدمون.
في الواقع، يتبع العديد من المطورين أسلوب التطوير المستند إلى الاختبار (TDD) عن طريق كتابة التعليمات البرمجية للاختبار قبل تنفيذ ميزة جديدة. الفكرة هي كتابة مجموعة من الاختبارات، غالبا ما تسمى المواصفات، التي تفشل في البداية. بعد ذلك، يكتب المطور التعليمات البرمجية بشكل متزايد لتنفيذ الميزة حتى تنجح جميع الاختبارات. لا توثق المواصفات المتطلبات فحسب، بل تساعد عملية TDD على ضمان كتابة الكمية الضرورية فقط من التعليمات البرمجية لتنفيذ الميزة.
إعادة بناء التعليمات البرمجية
لنفترض أن لديك قاعدة تعليمات برمجية كبيرة تريد إعادة بناء التعليمات البرمجية لجعل أجزاء معينة تعمل بشكل أسرع. كيف تعرف أن جهود إعادة بناء التعليمات البرمجية الخاصة بك لن تتسبب في توقف أجزاء من تطبيقك؟
تعمل الاختبارات التلقائية كنوع من العقد. أي أنك تحدد المدخلات والنتائج المتوقعة. عندما يكون لديك مجموعة من الاختبارات، تكون قادرا بشكل أفضل على تجربة التعليمات البرمجية وإعادة بناء التعليمات البرمجية الخاصة بك. عند إجراء تغيير، كل ما عليك القيام به هو تشغيل اختباراتك والتحقق من استمرار اجتيازها. بعد تحقيق أهداف إعادة بناء التعليمات البرمجية الخاصة بك، يمكنك إرسال التغيير إلى البنية الأساسية لبرنامج ربط العمليات التجارية للبناء بحيث يمكن للجميع الاستفادة، ولكن مع مخاطر أقل لتعطل شيء ما.
ما هي أنواع الاختبارات التلقائية الموجودة؟
هناك العديد من أنواع الاختبار التلقائي. يخدم كل اختبار غرضا منفصلا. على سبيل المثال، قد تقوم بإجراء اختبارات الأمان للمساعدة في التحقق من أن المستخدمين المصرح لهم فقط يمكنهم الوصول إلى جزء من البرنامج أو إحدى ميزاته.
عندما نذكر التكامل المستمر وبنية البنية الأساسية لبرنامج ربط العمليات التجارية، فإننا عادة ما نشير إلى اختبار التطوير. يشير اختبار التطوير إلى الاختبارات التي يمكنك تشغيلها قبل نشر التطبيق في بيئة اختبار أو إنتاج.
على سبيل المثال، يتحقق اختبار التحليل، وهو شكل من أشكال تحليل التعليمات البرمجية الثابتة، من التعليمات البرمجية المصدر لتحديد ما إذا كان يتوافق مع دليل أنماط فريقك. تكون قراءة التعليمات البرمجية المُنسَقة باستمرار وتعديلها أمراً سهلاً على الجميع.
في هذه الوحدة، ستعمل مع اختبار الوحدة واختبار تغطية التعليمات البرمجية.
يتحقق اختبار الوحدة من المكونات الأساسية للبرنامج أو المكتبة، مثل وظيفة فردية أو أسلوب. يمكنك تحديد إدخال واحد أو أكثر مع النتائج المتوقعة. يقوم مشغل الاختبار بإجراء كل اختبار ويتحقق لمعرفة ما إذا كانت النتائج الفعلية والمتوقعة متطابقة.
على سبيل المثال، لنفترض أن لديك دالة تقوم بإجراء عملية حسابية تتضمن القسمة. قد تحدد بعض القيم التي تتوقع أن يدخلها المستخدمون مع قيم حالة الحافة مثل 0 و-1. إذا كان إدخال معين ينتج عنه خطأ أو استثناء، يمكنك التحقق من أن الدالة تنتج نفس الخطأ.
يحسب اختبار تغطية التعليمات البرمجية النسبة المئوية للتعليمات البرمجية التي تغطيها اختبارات الوحدة الخاصة بك. يمكن أن يتضمن اختبار تغطية التعليمات البرمجية فروعا شرطية في التعليمات البرمجية الخاصة بك للتأكد من تغطية دالة.
كلما زادت نسبة تغطية التعليمات البرمجية، زادت الثقة في أنك لن تكتشف لاحقا خطأ في التعليمات البرمجية لم يتم اختباره بالكامل. لا تحتاج إلى الوصول إلى تغطية التعليمات البرمجية بنسبة 100 بالمائة. في الواقع، عند البدء، من المحتمل أن تجد أن لديك نسبة مئوية منخفضة، ولكن هذا يمنحك نقطة بداية يمكنك من خلالها إضافة اختبارات إضافية تغطي التعليمات البرمجية الإشكالية أو المستخدمة بشكل متكرر.
إبقاء اختبارات الوحدة معزولة
عندما تتعلم عن اختبار الوحدة، قد تسمع مصطلحات مثل الصور الوهمية والكعبان وحقن التبعية.
تذكر أن اختبار الوحدة يجب أن يتحقق من دالة أو أسلوب فردي، وليس كيفية تفاعل المكونات المتعددة. ولكن إذا كانت لديك دالة تستدعي قاعدة بيانات أو خادم ويب، فكيف تتعامل مع ذلك؟
لا يؤدي استدعاء خدمة خارجية إلى كسر العزل فحسب، بل يمكن أن يؤدي إلى إبطاء الأمور. إذا تعطلت قاعدة البيانات أو خادم الويب أو لم يكن متوفرا، يمكن أن يؤدي الاستدعاء أيضا إلى تعطيل تشغيل الاختبار.
باستخدام تقنيات مثل المحاكاة وحقن التبعية، يمكنك إنشاء مكونات تحاكي هذه الوظيفة الخارجية. ستحصل على مثال لاحقا في هذه الوحدة النمطية.
لاحقا، يمكنك تشغيل اختبارات التكامل للتحقق من أن التطبيق الخاص بك يعمل بشكل صحيح مع قاعدة بيانات حقيقية أو خادم ويب.
ما الذي يجعل الاختبار جيدا؟
ستتمكن بشكل أفضل من تحديد اختبار جيد أثناء اكتسابك خبرة في كتابة الاختبارات الخاصة بك واختبارات القراءة التي كتبها الآخرون. فيما يلي بعض الإرشادات للبدء:
- لا تختبر من أجل الاختبار: يجب أن تخدم اختباراتك غرضا يتجاوز كونه عنصر قائمة اختيار للعبور. اكتب الاختبارات التي تتحقق من أن التعليمات البرمجية الهامة تعمل على النحو المنشود ولا تكسر الوظائف الموجودة.
- حافظ على اختباراتك قصيرة: يجب أن تنتهي الاختبارات في أسرع وقت ممكن، خاصة تلك التي تحدث أثناء مراحل التطوير والبناء. عند تشغيل الاختبارات أثناء انتقال كل تغيير عبر المسار، لا تريد أن تكون الازدحام.
- تأكد من أن الاختبارات قابلة للتكرار: يجب أن تنتج عمليات التشغيل الاختبارية نفس النتائج في كل مرة، سواء قمت بتشغيلها على جهاز الكمبيوتر الخاص بك، أو كمبيوتر زميل في العمل، أو في البنية الأساسية لبرنامج ربط العمليات التجارية للبناء.
- حافظ على تركيز اختباراتك: من المفاهيم الخاطئة الشائعة أن الاختبارات تهدف إلى تغطية التعليمات البرمجية التي كتبها الآخرون. عادة، يجب أن تغطي اختباراتك التعليمات البرمجية الخاصة بك فقط. على سبيل المثال، إذا كنت تستخدم مكتبة رسومات مفتوحة المصدر في مشروعك، فلن تحتاج إلى اختبار تلك المكتبة.
- اختر النقاوة المناسبة: على سبيل المثال، إذا كنت تقوم بإجراء اختبار وحدة، فلا يجب أن يجمع الاختبار الفردي أو يختبر وظائف أو أساليب متعددة. اختبر كل وظيفة بشكل منفصل ثم اكتب اختبارات التكامل لاحقا التي تتحقق من تفاعل مكونات متعددة بشكل صحيح.
ما أنواع أدوات الاختبار المتوفرة؟
تعتمد أدوات الاختبار التي تستخدمها على نوع التطبيق الذي تقوم ببناءه ونوع الاختبار الذي تريد تنفيذه. على سبيل المثال، يمكنك استخدام Selenium لإجراء اختبار واجهة المستخدم على العديد من أنواع مستعرضات الويب وأنظمة التشغيل.
بصرف النظر عن اللغة المكتوب بها تطبيقك، تتوفر لك عدة أدوات اختبار لاستخدامها.
على سبيل المثال، بالنسبة لتطبيقات Java، قد تختار Checkstyle لإجراء اختبار التحليل وJUnit لإجراء اختبار الوحدة.
في هذه الوحدة النمطية، سنستخدم NUnit لاختبار الوحدة لأنه شائع في مجتمع .NET.