اختبار البرمجيات

🎯 ما هو اختبار البرمجيات؟

التعريف

يهدف اختبار البرمجيات إلى إظهار أن البرنامج يقوم بما صُمم من أجله واكتشاف عيوب البرنامج قبل وضعه قيد الاستخدام.

عملية الاختبار لها هدفان متميزان:

🎖️ الهدف 1: التحقق (Validation)

إثبات للمطور وللعميل أن البرنامج يلبي متطلباته.

تلبية المتطلبات

🔍 الهدف 2: اختبار العيوب (Defect Testing)

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

اكتشاف العيوب

📌 مجالات التركيز الرئيسية

الصحة (Correctness): سلوك البرنامج فيما يتعلق بالمتطلبات أو الغرض منه.
الأداء (Performance): سلوك البرنامج تحت ظروف مختلفة.
المتانة (Robustness): القدرة على التعامل مع المدخلات الخاطئة والحالات غير المتوقعة.
التثبيت (Installation): جوانب أخرى لإصدار البرنامج.

📚 تعاريف أساسية

عطل (Failure)

انحراف في السلوك الملاحظ للبرنامج أو النظام عن مواصفاته.

مثال: square(3) = 6 ❌

خطأ/عيب (Fault/Defect)

خطوة أو عملية أو تعريف بيانات غير صحيح في الكود.

مثال: return x * 2; بدلاً من return x * x;

// مثال: خطأ في الكود int square(int x) { return x * 2; // <-- خطأ: يجب أن يكون x * x } // حالات الاختبار square(2) = 4 ✓ صحيح (صدفة) square(3) = 6 ✗ عطل (يكشف الخطأ)

✅ التحقق والمراجعة (V&V)

الاختبار هو جزء من عملية أوسع للتحقق والمراجعة للبرمجيات.

التحقق (Verification)

"هل نبني المنتج بشكل صحيح؟"

الهدف هو التحقق من أن البرنامج يلبي متطلباته الوظيفية وغير الوظيفية المعلنة.

يتحقق من المواصفات.
جودة داخلية.
مرتكز على العملية.

المراجعة (Validation)

"هل نبني المنتج الصحيح؟"

عملية أشمل تضمن أن البرنامج يلبي توقعات العميل.

يتحقق من احتياجات العميل.
جودة خارجية.
مرتكز على المنتج.

🔬 أنواع الاختبار

⬛ اختبار الصندوق الأسود

اختبار مبني على المواصفات الخارجية دون معرفة بالهيكل الداخلي للكود.

وظيفي مبني على المتطلبات

⬜ اختبار الصندوق الأبيض

اختبار مبني على هيكل الكود الداخلي وتفاصيل التنفيذ.

هيكلي مبني على الكود

⬛ اختبار الصندوق الأسود

التعريف

اختبار الصندوق الأسود هو أسلوب اختبار يتم فيه اختبار وظائف/مميزات التطبيق قيد الاختبار (AUT) دون النظر إلى هيكل الكود الداخلي، أو تفاصيل التنفيذ، أو معرفة المسارات الداخلية للبرنامج.

🎯 خصائص رئيسية

مبني بالكامل على متطلبات ومواصفات البرنامج.
يركز على المدخلات والمخرجات دون الاكتراث للمعرفة الداخلية.
يتم اختيار حالات الاختبار قبل التنفيذ.
يساعد في جعل التصميم والكتابة صحيحين بالنسبة للمواصفات.

📋 عملية اختبار الصندوق الأسود

1. فحص المتطلبات

→

2. اختيار مدخلات صالحة/غير صالحة

→

3. تحديد المخرجات المتوقعة

↓

4. بناء حالات الاختبار

→

5. تنفيذ الاختبارات

→

6. مقارنة النتائج

🔧 تقنيات اختبار الصندوق الأسود

1️⃣ اختبار جدول القرار (Decision Table)

يضع جدول القرار الأسباب وتأثيراتها في مصفوفة. يوجد مزيج فريد في كل عمود.

مثال: شاشة تسجيل الدخول

