اختبار انتقالات الحالة

لماذا يهم

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

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

الحالات والأحداث والانتقالات والشروط الحارسة

الحالة (State) وضعٌ يبقى فيه الكيان المنمذَج حتى يحدث شيء ما. والحدث (Event) هو ما يحدث: نقرة، أو وصول رسالة، أو انتهاء مؤقّت. والانتقال (Transition) هو تغيّر الحالة الذي يسببه حدث، ويعدّه منهج ISTQB لحظياً. وقد يُطلق إجراءً (Action) مثل إرسال رسالة SMS، وقد يحمل شرطاً حارساً (Guard Condition) يجب أن يكون صحيحاً كي يحدث الانتقال.

يُكتب وصف الانتقال بالصيغة event [guard] / action، أي «الحدث [الشرط الحارس] / الإجراء»، مع حذف الأجزاء غير الموجودة. وتظهر أهمية الشرط الحارس حين يقود الحدث نفسه إلى حالات مختلفة: «رمز خاطئ [المحاولة الخاطئة الأولى أو الثانية]» يُبقي المستخدم في «أُرسل الرمز»، أما «رمز خاطئ [المحاولة الخاطئة الثالثة]» فيُقفل الحساب. والشرط الحارس مثل عدد المحاولات حدٌّ في حقيقته، فاختبر جانبيه كليهما. وتستخدم الأمثلة هذا المتطلب:

• يطلب المستخدم رمزاً، فيرسل النظام رمزاً من ⁦6⁩ أرقام برسالة SMS صالحاً لمدة ⁦5⁩ دقائق.
• الرمز الصحيح يُدخل المستخدم إلى حسابه، ولا يصلح الرمز إلا لمرة واحدة. وتسجيل الخروج يُنهي الجلسة.
• بعد رمز خاطئ يمكن للمستخدم المحاولة مجدداً، والرمز الخاطئ الثالث على التوالي يُقفل الحساب ⁦30⁩ دقيقة، يمكنه بعدها طلب رمز جديد.

مخطط الحالات وجدول الحالات

يرسم مخطط الحالات (State Diagram)، ويُسمّى أيضاً مخطط انتقالات الحالة، الحالاتِ مربعاتٍ والانتقالاتِ الصالحة أسهماً موسومة. ولمتطلب تسجيل الدخول أربع حالات، من S1 إلى S4، وسبعة انتقالات، من T1 إلى T7. والمخطط سهل المراجعة مع الفريق، لكنه لا يُظهر إلا المسموح به.

ويحمل جدول الحالات (State Table) النموذج نفسه في شبكة: صف لكل حالة، وعمود لكل حدث، وفي كل خلية الانتقال وحالته الهدف. ويُظهر الممنوع أيضاً: فالخلية الفارغة، وعلامتها الشَّرطة في الجدول أدناه، انتقال غير صالح، يجب أن يرفض فيه النظام الحدث أو يتجاهله ويبقى في حالته. ويخصّص منهج ISTQB عموداً لكل حدث مع شرطه الحارس، فيأخذ E3 عمودين؛ أما هذا الجدول فيجمع الشرطين الحارسين للحدث E3 في خلية واحدة ليبقى مختصراً.

وملء الجدول يكشف الثغرات. فالمتطلب لا يقول ماذا يحدث إذا طلب المستخدم رمزاً آخر بينما الرمز الأول ما زال صالحاً، لذا تحمل الخلية ⁦S2 × E1⁩ سؤالاً لمالك المنتج لا اختباراً.

                 E1        E2        E3                E4        E5        E6
                 request   correct   wrong             code      sign      lock
                 code      code      code              expires   out       ends
S1 Signed out    T1: S2    -         -                 -         -         -
S2 Code sent     ?         T2: S3    T3: S2 [1st,2nd]  T5: S1    -         -
                                     T4: S4 [3rd]
S3 Signed in     -         -         -                 -         T6: S1    -
S4 Locked        -         -         -                 -         -         T7: S1

-  invalid transition: refused, the state does not change
?  not specified in the requirement: ask the product owner

جرّبها: مولّد انتقالات الحالات

التغطية: جميع الحالات، والانتقالات الصالحة، وجميع الانتقالات

حالة الاختبار هنا تسلسلٌ من الأحداث يبدأ من حالة معروفة، مع الحالة والإجراء المتوقعين بعد كل حدث، وغالباً ما تغطي حالة الاختبار الواحدة عدة انتقالات. ويناقش منهج ISTQB للمستوى التأسيسي ثلاثة معايير للتغطية، كلٌّ منها أقوى مما قبله: فبلوغ ⁦100%⁩ من معيار لاحق يضمن ⁦100%⁩ من المعايير السابقة.

