سيناريو الاختبار مقابل حالة الاختبار: شرح الفروق الرئيسية

يتم استخدام مصطلحي "سيناريو الاختبار" و "حالة الاختبار" وكأنهما يعنيان نفس الشيء. لكنهما ليسا كذلك. الخلط بينهما هو الطريقة التي تجعل خطط الاختبار إما مبهمة جدًا بحيث لا يمكن تنفيذها أو مفصلة جدًا بحيث يصعب قراءتها. أحدهما يصف ما يجب اختباره؛ والآخر يصف بالضبط كيف. عندما تفهم العلاقة بشكل صحيح، يصبح تغطيتك قابلة للتدقيق والتشغيل.

يقدم هذا الدليل تعريفًا لكل مصطلح، ويوضح الاختلافات جنبًا إلى جنب، ويعرض كيفية عملهما معًا في سير عمل حقيقي لاختبار واجهة برمجة التطبيقات (API) باستخدام Apidog.

ما هو سيناريو الاختبار؟

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

فكر في الأمر كعنوان. بالنسبة لعملية الدفع في التجارة الإلكترونية، قد تكون السيناريوهات كالتالي:

• التحقق من الدفع لمستخدم مسجل ببطاقة محفوظة
• التحقق من الدفع لمستخدم زائر
• التحقق من الدفع عندما ينفد مخزون سلعة أثناء عملية الشراء
• التحقق من الدفع عندما يتم رفض الدفع

يخبرك كل سطر ماذا يجب التحقق منه ولماذا يهم ذلك العمل. لا يخبرك أي منها عن نقطة النهاية (endpoint) التي يجب الاتصال بها أو الحمولة (payload) التي يجب إرسالها. يُكتب السيناريو من وجهة نظر المستخدم أو المتطلبات، لذلك يبقى قابلاً للقراءة من قبل مديري المنتجات والمهندسين على حد سواء.

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

ما هي حالة الاختبار؟

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

خذ سيناريو "التحقق من الدفع لمستخدم زائر". ينقسم هذا السيناريو إلى حالات مثل:

• إرسال POST /orders بحمولة زائر صالحة يعيد 201 ومعرف طلب order_id
• إرسال POST /orders بدون عنوان شحن يعيد 400 وخطأ تحقق validation_error
• إرسال POST /orders مع وحدة SKU (وحدة حفظ المخزون) غير متوفرة يعيد 409 وerror: out_of_stock

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

السمة المميزة لحالة الاختبار هي الدقة. "الدفع يعمل" هو جزء من سيناريو في أحسن الأحوال. "إرسال طلب زائر صالح، وتوقع 201 مع order_id غير فارغ" هي حالة اختبار.

الاختلافات الرئيسية

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

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

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

كيف يعمل السيناريوهات والحالات معًا

سير العمل العملي ينتقل من العام إلى الخاص في خمس خطوات.

1. تحديد السيناريوهات من المتطلبات. اقرأ المواصفات أو وثائق واجهة برمجة التطبيقات (API) وقم بإدراج كل سلوك يستحق التحقق منه، بما في ذلك المسارات غير السعيدة. هذا هو المكان الذي يتم فيه اكتشاف التغطية المفقودة، لذا اقضِ وقتًا حقيقيًا هنا.

2. تحديد هدف كل سيناريو. اذكر ما يعنيه "تم". بالنسبة لـ "التحقق من دفع الزائر"، الهدف هو أن يتمكن الزائر من تقديم طلب واستلام تأكيد، بينما يتم رفض الطلبات غير الصالحة بشكل نظيف.

3. كتابة حالات الاختبار تحت كل سيناريو. قم بتوسيع كل سيناريو إلى حالات ملموسة مع المدخلات والنتائج المتوقعة. قم بتغطية المسار السعيد، وكل فشل في التحقق، والظروف الحافة ذات الصلة.

4. المراجعة للتأكد من الاكتمال. ارجع إلى الأعلى في الشجرة. هل يحتوي كل سيناريو على الأقل على حالة مسار سعيد واحدة وحالة سلبية واحدة؟ هل يظهر كل رمز حالة موثق في بعض النتائج المتوقعة؟ الفجوات التي يتم العثور عليها هنا رخيصة؛ الفجوات التي يتم العثور عليها في الإنتاج ليست كذلك.

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

بالنسبة للفرق التي تعتمد على السلوك، تتوافق السيناريوهات بشكل طبيعي مع تنسيق Given-When-Then من Gherkin؛ دليل Gherkin لاختبار API القائم على BDD يوضح كيف يحافظ هذا الهيكل على قابلية قراءة السيناريوهات مع بقائها قابلة للتنفيذ.

مثال عملي: من السيناريو إلى الحالات

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

السيناريو: يمكن للمستخدم إنشاء ملاحظة. سطر واحد. ينتمي هذا السيناريو إلى خطة الاختبار، ويمكن لأي شخص قراءته. لا يذكر نقاط النهاية، أو الحمولات، أو رموز الحالة، ولا ينبغي له ذلك.

الآن قم بتوسيعه إلى حالات. كل حالة هي فحص واحد قابل للتشغيل بمدخلات دقيقة ونتيجة متوقعة دقيقة.

• الحالة 1، المسار السعيد. POST /notes مع {"title": "Groceries", "body": "milk, eggs"} ورمز دخول صالح. توقع 201، جسم استجابة يحتوي على id غير فارغ، title يساوي Groceries، وطابع زمني created_at. استجابة في أقل من 600 مللي ثانية.
• الحالة 2، حقل مطلوب مفقود. POST /notes مع {"body": "milk, eggs"} ورمز دخول صالح. توقع 400، error يساوي validation_error، وdetails تسمي حقل title.
• الحالة 3، غير مصادق عليه. POST /notes بجسم صالح وبدون رمز دخول. توقع 401 ولا يوجد id في الاستجابة.
• الحالة 4، حمولة زائدة الحجم. POST /notes مع body بحجم 2 ميجابايت. توقع 413 ورسالة خطأ واضحة.

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

بناء السيناريوهات والحالات في Apidog

يقوم Apidog بنمذجة هذا الهيكل مباشرة، بحيث يتطابق الهيكل في خطة الاختبار الخاصة بك مع الهيكل في أدواتك.

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

كل كتلة طلبات مع تأكيدات هي فعليًا حالة اختبار. يمكنك تأكيد رموز الحالة، وحقول جسم الاستجابة، وتوافق المخطط (schema)، ووقت الاستجابة بالنقر، دون كتابة نص برمجي. يتيح الاختبار المعتمد على البيانات لحالة واحدة التشغيل مقابل العديد من صفوف الإدخال من ملف CSV أو JSON، بحيث تغطي حالة سلبية واحدة كل تركيبة غير صالحة.

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

قم بتنزيل Apidog لبناء أول سيناريو لك ومشاهدة تجميع الحالات إلى السيناريوهات عمليًا.

لماذا تحتاج لكليهما، وليس أحدهما

تحاول الفرق أحيانًا تخطي طبقة واحدة. تخطي السيناريوهات وكتابة الحالات فقط ينتج عنه قائمة طويلة ومسطحة بدون خريطة تغطية؛ لا يمكنك الإجابة على سؤال "هل اختبرنا عملية الدفع للضيف بالكامل؟" دون إعادة قراءة كل حالة. تخطي الحالات والاحتفاظ بالسيناريوهات فقط ينتج عنه خطة لا يمكن لأحد تنفيذها بشكل متسق، لأن "التحقق من الدفع" يعني شيئًا مختلفًا لكل مختبر.

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

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

الأسئلة المتكررة

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

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

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

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