الشرط: يجب على المستخدم تقديم اسم مستخدم صحيح و كلمة مرور صحيحة للوصول للصفحة الرئيسية. أي إدخال غير صحيح يعرض رسالة خطأ.

الشروط	القاعدة 1	القاعدة 2	القاعدة 3	القاعدة 4
اسم المستخدم (ص/خ)	خ	ص	خ	ص
كلمة المرور (ص/خ)	خ	خ	ص	ص
المخرج (خ/ر)	خ	خ	خ	ر

الشرح: ص = صحيح، خ = خطأ، خ = رسالة خطأ، ر = شاشة البداية

2️⃣ تقسيم فئات التكافؤ (Equivalence Partitioning)

يُستخدم لتقليل عدد حالات الاختبار المحتملة إلى مستوى أمثل مع الحفاظ على تغطية اختبار معقولة. يقسم بيانات المدخلات إلى فئات تكافؤ مختلفة حيث يمكن اعتبار سلوك النظام متشابهًا.

مثال: طلب بيتزا (مسموح من 1 إلى 10 بيتزا)

بدلاً من اختبار جميع القيم المحتملة، قسّم إلى أقسام:

غير صالح: < 1 (مثلاً، اختبر بـ -1)
صالح: 1-10 (مثلاً، اختبر بـ 8)
غير صالح: > 10 (مثلاً، اختبر بـ 33)

3️⃣ اختبار القيم الحدودية (Boundary Value)

يركز على القيم عند الحدود. تحدد هذه التقنية ما إذا كان نطاق معين من القيم مقبولاً من النظام أم لا.

للمدى [1, 10]: • غير صالح: 0 (أسفل الحد الأدنى مباشرة) • صالح: 1 (الحد الأدنى)، 2 (أعلى الحد الأدنى مباشرة) • صالح: 9 (أسفل الحد الأقصى مباشرة)، 10 (الحد الأقصى) • غير صالح: 11 (أعلى الحد الأقصى مباشرة)

✅ مزايا اختبار الصندوق الأسود

يمكن تصميم حالات الاختبار مبكراً.
لا تتطلب معرفة بالبرمجة.
اختبارات من منظور المستخدم.
يساعد في التحقق من المواصفات.

القيود

تغطية محدودة للكود.
لا يمكن اختبار الوظائف المخفية.
قد تفوت الأخطاء المنطقية.

⬜ اختبار الصندوق الأبيض

التعريف

تُشتق حالات الاختبار من مواصفات التصميم الداخلي أو الكود الفعلي للبرنامج. يتضمن استخدام الكود المصدري لإيجاد كل مسار تنفيذي ممكن.

🎯 ميزات رئيسية

يختبر التفاصيل الداخلية للكود.
يفحص جميع المسارات التي يمكن للبرنامج تنفيذها.
يتطلب معرفة بالبرمجة.
يُنفذ من قبل المطورين.

🔍 اختبار المسار الأساسي (Basis Path)

الغرض

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

📊 التعقيد الحلقي (Cyclomatic Complexity)

مقياس برمجي يُستخدم لقياس تعقيد المسار لبرنامج ما. إنه مقياس كمي للمسارات المستقلة في الكود المصدري.

الصيغة 1: V(G) = E - N + 2 حيث: E = عدد الحواف (Edges) N = عدد العقد (Nodes) الصيغة 2: V(G) = P + 1 حيث: P = عدد عقد القرار/الشرط (Predicate)

🔢 تفسير قيمة التعقيد

التعقيد	المعنى	قابلية الاختبار
1-10	كود منظم ومكتوب جيداً	عالية
10-20	كود معقد	متوسطة
20-40	كود معقد جداً	منخفضة
>40	غير قابل للاختبار	منخفضة جداً

📝 خطوات اختبار المسار الأساسي

الخطوة 1: رسم مخطط انسياب التحكم

إنشاء رسم بياني بالعقد والحواف من الكود المصدري لتحديد مسارات البرنامج المختلفة.

الخطوة 2: حساب التعقيد

استخدم V(G) = E - N + 2 أو V(G) = P + 1 لتحديد عدد المسارات المستقلة.

الخطوة 3: تحديد المجموعة الأساسية

