كيف تكتب حالات الاختبار (Test Cases)
حالة الاختبار تعليمة دقيقة قابلة للتكرار: مع هذه الشروط المسبقة، نفّذ هذه الخطوات بهذه البيانات، وتوقّع هذه النتيجة. وعندما تُكتب جيداً تتيح لأي مختبِر — أو سكربت أتمتة — التحقق من سلوك واحد بالطريقة نفسها في كل مرة، وتخبر المطوّر بالضبط كيف يعيد إنتاج الفشل. أما عندما تُكتب بشكل سيئ فهي جملة غامضة تنجح يوم الاثنين وتفشل يوم الثلاثاء لأسباب لا يستطيع أحد تسميتها.
يمنحك هذا الدليل بنية حالة الاختبار الجيدة، ونموذجاً يمكنك لصقه في Jira أو TestRail أو جدول بيانات، ومثالاً عملياً، وتقنيات التصميم التي تحوّل المتطلب إلى مجموعة صغيرة من الحالات ذات تغطية حقيقية.
الحقول التي تحتاجها كل حالة اختبار
- المعرّف — معرّف ثابت (TC-LOGIN-004) حتى يمكن الإشارة إلى الحالة من تقارير الأخطاء والتقارير.
- العنوان — سطر واحد يسمّي السلوك لا الميزة: «تسجيل الدخول يرفض كلمة المرور الخاطئة برسالة واضحة»، لا «اختبار تسجيل الدخول».
- الشروط المسبقة — الحالة التي يجب أن يكون عليها النظام قبل الخطوة 1: مستخدم موجود وموثّق (ويمكن لبريد مؤقت أن يستقبل رسالة التوثيق عند إنشائه)، أو سلة فارغة، أو دور محدد.
- بيانات الاختبار — القيم الدقيقة المستخدمة، أو إشارة إلى مجموعة بيانات مولّدة. «بريد إلكتروني صالح» ليس بيانات اختبار؛ أما «layla.h@example.com» فهو كذلك.
- الخطوات — مرقّمة، إجراء واحد في كل خطوة، مكتوبة بحيث يستطيع موظف جديد اتباعها.
- النتيجة المتوقعة — ما يجب ملاحظته بعد الخطوة الأخيرة، بتحديد يكفي للتحقق: رمز الحالة، ونص الرسالة، وحالة السجل.
- الأولوية والنوع — دخاني، انحدار، سلبي، حدّي — حتى يمكن تصفية الحزم.
- التتبّع — المتطلب أو قصة المستخدم أو معيار القبول الذي تغطيه الحالة.
نموذج حالة اختبار
ID: TC-LOGIN-004
Title: Login rejects a wrong password with a clear message
Priority: High Type: Negative
Requirement: US-12 (User can sign in with email and password)
Preconditions: A verified account exists for layla.h@example.com
Test data: email = layla.h@example.com, password = WrongPass!9
Steps:
1. Open /login
2. Enter the email and the wrong password
3. Click "Sign in"
Expected result:
- The page stays on /login
- The message "Email or password is incorrect" is shown
- No session cookie is set; the failed attempt is counted
Postconditions: Account is not locked (attempt 1 of 5)جرّبها: مولّد حالات الاختبار جرّبها: قصة المستخدم ← حالات اختبار
الفرق بين سيناريو الاختبار وحالة الاختبار
سيناريو الاختبار عبارة من سطر واحد تصف موقفاً يجب اختباره: من يفعل ماذا، وتحت أي شرط، وما النتيجة التي تهمّ — «مستخدم مسجَّل يحاول تسجيل الدخول بكلمة مرور خاطئة فيُرفض دخوله». أما حالة الاختبار فهي السكربت التفصيلي لتنويع واحد من ذلك السيناريو، ببيانات دقيقة وخطوات ونتيجة متوقعة. ويتوسع السيناريو الواحد عادةً إلى عدة حالات تختلف في البيانات أو في حالة النظام وتشترك في نتيجته: كلمة مرور خاطئة، والكلمة الصحيحة مكتوبةً وزر Caps Lock مفعَّل، وكلمة المرور القديمة بعد إعادة تعيينها. والحالة TC-LOGIN-004 في النموذج أعلاه واحدة منها. أما «التحقق من تسجيل الدخول ببيانات صالحة وغير صالحة» فأوسع من أن يكون سيناريو واحداً: فتسجيل الدخول الصالح، وكلمة المرور الخاطئة، والحساب المقفل تنتهي بنتائج مختلفة، فلكلٍّ منها سيناريو مستقل بحالاته. ابدأ بالسيناريوهات للاتفاق على النطاق، ثم اكتب الحالات للتنويعات المهمة.
تقنيات تصميم تكتشف الأخطاء الحقيقية
- تقسيم التكافؤ — اجمع المدخلات التي يجب أن يعاملها النظام بالطريقة نفسها (الأعمار 18–65) واختبر قيمة واحدة من كل مجموعة بدلاً من كل قيمة.
- تحليل القيم الحدّية — تعيش معظم العيوب عند الحواف. لحقل يقبل 1–100، اختبر 0 و1 و2 و99 و100 و101.
- جداول القرار — عندما تتحد عدة شروط (عضو؟ قسيمة؟ أكثر من 50 ريالاً؟)، يضمن جدول بكل التوليفات عدم نسيان أي قاعدة.
- اختبار انتقال الحالات — لأي شيء له دورة حياة (طلب: أُنشئ ← دُفع ← شُحن ← استُرد)، اختبر كل انتقال مسموح والانتقالات الممنوعة.
- الاختبار السلبي — أنواع خاطئة، وحقول ناقصة، وأحرف خاصة، ومدخلات طويلة جداً، وإجراءات متزامنة، وجلسات منتهية.
- الاختبار الزوجي — عندما تكثر توليفات المعاملات، غطِّ كل زوج من القيم بجزء صغير من الحالات.
المحور مختصر بين 2 و99: ليس بمقياس الرسم
- ≤ 0غير صالح
- 1–100صالح
- ≥ 101غير صالح
- 10 أسفل الحد الأدنى مباشرةًالمتوقع: الرفض
- 21 الحد الأدنىالمتوقع: القبول
- 32 فوق الحد الأدنى مباشرةًالمتوقع: القبول
- 499 أسفل الحد الأقصى مباشرةًالمتوقع: القبول
- 5100 الحد الأقصىالمتوقع: القبول
- 6101 فوق الحد الأقصى مباشرةًالمتوقع: الرفض
المجموعات الثلاث ناتجة عن تطبيق تقسيم التكافؤ على الحقل نفسه، وهو يختبر قيمة واحدة من كل مجموعة؛ أما القيم الست فتقع عند حواف المجموعات، حيث تعيش معظم العيوب.
جرّبها: مولّد القيم الحدّية جرّبها: مولّد أقسام التكافؤ جرّبها: مولّد جداول القرار جرّبها: مولّد الاختبارات السلبية جرّبها: مولّد السيناريوهات السلبية بالذكاء الاصطناعي جرّبها: مولّد الحالات الحدّية بالذكاء الاصطناعي
من قصة المستخدم إلى حالات الاختبار
ابدأ من معايير القبول. كل عبارة Given/When/Then هي حالة إيجابية واحدة على الأقل؛ وكل «يجب ألا» أو «يجب» تخفي حالة سلبية. ثم أضف حدود كل حقل تذكره القصة، وحالة لكل دور مستخدم يلامس الميزة، وحالة لما يحدث عند فشل تبعية (مزوّد الدفع أو خدمة البريد). تنتج القصة ذات معايير القبول الثلاثة عادةً ما بين ثماني وخمس عشرة حالة.
جرّبها: قصة المستخدم ← حالات اختبار جرّبها: مولّد معايير القبول جرّبها: مولّد حالات الاختبار بالذكاء الاصطناعي
الأخطاء الشائعة
- اختبار عدة أشياء في حالة واحدة — عندما تفشل لا يعرف أحد أي جزء تعطّل.
- نتائج متوقعة غامضة («يعمل بشكل صحيح»، «تظهر رسالة خطأ») لا يمكن الحكم عليها بالنجاح أو الفشل.
- خطوات تعتمد على تنفيذ حالة أخرى أولاً، فلا يمكن تشغيل الحزمة بأي ترتيب.
- بيانات اختبار من بيانات عملاء حقيقيين — استخدم بيانات مولّدة واقعية لكنها اصطناعية.
- كتابة المسار السعيد فقط. معظم حوادث الإنتاج حالات سلبية أو حدّية.
- عدم التشذيب أبداً: الحالات الخاصة بميزات محذوفة والحالات المكررة تجعل دورات الانحدار بطيئة وغير موثوقة.
جرّبها: مصنع بيانات الاختبار جرّبها: كاشف حالات الاختبار المكرّرة بالذكاء الاصطناعي
الأسئلة الشائعة
ما الفرق بين حالة الاختبار وسيناريو الاختبار؟
السيناريو يصف في سطر واحد موقفاً يجب اختباره والنتيجة التي تهمّ؛ وحالة الاختبار هي السكربت خطوة بخطوة لتنويع واحد من ذلك السيناريو، مع البيانات الدقيقة والنتيجة المتوقعة. والمواقف التي تنتهي بنتائج مختلفة، مثل تسجيل الدخول الصالح والحساب المقفل، سيناريوهات منفصلة.
كم حالة اختبار يجب أن تكون للميزة الواحدة؟
ما يكفي لتغطية كل معيار قبول، وكل حد لكل مدخل، وكل دور، وأنماط الفشل الرئيسية — عادةً 8–15 لقصة مستخدم نموذجية. تغطية السلوكيات أهم من العدد.
هل يجب أن تتضمن حالات الاختبار بيانات اختبار؟
نعم، أو إشارة إلى مجموعة بيانات مولّدة. بدون قيم دقيقة لا تكون الحالة قابلة للتكرار ويصعب إعادة إنتاج الفشل.
ما الصيغة التي تتوقعها Jira وTestRail وXray؟
جميعها تستورد CSV بأعمدة للعنوان والشروط المسبقة والخطوات والنتيجة المتوقعة والأولوية. اجعل كل خطوة في صف عندما تدعم الأداة جداول الخطوات.
هل يستطيع الذكاء الاصطناعي كتابة حالات الاختبار؟
يستطيع الذكاء الاصطناعي صياغة مجموعة أولى قوية من قصة مستخدم أو متطلب، بما فيها الحالات السلبية والحدّية التي يتجاوزها المراجعون كثيراً. وينبغي للمختبِر مراجعة كل حالة في سياق العمل وحذف ما لا ينطبق.
كيف أكتب حالات اختبار لواجهة API؟
تنطبق البنية نفسها: الخطوات طلبات، وبيانات الاختبار هي الحمولة والترويسات، والنتيجة المتوقعة هي رمز الحالة وجسم الاستجابة وأي تغيّر في الحالة. راجع دليل اختبار API للطريقة الكاملة.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsالمعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
تمرين عملي
اكتب حالات الاختبار لتحويل الأموال بين حسابات العميل
تختبر تطبيق الجوال لبنك تجزئة خيالي. قصة المستخدم PAY-31 جاهزة لتصميم الاختبار، وقد كتب أحد زملائك مسودة حالة اختبار واحدة لها. تجد أدناه القصة، وملاحظة عن طريقة عمل التحويلات، والمسودة.
راجع المسودة أولاً في ضوء الحقول التي تحتاجها كل حالة اختبار والأخطاء الشائعة الواردة في الدليل. ثم استبدل بها حالات اختبار يستطيع مختبِر آخر تنفيذها دون أن يسألك عن شيء: اكتب حالتين كاملتين بنموذج الدليل، واستخرج بقية المجموعة قائمةً بسطر واحد لكل حالة. وحيث لا تحدد القصة النتيجة المتوقعة فلا تخمّن، بل اكتبها سؤالاً لمالك المنتج.
تكفي الورقة والقلم؛ وخصّص لذلك نحو 30 دقيقة. وبعد ذلك يمكنك التحقق من قيم المبلغ بأداة «تحليل القيم الحدّية»، فهي تتعامل مع القيم العشرية، وأخذ صيغ مبالغ لحالات سلبية إضافية من أداة «مولّد مجموعات الأرقام العشرية»، ولصق المعايير من AC1 إلى AC3، معياراً في كل سطر، في أداة «المتطلبات ← حالات اختبار» لمقارنة مصفوفة التتبّع التي تُنتجها بمصفوفتك.
بنك تجزئة خيالي، تطبيق الجوال. جميع الحسابات بالريال السعودي (SAR).
النظام المصرفي الأساسي (Core banking) هو الذي ينفّذ التحويلات، ويستدعيه التطبيق
عندما يضغط العميل «تأكيد».
تُفتح شاشة «بين حساباتي» من «التحويلات»، وفيها الحقول «من» و«إلى» و«المبلغ» وزر «تأكيد».
يرى العميل أيضاً حسابات شاركها معه عميل آخر بصلاحية العرض فقط؛ وهذه الحسابات
ليست حساباته.
PAY-31 تحويل الأموال بين حساباتي
بصفتي عميلاً لديه أكثر من حساب
أريد نقل الأموال بين حساباتي
كي أدفع من الحساب الذي أختاره.
AC1 بافتراض أنني مسجّل الدخول ولديّ حسابان نشطان على الأقل، عندما أختار حساب مصدر
وحساب وجهة مختلفاً عنه ومبلغاً وأضغط «تأكيد»، يُخصم المبلغ من المصدر ويُضاف إلى
الوجهة فوراً، ويظهر تأكيد يتضمن رقماً مرجعياً.
AC2 يجب أن يكون المبلغ من 1.00 إلى 20,000.00 ريال شاملاً الحدّين، بمنزلتين عشريتين
على الأكثر. وإلا يبقى زر «تأكيد» معطّلاً وتظهر تحت الحقل رسالة
«أدخل مبلغاً من 1.00 إلى 20,000.00 ريال».
AC3 يجب ألا ينزل التحويل برصيد حساب المصدر عن الصفر. وعندما أؤكد مبلغاً أكبر من
الرصيد المتاح في حساب المصدر، تظهر رسالة «الرصيد غير كافٍ» ولا تنتقل أي أموال.
مسودة حالة اختبار كتبها زميل
العنوان: اختبار التحويل
الخطوات: 1. سجّل الدخول باسم أحمد الحربي (نُسخت حساباته من بيئة الإنتاج).
2. نفّذ TC-DEP-03 أولاً كي يكون في حساب التوفير مال.
3. حوّل بعض المال من التوفير إلى الجاري، ثم جرّب مبلغاً كبيراً ومبلغاً
أكبر من الرصيد.
المتوقع: التحويل يعمل بشكل صحيح وتظهر رسالة خطأ.- راجع المسودة حقلاً حقلاً — المعرّف، والعنوان، والشروط المسبقة، وبيانات الاختبار، والخطوات، والنتيجة المتوقعة، والأولوية والنوع، والتتبّع — ودوّن ما ينقص منها وما هو ضعيف. وسمِّ كل خطأ شائع من أخطاء الدليل تقع فيه.
- عُدّ السلوكيات التي تختبرها المسودة، وقسّمها بحيث تتحقق كل حالة من سلوك واحد.
- اكتب حالتين كاملتين بنموذج الدليل: التحويل الصالح (AC1)، وتحويلاً يزيد على الرصيد المتاح بمقدار 0.01 ريال (AC3). استخدم بيانات اختبار دقيقة واصطناعية، ونتائج متوقعة يحكم عليها أي شخص بالنجاح أو الفشل بالطريقة نفسها.
- استخرج بقية المجموعة بطريقة الدليل للانتقال من قصة المستخدم إلى حالات الاختبار: حالة إيجابية لكل معيار قبول، وحالة سلبية لكل «يجب» و«يجب ألا»، وحدود كل رقم، وحالة لكل نوع من المستخدمين أو الحسابات، وحالة لتعطّل النظام المصرفي الأساسي. اكتب سطراً واحداً لكل حالة: المعرّف، والنوع، والمعيار، وبيانات الاختبار، والنتيجة المتوقعة.
- تحقق من أن كل معيار قبول تغطيه حالة واحدة على الأقل، واكتب أسئلتك لمالك المنتج.
إظهار الإجابة النموذجية
مراجعة المسودة (الخطوة 1). قد تختلف صياغتك؛ وسبع ملاحظات أو أكثر من هذه إجابة كاملة. (1) لا معرّف لها، فلا تستطيع تقارير الأخطاء ولا تقارير الاختبار الإشارة إليها. (2) العنوان «اختبار التحويل» يسمّي الميزة لا السلوك. (3) لا شروط مسبقة: الأرصدة الابتدائية غير مذكورة، فلا يستطيع أحد أن يقول ما الأرصدة المتوقعة بعد التنفيذ. (4) الخطوة 2 تجعل الحالة معتمدة على تنفيذ TC-DEP-03 أولاً، فلا يمكن تشغيل الحزمة بأي ترتيب؛ والرصيد الذي تحتاجه الحالة مكانه شروطها المسبقة. (5) العميل وحساباته منسوخة من بيئة الإنتاج: لا مكان لبيانات العملاء الحقيقيين في حالات الاختبار، ولا سيما في البنوك؛ استخدم عميل اختبار اصطناعياً. (6) بيانات الاختبار غامضة: «بعض المال» و«مبلغاً كبيراً» ليستا قيمتين، فسينفّذ مختبِران اختبارين مختلفين. (7) الخطوة 3 تجمع عدة إجراءات وثلاثة سلوكيات — تحويلاً صالحاً، وحدّ 20,000.00 ريال، وفحص الرصيد — فإذا فشلت لا يعرف أحد أي جزء تعطّل. (8) عبارة «التحويل يعمل بشكل صحيح وتظهر رسالة خطأ» لا يمكن الحكم عليها بالنجاح أو الفشل: ما الأرصدة، وما الرسالة، وهل يظهر رقم مرجعي؟ (9) لا أولوية ولا نوع ولا تتبّع إلى PAY-31 ومعاييرها. وأربع من هذه الملاحظات أخطاء شائعة يسمّيها الدليل: اختبار عدة أشياء في حالة واحدة (7)، ونتيجة متوقعة غامضة (8)، وخطوة تعتمد على حالة أخرى (4)، وبيانات عملاء حقيقيين (5).
التقسيم (الخطوة 2): تختبر المسودة ثلاثة سلوكيات، فتصبح ثلاث حالات: التحويل الصالح (TC-PAY31-01)، ومبلغاً يتجاوز الحدّ (TC-PAY31-05)، ومبلغاً يتجاوز الرصيد (TC-PAY31-09). وكل حالة سلبية تخالف قاعدة واحدة فقط: حالات الحدّ تحوّل من حساب التوفير الذي يزيد رصيده على 20,000.00 ريال، وحالات الرصيد تستخدم مبالغ داخل الحدّ؛ فإذا فشلت إحداها دلّت على قاعدة واحدة. وتبدأ جميع الحالات من مجموعة البيانات الاصطناعية نفسها، وتُستعاد قبل كل تشغيل: عميل الاختبار CUST-T-031، وحساب التوفير SAV-2002 برصيد 25,000.00 ريال، والحساب الجاري CUR-1001 برصيد 5,000.00 ريال، وكلاهما نشط ولا معاملات معلّقة عليهما؛ وتضيف الحالتان TC-PAY31-11 وTC-PAY31-12 الحساب المشارَك وعميل الاختبار الثاني اللذين تذكرانهما.
الحالة TC-PAY31-01 كاملة (الخطوة 3). العنوان: التحويل بين حسابات العميل ينقل المبلغ ويعرض رقماً مرجعياً. الأولوية: عالية. النوع: إيجابي، وهي مرشّحة أيضاً لحزمة اختبار الدخان. المتطلب: المعيار AC1 من PAY-31. الشروط المسبقة: العميل CUST-T-031 مسجّل الدخول؛ والرصيد المتاح في SAV-2002 هو 25,000.00 ريال، وفي CUR-1001 5,000.00 ريال. بيانات الاختبار: المصدر SAV-2002، والوجهة CUR-1001، والمبلغ 250.00. الخطوات: 1. افتح «التحويلات». 2. اختر «بين حساباتي». 3. اختر SAV-2002 في «من». 4. اختر CUR-1001 في «إلى». 5. أدخل 250.00 في «المبلغ». 6. اضغط «تأكيد». النتيجة المتوقعة: يظهر تأكيد يتضمن رقماً مرجعياً؛ ويعرض SAV-2002 رصيد 24,750.00 ريال، ويعرض CUR-1001 رصيد 5,250.00 ريال. الشروط اللاحقة: تغيّر الرصيدان؛ فاستعد مجموعة البيانات قبل التشغيل التالي.
الحالة TC-PAY31-09 كاملة. العنوان: تحويل يزيد على الرصيد المتاح بمقدار 0.01 ريال يُرفض برسالة «الرصيد غير كافٍ». الأولوية: عالية. النوع: سلبي، حدّي. المتطلب: المعيار AC3 من PAY-31. الشروط المسبقة: العميل CUST-T-031 مسجّل الدخول؛ والرصيد المتاح في CUR-1001 هو 5,000.00 ريال، وفي SAV-2002 25,000.00 ريال. بيانات الاختبار: المصدر CUR-1001، والوجهة SAV-2002، والمبلغ 5000.01، أي الرصيد زائد 0.01، وهو داخل حدّ المعيار AC2، فلا يخالف إلا AC3. الخطوات: 1. افتح «التحويلات». 2. اختر «بين حساباتي». 3. اختر CUR-1001 في «من». 4. اختر SAV-2002 في «إلى». 5. أدخل 5000.01 في «المبلغ». 6. اضغط «تأكيد». النتيجة المتوقعة: تظهر رسالة «الرصيد غير كافٍ»؛ ولا يظهر تأكيد ولا رقم مرجعي؛ ويبقى رصيد CUR-1001 5,000.00 ريال ورصيد SAV-2002 25,000.00 ريال. الشروط اللاحقة: لا شيء، فالرصيدان لم يتغيّرا.
بقية المجموعة (الخطوة 4)، بسطر لكل حالة؛ ومع الحالتين السابقتين يصبح المجموع 14 حالة. TC-PAY31-02 [حدّي · AC2] المبلغ 1.00، وهو الحدّ الأدنى، من SAV-2002: مقبول؛ ويعرض SAV-2002 24,999.00 وCUR-1001 5,001.00. TC-PAY31-03 [حدّي · AC2] المبلغ 0.99: يبقى زر «تأكيد» معطّلاً، وتظهر تحت الحقل رسالة «أدخل مبلغاً من 1.00 إلى 20,000.00 ريال»، ولا يتغيّر أي رصيد. TC-PAY31-04 [حدّي · AC2] المبلغ 20000.00، وهو الحدّ الأعلى، من SAV-2002: مقبول؛ ويعرض SAV-2002 5,000.00 وCUR-1001 25,000.00. TC-PAY31-05 [حدّي · AC2] المبلغ 20000.01 من SAV-2002: يبقى زر «تأكيد» معطّلاً وتظهر الرسالة نفسها؛ ورصيد 25,000.00 يضمن أن الحدّ وحده هو المخالَف. TC-PAY31-06 [سلبي · AC2] المبلغ 10.005 بثلاث منازل عشرية: غير مقبول؛ أما هل تظهر الرسالة أم تتعذّر كتابة المنزلة الثالثة أصلاً فهو السؤال Q1. TC-PAY31-07 [سلبي · AC2] ترك «المبلغ» فارغاً: يبقى زر «تأكيد» معطّلاً (وهل تظهر الرسالة أيضاً جزء من السؤال Q1).
TC-PAY31-08 [حدّي · AC3] مبلغ يساوي الرصيد المتاح، 5000.00 من CUR-1001: مقبول، لأن المعيار AC3 يمنع النزول عن الصفر لا بلوغه؛ ويعرض CUR-1001 0.00 وSAV-2002 30,000.00. TC-PAY31-10 [سلبي · AC1] بعد اختيار SAV-2002 في «من» لا يمكن اختياره في «إلى»؛ وكيف يظهر ذلك هو السؤال Q3. TC-PAY31-11 [سلبي · الدور] الحساب الذي شاركه عميل آخر مع CUST-T-031 بصلاحية العرض فقط (VIEW-3003) لا يُعرض في «من»؛ أما هل يُعرض في «إلى» فهو السؤال Q4. TC-PAY31-12 [سلبي · الشرط المسبق في AC1] عميل الاختبار CUST-T-032 لديه حساب نشط وحساب مغلق: لا يُعرض الحساب المغلق ولا يمكن إجراء أي تحويل؛ وما يراه العميل هو السؤال Q5. TC-PAY31-13 [سلبي · التبعية] النظام المصرفي الأساسي لا يستجيب بعد «تأكيد» (يُحاكى ذلك في بيئة الاختبار، بوحدة بديلة (Stub) مثلاً): لا يظهر تأكيد، ولا يحدث تحويل منقوص، فإما أن يتغيّر الرصيدان مرة واحدة وإما ألا يتغيّر أيّ منهما؛ والرسالة وسلوك إعادة المحاولة هما السؤال Q6. TC-PAY31-14 [سلبي · AC1، إجراءات متزامنة] الضغط على «تأكيد» مرتين بسرعة مع المبلغ 250.00 من SAV-2002 إلى CUR-1001: تحويل واحد فقط ورقم مرجعي واحد؛ ويعرض SAV-2002 24,750.00 لا 24,500.00، ويعرض CUR-1001 5,250.00. وإن اتبعت نمط القيم الست في الدليل (ثلاث قيم عند كل حدّ)، فأضف أيضاً 1.01 و19999.99 من SAV-2002، و4999.99 من CUR-1001 عند حدّ الرصيد؛ والقيم الثلاث كلها مقبولة.
التغطية (الخطوة 5): المعيار AC1 تغطيه الحالات TC-PAY31-01 و10 و12 و13 و14، والمعيار AC2 تغطيه الحالات من 02 إلى 07، والمعيار AC3 تغطيه الحالتان 08 و09، ودور العرض فقط تغطيه الحالة 11. ولكل معيار حالة إيجابية وحالة سلبية على الأقل. ويتوقع الدليل نحو ثماني إلى خمس عشرة حالة لقصة ذات ثلاثة معايير؛ لكن ما يجعل المجموعة كاملة ليس العدد، بل تغطية كل معيار وكل حدّ وكل نوع من المستخدمين وتعطّل التبعية.
أسئلة لمالك المنتج: Q1 هل تُمنع كتابة المنزلة العشرية الثالثة، أم تُقبل كتابتها ثم تظهر رسالة المعيار AC2؟ وهل تظهر هذه الرسالة أيضاً ما دام «المبلغ» فارغاً؟ وهل تُقبل المبالغ المكتوبة بفاصل الآلاف (1,000.00) أو بالأرقام العربية المشرقية؟ Q2 هل يستبعد «الرصيد المتاح» في AC3 عمليات البطاقة المعلّقة والمبالغ المحجوزة؟ Q3 هل يُحذف حساب المصدر من قائمة «إلى»، أم تظهر رسالة؟ Q4 هل يمكن تحويل المال إلى حساب مشارَك بصلاحية العرض فقط، أم يُخفى من القائمتين؟ Q5 ماذا يرى في «بين حساباتي» العميلُ الذي لديه أقل من حسابين نشطين؟ Q6 حين لا يستجيب النظام المصرفي الأساسي: ما الرسالة التي تظهر، وهل يحق للعميل إعادة المحاولة، وما الذي يمنع إعادة المحاولة من نقل المال مرتين؟ Q7 هل حدّ 20,000.00 ريال لكل تحويل هو الحدّ الوحيد، أم يوجد أيضاً حدّ يومي إجمالي؟
راجع عملك: يجب أن يسمّي عنوان كل حالة كاملة سلوكاً واحداً، وأن يتحقق كل سطر في قائمتك من سلوك واحد، وأن تبدأ كل حالة من شروط مسبقة مذكورة لا من حالة أخرى، وأن تستخدم قيماً اصطناعية دقيقة، وأن تكون نتيجتها المتوقعة مما يحكم عليه مختبِران بالطريقة نفسها. وبمصطلحات ISTQB، فإن القصة PAY-31 ومعاييرها هي أساس الاختبار (Test basis)، وكل سطر في قائمتك يغطي شرط اختبار (Test condition)، وكل حالة كاملة تتضمن الشروط المسبقة والمدخلات والنتائج المتوقعة والشروط اللاحقة التي يذكرها مسرد ISTQB في تعريفه لحالة الاختبار. وإن لم تكن في مجموعتك الحالة TC-PAY31-08 (مبلغ يساوي الرصيد) أو TC-PAY31-13 (تعطّل التبعية) أو TC-PAY31-14 (الضغط المزدوج)، فأضفها: فالأولى هي الحدّ الذي يسمح به المعيار AC3، والثانية هي تعطّل التبعية الذي تطلبه طريقة الدليل لقصص المستخدم، والثالثة من الإجراءات المتزامنة في قائمة الدليل للاختبارات السلبية.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.
جزء من مسار تعلم ضمان الجودة
قبل هذا الموضوع
الموضوعات التالية
الأدوات المذكورة في هذا الدليل
ولّد حالات اختبار منظّمة (المعرّف والعنوان والشروط المسبقة والخطوات والنتيجة المتوقّعة والأولوية) من وصف الميزة وقائمة الحقول.
ولّد سيناريوهات اختبار عالية المستوى تغطي الجوانب الوظيفية والسلبية والأمنية وسهولة الاستخدام والتوافق لأي ميزة.
حوّل قصة مستخدم (As a / I want / So that) إلى حالات اختبار منظّمة باستخدام القوالب والقواعد الاستدلالية.
ولّد حالات اختبار سلبية لحقول النماذج وواجهات API: قيم فارغة وnull ونوع خاطئ وطول زائد وحقن وصيغة غير صالحة.
ولّد القيم الحدّية (min-1 وmin وmin+1 والقيمة الاسمية وmax-1 وmax وmax+1) للقيود الرقمية وقيود الطول.
اشتق فئات التكافؤ الصالحة وغير الصالحة لكل مدخل واختر قيم اختبار تمثيلية.
أنشئ جداول القرار من الشروط والإجراءات، وولّد جميع تركيبات القواعد، واختزل المستحيل منها.
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
حوّل قصة مستخدم إلى حالات اختبار احترافية ومنظّمة (المعرّف والعنوان والنوع والأولوية والشروط المسبقة والبيانات والخطوات والنتيجة المتوقّعة) باستخدام الذكاء الاصطناعي من متقن.
مصنع متكامل لبيانات الاختبار الاصطناعية: مستخدمون وعملاء وشركات وعناوين وأرقام وتواريخ وسلاسل نصية بصيغة JSON أو CSV أو SQL أو XML.