UML: مخططات حالات الاستخدام والسيناريوهات

من حالات الاستخدام إلى حالات الاختبار

18 دقيقة الدرس 9 من 10

من حالات الاستخدام إلى حالات الاختبار

سيناريو حالة الاستخدام المكتوب بعناية ليس مجرد وثيقة متطلبات — بل هو بذرة اختبار القبول. كل تدفق وثّقته في الدرس السابق (التدفق الرئيسي الناجح، التدفقات البديلة، تدفقات الاستثناء) يُقابله مباشرة حالة اختبار واحدة على الأقل. المحللون الذين يفهمون هذه العلاقة يكتبون سيناريوهات أكثر دقة، والمختبرون الذين يفهمونها يقضون وقتاً أقل بكثير في ابتكار مدخلات الاختبار من الصفر.

يعرض هذا الدرس الأسلوب المنهجي لاشتقاق مجموعة كاملة من حالات الاختبار من سيناريوهات حالات الاستخدام، مستخدماً نظام حجز عيادة مثالاً متواصلاً.

لماذا تُعدّ حالات الاستخدام بذوراً ممتازة للاختبار

تشترك سيناريوهات حالات الاستخدام مع حالات الاختبار في ثلاث خصائص: تصف شرطاً مسبقاً (حالة النظام والجهة الفاعلة قبل بدء التفاعل)، وتسلسلاً من الخطوات (الإجراءات واستجابات النظام)، وشرطاً لاحقاً (ما يجب أن يكون صحيحاً حين ينتهي السيناريو بنجاح أو يُخفق). ولأن هذا البناء موجود بالفعل في السيناريو، فأنت لا تكتب الاختبارات من الصفر — بل تُترجم عملاً تحليلياً قائماً إلى صيغة اختبار.

قاعدة التعيين بسيطة:

كل تدفق نجاح رئيسي يُنتج حالة اختبار للمسار السعيد.
كل تدفق بديل يُنتج حالة اختبار تباين أو أكثر.
كل تدفق استثناء يُنتج حالة اختبار سلبية أو أكثر.
كل نقطة امتداد (حيث يمكن لحالة استخدام ممتدة أن تُطلق) تُنتج اختبارات للمسارين: المُطلَق وغير المُطلَق.

اختبارات القبول مقابل اختبارات الوحدة: حالات الاختبار المشتقة من حالات الاستخدام هي اختبارات قبول على مستوى النظام — تختبر هدفاً مستخدماً قابلاً للملاحظة من البداية حتى النهاية. إنها لا تحلّ محل اختبارات الوحدة التي يكتبها المطورون لتغطية المنطق الداخلي. المحللون يمتلكون مواصفة اختبار القبول؛ المطورون يمتلكون اختبارات الوحدة.

أسلوب الترجمة — خطوة بخطوة

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

الخطوة الأولى — تحديد السيناريو

أدرج كل سيناريو (التدفق الرئيسي وجميع التدفقات البديلة وتدفقات الاستثناء) في حالة الاستخدام. أعطِ كل سيناريو تسمية مختصرة. في حالة حجز موعد:

BA-S1 — يحجز المريض موعداً صالحاً (التدفق الرئيسي الناجح)
BA-S2 — لا توجد فترات متاحة في التاريخ المحدد (تدفق بديل)
BA-S3 — المريض يقدم تنسيق معرّف غير صالح (تدفق استثناء)
BA-S4 — انتهاء مهلة النظام أثناء تأكيد الفترة (تدفق استثناء)

الخطوة الثانية — تحديد الشروط المسبقة وبيانات الاختبار

يصبح الشرط المسبق لكل سيناريو من حالة الاستخدام جملة Given (مُعطى) في الاختبار. حدّد بيانات اختبار ملموسة: أسماء أطباء حقيقية، وتواريخ محددة، وسلاسل معرّف دقيقة. البيانات الملموسة تجعل الاختبارات قابلة للتكرار وتُزيل الغموض عن معنى "صالح".

الخطوة الثالثة — اشتقاق خطوات الاختبار

تصبح كل خطوة في تدفق السيناريو إجراءً في الاختبار أو تحققاً من النظام. الإجراءات التي يُنفذها الجهة الفاعلة تصبح خطوات When (عندما)؛ واستجابات النظام المتوقعة تصبح تأكيدات Then (إذن).

الخطوة الرابعة — صياغة النتيجة المتوقعة

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

الخطوة الخامسة — إضافة القيم الحدية وفئات التكافؤ

بمجرد حصولك على الاختبارات المشتقة من السيناريو، عزّزها بالقيم الحدية: الحد الأدنى والأقصى المسموح به للمدخلات، والقيم خارج تلك الحدود مباشرة. هذه الخطوة هي حيث تتقاطع الاختبارات المشتقة من حالات الاستخدام مع أساليب تصميم الاختبار الكلاسيكية (تقسيم التكافؤ، تحليل القيم الحدية).