تحديد المجموعة الأساسية للمسارات المستقلة عبر البرنامج.

الخطوة 4: توليد حالات الاختبار

إنشاء حالات اختبار لتنفيذ جميع المسارات المحددة.

💡 مثال: إيجاد القيمة الدنيا

min = A[0]; i = 1; while (i < N) { if (A[i] < min) min = A[i]; i = i + 1; } print min

حساب التعقيد الحلقي: • العقد (N) = 6 • الحواف (E) = 7 • عقد القرار (P) = 2 V(G) = 7 - 6 + 2 = 3 V(G) = 2 + 1 = 3 المسارات المستقلة (3 مطلوبة): 1. [1 → 2 → 6] (مصفوفة فارغة) 2. [1 → 2 → 3 → 5 → 2 → 6] (لا تحديث للقيمة الدنيا) 3. [1 → 2 → 3 → 4 → 5 → 2 → 6] (تحديث القيمة الدنيا) حالات الاختبار: 1. N=0, A=[] 2. N=2, A=[5,7] (ترتيب تصاعدي) 3. N=3, A=[5,3,4] (الدنيا في المنتصف)

🎯 استخدامات التعقيد الحلقي

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

⚖️ مقارنة: الصندوق الأسود مقابل الأبيض

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

🏗️ مستويات الاختبار

توجد مستويات مختلفة من الاختبار يتم تنفيذها بواسطة أشخاص مختلفين في أوقات مختلفة:

1️⃣ اختبار الوحدة

اختبار المكونات الفردية

مستوى المطور

2️⃣ اختبار التكامل

اختبار المكونات المتكاملة

مستوى الوحدة

3️⃣ اختبار النظام

اختبار النظام بأكمله

مستوى النظام

4️⃣ اختبار القبول

اختبار النظام النهائي

مستوى المستخدم

1️⃣ اختبار الوحدة

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

🎯 لماذا اختبار الوحدة؟

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

📋 أنواع مراجعة الكود

جولة في الكود (Code Walkthrough)

مراجعة شبه رسمية.
المؤلف هو العارض.
يقودها المؤلف فقط.
المُراجِعون غير مستعدين مسبقاً.

فحص الكود (Code Inspection)

مراجعة رسمية.
المؤلف ليس العارض.
يقودها مشرف.
المُراجِعون مستعدون جيداً.

2️⃣ اختبار التكامل

يتضمن اختبار التكامل بناء نظام من مكوناته واختباره بحثاً عن مشاكل تنشأ من تفاعلات المكونات. يتم دمج وحدات برمجية مختلفة واختبارها كمجموعة.

المبدأ الرئيسي

لتبسيط تحديد مكان الخطأ، يجب أن تُدمج الأنظمة بشكل تدريجي.

🎯 لماذا اختبار التكامل؟

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

🔧 أساليب اختبار التكامل

1️⃣ أسلوب الانفجار الكبير (Big Bang)

✅ المزايا

ملائم للأنظمة الصغيرة.
جميع الوحدات تُختَبر مرة واحدة.

❌ العيوب

تحديد مكان الخطأ صعب.
قد تُفوت الواجهات.
الوحدات الحرجة لا تُعطى أولوية.

2️⃣ الأسلوب التدريجي (Incremental)

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

🔑 مفاهيم رئيسية: الـ Stubs والـ Drivers

Stub: برنامج وهمي يحاكي وحدة يتم استدعاؤها (يُستخدم في الاختبار من أعلى لأسفل).

Driver: برنامج وهمي يستدعي وحدة (يُستخدم في الاختبار من أسفل لأعلى).

📊 التكامل من أعلى لأسفل (Top-Down)

الاختبار من الأعلى إلى الأسفل متبعاً انسياب التحكم.

يستخدم: Stubs للاختبار.

الإيجابيات: نموذج أولي مبكر، اختبار الوحدات الحرجة أولاً.

السلبيات: يحتاج للعديد من Stubs، الوحدات السفلية غير مُختبرة بشكل كافٍ.

📊 التكامل من أسفل لأعلى (Bottom-Up)

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

يستخدم: Drivers للاختبار.

الإيجابيات: تحديد مكان الخطأ أسهل، لا انتظار للوحدات.

السلبيات: الوحدات الحرجة تُختبر أخيراً، لا يوجد نموذج أولي مبكر.

📝 مثال على اختبار تكامل

معرف حالة الاختبار	الهدف	الوصف	النتيجة المتوقعة
1	تسجيل دخول → رابط صندوق البريد	أدخل بيانات الاعتماد وانقر على تسجيل الدخول	يتم التوجيه إلى صندوق البريد
2	صندوق البريد → رابط الحذف	اختر رسالة وانقر على حذف	الرسالة في مجلد المهملات

3️⃣ اختبار النظام

يُتحقق اختبار النظام من منتج البرمجيات المتكامل بالكامل. يقيم مواصفات النظام من البداية للنهاية.

🔍 أنواع اختبار النظام

الاختبار الوظيفي

اختبار النظام بأكمله مقابل المتطلبات الوظيفية.

مبني على المتطلبات

اختبار الأداء

اختبار المتطلبات غير الوظيفية (أوقات الاستجابة، اختبار الحمل، إلخ).

مبني على الأداء

⚡ الاختبار غير الوظيفي

اختبار الجوانب غير الوظيفية مثل الأداء، سهولة الاستخدام، الموثوقية، إلخ.

🔒 الأمان

الحماية من الهجمات

🔄 الموثوقية

وظيفة مستمرة دون فشل

💪 التحمل/المقاومة (Survivability)

الاستعادة من فشل النظام

📊 قابلية التوسع

التعامل مع الطلب المتزايد

🎯 اختبار الأداء

يفحص السرعة، وقت الاستجابة، الموثوقية، استخدام الموارد، وقابلية التوسع تحت حمل العمل المتوقع.

السرعة: هل يستجيب التطبيق بسرعة؟
قابلية التوسع: أقصى حمل مستخدم يمكن للتطبيق التعامل معه.
الاستقرار: هل التطبيق مستقر تحت أحمال متغيرة؟

4️⃣ اختبار القبول

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

🎯 ميزات رئيسية

يُستخدم فقط تقنيات اختبار الصندوق الأسود.
يُنفذ من قبل المستخدمين النهائيين الفعليين.
يمكن مشاركة أصحاب المصلحة الآخرين.
التحقق النهائي قبل النشر.

🔄 اختبار الانحدار

التعريف

عند إصدار برنامج جديد، تظهر الحاجة لإعادة تشغيل الاختبارات القديمة التي اجتازها التطبيق سابقاً لضمان ألا يُعيد البرنامج الجديد إدخال عيوب قديمة أو يُحدث آثار جانبية جديدة (انحدارات).

⚠️ التحديات

موارد محدودة (وقت، أشخاص، أنظمة اختبار).
عدد كبير من حالات الاختبار لإعادة التنفيذ.
الموازنة بين الاختبار الشامل وقيود الوقت.

🎯 متى يتم تنفيذ اختبار الانحدار؟

بعد إصلاحات الكود.
بعد الترقيات.
بعد صيانة النظام.
عند إضافة مميزات جديدة.

✨ أفضل ممارسات الاختبار

✅ افعل

ابدأ الاختبار مبكراً.
اختبر خلال دورة التطوير.
أتمتة الاختبارات المتكررة.
وثّق حالات الاختبار بدقة.
استخدم كل من الصندوق الأسود والأبيض.
أشرك المستخدمين النهائيين مبكراً.
تتبع العيوب وحللها.

❌ لا تفعل

لا تتخطى اختبار الوحدة.
لا تختبر بدون خطة.
لا تتجاهل الاختبارات الفاشلة.
لا تختبر فقط المسارات السعيدة (الطبيعية).
لا تفترض أن الاختبارات تمرر.
لا تختبر في بيئة الإنتاج فقط.
لا تنسى الحالات الحدودية.

📚 ملخص

نقاط أساسية

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

انسياب عملية الاختبار

المتطلبات

→

اختبار الوحدة

→

التكامل

↓

اختبار النظام

→

القبول

→

النشر