• تغطية جميع الحالات (All States Coverage): عناصر التغطية هي الحالات. وتبلغ حالتا اختبار ⁦100%⁩، هما E1 ثم E2، وE1 ثم E3 ثلاث مرات، لكنهما لا تنفّذان إلا الانتقالات من T1 إلى T4، أي ⁦4⁩ من ⁦7⁩ انتقالات صالحة (⁦57%⁩). فيبقى انتهاء صلاحية الرمز وتسجيل الخروج وانتهاء القفل دون اختبار.
• تغطية الانتقالات الصالحة (Valid Transitions Coverage)، وتُسمّى أيضاً تغطية 0-switch: عناصر التغطية هي الانتقالات الصالحة المفردة، من T1 إلى T7. وهي المعيار الأكثر استخداماً، وبلوغ ⁦100%⁩ منها يضمن المرور بكل الحالات أيضاً.
• تغطية جميع الانتقالات (All Transitions Coverage): عناصر التغطية هي كل الانتقالات في جدول الحالات؛ فيُنفَّذ كل انتقال صالح ويُجرَّب كل انتقال غير صالح. ويوصي بها المنهج حداً أدنى للبرمجيات الحرجة للمهمة وللسلامة.

مثال تطبيقي: حالات اختبار الرمز لمرة واحدة

لتحقيق تغطية الانتقالات الصالحة، ابدأ كل حالة اختبار من S1 وتابع الأحداث حتى يُنفَّذ كل انتقال. وتكفي ثلاث حالات اختبار. ويمكن لتسلسل طويل واحد أن يغطي الانتقالات السبعة، لأن T5 وT6 وT7 تعود كلها إلى S1، لكن إخفاقاً مبكراً فيه يمنع تنفيذ كل الانتقالات التي تليه. في TC-03 ينفّذ الرمزان الخاطئان الأول والثاني T3 لأن الشرط الحارس صحيح، وينفّذ الثالث T4.

اكتب كل نتيجة متوقعة بصيغة الحالة والإجراء، لا رسالة الشاشة وحدها: بعد الرمز الخاطئ الثاني يبقى المستخدم في S2 ويرى أن محاولة واحدة متبقية. وتنتظر TC-02 وTC-03 مدة ⁦5⁩ دقائق و⁦30⁩ دقيقة، فاسأل مبكراً هل تسمح بيئة الاختبار بتقصير هذه المدد أو بضبط الساعة.

Every test case starts in S1 Signed out.

ID     Events and resulting states                            Covers
TC-01  E1 -> S2   E2 -> S3   E5 -> S1                         T1 T2 T6
TC-02  E1 -> S2   E4 -> S1                                    T1 T5
TC-03  E1 -> S2   E3 -> S2   E3 -> S2   E3 -> S4   E6 -> S1   T1 T3 T4 T7

Valid transitions coverage: 7 of 7 (100%)
All states coverage:        4 of 4 (100%)

جرّبها: مولّد حالات الاختبار

اختبار الانتقالات غير الصالحة

من الخلايا الفارغة الـ⁦17⁩ في هذا الجدول لا يمكن إطلاق خمس: فالقفل لا ينتهي إلا في S4، والرمز غير المستخدَم، وهو وحده ما تنتهي صلاحيته، لا يوجد إلا في S2 وS4. علّم هذه الخمس بأنها غير قابلة للاختبار واذكر السبب؛ والـ⁦12⁩ الباقية هي الانتقالات غير الصالحة التي تجرّبها لتغطية جميع الانتقالات.

جرّب انتقالاً واحداً في كل حالة اختبار: فإذا قُبلت محاولة أولى خطأً، فلن يكون النظام في الحالة التي تفترضها المحاولة التالية، فيخفي عيبٌ عيباً آخر، ويسمّي منهج ISTQB ذلك حجب العيوب (Defect Masking)، ويُعرف أيضاً باسم Fault Masking. والنتيجة المتوقعة أن يُرفض الحدث ولا تتغيّر الحالة؛ فتأكّد من الحالة بالحدث التالي أو عبر الواجهة البرمجية (API). وابدأ بالمحاولات الأهم من ناحية الأمان:

• ⁦S4 × E2⁩: أثناء القفل، أدخل الرمز الصحيح قبل انتهاء صلاحيته. المتوقع: يبقى الحساب مقفَلاً، ولا تُفتح جلسة.
• ⁦S3 × E2⁩: بعد تسجيل الدخول، أرسل الرمز نفسه مرة أخرى. المتوقع: يُرفض، وتبقى جلسة واحدة فقط.
• ⁦S1 × E2⁩: أدخل رمزاً بعد انتهاء صلاحيته (T5). المتوقع: يُرفض، ويبقى المستخدم غير مسجَّل الدخول.
• ⁦S4 × E1⁩: اطلب رمزاً جديداً أثناء القفل. المتوقع: لا تُرسل رسالة SMS، ويبقى الحساب مقفَلاً.
• ⁦S4 × E4⁩: انتظر انتهاء صلاحية الرمز أثناء قفل الحساب. المتوقع: يبقى الحساب مقفَلاً؛ فالانتقال إلى «غير مسجَّل الدخول» يتيح للمستخدم طلب رمز جديد قبل انقضاء الدقائق الـ⁦30⁩ بوقت طويل.

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.