يمكنك تحديد ما يجب اختباره وتحديد حالات الاختبار وتحديد الأولويات.
لقد تعرفت في المشاركة السابقة على استراتيجيات الاختبار، وعدد الاختبارات اللازمة لاختبار التطبيق، وكيفية العثور على أفضل نتيجة لاكتساب أكبر قدر من الثقة في النتائج مع الأخذ في الاعتبار مواردك. ومع ذلك، فإن هذا يعطينا فكرة عن مقدار الاختبار. لا تزال بحاجة إلى تحديد ما يجب اختباره بالضبط. يمكن أن تكون المعايير الثلاثة التالية مفيدة في فهم ما يمكن توقعه في الاختبار ومعرفة نوع الاختبار ومستوى التفاصيل المناسبَين بشكل أفضل:
- اعتنِ بالمسار الصحيح. هذه هي قصة المستخدم الأكثر عمومية أو الأساسية في تطبيقك، حيث سيلاحظ المستخدم خطأً بسرعة كبيرة.
- حدِّد مستوى التفاصيل بعناية. يمكنك تناول مزيد من التفاصيل إذا كانت حالة الاستخدام عُرضة للاختراق أو إذا كان أحد الأخطاء يمكن أن يؤدي إلى ضرر كبير.
- إعطاء الأولوية للاختبارات ذات المستوى الأدنى، مثل اختبارات الوحدة والتكامل، بدلاً من الاختبارات الشاملة ذات المستوى الأعلى كلما أمكن ذلك.
تستكشف بقية هذه المقالة هذه المعايير وكيفية تطبيقها عند تحديد حالات الاختبار.
ما هي الحالة الاختبارية؟
في مجال تطوير البرامج، حالة الاختبار هي سلسلة من الإجراءات أو الظروف التي تم وضعها للتأكد من فعالية برنامج أو تطبيق. تهدف حالة الاختبار إلى التأكد من أن البرنامج يعمل كما هو مخطط له وأن جميع ميزاته ووظائفه تعمل بشكل صحيح. ينشئ مختبِرو البرامج أو مطورو البرامج عادةً حالات الاختبار هذه لضمان تلبية البرنامج للمتطلبات والمواصفات المحددة.
عند تشغيل حالة اختبار، يُجري البرنامج سلسلة من عمليات الفحص للتأكد من تحقيق النتائج المرجوة. أثناء القيام بذلك، يفي الاختبار بالمهام التالية:
- التحقق من بيانات الشحن: يشير ذلك المصطلح إلى عملية الفحص الدقيق للبرامج للتأكّد من أنّها تعمل بدون أخطاء. من الأهمية بمكان تحديد ما إذا كان المنتج الذي تم إنشاؤه يلبي جميع المتطلبات غير الوظيفية اللازمة ويحقق الغرض المقصود بنجاح. السؤال الذي يجيب عليه هو: "هل نبني المنتج بشكل صحيح؟"
- التحقّق من الصحة: عملية التأكد من أن المنتج البرمجي يفي بالمعايير اللازمة أو المتطلبات عالية المستوى. يتضمن التحقق مما إذا كان المنتج الفعلي يتماشى مع المنتج المتوقع. بشكل أساسي، نحن نجيب على السؤال: "هل نبني المنتج المناسب لمتطلبات المستخدم؟"
افترض أن البرنامج فشل في تقديم النتيجة المتوقعة. في هذه الحالة، ستكون حالة الاختبار هي الرسالة، وبالتالي تكون النتيجة غير ناجحة وسيحتاج المطوّر أو المُختبِر إلى التحقيق في المشكلة وإيجاد حلّ لها. فكر في عمليات التحقق والإجراءات على أنها مسارات يتبعها الكمبيوتر، بغض النظر عن نوع الاختبار. تسمى مجموعات بيانات الإدخال أو الشروط المستخدمة للتحقق "فئات التكافؤ". ومن المفترض أن يحصلوا على سلوك مشابه أو نتائج مماثلة من النظام الذي يخضع للاختبار. قد تختلف المسارات المحدّدة التي يتم تنفيذها داخل الاختبار ولكن يجب أن تتطابق مع الأنشطة وتأكيدات البيانات التي تم تنفيذها في هذا الاختبار.
مسارات الاختبار: الأنواع النموذجية من حالات الاختبار
في مجال تطوير البرامج، تكون حالة الاختبار عبارة عن سيناريو لتنفيذ الرمز يتم توقع منه سلوك معيّن واختباره. عادةً، هناك ثلاثة سيناريوهات لتكوين حالات الاختبار منها.
الملف الأول هو الأكثر شهرة، والذي ربما تستخدمه بالفعل. وهو المسار الصحيح، الذي يُعرف أيضًا باسم "سيناريو اليوم سعيد" أو "المسار الذهبي". ويحدّد هذا الأسلوب حالة الاستخدام الأكثر شيوعًا للميزة أو التطبيق أو التغيير، أي الطريقة التي يجب أن تنجح بها هذه العملية لدى العميل.
غالبًا ما يتم استبعاد مسار الاختبار الثاني الأكثر أهمية الذي يجب تناوله في حالات الاختبار لأنه غير مريح - حيث قد يوحي اسمه. إنّه "المسار المخيف" أو الاختبار السلبي يستهدف هذا المسار السيناريوهات التي تتسبّب في عمل الرمز البرمجي على نحو غير صحيح أو تؤدي إلى إدخال حالة خطأ. يعد اختبار هذه السيناريوهات أمرًا مهمًا بشكل خاص إذا كان لديك حالات استخدام ضعيفة للغاية تفرض مخاطر عالية على الأطراف المعنية أو المستخدمين.
هناك بعض المسارات الأخرى التي قد ترغب في معرفتها والنظر في استخدامها، ولكنها عادة ما تكون أقل استخدامًا. يلخص الجدول التالي هذه الخطوات:
| مسار الاختبار | الشرح |
|---|---|
| مسار غاضب | يؤدي ذلك إلى حدوث خطأ، ولكنه متوقَّع، مثلاً إذا كنت تريد التأكّد من أنّ طريقة التعامل مع الأخطاء تعمل بشكل صحيح. |
| مسار متأخر | يتعامل هذا المسار مع أي سيناريوهات متعلقة بالأمان يحتاج تطبيقك إلى تلبيتها. |
| مسار مقفر | لا يحصل مسار اختبار السيناريو في تطبيقك على بيانات كافية للعمل، على سبيل المثال، اختبار القيم الفارغة. |
| مسار منسي | اختبار سلوك التطبيق باستخدام موارد غير كافية، مثل فقدان البيانات |
| مسار غير حاسم | الاختبار مع مستخدم يحاول تنفيذ إجراءات أو متابعة قصص المستخدمين في تطبيقك ولكنه لم يكمل عمليات سير العمل هذه. قد يكون هذا هو الحال، على سبيل المثال، عندما يقاطع المستخدم سير عمله. |
| طريق طمع | محاولة إجراء الاختبارات باستخدام كميات هائلة من المدخلات أو البيانات |
| مسار مرهق | محاولة تحميل تطبيقك بأي وسيلة ضرورية إلى أن يتوقف عن العمل (على غرار اختبار التحميل) |
تتوفّر عدة طرق لتصنيف هذه المسارات. هناك نهجان شائعان هما:
- تقسيم المكافئ: يشير ذلك المصطلح إلى طريقة اختبار تصنّف حالات الاختبار إلى مجموعات أو أقسام، ما يساعد في إنشاء فئات تساوي. ويستند هذا إلى فكرة أنه إذا كشفت حالة اختبار واحدة في أحد الأقسام عن وجود عيب، فمن المحتمل أن تكشف حالات الاختبار الأخرى في القسم نفسه عن عيوب مماثلة. نظرًا لأن جميع المدخلات ضمن فئة تكافؤ معيّنة يجب أن تُظهر سلوكًا متطابقًا، يمكنك تقليل عدد حالات الاختبار. مزيد من المعلومات عن تقسيم التكافؤ
- تحليل الحدّ: يشير ذلك المصطلح إلى طريقة اختبار تُعرف أيضًا باسم تحليل قيمة الحدود تفحص الحدود أو القيَم القصوى للقيم المُدخلة للعثور على أي مشاكل أو أخطاء محتمَلة قد تظهر عند حدود قدرات النظام أو قيوده.
أفضل الممارسات: كتابة حالات الاختبار
وستحتوي حالة الاختبار الكلاسيكية التي يكتبها المُختبِر على بيانات محدّدة لمساعدتك في استيعاب محتوى الاختبار الذي تريد إجراؤه، وبالطبع تنفيذ الاختبار. يقوم المختبر النموذجي بتوثيق جهود الاختبار الخاصة به في جدول. هناك نمطان يمكننا استخدامهما في هذه المرحلة، حيث يساعدنا في تنظيم حالات الاختبار وفي وقت لاحق، الاختبارات نفسها أيضًا:
- النمط الترتيب والتنفيذ والتأكيد. نمط الاختبار "الترتيب والتنفيذ والتأكيد" (المعروف أيضًا باسم "AAA" أو "Triple A") هو طريقة لتنظيم الاختبارات في ثلاث خطوات مميزة: ترتيب الاختبار، ثم إجراء الاختبار، وأخيرًا وليس آخرًا استخلاص النتائج.
- النمط ما يتم تقديمه ومتى ثم. يشبه هذا النمط نمط AAA، ولكنه له بعض الجذور في التطوير المستند إلى السلوك.
وسوف تتناول المقالات المستقبلية مزيدًا من التفاصيل حول هذه الأنماط بمجرد أن نغطي بنية الاختبار نفسه. إذا أردت التعمّق أكثر في هذه الأنماط في هذه المرحلة، اطّلِع على هاتين المقالتين: الترتيب - التنفيذ - النمط - نمط لكتابة اختبارات جيدة - والوقت المناسب لذلك.
وفقًا لجميع الدروس المستفادة من هذه المقالة، يلخص الجدول التالي مثالاً كلاسيكيًا:
| المعلومات | الشرح |
|---|---|
| المتطلبات الأساسية | كل ما يجب القيام به قبل كتابة الاختبار. |
| عنصر قيد الاختبار | ما الذي يجب إثبات صحته؟ |
| البيانات المدخلة | المتغيرات وقيمها. |
| الخطوات التي سيتم تنفيذها | جميع الأشياء التي ستفعلها لجعل الاختبار حقيقة: جميع الإجراءات أو التفاعلات التي تجريها في الاختبارات. |
| النتيجة المتوقعة | ما ينبغي أن يحدث والتوقعات التي يجب تلبيتها. |
| النتيجة الفعلية | ما يحدث بالفعل. |
في الاختبار الآلي، لا تحتاج إلى توثيق جميع حالات الاختبار هذه بالطريقة التي يحتاجها المختبِر، على الرغم من أن ذلك مفيد بلا شك. يمكنك العثور على جميع هذه المعلومات في الاختبار إذا كنت مهتمًا بذلك. لذلك دعنا نترجم حالة الاختبار الكلاسيكي هذه إلى اختبار آلي.
| المعلومات | الترجمة إلى اختبار آلي |
|---|---|
| المتطلبات الأساسية | كل الأشياء التي تحتاجها، وترتيب الاختبار، والتفكير في ما يتم تقديمه لتحقيق سيناريو الاختبار. |
| عنصر قيد الاختبار | يمكن أن يكون هذا "الكائن" أشياء مختلفة: تطبيق أو تدفق أو وحدة أو مكون قيد الاختبار. |
| البيانات المدخلة | قيم المَعلمات |
| الخطوات التي سيتم تنفيذها | يشير هذا المصطلح إلى جميع الإجراءات والأوامر التي يتم تنفيذها داخل الاختبار والأشياء التي يتم اتخاذ إجراءات بشأنها، بالإضافة إلى معرفة ما يحدث عند تنفيذ إجراءات معيّنة. |
| النتيجة المتوقعة | التأكيد الذي تستخدمه للتحقق من صحة التطبيق، والأمور التي تؤكّد عليها في التطبيق. |
| النتيجة الفعلية | نتيجة الاختبار المبرمَج. |