المعلوماتية > برمجيات
ما هي اختبارات جودة البرمجيّات؟
تعدّ البرمجيّات العنصر الرئيسي في العديد من الأنظمة والأجهزة المنتشرة في حياتنا، إذ تعرّف هذه البرمجيّات سلوك موجّهات الشبكة والشبكات الماليّة وشبكات الهواتف والويب، وغيرها من بنى الحياة الحديثة. كما أنّها مكوّنٌ جوهريٌّ في الكثير من التطبيقات المُدمَجة (المضمّنة) والّتي تتحكّم بتطبيقاتٍ غريبة كالطائرات والمركبات الفضائيّة بالإضافة إلى التطبيقات الأقل تعقيداً كالساعات والسيارات والأجهزة الخليويّة وأجهزة التحكّم عن بعد. وعلى الرغم من تأثير العديد من العوامل على وثوقيّة هذه البرمجيّات ونجاحها كالتصميم والتنفيذ الدقيقين، إلّا أنّ الاختبار هو الوسيلة الرئيسيّة التي تعتمدها الصناعة لتقييم البرمجيات التي لا تزال قيد التطوير.
بدايةً، تمكّنت الشركات البرمجية منذ فترةٍ ليست بطويلةٍ من تحمّل تكاليف توظيف مبرمجين لا يجيدون إجراء أيّ اختبارٍ لمشاريعهم، بالإضافة إلى مختبرين لا يعرفون أيّ شيءٍ عن البرمجة. ولم يكن من الضروري لصنّاع البرمجيات أن يعرف موظّفوهم المبادئ التقنيّة للاختبار أو حتّى تطوير البرمجيات. وبذلك كان اختبار البرمجيات في بداياته نشاطاً غيرَ تقنيّ ويتمّ النظر إليه على أنّه عملٌ إداريّ.
ومع تطوّر هندسة البرمجيّات وانتشار برمجيّاتها في حياتنا اليوميّة، ظهرت متطلّباتٌ صارمةٌ بخصوص وثوقيّة هذه البرمجيّات وصيانتها وأمنها. وكان لا بدّ للصناعة أن تتجاوب مع هذه المتطلّبات الجديدة بتطوير طرق اختبارها لهذه البرمجيّات، ممّا يعني زيادة الخبرة التقنيّة لمهندسي الاختبار بالإضافة إلى تعزيز أهميّة الاختبار وضرورته عند المبرمجين.
كما أصبحت أفكار وتقنيّات اختبار البرمجيّات معرفةً ضروريّةً لجميعِ مطوّري البرمجيّات إذ أصبح بإمكان المبرمج أن يتوقّع مفاهيم هذا الاختبار وطرقه وأحياناً نتائجه.
تدعى عمليّة اختبار البرمجيات بـ:
مراقبة جودة البرمجيات software quality control.
ضمان جودة البرمجيات software quality assurance.
الهدف الرئيسي من عملية اختبار البرمجيات ضمان ما يلي:
Validation: هل ما قمنا ببنائه هو المنتج الصحيح والمطلوب؟
Verification: هل يقوم X بما طُلب منه؟ إذ قد يكون X جزءاً من الرماز (code)، أو نموذجاً أو أحد المتطلّبات.
بعض المصطلحات:
الخطأ Error: وهو أي خطأ قام به المهندس كنتيجةٍ عن سوء الفهم للمتطلّبات أو التصميم.
العيب Fault: وهو ظهور هذا الخطأ ضمن الرماز، وندعوه غالباً Bug (بمعنى إصابة).
الفشل Failure: وهو السلوك أو النتيجة غير الصحيحة والناتجة عن تنفيذ رماز يحوي عيباً ما،
قد يكون هذا الفشل مباشراً (كأن ينهار النظام) أو قد يظهر لاحقاً خلال التنفيذ.
هل يكون النظام خالياً من العيوب إن تجاوز كلّ اختباراته بنجاح؟
للأسف لا، فقد تكون العيوب مختبئة ضمن أجزاءٍ نادرة التنفيذ من الرماز، وبذلك تكون وظيفة الاختبار إثبات وجود العيوب وليس عدم وجودها وتأثيرها على النظام.
ولكن في حال قمنا بتشكيل مجموعة اختباراتٍ واسعةٍ تشمل كافة وظائف النظام، فاجتياز هذه المجموعة يعني أنّ نظامنا ذو جودةٍ عاليةٍ وقابلٌ للنشر.
ما هي الطريقة المُثلى لإجراء الاختبارات؟
1- تجميع كافّة وظائف وسلوكيّات النظام على اعتبار أنّها فضاء واسع.
2- تقسيم هذا الفضاء إلى أجزاء مختلفة الوظيفة (أو التنفيذ).
3- تكوين اختباراتٍ تماثل نتيجة كلّ جزءٍ من هذا الفضاء وتنفيذ هذه الاختبارات.
لنفرض أنّه لدينا برنامجٌ يقوم بإيجاد القاسم المشترك الأكبر لعددين x وy، فمن الممكن أن تكون أجزاء الفضاء في هذه الحالة:
اختبار حالةٍ شائعة مثل x=6 وy=9 (القاسم المشترك الأكبر هنا=3).
اختبار كَون أحد العددين هو القاسم المشترك الأكبر مثل x=2 وy=4 (القاسم المشترك الأكبر=2).
اختبار عددين أوليّين مثل x=3 وy=5 (القاسم المشترك الأكبر=1).
اختبار كون أحد العددين مساوياً للصفر مثل x=9 وy=0 (لا يوجد قاسم مشترك أكبر).
اختبار كون أحد العددين سالباً مثل x=-3 و y=9 (القاسم المشترك الأكبر هنا هو العدد السالب).
ويتضّح لنا من المثال السابق أنّ اختبارَ نظامٍ ما بالكامل هو أمرٌ مستحيل.
يُعتبر الاختبار عمليّةً مستمرّةً ينبغي تطبيقها في كلّ مرحلةٍ من مراحل تطوير البرمجيّات، ففي مرحلة تجميع المتطلّبات مثلاً، تكون مهمّة الاختبار التأكّد من فهم جميع المتطلّبات، وفي حال كان تنفيذ النظام يعتمد على نموذجٍ تكراريّ iterations فعلى مسؤولي الاختبار القيام بالتحقّق في نهاية كلّ دورة.
بعض أنواع الاختبارات:
- اختبار الوحدة Unit Testing: ويهتمّ بالمفاهيم منخفضة المستوى من النظام، إذ يَجري الاختبار هنا ضمن الرماز البرمجي ومن أجل كلّ نموذجٍ وكلّ عمليّة.
مثال: من أجل كلّ تابعٍ أو إجرائيّةٍ foo() سنجد تابعاً لاختباره يدعى testFoo()
- اختبار التكامل Integration Testing: ويهتمّ بضمان عمل جميع الأجزاء بشكلٍ صحيحٍ بعد دمجها معاً وخاصّةً عندما يعمل أكثرُ من مطوّرٍ واحدٍ على كتابة الرماز.
- اختبار النظام System Testing: للتأكّد من عمل جميع الوظائف الكبيرة ضمن النظام وتطبيق جميع متطلبّات الزبون.
- اختبار القبول Acceptance Testing: ويجري عادةً من قبل المستخدمين للتأكّد من تلبية النظام لاحتياجاتهم.
- اختبارات الرماز:
1- اختبار الصندوق الأسود Black Box Testing: هل سلوك النظام مطابقٌ لما جاء في المتطلّبات؟
2- اختبار الصندوق الرمادي Grey Box Testing: هل سلوك النظام مطابقٌ لما جاء في المتطلبات مع وجود معرفة ضئيلة ببنية هذا النظام.
3- اختبار الصندوق الأبيض White Box Testing: اختبار جميع أجزاء الرماز من عباراتٍ وتفرّعاتٍ وغيرها.
- اختبار التراجع Regression Testing: ويقصد به إعادة اختبار البرمجيّة بعد أن تمّ تعدليها أو إصلاح أخطاء سبق وتمّ العثور عليها. ويتطلّب هذا النوع أكبر قدرٍ من الجهد وغالباً ما يتمّ إجراء العديد من جولات الاختبار التراجعيّة في الأنظمة الكبيرة، لأنّ أيَّ تعديلٍ بسيطٍ ضمن أحد أجزاء البرمجيّة قد يسبّب غالباً مشاكل في أماكن بعيدةٍ حتّى، وتكون وظيفة الاختبار التراجعيّ اكتشاف هذا النوع من الأخطاء.
الاختبارات المؤتمتة Automated Testing:
إن تطبيق جميع الاختبارات السابقة يدوياً (وخصوصاً اختبارات الرماز) أمرٌ قد يكون في غاية الصعوبة، ولكن من حسن الحظ، هناك العديد من الأدوات التي تقوم بتغطية وتعقّب الرماز بأكمله. وتقوم هذه الأنظمة المؤتمتة بتوليد تقارير لإظهار النسبة المئوية المُنجَزة من اختبار الرماز، كما أنّ بعضها يظهر لنا العبارة البرمجية التي تخضع حاليّاً للاختبار.
---------------------------------------------------------
المصادر: