الاختبار والتحقق وضمان الجودة
مشروع: خطة اختبار من وثيقة متطلبات النظام
مشروع: خطة اختبار من وثيقة متطلبات النظام
على مدار هذا البرنامج التعليمي، درست التحقق والصحة، ومستويات الاختبار، وحالات الاختبار المبنية على المتطلبات، وتقنيات تصميم الاختبار، واختبار قبول المستخدم، ومصفوفة تتبع المتطلبات، وإدارة العيوب، والاختبار غير الوظيفي، وبوابات الجودة. تجمع هذه المحاضرة الختامية تلك المهارات كلها في تمرين واحد واقعي: استخلاص خطة اختبار كاملة وحالات اختبار تمثيلية مباشرةً من نموذج وثيقة متطلبات النظام (SRS).
السيناريو هو بوابة المرضى لعيادة طبية — نظام إلكتروني يتيح للمرضى حجز المواعيد، والاطلاع على السجلات الطبية، وتلقي التذكيرات التلقائية. مقطع وثيقة SRS أدناه يمثّل بصدق نماذج توثيق مشاريع حقيقية: بعض المتطلبات صريحة وقابلة للاختبار مباشرةً، وبعضها يستلزم تفكيراً محلل قصيراً قبل أن تظهر شروط الاختبار منه. ستسير عبر دورة العمل الكاملة من وثيقة SRS إلى خطة الاختبار.
الخطوة 1 — قراءة مقطع وثيقة SRS
المقطع التالي مأخوذ من وثيقة SRS افتراضية لكنها واقعية لبوابة مرضى العيادة (CPP). ادرسها قبل القراءة أدناه — تُستخلص خطة الاختبار حصراً من هذه النصوص.
وثيقة متطلبات البرمجيات
المشروع: بوابة مرضى العيادة (CPP) الإصدار 1.0
أُعدَّت بواسطة: فريق تحليل الأنظمة
--- المتطلبات الوظيفية ---
REQ-F01: يجب أن يتمكن الزائر من تسجيل حساب باستخدام عنوان بريد إلكتروني
صالح وكلمة مرور لا تقل عن 8 أحرف تحتوي على حرف كبير واحد
ورقم واحد على الأقل.
REQ-F02: يجب أن يتمكن المريض المسجل من تسجيل الدخول ببريده الإلكتروني
وكلمة مروره. بعد 5 محاولات دخول فاشلة متتالية يُقفل الحساب
لمدة 30 دقيقة.
REQ-F03: يجب أن يتمكن المريض من البحث عن الفترات المتاحة حسب اسم الطبيب
والتخصص ونطاق التاريخ.
REQ-F04: يجب أن يتمكن المريض من حجز فترة متاحة. يجب على النظام إرسال
بريد إلكتروني تأكيدي خلال 60 ثانية وتخفيض توافر الفترة بمقدار 1.
REQ-F05: يجب أن يتمكن المريض من إلغاء موعد محجوز قبل ساعتين على الأقل
من الوقت المحدد. الفترات الملغاة ضمن هذه النافذة تُصنَّف
"غير متاحة" برمز السبب.
REQ-F06: يجب على النظام عرض آخر 12 شهراً من تاريخ مواعيد المريض في
صفحة ملفه الشخصي.
--- المتطلبات غير الوظيفية ---
REQ-NF01 (الأداء): يجب أن تُعيد صفحة نتائج البحث عن مواعيد النتائج
في أقل من 3 ثوانٍ لـ 95% من الطلبات تحت حمل 200 مستخدم متزامن.
REQ-NF02 (الأمان): يجب نقل جميع بيانات المرضى عبر TLS 1.2 أو أعلى.
يجب تخزين كلمات المرور كقيم مشفرة بملح؛ لا تُخزَّن كلمات
المرور النصية أو تُسجَّل في السجلات.
REQ-NF03 (سهولة الاستخدام): يجب أن يتمكن المستخدم الجديد من إتمام
التسجيل والحجز الأول خلال 10 دقائق دون مساعدة.
REQ-NF04 (التوافر): يجب أن تحافظ البوابة على 99.5% نشاطاً خلال ساعات
العمل (07:00–22:00 بالتوقيت المحلي)، باستثناء نوافذ الصيانة
المخطط لها المُعلَن عنها قبل 48 ساعة.
عادة المحلل: قبل كتابة أي حالة اختبار، رقّم كل متطلب وصنّفه (وظيفي / أداء / أمان / سهولة استخدام / توافر). هذا التصنيف المبكر يحدد تقنية الاختبار وصاحب المسؤولية في كل متطلب.
الخطوة 2 — هيكلة خطة الاختبار
خطة الاختبار هي الوثيقة الحاكمة لجهد الاختبار. لا تحتوي على كل حالة اختبار — بل تحدد النطاق والنهج والمسؤوليات والجدول الزمني ومعايير الدخول والخروج. تبدو خطة اختبار مرنة لكنها متكاملة لبوابة CPP v1.0 كما يلي:
خطة الاختبار — بوابة مرضى العيادة (CPP) الإصدار 1.0
1. النطاق
ضمن النطاق : جميع متطلبات SRS v1.0 (REQ-F01 إلى REQ-F06،
REQ-NF01 إلى REQ-NF04).
خارج النطاق: لوحة الإدارة، تكامل الدفع (نطاق الإصدار 2.0).
2. مستويات الاختبار والمسؤولون
اختبار الوحدة : فريق التطوير (لكل وحدة)
اختبار التكامل : فريق التطوير (عقود API)
اختبار النظام : فريق ضمان الجودة (تغطية SRS الكاملة)
اختبار قبول المستخدم : 3 موظفي استقبال + 5 مرضى (مجموعة تجريبية)
3. تقنيات تصميم الاختبار
تقسيم التكافؤ + تحليل القيمة الحدية : REQ-F01 (كلمات المرور)
اختبار جدول القرار : REQ-F02 (منطق القفل)
اختبار حالات الاستخدام : REQ-F03, REQ-F04, REQ-F05
اختبار الأداء : REQ-NF01
اختبار الأمان : REQ-NF02
استكشافي / سهولة الاستخدام : REQ-NF03
4. معايير الدخول (يبدأ الاختبار عند)
- اجتياز جميع الميزات المشمولة بـ SRS مراجعة الكود.
- نشر بناء مستقر في بيئة الاختبار.
- تحميل بيانات الاختبار (10 مرضى تجريبيون، 3 أطباء، شبكة فترات 30 يوماً).
5. معايير الخروج (يُوافق على الإصدار عند)
- تنفيذ 100% من حالات الاختبار الحرجة/العالية الأولوية ونجاحها.
- صفر عيوب حرجة مفتوحة؛ لا أكثر من 3 عيوب متوسطة مفتوحة.
- الحصول على موافقة UAT من ممثل العيادة.
- استيفاء معيار أداء REQ-NF01 في بيئة الاختبار.
6. إدارة العيوب
الأداة: نظام تتبع المشاريع.
مستويات الخطورة: حرج / عالٍ / متوسط / منخفض.
العيوب الحرجة تحجب الإصدار؛ جميع الأخرى مسجّلة للفرز.
7. الجدول الزمني (تقديري)
اختبار الوحدة والتكامل : الأسبوعان 1-2
اختبار النظام : الأسبوعان 3-4
اختبار قبول المستخدم : الأسبوع 5
الأداء والأمان : الأسبوع 5 (متوازٍ)
إصلاح العيوب والانحدار : الأسبوع 6
قرار الإطلاق / عدم الإطلاق : نهاية الأسبوع 6
الخطوة 3 — استخلاص حالات الاختبار التمثيلية
بعد وضع خطة الاختبار، تكتب حالات الاختبار لعينة تمثيلية من المتطلبات. تحتوي مجموعة الاختبارات الكاملة لـ CPP على 80-120 حالة اختبار؛ الحالات الست أدناه هي مراسي التحليل — واحدة لكل متطلب وظيفي — ينطلق منها فريق ضمان الجودة لتوسيع التغطية.
حالة الاختبار TC-01
المتطلب : REQ-F01 (التسجيل)
التقنية : تحليل القيمة الحدية على حقل كلمة المرور
الشرط السابق: لا يوجد حساب لـ test@clinic.example
الخطوات : 1. انتقل إلى صفحة /register.
2. أدخل البريد الإلكتروني = test@clinic.example.
3. أدخل كلمة المرور = "Abc1234" (7 أحرف — أقل بحرف من الحد الأدنى).
4. أرسل النموذج.
المتوقع : يرفض النظام الإرسال؛ رسالة خطأ تنص على الحد الأدنى 8 أحرف.
الخطوة 5 : غيّر كلمة المرور إلى "Abc12345" (8 أحرف بالضبط، حرف كبير وأرقام).
أرسل النموذج.
المتوقع : إنشاء الحساب؛ إرسال بريد التأكيد.
الأولوية : حرجة
حالة الاختبار TC-02
المتطلب : REQ-F02 (قفل الحساب)
التقنية : جدول القرار
الشرط السابق: حساب موجود لـ lock@clinic.example؛ لا محاولات فاشلة سابقة.
الخطوات : 1. حاول تسجيل الدخول بكلمة مرور خاطئة 5 مرات متتالية.
المتوقع (بعد المحاولة 5): يعرض النظام "الحساب مقفل لمدة 30 دقيقة".
الخطوة 2 : انتظر 31 دقيقة. حاول الدخول بكلمة المرور الصحيحة.
المتوقع : نجاح تسجيل الدخول؛ إعادة ضبط عداد المحاولات الفاشلة إلى 0.
الأولوية : حرجة
حالة الاختبار TC-04
المتطلب : REQ-F04 (الحجز + البريد التأكيدي)
التقنية : حالة استخدام / تكامل
الشرط السابق: مريض مسجل الدخول؛ فترة متاحة واحدة لـ الدكتور سالم 2026-07-15 الساعة 10:00.
الخطوات : 1. اختر الفترة 10:00 من نتائج البحث.
2. أكّد الحجز.
المتوقع : (أ) تظهر شاشة التأكيد برقم مرجع الحجز.
(ب) يتراجع توافر الفترة من 1 إلى 0.
(ج) يصل البريد الإلكتروني التأكيدي إلى صندوق وارد المريض خلال 60 ثانية.
الأولوية : حرجة
حالة الاختبار TC-05
المتطلب : REQ-F05 (الإلغاء — ضمن النافذة المسموح بها)
التقنية : القيمة الحدية على موعد الإلغاء النهائي
الشرط السابق: لدى المريض حجز لـ 14:00 اليوم.
الوقت الحالي = 11:59 (دقيقة واحدة قبل حد الساعتين).
الخطوات : 1. انتقل إلى مواعيدي. 2. اختر حجز 14:00. انقر إلغاء.
المتوقع : نجاح الإلغاء؛ تحرر الفترة؛ المريض يتلقى تأكيد الإلغاء.
البديل : كرّر الأمر مع الوقت الحالي = 12:01 (دقيقة واحدة بعد الحد).
المتوقع : يمنع النظام الإلغاء؛ يعرض خطأ يُبيّن حد الساعتين.
الأولوية : عالية
اقرن دائماً المسارات الإيجابية والسلبية. تحتوي TC-05 على الإلغاء الصحيح (قبل الحد بدقيقة) والإلغاء المرفوض (بعد الحد بدقيقة). تحليل القيمة الحدية عند حد قاعدة عمل هو من أعلى التقنيات إنتاجاً في أدوات المحلل — فهو يكشف الحالات الحافة التي يفوّتها المطورون في الغالب.
الخطوة 4 — التعيين إلى مصفوفة تتبع المتطلبات (RTM)
بعد كتابة حالات الاختبار، تُعيّنها في RTM للتأكد من أن كل متطلب يملك حالة اختبار واحدة على الأقل وأن كل حالة اختبار ترتبط بمتطلب واحد على الأقل. أدناه مصفوفة RTM لبوابة CPP v1.0 (مختصرة لإظهار التغطية).
فجوات التغطية مسؤولية المحلل. إن أنهيت مصفوفة RTM ووجدت أي صف متطلب خالياً من حالات الاختبار، فهذه ثغرة — ليست مشكلة ضمان الجودة، بل مشكلة تحليل. إما أن المتطلب لم يكن قابلاً للاختبار أصلاً (ارجع وأعِد صياغته)، أو أن حالة الاختبار لم تُكتب ببساطة (اكتبها الآن). المتطلب الذي لا يملك حالة اختبار هو متطلب لن يُتحقق منه أبداً.
الخطوة 5 — تحديد سيناريوهات اختبار قبول المستخدم (UAT)
إلى جانب مجموعة حالات الاختبار الرسمية، يكتب المحلل سيناريوهات UAT شاملة للرحلات الكاملة التي ينفذها أصحاب المصلحة الحقيقيون. تختلف سيناريوهات UAT عن حالات الاختبار: إذ تصف رحلات عمل متكاملة لا شروطاً معزولة. ثلاثة سيناريوهات UAT تغطي مسارات المستخدم الرئيسية لبوابة CPP v1.0:
- UAT-01 "رحلة المريض الجديد": يسجّل مريض جديد حساباً، يبحث عن طبيب قلب، يحجز فترة، يتلقى بريداً تأكيدياً، ثم يشاهد الموعد في سجله. المسؤول عن الموافقة: ممثل المريض.
- UAT-02 "الإلغاء وإعادة الحجز": يلغي مريض موعداً ضمن النافذة المسموح بها (قبل الحد بساعتين)، يتحقق من تحرر الفترة في نتائج البحث، ثم يعيد حجز فترة مختلفة فوراً. المسؤول عن الموافقة: موظف الاستقبال.
- UAT-03 "الاسترداد بعد قفل الأمان": يدخل مريض كلمة مرور خاطئة 5 مرات، ينتظر 30 دقيقة (محاكاة ببيانات الاختبار)، ثم يستعيد الوصول بكلمة المرور الصحيحة. المسؤول عن الموافقة: مسؤول تقنية المعلومات في العيادة.
الدروس المستخلصة للمحلل
بالنظر إلى مشروع CPP، دورة العمل التي طبّقتها للتو قابلة للتكرار على أي نظام بأي حجم:
- صنّف المتطلبات حسب النوع قبل كتابة أي حالة اختبار — النوع يحدد التقنية والمسؤول.
- اكتب خطة الاختبار أولاً — النطاق ومعايير الدخول والخروج والمسؤوليات قبل حالات الاختبار الفردية.
- استخلص حالات الاختبار من شروط المتطلبات — حلّل كل متطلب إلى مسندات قابلة للاختبار؛ كل مسند يصبح حالة اختبار إيجابية أو سلبية.
- طبّق تحليل القيمة الحدية عند كل حد رقمي — كلمة مرور 8 أحرف، نافذة الإلغاء ساعتان، حد التاريخ 12 شهراً، مهلة البريد 60 ثانية — كلها حدود صريحة قدّمتها لك وثيقة SRS.
- أكمل مصفوفة RTM — هي دليل التغطية، ليست مجرد إجراء بيروقراطي.
- افصل سيناريوهات UAT عن حالات اختبار النظام — UAT يتحقق من صحة رحلات العمل؛ اختبارات النظام تتحقق من المتطلبات الفردية.
هذه هي دورة جودة المحلل الكاملة. من نص وثيقة SRS إلى خطة الاختبار، إلى حالة الاختبار، إلى مصفوفة RTM، إلى سيناريو UAT: لقد سلكت المسار الكامل الآن. في الواقع العملي، يضع المحلل الجيد النسخة الأولى من خطة الاختبار وسيناريوهات UAT في الوقت ذاته الذي تبلغ فيه وثيقة SRS مرحلة المسودة الأولى — الجودة تُصمَّم من البداية، لا تُلصَق في النهاية.