حدِّد ما يجب اختباره وحدِّد حالات الاختبار وأعطِ الأولوية.
في المشاركة السابقة، تعرّفت على استراتيجيات الاختبار وعدد الاختبارات اللازمة لاختبار التطبيق وكيفية العثور على الاختبار الأنسب للحصول على أكبر قدر من الثقة في النتائج مع مراعاة الموارد المتاحة لك. ومع ذلك، لا يمنحنا هذا سوى فكرة عن عدد الاختبارات التي يجب إجراؤها. لا تزال بحاجة إلى تحديد ما يجب اختباره بالضبط. يمكن أن تكون المعايير الثلاثة التالية مفيدة في فهم ما يمكن توقّعه في الاختبار ومعرفة نوع الاختبار ومستوى التفاصيل الأنسب:
- احرص على الحفاظ على مسار التحسين الناجح. هذه هي قصة المستخدم الأكثر عمومية أو أساسية لتطبيقك، حيث سيلاحظ المستخدم خطأً بسرعة كبيرة.
- حدِّد بعناية مستوى التفاصيل. أدخِل المزيد من التفاصيل إذا كانت حالة الاستخدام معرّضة للخطر أو إذا كان الخطأ سيؤدي إلى حدوث أضرار جسيمة.
- امنح الأولوية للاختبارات من المستوى الأدنى، مثل اختبارات الوحدة والدمج، على الاختبارات الشاملة من المستوى الأعلى كلما أمكن ذلك.
وتتناول بقية هذه المقالة هذه المعايير وكيفية تطبيقها عند تحديد حالات الاختبار.
ما هو نموذج الاختبار؟
في مجال تطوير البرامج، يكون نموذج الاختبار عبارة عن تسلسل من الإجراءات أو الظروف التي تم وضعها لتأكيد فعالية برنامج أو تطبيق معيّن. تهدف حالة الاختبار إلى التأكّد من أنّ البرنامج يعمل على النحو المخطّط وأنّ جميع ميزاته ووظائفه تعمل بشكل صحيح. عادةً ما ينشئ مختبِرو البرامج أو مطوّروها حالات الاختبار هذه لضمان استيفاء البرنامج للمتطلبات والمواصفات المحدّدة.
عند تنفيذ حالة اختبار، يُجري البرنامج سلسلة من عمليات التحقّق للتأكّد من أنّه يحقّق النتائج المطلوبة. وأثناء إجراء ذلك، ينفِّذ الاختبار المهام التالية:
- التحقّق: عملية التحقّق من البرامج بدقة للتأكّد من أنّها تعمل بدون أخطاء من المهم تحديد ما إذا كان المنتج الذي تم إنشاؤه يستوفي جميع المتطلبات غير الوظيفية اللازمة ويحقّق الغرض المقصود منه بنجاح. ويجيب عن السؤال التالي: "هل نبني المنتج بشكل صحيح؟"
- التحقّق: عملية التأكّد من أنّ منتج البرنامج يستوفي المعايير اللازمة أو المتطلبات العالية المستوى ويشمل ذلك التحقّق مما إذا كان المنتج الفعلي متوافقًا مع المنتج المتوقّع. في الأساس، نجيب عن السؤال التالي: "هل نبني المنتج المناسب لمتطلبات المستخدم؟"
لنفترض أنّ البرنامج فشل في تحقيق النتيجة المتوقّعة. في هذه الحالة، ستكون حالة الاختبار هي المرسِل، ما يؤدي إلى الإبلاغ عن نتيجة غير ناجحة، وسيحتاج المطوّر أو المختبِر إلى التحقيق في المشكلة واقتراح حلّ لها. يمكنك اعتبار عمليات التحقّق والإجراءات مسارات يتّبعها الكمبيوتر بغض النظر عن نوع الاختبار. تُعرف مجموعات بيانات الإدخال أو الشروط المستخدَمة للتحقّق باسم "فئات التكافؤ". من المفترض أن يحصلوا على سلوك أو نتائج مشابهة من النظام الذي يخضع للاختبار. قد تختلف المسارات المحدّدة التي يتم تنفيذها داخل الاختبار، ولكن يجب أن تتطابق مع الأنشطة والافتراضات التي تم إجراؤها في الاختبار.
مسارات الاختبار: الأنواع النموذجية لحالات الاختبار
في تطوير البرامج، حالة الاختبار هي سيناريو تنفيذ رمز برمجي يُتوقّع منه سلوك معيّن ويتم اختباره. عادةً ما تكون هناك ثلاثة سيناريوهات لإنشاء حالات الاختبار.
الطريقة الأولى هي الأكثر شهرة، والتي يُرجّح أنّك تستخدمها حاليًا. يُعرف هذا المسار باسم المسار الناجح، ويُعرف أيضًا باسم "سيناريو اليوم السعيد" أو "المسار الذهبي". ويحدّد سيناريو الاستخدام الأكثر شيوعًا للميزة أو التطبيق أو التغيير، أي الطريقة التي من المفترض أن يعمل بها المسار على نحو جيد للعملاء.
غالبًا ما يتم تجاهل مسار الاختبار الثاني الأكثر أهمية لتغطيته في حالات الاختبار، لأنّه غير مريح، كما قد يشير اسمه. يُعرف هذا المسار باسم "المسار المخيف" أو الاختبار السلبي. يستهدف هذا المسار السيناريوهات التي تؤدي إلى سلوك غير صحيح للرمز أو دخوله في حالة خطأ. من المهم جدًا اختبار هذه السيناريوهات إذا كانت لديك حالات استخدام معرّضة للخطر بشكل كبير وتفرض مخاطر عالية على الجهات المعنية أو المستخدمين.
هناك بعض المسارات الأخرى التي قد تريد التعرّف عليها والتفكير في استخدامها، ولكنّها عادةً ما تكون أقل شيوعًا. يلخِّص الجدول التالي هذه التحسينات:
| مسار الاختبار | الشرح |
|---|---|
| مسار غاضب | يؤدي ذلك إلى حدوث خطأ، ولكنّه خطأ متوقّع، على سبيل المثال، إذا كنت تريد التأكّد من أنّ معالجة الأخطاء تعمل بشكل صحيح. |
| مسار متأخر | يهتم هذا المسار بأي سيناريوهات متعلّقة بالأمان يحتاج تطبيقك إلى تنفيذها. |
| مسار مهجور | لا يحصل المسار الذي يختبر السيناريو في تطبيقك على بيانات كافية للعمل، على سبيل المثال، اختبار القيم الخالية. |
| مسار النسيان | اختبار سلوك تطبيقك باستخدام موارد غير كافية، على سبيل المثال، بدء فقدان البيانات |
| مسار غير محدّد | الاختبار مع مستخدم يحاول تنفيذ إجراءات أو اتّباع قصص مستخدمين في تطبيقك ولكنّه لم يكمل هذه سير العمل وقد يحدث ذلك، على سبيل المثال، عندما يقاطع المستخدم سير العمل. |
| المسار الجشع | محاولة إجراء الاختبار باستخدام كميّات كبيرة من المدخلات أو البيانات |
| مسار مرهق | محاولة تحميل تطبيقك بأي وسيلة ضرورية إلى أن يتوقّف عن العمل (على غرار اختبار التحميل) |
هناك عدة طرق لتصنيف هذه المسارات. في ما يلي طريقتان شائعتان:
- تقسيم المساواة: طريقة اختبار لفهرسة حالات الاختبار إلى مجموعات أو أقسام، ما يساعد في إنشاء فئات التكافؤ. ويستند ذلك إلى الفكرة القائلة بأنّه إذا كشفت حالة اختبار واحدة في قسم عن عيوب، من المرجّح أن تكشف حالات الاختبار الأخرى في القسم نفسه عن عيوب مشابهة. بما أنّ جميع المدخلات ضمن فئة تكافؤ معيّنة يجب أن تعرِض سلوكًا متطابقًا، يمكنك تقليل عدد حالات الاختبار. مزيد من المعلومات عن تقسيم المساواة
- تحليل الحدّ طريقة اختبار، تُعرف أيضًا باسم تحليل القيم الحدية، تفحص حدود قيم الإدخال أو قيمها القصوى للعثور على أي مشاكل أو أخطاء محتملة قد تحدث عند حدود إمكانات النظام أو قيوده.
أفضل الممارسات: كتابة حالات الاختبار
ستتضمّن حالة الاختبار الكلاسيكية التي يكتبها المختبِر بيانات محدّدة لمساعدتك في فهم محتوى الاختبار الذي تريد إجراؤه، وبالطبع تنفيذ الاختبار. يوثّق المختبِر النموذجي جهوده في الاختبار في جدول. هناك نمطان يمكننا استخدامهما في هذه المرحلة، ما يساعدنا في تنظيم حالات الاختبار، ثم الاختبارات نفسها لاحقًا:
- نمط ترتيب، تصرف، تأكيد يُعدّ نمط الاختبار "ترتيب، وتنفيذ، وتأكيد" (المعروف أيضًا باسم "AAA" أو "الثلاثة أحرف A") طريقة لتنظيم الاختبارات في ثلاث خطوات متميزة: ترتيب الاختبار، ثم تنفيذه، وأخيراً وليس آخرًا، استخلاص النتائج.
- نمط Given, when, then يشبه هذا النمط نمط AAA، ولكنّه يستند إلى التطوير المستنِد إلى السلوك.
ستتضمّن المقالات المستقبلية مزيدًا من التفاصيل حول هذه الأنماط، بعد أن نتناول بنية الاختبار نفسه. إذا كنت تريد التعمّق في هذه الأنماط في هذه المرحلة، اطّلِع على المقالتَين التاليتَين: Arrange-Act-Assert: A pattern for writing good tests (ترتيب-تنفيذ-تأكيد: نمط لكتابة اختبارات جيدة) وGiven-When-Then (معطى-عندما-ثم).
استنادًا إلى كل ما تعلمته من هذه المقالة، يلخِّص الجدول التالي مثالاً كلاسيكيًا:
| معلومات | الشرح |
|---|---|
| المتطلبات الأساسية | كل ما يجب تنفيذه قبل كتابة الاختبار |
| العنصر الذي يتم اختباره | ما الذي يجب إثبات ملكيته؟ |
| إدخال البيانات | المتغيّرات وقِيمها |
| الخطوات التي يجب تنفيذها | جميع الإجراءات التي ستتّخذها لتنفيذ الاختبار: جميع الإجراءات أو التفاعلات التي تُجريها في اختباراتك. |
| النتيجة المتوقّعة | ما الذي من المفترض أن يحدث والتوقعات التي يجب تحقيقها |
| النتيجة الفعلية | ما يحدث في الواقع |
في الاختبار الآلي، لا تحتاج إلى توثيق جميع حالات الاختبار هذه بالطريقة التي يحتاجها المختبِر، على الرغم من أنّه من المفيد بلا شك إجراء ذلك. يمكنك العثور على كل هذه المعلومات في اختبارك إذا انتبهتم إلى ذلك. لنترجم إذًا حالة الاختبار الكلاسيكية هذه إلى اختبار مبرمَج.
| معلومات | الترجمة إلى برمجة اختبارات البرامج |
|---|---|
| المتطلبات الأساسية | كل ما تحتاجه لترتيب الاختبار والتفكير في ما يجب تقديمه لتنفيذ سيناريو الاختبار |
| العنصر الذي يتم اختباره | يمكن أن يكون هذا "العنصر" أشياء مختلفة: تطبيق أو عملية أو وحدة أو مكوّن قيد الاختبار. |
| إدخال البيانات | قيم المَعلمات |
| الخطوات التي يجب تنفيذها | جميع الإجراءات والأوامر التي يتم تنفيذها داخل الاختبار، والإجراءات التي تتّخذها استنادًا إلى النتائج، ومعرفة ما يحدث عند تنفيذ إجراءات معيّنة |
| النتيجة المتوقّعة | العبارة التي تستخدمها للتحقّق من صحة تطبيقك، والعناصر التي تؤكد عليها في تطبيقك |
| النتيجة الفعلية | نتيجة اختبارك المبرمَج. |