الاختبار التوافيقي
الاختبار التوافيقي (Combinatorial Testing) تقنية لتصميم الاختبار من نوع الصندوق الأسود، تُصمَّم فيها حالات الاختبار لتنفيذ توليفات مختارة من قيم عدة معاملات. فبدلاً من تشغيل كل التوليفات، تختار قوة (Strength) يُرمز لها بالحرف t: لأي t من المعاملات، تظهر كل توليفة من قيمها في اختبار واحد على الأقل. فصفحة دفع لها خمسة معاملات، لكل منها أربع قيم، فيها 1,024 توليفة؛ ويكفي 16 اختباراً لتغطية كل زوج من القيم.
الاختبار الزوجي (Pairwise) هو اختبار توافيقي بقوة 2. ويضيف هذا الدرس اختيار القوة، والقيود (Constraints) بين المعاملات، وطريقة شجرة التصنيف، ومتى لا تكفي الأزواج.
لماذا يهم
تظهر إخفاقات كثيرة فقط عندما تلتقي قيم بعينها: فالتوصيل السريع وقسيمة الخصم بمبلغ ثابت وحساب الأعمال يعمل كلٌّ منها منفرداً، ويعمل أيُّ اثنين منها معاً، ومع ذلك يُحتسب رسم خاطئ على عميل الأعمال الذي يختار التوصيل السريع مع قسيمة بمبلغ ثابت. والقائمة المنتقاة يدوياً من التوليفات تترك ثغرات لا يراها أحد، أما المجموعة التوافيقية فلها هدف معلن يمكن التحقق منه، مثل «كل ثلاثية مسموحة من خيار التوصيل ونوع العميل والقسيمة»، فيصبح ما يُستبعد قراراً لا مصادفة.
وبالنسبة إلى المختبِر، تحوّل هذه التقنية عدد الاختبارات إلى حجة: ما تضمنه المجموعة، وما لا تضمنه، وكم ستكلّف قوة أعلى.
القوة: كم معاملاً يجب أن يلتقي
القوة 1 هي تغطية كل اختيار (Each Choice Coverage) التي عرفتها في تقسيم التكافؤ: تظهر كل قيمة مرة واحدة على الأقل. والقوة 2 (الاختبار الزوجي) تضع كل زوج من قيم أي معاملين معاً في اختبار ما، والقوة 3 كل ثلاثية، وحين تساوي t عدد المعاملات تعود إلى كل التوليفات. يسمّي مسرد ISTQB هذا n-wise testing، بينما تقول NIST وكثير من الأدوات t-way. وتُسمّى مجموعة الاختبارات التي تبلغ قوة معينة مصفوفة تغطية (Covering Array).
لا يقل الحد الأدنى عن حاصل ضرب أكبر t من أعداد القيم: فمعاملان لكل منهما أربع قيم يكوّنان 16 زوجاً، ولا يحمل الاختبار الواحد إلا زوجاً واحداً منها، لذا يحتاج الاختبار الزوجي إلى 16 اختباراً على الأقل. وفي صفحة الدفع توجد مجموعات من 16 و64 و256 اختباراً بالضبط. وكل درجة أعلى تضرب الحد الأدنى في عدد القيم تقريباً، لذلك تُختار القوة حسب المخاطر ولا تُرفع إلى أقصاها تلقائياً.
هذه هي الأحجام الدنيا، وتوجد لهذا النموذج مجموعات بهذه الأحجام بالضبط. وتغيّر القيود والأعداد غير المتساوية من القيم هذه الأرقام، وقد يعيد المولّد صفوفاً أكثر من الحد الأدنى.
النسخة النصية
Checkout: 5 parameters x 4 values each
Strength Every test set must contain Minimum
1-way (each choice) every value at least once 4
2-way (pairwise) every pair of values, any 2 parameters 16
3-way every triple of values, any 3 parameters 64
4-way every combination of any 4 parameters 256
5-way (all combinations) 4 x 4 x 4 x 4 x 4 1,024القيود بين المعاملات
بعض التوليفات مستحيلة: فالمتجر يقدّم Apple Pay على الويب وفي تطبيق iOS فقط. وإذا لم يعرف المولّد ذلك ظهرت صفوف لا يمكن تنفيذها، وحذفُها لاحقاً يحذف معها الأزواج الأخرى التي كانت تحملها. لذلك عرّف القيود قبل التوليد، لتُغطّى كل توليفة مسموحة ولا تظهر أي توليفة محظورة. والصيغة المستخدمة أدناه عامة، ولكل أداة صيغتها الخاصة. فأداة «مولّد الاختبار الزوجي» (Pairwise Testing Generator) تقبل التوليفة المحظورة بالشكل Payment = Apple Pay AND Device = Android app، وتقبل الاستلزام أدناه كما هو مكتوب.
- توليفة محظورة:
NOT (Payment = Apple Pay AND Device = Android app). - استلزام (Implication):
IF Customer = guest THEN Payment <> bank transfer(التحويل البنكي يتطلب حساباً، لذا لا تعرضه الصفحة على الضيوف). - معامل مشروط: نوع البطاقة لا يهم إلا في الدفع بالبطاقة؛ أعطه قيمة «لا ينطبق» أو نمذجه تفريعاً في شجرة التصنيف.
- ليس قيداً: توليفة يصل إليها المستخدم لكن يجب أن يرفضها النظام. أبقِها اختباراً بنتيجته المتوقعة؛ أما القيم غير الصالحة فلها، كما في الاختبار الزوجي، اختبارات سلبية خاصة بها.
طريقة شجرة التصنيف
طريقة شجرة التصنيف (Classification Tree Method)، التي وصفها Grochtmann وGrimm عام 1993، ترسم النموذج ليراجعه الفريق. الجذر هو موضوع الاختبار (Test Object)، وتحته التصنيفات (Classifications)، أي الجوانب التي قد تغيّر النتيجة، ويُقسَم كل تصنيف إلى فئات (Classes) هي أقسام تكافؤ. ويمكن تفريع الفئة بتصنيف آخر، مثل نوع البطاقة تحت «بطاقة».
وتحت الشجرة جدول التوليفات (Combination Table): كل صف فيه حالة اختبار تُعلَّم فيها فئة واحدة من كل تصنيف ينطبق. ويحدد معيار التغطية عدد الصفوف: كل فئة مرة، أو كل زوج، أو قوة أعلى، أو كل التوليفات.
Checkout (test object)
|-- Payment
| |-- card --> Card scheme: Visa | Mastercard | mada
| |-- Apple Pay
| |-- bank transfer
| `-- cash on delivery
|-- Delivery: standard | express | same-day | store pickup
|-- Customer: guest | new account | returning | business
|-- Device: desktop web | mobile web | Android app | iOS app
`-- Coupon: none | percentage | fixed amount | free shipping
Combination table (one row = one test case, one class per classification)
TC Payment Scheme Delivery Customer Device Coupon
1 card mada express business iOS app fixed amount
2 Apple Pay - store pickup guest desktop web free shipping
3 bank transfer - same-day returning Android app noneمتى تتجاوز الأزواج
الاختبار الزوجي خيار افتراضي معقول: فأبحاث NIST تذكر أن معظم الإخفاقات في البرمجيات التي درستها نتجت عن معامل واحد أو عن تفاعل معاملين، وأن ما نتج عن ثلاثة معاملات أو أكثر يتناقص تدريجياً. لكن هذا اتجاه لا ضمان.
ونادراً ما يعني تجاوزُ الأزواج رفعَ t للنموذج كله. استخدم القوة المختلطة (Mixed Strength): أبقِ تغطية 2-way لكل المعاملات، وارفع t للمجموعة المتفاعلة منها فقط، كما يفعل المثال التطبيقي أدناه مع رسم التوصيل. وإذا كان المنطق مكتوباً قواعد صريحة، فقد يختبره جدول القرار أفضل. فكّر في القوة 3 أو أعلى لمجموعة من المعاملات عندما:
- تجمع قاعدة واحدة ثلاثة معاملات أو أكثر: الرسوم والأسعار والأهلية والصلاحيات.
- يكون الإخفاق مكلفاً: مال أو صحة أو التزامات قانونية أو فقدان بيانات.
- تضمّن عيب سابق ثلاثة معاملات معاً.
- تكون الاختبارات مؤتمتة ورخيصة، فلا يكلّف 64 صفاً أكثر من 16 بكثير.
مثال تطبيقي: تخطيط مجموعة اختبارات لصفحة الدفع
لصفحة الدفع خمسة معاملات لكل منها أربع فئات من تقسيم التكافؤ، واستُبعد نوع البطاقة لأن مزوّد الدفع يعامل جميع الأنواع بالطريقة نفسها، كما أكّد أحد المطورين. وينص متطلب على أن رسم التوصيل يعتمد على خيار التوصيل ونوع العميل والقسيمة معاً. وأكّد مالك المنتج ثلاثة قيود: لا يُعرض Apple Pay في تطبيق Android، ولا يُتاح الدفع عند الاستلام لطلبات الاستلام من المتجر، ولا يُعرض التحويل البنكي على الضيوف.
تشغّل الخطة الاختبار الزوجي عبر واجهة المستخدم حيث الاختبارات بطيئة، وتشغّل ثلاثيات الرسم الـ64 كلها اختبارات معتمدة على البيانات على الواجهة البرمجية (API) حيث هي رخيصة. ولولا القيود لكفى 16 اختباراً لتغطية كل زوج، أما معها فلا يمكن بلوغ 16. فكل وسيلة دفع وكل جهاز يجب أن يلتقي بأنواع القسائم الأربعة، لذا يجب أن يظهر كلٌّ منها، في مجموعة من 16 صفاً، أربع مرات بالضبط. وعندها لا تستطيع صفوف Apple Pay الأربعة أن تستخدم سوى ثلاثة أجهزة، ولا صفوف تطبيق Android الأربعة سوى ثلاث وسائل دفع، فيتكرر زوجان من أزواج الدفع والجهاز، وتحتاج الأزواج المسموحة الـ15 إلى 17 صفاً على الأقل. ويعيد «مولّد الاختبار الزوجي» 22 صفاً لهذا النموذج. والاستلام من المتجر مع قسيمة توصيل مجاني ممكن، فهو ليس قيداً بل إحدى تلك الثلاثيات، بالنتيجة المتوقعة التي حددها مالك المنتج. والمجموع نحو 8% من 1,024 توليفة، ولكل جزء ضمان معلن.
Parameters (4 values each)
Payment card | Apple Pay | bank transfer | cash on delivery
Delivery standard | express | same-day | store pickup
Customer guest | new account | returning | business
Device desktop web | mobile web | Android app | iOS app
Coupon none | percentage | fixed amount | free shipping
Constraints
NOT (Payment = Apple Pay AND Device = Android app)
NOT (Payment = cash on delivery AND Delivery = store pickup)
IF Customer = guest THEN Payment <> bank transfer
Plan
UI 2-way, all 5 parameters at least 17 tests (generator: 22)
API 3-way, Delivery x Customer x Coupon 64 tests, every fee triple
Not planned: all combinations 1,024 (832 allowed)أخطاء شائعة
- رفع القوة لكل المعاملات «للاحتياط»، مما يضاعف عدد الاختبارات؛ ارفعها فقط حيث تتفاعل المعاملات.
- تعريف توليفة على أنها قيد لأن النظام يجب أن يرفضها، فلا تُختبر معالجة الخطأ فيها أبداً.
- كتابة قيد أوسع من القاعدة، مثل استبعاد Apple Pay في كل مكان بدلاً من تطبيق Android وحده، فتختفي توليفات صالحة من الاختبار دون أن يلاحظ أحد.
- رسم شجرة تصنيف تتداخل فئاتها أو تترك فجوات، فيقع المُدخل الواحد في فئتين أو في لا فئة.
- اختيار القوة مرة واحدة وعدم مراجعتها حين تكشف قواعد جديدة أو حوادث أن معاملات أكثر تتفاعل.
- معاملة تغطية t-way كأنها دليل: فهي تبيّن التوليفات التي نُفّذت، لا أن كل نتيجة فُحصت ولا أن النموذج مكتمل.
من منظور ضمان الجودة
ابنِ النموذج أثناء تحليل الاختبار وتصميمه مع مالك المنتج، الذي يؤكد أي التوليفات مستحيلة وأيها يجب أن يعرض خطأ، ومع أحد المطورين، الذي يعرف أي المعاملات تجمعها الشيفرة فعلاً. فدالة تحسب رسماً من ثلاثة مدخلات إشارة قوية إلى تغطية ثلاثية.
سجّل قوة كل مجموعة من المعاملات وسبب اختيارها بجانب النموذج، ليرى المراجعون لماذا يوجد 22 أو 86 اختباراً. وراجعها بعد الحوادث: إذا احتاج إخفاق في بيئة الإنتاج إلى ثلاث قيم معاً، فانقل تلك المعاملات إلى مجموعة ثلاثية ودوّن السبب.
تمرين عملي
خطّط مجموعة اختبارات توافيقية لاستمارة حجز فندقي
لاستمارة حجز فندقي المعاملات الستة والقواعد الثلاث المذكورة أدناه. ابنِ نموذجاً للاستمارة، وصنّف القواعد إلى قيود واختبارات، وخطّط القوة لكل جزء. ثم تحقق من الجزء الزوجي بأداة «مولّد الاختبار الزوجي» (Pairwise Testing Generator).
استمارة حجز فندقي (الويب والتطبيق)
Room standard | deluxe | suite
Guests 1 | 2 | 3
Board room only | breakfast | half board
Payment pay now by card | pay at hotel
Member loyalty member | not a member
Channel web | app
القاعدة A: الغرفة القياسية (standard) تتسع لضيفين على الأكثر، ولا يعرض
محدِّد عدد الضيوف القيمة 3 عند اختيار غرفة قياسية.
القاعدة B: الدفع في الفندق (pay at hotel) لأعضاء برنامج الولاء فقط. وإذا اختاره
غير العضو، تعرض الصفحة «سجّل الدخول للدفع في الفندق».
القاعدة C: يُحسب السعر من الغرفة وعدد الضيوف ونوع الإقامة (board) معاً.- ارسم شجرة تصنيف فيها تصنيف واحد لكل معامل.
- قرّر هل القاعدتان A وB قيدان أم اختباران.
- احسب كل التوليفات، والمسموح منها، والحد الأدنى لحجم مجموعتي 1-way و2-way.
- استخدم القاعدة C لتحديد موضع الحاجة إلى 3-way والحد الأدنى لعدد اختباراتها.
- ولّد مجموعة زوجية بعد تعريف القاعدة A، ثم افحص حجمها وتغطيتها للأزواج وكل صف فيها مقابل القاعدة A.
إظهار الإجابة النموذجية
الشجرة: الجذر استمارة الحجز، وتحته تصنيف واحد لكل معامل، وقيمه المدرجة هي فئاته.
القاعدة A قيد، لأن الاستمارة تجعل التوليفة مستحيلة: NOT (Room = standard AND Guests = 3). أما القاعدة B فليست قيداً: يستطيع غير العضو اختيار الدفع في الفندق، فتبقى اختباراً نتيجته المتوقعة رسالة تسجيل الدخول.
كل التوليفات: 3 × 3 × 3 × 2 × 2 × 2 = 216؛ وتزيل القاعدة A منها 1 × 1 × 3 × 2 × 2 × 2 = 24 توليفة، فيبقى 192. وتحتاج مجموعة 1-way إلى 3 اختبارات على الأقل، ومجموعة 2-way إلى 9 على الأقل، لأن للمعاملين Room وBoard وحدهما تسعة أزواج. ومع القاعدة A لا يمكن بلوغ 9: فالصفوف التسعة يجب أن تضم كل زوج من Room وBoard وكل زوج من Guests وBoard مرة واحدة بالضبط، فيظهر كل نوع غرفة وكل عدد ضيوف ثلاث مرات بالضبط. لكن صفوف الغرفة القياسية الثلاثة لا تقبل إلا ضيفاً أو ضيفين، والصفوف الثلاثة التي فيها 3 ضيوف لا تقبل إلا deluxe أو suite، فيتكرر زوجان من أزواج Room وGuests، وتحتاج أزواجهما المسموحة الثمانية عندئذٍ إلى 10 صفوف. وتوجد مجموعة من 10 صفوف، لذا فالحد الأدنى مع القيد هو 10.
تجمع القاعدة C بين Room وGuests وBoard: 27 ثلاثية ناقص الثلاث التي تحظرها القاعدة A تبقى 24، فتحتاج إلى 24 اختباراً على الأقل، مع توزيع بقية المعاملات بحيث تبقى أزواجها مغطاة. وهذه قوة مختلطة: 3-way لهذه المعاملات الثلاثة، و2-way لبقيتها.
أدخل كل معامل في سطر مستقل، مثل Room: standard, deluxe, suite، وعرّف القاعدة A بالشكل Room = standard AND Guests = 3، فتعاملها الأداة توليفةً محظورة. ويجب أن تعرض الأداة 92 زوجاً من القيم (93 ناقص الزوج المحظور)، كلها مغطاة. وقد يعيد المولّد 11 صفاً بدلاً من الحد الأدنى 10، وأي مجموعة تغطي كل زوج مسموح صحيحة. وإذا جمع صف بين غرفة standard و3 ضيوف، فالقيد لم يُطبَّق: أعد التوليد بعد تعريفه بدلاً من حذف الصف.
أسئلة شائعة
هل الاختبار التوافيقي هو نفسه الاختبار الزوجي؟
الاختبار الزوجي اختبار توافيقي بقوة 2. أما الاختبار التوافيقي فهو التقنية العامة: أي قوة، وقوى مختلطة لمجموعات مختلفة من المعاملات، وقيود تزيل التوليفات المستحيلة.
أي قوة أختار؟
ابدأ بتغطية 2-way لكل المعاملات. وارفعها إلى 3-way للمعاملات التي تجمعها قاعدة واحدة أو حيث يكون الإخفاق مكلفاً، ولا تفكّر في 4-way أو أكثر إلا لأجزاء صغيرة حرجة اختباراتها مؤتمتة. فالقوة قرار مبني على المخاطر، لذا سجّل سبب اختيارك.
هل أحتاج إلى أداة لبناء مجموعة الاختبارات؟
نعم إذا زادت المعاملات على عدد قليل، فبناء مصفوفات التغطية يدوياً بطيء وسهل الخطأ. لكن النموذج يبقى عملك أنت. وافحص المخرجات: عدد الصفوف، وخلوّها من أي توليفة محظورة، واكتمال التغطية بالقوة المختارة حين تعرض الأداة ذلك.
هل تحلّ شجرة التصنيف محل تقسيم التكافؤ؟
لا، بل تُبنى عليه. ففئات الشجرة أقسام تكافؤ، ويمكن أن تكون القيم الحدّية فئات أيضاً. تنظّم الشجرة أقسام عدة جوانب في صورة واحدة، ويختار جدول التوليفات أيّها يُختبر معاً.
المراجع
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsالمعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
تدرّب بأدوات متقن
ولّد أصغر مجموعة اختبارات زوجية (all-pairs) من المعاملات وقيمها.
اشتق فئات التكافؤ الصالحة وغير الصالحة لكل مدخل واختر قيم اختبار تمثيلية.
أنشئ جداول القرار من الشروط والإجراءات، وولّد جميع تركيبات القواعد، واختزل المستحيل منها.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.