البرمجيات (اختبار-)
برمجيات (اختبار)
Software testing -
مهيب النقري
يعتمد تطوير النظم البرمجية في المقام الأول على العامل البشري، وهذا ما يزيد فرص ارتكاب الأخطاء التي قد تبدأ من مرحلة تحديد الأهداف، ثمّ التحليل والتصميم، وصولاً إلى مراحل التطوير والاختبار.
اختبار البرمجيات software testing هو أحد أهم مكوّنات ضمان جودة البرمجيات software quality assurance والتي تشتمل كذلك على: معايير هندسة البرمجيات software engineering standardsوإجراءات التدقيق audits والمراجعات التقنية reviews وإجراءات جمع الأخطاء/العيوب وتحليلها، وغيرها.
ومن جهة أخرى يعبّر مفهوم جودة البرمجيات عن التوافق مع المتطلبات الوظيفية وغير الوظيفية ومتطلبات الأداء، ومع معايير تطوير البرمجيات.
ونظراً لأهمية اختبار البرمجيات خلال مراحل تطوير النظم البرمجية، فقد خصّص لها نموذج نضج القدرة المتكامل Capability Maturity Model Integration (CMMI) المعتمد من معهد صناعة البرمجيات في جامعة كارنيغي ميلون Carnegie Mellon الأمريكية، إجراءين أساسيّين من اثنين وعشرين إجراءً معتمداً في هذا النموذج، وهما إجراء التحقق verification وإقرار الصلاحية validation.
اختبار البرمجيات هو إحدى مراحل هندستها، والتي تمثّل ضمان جودتها بهدف إجراء المراجعة النهائية للتحليل والتصميم وكتابة الرماز code.
يعتمد مفهوم اختبار البرمجيات على مبدأ «الهدم». وفي حين يعتمد مهندس البرمجيات على «بناء» البرمجية ابتداءً من المفهوم المجرّد وصولاً إلى المنتج الفعلي؛ فإن عمل مهندس الاختبار يقوم على بناء سلسلة من حالات الاختبار test cases التي تهدف إلى «هدم» البرمجيات التي بُنيت.
يعتمد تنفيذ اختبار البرمجيات على بناء نص اختبار test script، وهي مجموعة من التعليمات التي يجري تطبيقها على النظام المختبَر للتحقّق من صحة عمله. ويمكن بناء نصوص الاختبار يدوياً، وتسمى عندها حالات الاختبار، أو طريقة مؤتمتة، أي إنها تكون على هيئة برامج قصيرة مكتوبة بلغة برمجية ما لاختبار جزء معين من أجزاء البرمجية.
تعطي نتائج اختبار البرمجيات مؤشراً على موثوقيتها وجودتها، ولكن من المهم جداً إدراك أن بإمكان اختبار البرمجيات إثبات احتوائها على أخطاء فقط، لكنه لا يستطيع أبداً إثبات خلوها من العيوب.
يعتمد اختبار البرمجيات على مجموعة من المبادئ الأساسية، أهمها:
1- تتبع الاختبارات متطلبات الزبون أولاً، ويجب أن تبدأ في مراحل مبكّرة من بناء البرمجيات فور إنجاز المتطلبات.
2- تُبنى الاختبارات الناجحة تدريجياً، أي ابتداءً من «القطع الصغيرة» التي تمثّل مجتزآت modules البرنامج المستقلة، وصولاً إلى «القطع الكبيرة» أي المجتزآت المتكاملة ومن ثمّ بناء كامل النظام.
3- الاختبارات الشاملة مستحيلة: أي من المستحيل تنفيذ كل تركيبات مسارات البرامج (المعتدلة الحجم أو الأكبر) في أثناء الاختبارات، لذلك يعتمد هدف الاختبار الأساسي على التحقق من منطق البرنامج إلى حدّ كافٍ.
4- لضمان تنفيذ الاختبارات تنفيذاً فعّالاً، ينبغي إجراؤها من شخص آخر أو أكثر، غير الذي قام بتطويرها.
تعتمد استراتيجية اختبار البرمجيات على تطبيق الخطوات الأربع التالية تتابعياً من خلال سياق حلزوني، يبدأ من اختبار الوحدة في مركز الحلزون صعوداً إلى اختبار النظام:
1- اختبار الوحدة unit testing: وهو يركّز على كامل المجتزأ على نحوٍ منفصل، للتوثق من صحة عمله. يعتمد هذا الاختبار على التحقّق من مسارات محدّدة ضمن بنية تحكّم المجتزأ، لضمان إجراء التغطية الكاملة واكتشاف أكبر عدد ممكن من الأخطاء ضمن الرماز المصدري source code. يقوم مطوّر الرماز عادةً بإجراء هذا النوع من الاختبارات للتقليل من أخطاء الرماز قدر الإمكان قبل الانتقال إلى المراحل التالية التي يغدو فيها كشف الأخطاء وتصحيحها أكبر كلفة.
2- اختبار التكامل integration testing: يُطبّق هذا الاختبار بعد تجميع جميع المجتزآت وتشكيل حزمة البرمجيات الكاملة. يركّز هذا الاختبار على دخل حزمة البرمجيات وخرجها، واختبار مسارات برمجية محدّدة لضمان شمول مسارات التحكّم الرئيسة. كما يركّز على تصميم design البنيان البرمجي. يعتمد هذا النوع من الاختبارات على مجموعة من استراتيجيات التكامل التزايدي incremental integration أهمها: التكامل النزولي top-down integration، والتكامل الصعودي bottom-up integration، الاختبار الانكفائي regression testing، والاختبار الدخاني smoke testing.
3- اختبار إقرار الصلاحية validation testing: يركّز هذا الاختبار على المتطلبات requirements؛ إذ يجري التحقّق من مطابقة البرمجيات لجميع متطلبات المعلومات، والمتطلبات الوظيفية والسلوكية ومتطلبات الأداء. وعند بناء البرمجيات بحسب طلب زبون محدّد تُجرى سلسلة اختبارات قبول acceptance tests عند الزبون للتحقق من مطابقة البرمجيات لجميع متطلباته. أما في حال بناء البرمجيات لأكثر من زبون فيمكن إجراء اختبارَي ألفا وبتّا alpha and beta testing لكشف الأخطاء من قبل الزبون النهائي. يُجرى الاختبار ألفا من قبل الزبون، وفي موقع المطوّر، والذي يقوم بتدوين الأخطاء ومشكلات الاستخدام. أما الاختبار بتّا فيقوم به الزبون النهائي، وفي موقع أو أكثر من مواقع الزبون، ومن دون حضور المطوّر؛ إذ يقوم الزبون النهائي بتسجيل المشكلات التي يصادفها ورفعها إلى المطوّر في مدة متفق عليها.
4- اختبار النظام system testing: وهي الخطوة الأخيرة من خطوات الاختبار، وتقع خارج حدود هندسة البرمجيات ضمن النظام الحاسوبي الأوسع. يركّز هذا الاختبار على ضمّ البرمجيات التي تمّ اختبار صلاحيتها في الخطوة السابقة إلى عناصر النظام الأخرى كالعتاديات والأشخاص وقواعد المعطيات لضمان حسن تشابكها معاً، والتحقّق من حسن أداء وظيفة كامل النظام. تتوافر لاختبار النظام أنماط عدة أهمها:
آ- اختبار الاستعادة recovery testing: يهدف إلى إرغام البرمجيات على الإخفاق بأساليب عديدة والتحقّق من القدرة على استعادة هذه البرمجيات على النحو الصحيح.
ب- اختبار الأمن security testing: يهدف إلى التحقق من أن آليات الحماية المستخدمة قادرة على حماية البرمجيات من الاختراقات الخارجية.
ج- اختبار الإجهاد stress testing: يهدف إلى التحقّق من قدرة البرمجيات على الصمود في الحالات غير الاعتيادية التي تتطلب موارد بكميات وأحجام وتواتر غير طبيعي.
د - اختبار الأداء performance testing: يتحقّق من حسن أداء البرمجيات في الزمن الحقيقي، خاصةً بعد تكامل عناصر النظام كافةً.
وتتوافر طريقتان أساسيتان لبناء حالات الاختبار:
1- اختبار الصندوق الأسود black-box testing: وهو يركّز على المتطلبات الوظيفية للبرمجيات لإجراء الاختبارات التي تُظهر الجاهزية الكاملة لكل وظيفة وتقصي الأخطاء الموجودة فيها.
2- اختبار الصندوق الأبيض white-box testing: وهو يركّز على المكوّنات الداخلية لضمان أن العمليات الداخلية تجري وفقاً للتوصيف. وهو يشمل اختبار المسارات المستقلة والقرارات المنطقية والحلقات وبنى المعطيات.
بعد إجراء سلسلة ناجحة من الاختبارات واكتشاف الأخطاء، يمكن الانتقال إلى إجراء التنقيح debugging الذي يهدف إلى إلغاء سبب هذه الأخطاء بتنفيذ حالات اختبار لتحديد حالات عدم التطابق بين النتائج المتوقعة والفعلية.
|
مراجع للاستزادة: - CMMI Product Team, CMMI for Development, Version 1.3, Carnegie Melon, Software Engineering Institute, USA, 2010. – G. Myers, C. Sandler, T. Badgett, The Art of Software Testing, John Wiley, 2011. - R. S. Pressman, Software Engineering: A Practitioner’s Approach, McGraw-Hill, 2010. |
- التصنيف : كهرباء وحاسوب - النوع : كهرباء وحاسوب - المجلد : المجلد الرابع مشاركة :
اخترنا لكم
المجلدات الصادرة عن موسوعة العلوم والتقانات