الرسم البياني الأول — تعيين التدفقات إلى حالات الاختبار

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

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

حالة اختبار كاملة مشتقة من سيناريو

فيما يلي المواصفة الكاملة للاختبار TC-BA-01، المشتقة مباشرة من التدفق الرئيسي الناجح لـ حجز موعد. لاحظ كيف يعكس البناء حقول سيناريو حالة الاستخدام.

Test Case ID : TC-BA-01
Use Case     : Book Appointment (main success flow)
Title        : Patient successfully books a future appointment
Priority     : High
Preconditions:
  - Patient is logged in (session active)
  - At least one available slot exists for Dr. Nour on 2026-07-15
  - Patient ID = P-10042 (valid format)

Test Steps:
  1. Navigate to Book Appointment screen
  2. Enter Patient ID: P-10042
  3. Select Doctor: Dr. Nour Al-Hassan
  4. Select Date: 2026-07-15
  5. Select Time Slot: 10:30
  6. Click Confirm

Expected Result:
  - Confirmation page shows: appointment reference #, doctor name, date, time
  - Appointment record saved in DB with status = PENDING
  - Confirmation email queued to patient@example.com
  - Slot 10:30 on 2026-07-15 marked unavailable

Postcondition : System in stable state; patient can view booking in history

Pass / Fail   : [ ]

قارن هذا بالاختبار TC-BA-03، المشتق من تدفق الاستثناء "المريض يقدم تنسيق معرّف غير صالح":

Test Case ID : TC-BA-03
Use Case     : Book Appointment (exception flow EF-1)
Title        : System rejects booking when patient ID is malformed
Priority     : Medium
Preconditions:
  - Patient is on the Book Appointment screen

Test Steps:
  1. Enter Patient ID: 10042 (missing P- prefix)
  2. Fill in all other valid fields
  3. Click Confirm

Expected Result:
  - Form does NOT submit
  - Inline error shown: "Patient ID must be in format P-NNNNN"
  - No record written to DB
  - Slot availability unchanged

Postcondition : User remains on form; can correct and resubmit

Pass / Fail   : [ ]

الرسم البياني الثاني — مصفوفة التغطية: السيناريوهات مقابل حالات الاختبار

تربط مصفوفة تغطية الاختبار كل حالة اختبار بالسيناريو الذي أُنشئت منه. تجيب على السؤال: "هل غطينا كل سيناريو؟" وهي وثيقة مطلوبة في معظم عمليات ضمان الجودة الرسمية.

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

تطبيق الأسلوب خارج الحجز

ينطبق نفس الأسلوب على أي مجال. بالنسبة لحالة الاستخدام تقديم طلب في متجر إلكتروني، ينتج التدفق الرئيسي الناجح اختبار المسار السعيد؛ وينتج التدفق البديل "نفد المنتج أثناء إتمام الدفع" اختبار تباين؛ وينتج كل من تدفقَي الاستثناء "بوابة الدفع ترفض البطاقة" و"عنوان الشحن خارج نطاق الخدمة" اختبارَين سلبيَّين منفصلَين. بالنسبة لحالة الاستخدام تجديد الاستعارة في نظام مكتبة، يصبح كل من التدفق البديل "تم الوصول إلى الحد الأقصى للتجديدات" وتدفق الاستثناء "المادة محجوزة من قِبَل قارئ آخر" اختباراً سلبياً مميزاً.

النمط عالمي. إذا كانت وثائق السيناريو الخاصة بك شاملة — إذا كانت تغطي جميع التدفقات البديلة وتدفقات الاستثناء الموضحة في الدرس السابق — فستحقق مجموعة الاختبارات الخاصة بك تغطية قبول واسعة تلقائياً تقريباً.

نصيحة — معرفات قابلة للتتبع من اليوم الأول: اعتمد اصطلاح معرّف حالة الاختبار الذي يتضمن اسم حالة الاستخدام ونوع التدفق: TC-[UseCase]-[NN]. عند اكتشاف عيب، يخبر المعرّف المراجعين فوراً بحالة الاستخدام التي نشأ منها، وأي سيناريو كان منقوص المواصفة، وأي محلل يجب إشراكه في الإصلاح.

عندما يكون السيناريو مفقوداً

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

خطأ شائع — الخلط بين حالات الاختبار ونصوص الاختبار: حالة الاختبار تحدد ما يجب التحقق منه (الخطوات، البيانات، النتيجة المتوقعة). نص الاختبار يحدد كيفية أتمتته (كود، محددات، تأكيدات). بوصفك محللاً، مهمتك هي مواصفة حالة الاختبار؛ مهندسو الأتمتة يترجمون تلك المواصفات إلى نصوص برمجية. لا تخلط بين الاثنين وإلا ستتخطى خطوة المواصفة وتنتج اختبارات آلية غير قابلة للتتبع.

ملخص

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