الوحدة 4 · عملية الاختبار (STLC)

تهيئة الاختبار

بقلم فريق ضمان الجودة في متقن سوفت · · 18 دقيقة · مبتدئ

تهيئة الاختبار (Test Implementation) هي نشاط الاختبار الذي يجهّز كل ما يلزم لتشغيل الاختبارات. وفي منهج ISTQB للمستوى التأسيسي (الإصدار ⁦4.0⁩) تأتي بعد تصميم الاختبار: تُنشأ مواد الاختبار (Testware) مثل بيانات الاختبار أو يُحصل عليها، وتُنظَّم حالات الاختبار في إجراءات اختبار (Test Procedures) وحزم اختبارات (Test Suites)، وتُكتب سكربتات الاختبار، ويُوضع جدول التنفيذ، وتُبنى بيئة الاختبار ويُتحقق منها.

يحدد التحليل ماذا نختبر، ويحدد التصميم كيف نختبر؛ أما التهيئة فتجيب عن سؤال عملي: هل يمكن أن يبدأ التنفيذ صباح الغد؟ ففي ميزة جديدة لرموز الخصم الترويجية يعني ذلك إجراءات مرتبة، ورموز خصم وحسابات محمَّلة، والبناء الصحيح على بيئة Staging مع اتصال بيئة تجربة الدفع (Sandbox)، وترتيباً متفقاً عليه لتشغيل الحزم.

لماذا يهم

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

وبالنسبة إلى المختبِر، التهيئة هي المرحلة التي يصبح فيها التصميم قابلاً للتكرار: فالإجراء الذي يذكر الإعداد (Set-up) والختام (Wrap-up) صراحةً يستطيع زميل تشغيله، ويمكن إعادة تشغيله بعد الإصلاح وأتمتته لاحقاً.

ماذا تُنتج التهيئة

ينتهي تصميم الاختبار بحالات اختبار ومتطلبات لبيانات الاختبار وبالبيئة التي تحتاجها الاختبارات. والتهيئة تحوّلها إلى مواد اختبار ملموسة. ويذكر منهج ISTQB مُخرَجات العمل التالية:

  • إجراءات الاختبار: حالات اختبار بترتيب التنفيذ، مع الخطوات التي تُعدّ شروطها المسبقة وتختم العمل بعدها.
  • سكربتات الاختبار (Test Scripts): تعليمات يدوية خطوة بخطوة أو شيفرة آلية تنفّذ الاختبارات.
  • حزم الاختبارات: إجراءات أو سكربتات تُنفَّذ معاً في تشغيل اختبار (Test Run) واحد.
  • بيانات الاختبار: الحسابات والسجلات والملفات والقيم الفعلية التي تلبّي متطلبات البيانات.
  • جدول تنفيذ الاختبار: أي الحزم تُشغَّل وبأي ترتيب، ومتى، وأين.
  • عناصر بيئة الاختبار: البيئة التي تعمل عليها الاختبارات، ومعها البدائل (Stubs) والمشغّلات (Drivers) التي تحلّ محل المكوّنات غير المتاحة (كما في درس اختبار المكوّنات)، والمحاكيات (Simulators) التي تتصرف كجهاز أو نظام حقيقي، والمحاكاة الافتراضية للخدمات (Service Virtualization) التي تحاكي خدمات تابعة بأكملها.
تحوّل تهيئة الاختبار حالات الاختبار المصمَّمة إلى إجراءات وحزم وجدول تنفيذ، بينما تُجهَّز بيانات الاختبار والبيئة؛ ولا يبدأ التنفيذ إلا بعد فحص الجاهزية. نموذج مفاهيمي
  1. 1حالات الاختبار من التصميممع متطلبات بيانات الاختبار واحتياجات البيئةالمُدخل
  2. 2إجراءات الاختبار وسكربتاتهحالات بترتيب التنفيذ مع الإعداد والختام
    تُجهَّز في الوقت نفسه
    • 3إنشاء بيانات الاختبارمُعبّأة ومسجّلة وقابلة للاستعادة
    • 4بناء البيئةالبناء والإعدادات والبدائل وحسابات الاختبار
  3. 5حزم الاختباراتإجراءات مجمَّعة لتشغيل اختبار واحد
  4. 6جدول تنفيذ الاختبارمرتّب حسب الأولوية والاعتماديات والموارد المتاحة
  5. 7فحص الجاهزيةحزمة الدخان وقائمة الجاهزية مع الأدلةبوابة

    فرع: فشل بند: أصلحه أو أخّر الحزم المتأثرة به، ثم افحص مجدداًفشل

بعد ذلك:يبدأ تنفيذ الاختبار بأول حزمة في الجدول

صورة مبسطة: تتداخل التهيئة مع تصميم الاختبار، ويُعاد فحص الجاهزية مع كل بناء جديد.

الإجراءات والحزم وجدول التنفيذ

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

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

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

TP-PROMO-01  Apply and remove a promo code
  Set-up:   account cust-basic-01, cart baseline CART-3 (3 items, 240.00 SAR)
            promo codes loaded: SAVE10 (active, 10%), OLD5 (expired)
  Run:      TC-03  apply SAVE10   -> discount 24.00, subtotal 216.00
            TC-05  remove SAVE10  -> subtotal back to 240.00
            TC-07  apply OLD5     -> "This code has expired", subtotal unchanged
  Wrap-up:  empty the cart, reset the usage count of SAVE10

Execution schedule, staging, day 1
  09:00  Smoke suite (8 checks)       must pass before any other suite
  09:30  Promo suite TP-PROMO-01..03  highest risk: changes what customers pay
  13:00  Checkout regression suite    payment sandbox booked 13:00-17:00

إنشاء بيانات الاختبار وتجهيز البيئة

حدّد التصميم البيانات التي تحتاجها الاختبارات، والتهيئة تُنشئها أو تحصل عليها: سكربتات أو ملفات تعبئة (Seed) للحسابات والمنتجات والطلبات في الحالات المطلوبة، وخط أساس مسجَّل يمكن استعادته بين التشغيلات، كي يكون اختلاف النتيجة مصدره البرمجية لا بيانات متبقية. وفضّل البيانات الاصطناعية أو المقنَّعة (Masked): فسجلات العملاء الحقيقية المنسوخة إلى بيئة اختبار تظل بيانات شخصية.

ثم تُبنى البيئة ويُتحقق منها، أي تُفحص ولا تُفترض: البناء المتوقع منشور، والإعدادات المؤثرة في السلوك مضبوطة كما خُطط لها، والخدمات الخارجية متاحة أو مستبدلة ببديل (Stub)، وكل حساب اختبار يستطيع تسجيل الدخول. ثم يبيّن اختبار الدخان (Smoke Test)، وهو حزمة قصيرة تغطي الوظائف الرئيسية، أن النظام يعمل بما يكفي لبدء الاختبار المخطط له.

جرّبها: مصنع بيانات الاختبار جرّبها: مولّد مجموعات بيانات SQL جرّبها: مولّد مستخدمين وهميين جرّبها: مولّد استجابات API وهمية

مثال تطبيقي: قائمة الجاهزية

قبل أن تبدأ حزم رموز الخصم، يمرّ المختبِر على قائمة تحقق الجاهزية (Readiness Checklist) ويسجّل نتيجة كل بند مع دليلها، فتتحول عبارة «أظن أننا جاهزون» إلى فحوص يستطيع أي شخص تكرارها. وكثير من الفرق تستخدم قائمة كهذه معاييرَ دخول (Entry Criteria) للتنفيذ، أي الشروط المسبقة التي يجب أن تتحقق قبل أن يبدأ. ويذكر منهج ISTQB من معايير الدخول المعتادة توفّرَ البيئات وبيانات الاختبار، ونجاحَ اختبارات الدخان.

وفشل بند لا يعني «ابدأ وتمنَّ الخير». ففي التشغيل الأول انتهت مهلة الاتصال ببيئة تجربة الدفع: فبدأت حزمة رموز الخصم في موعدها لأنها لا تصل إلى الدفع، وانتظرت حزمة انحدار الدفع، وذهبت المشكلة إلى مالك بيئة التجربة.

  • البناء: الإصدار ⁦4.2.0⁩ على Staging ويطابق ملاحظات الإصدار.
  • الإعدادات: العلم promo_codes مفعّل، والأسعار بالريال السعودي (SAR)، والمنطقة الزمنية تطابق الإنتاج لأن انتهاء صلاحية الرموز يعتمد عليها.
  • بيانات الاختبار: خطوط أساس السلال والرمزان SAVE10 وOLD5 محمَّلة، وسكربت الاستعادة شُغّل مرة.
  • الحسابات: حساب اختبار لكل دور (عميل وموظف دعم) يستطيع تسجيل الدخول، والشراء كزائر يعمل دون حساب.
  • التكاملات: بيئة تجربة الدفع تستجيب (فشل في التشغيل الأول)، وخدمة الرسائل النصية مستبدلة ببديل يسجّل الرسائل.
  • مواد الاختبار: الإجراءات من TP-PROMO-01 إلى 03 مُراجَعة ومربوطة بحالات الاختبار ومحمَّلة كتشغيل اختبار.
  • قابلية الملاحظة: المختبِرون يقرؤون سجلات التطبيق ووحدة تحكم المتصفح (Console).
  • حزمة الدخان: الفحوص الثمانية كلها تنجح على هذا البناء.

جرّبها: فاحص صحة API

أخطاء شائعة

  • نسخ حالات الاختبار إلى الأداة دون إعداد أو ختام أو ترتيب، فيترك فشل واحد بيانات تُفسد الحالات التالية.
  • إنشاء بيانات الاختبار يدوياً يوم التنفيذ، دون سجل ودون طريقة لاستعادتها.
  • افتراض أن البيئة جاهزة لأنها كانت جاهزة في السبرنت الماضي، بدلاً من التحقق من البناء والإعدادات والتكاملات في كل مرة.
  • الجدولة حسب الأولوية وحدها، فتنتظر حزمة عالية الأولوية بيانات لا تُنشئها إلا حزمة أقل أولوية.
  • تخطّي اختبار الدخان، ثم اكتشاف نشر معطوب بعد ساعة من الاختبارات الفاشلة والمعطّلة (Blocked).

من منظور ضمان الجودة

في الفريق الحقيقي تتداخل التهيئة مع التصميم، وتبدأ ما إن تستقر أولى حالات الاختبار. أرسل طلبات البيئة والبيانات مبكراً لأن غيرك ينفّذها: المطورون أو مهندسو DevOps ينشرون البناءات ويضبطون البيئات، وقد يشغّل مالك قاعدة البيانات سكربتات التعبئة، ويتفق قائد الاختبار على الجدول.

سجّل ما جهّزته: الإجراءات والحزم مربوطة بحالات الاختبار، وخط أساس البيانات وطريقة استعادته، والبناء والإعدادات قيد الاختبار، ونتيجة الجاهزية مؤرَّخة. وقبل التنفيذ اسأل: أي بناء بالضبط نختبر؟ ما الذي لا يحاكيه البديل؟ من يستعيد البيانات إذا أفسدها تشغيل ما؟ ومن هذه السجلات ينطلق الدرس التالي: متابعة الاختبار والتحكم فيه.

تمرين عملي

هيّئ اختبارات إعادة تعيين كلمة المرور

المطلوب

أنتج تصميم الاختبار ست حالات لميزة «نسيت كلمة المرور» في تطبيق ويب: TC-1 طلب رابط إعادة التعيين لبريد مسجَّل؛ TC-2 الطلب لبريد غير مسجَّل (الرسالة المحايدة نفسها)؛ TC-3 فتح الرابط وتعيين كلمة مرور جديدة صالحة؛ TC-4 فتح رابط تجاوز صلاحيته البالغة ⁦30⁩ دقيقة؛ TC-5 إعادة استخدام رابط مستخدَم؛ TC-6 تسجيل الدخول بكلمة المرور الجديدة.

هيّئ هذه الحالات: ابنِ الإجراءات، ورتّبها، واذكر بيانات الاختبار وعناصر البيئة، واكتب قائمة جاهزية من ستة بنود على الأقل.

الخطوات
  1. اجمع الحالات التي تشترك في الشروط المسبقة في إجراءات، واكتب الإعداد والختام لكل منها.
  2. رتّب الإجراءات مع ذكر الاعتماديات.
  3. اذكر البيانات وعناصر البيئة، ومنها طريقة استلام رسائل إعادة التعيين، ثم اكتب القائمة.
إظهار الإجابة النموذجية
الإجابة النموذجية

الإجراءات: TP-1 «طلب إعادة التعيين» (الإعداد: حساب مسجَّل وعنوان غير مسجَّل؛ والختام: حذف الرسائل الملتقَطة) يشغّل TC-1 وTC-2. وTP-2 «استخدام الرابط» (الإعداد: رابط جديد للحساب المسجَّل) يشغّل TC-3 ثم TC-6 ثم TC-5 الذي يجب أن يرفض الرابط المستخدَم؛ والختام: إعادة كلمة المرور الأساسية. وTP-3 «رابط منتهي الصلاحية» (الإعداد: حساب ثانٍ مُعبّأ له رابط مضى عليه أكثر من ⁦30⁩ دقيقة، كي لا يتداخل مع TP-2؛ والختام: التراجع عن أي تغيير في الساعة أو في إعداد الصلاحية) يشغّل TC-4.

الترتيب: TP-1 أولاً لأنه يثبت أن رسائل إعادة التعيين تصل؛ ثم TP-2 الذي تعتمد حالاته بعضها على بعض. أما TP-3 فيحتاج إلى رابط مضى عليه أكثر من ⁦30⁩ دقيقة: اطلبه في بداية الجلسة وشغّل TC-4 بعد مرور ⁦30⁩ دقيقة، أو اطلب من المطورين طريقة لإنهاء صلاحية الروابط، مثل إعداد صلاحية أقصر أو ساعة يمكن التحكم فيها، كي يُشغَّل في أي وقت.

البيانات والبيئة: حسابان مُعبّآن بكلمة مرور أساسية معروفة، وعناوين اختبار على نطاق محجوز مثل example.com، وخدمة لالتقاط البريد أو بديل لها كي لا تصل رسائل إعادة التعيين إلى شخص حقيقي أبداً، وطريقة لإنهاء صلاحية الروابط أو وقت للانتظار، والبناء قيد الاختبار على Staging.

قائمة الجاهزية: البناء منشور ومسجَّل؛ خدمة التقاط البريد تستقبل رسالة تجريبية؛ الحسابان المُعبّآن يسجّلان الدخول؛ استعادة كلمة المرور تعمل؛ انتهاء صلاحية الرابط يمكن محاكاته، أو انتظار ⁦30⁩ دقيقة مدرج في الجدول؛ المختبِرون يقرؤون السجلات؛ فحص دخان لتسجيل الدخول وصفحة إعادة التعيين ينجح.

أسئلة شائعة

ما الفرق بين حالة الاختبار وإجراء الاختبار؟

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

هل تهيئة الاختبار هي كتابة الاختبارات الآلية؟

لا. كتابة سكربتات الاختبار الآلية جزء من التهيئة حين تكون الاختبارات مؤتمتة، لكن التهيئة تشمل أيضاً الإجراءات اليدوية وبيانات الاختبار والحزم وجدول التنفيذ والبيئة. والفريق الذي لا يملك أي أتمتة يهيّئ اختباراته أيضاً.

كيف تقابل تهيئة الاختبار مراحل STLC؟

دورة حياة اختبار البرمجيات (STLC) نموذج متداول في الصناعة، لا مصطلح من مصطلحات ISTQB. فمرحلة «تطوير حالات الاختبار» فيها تغطي تصميم الاختبار ومعظم التهيئة، ومرحلة «تجهيز بيئة الاختبار» هي جزء البيئة من التهيئة معروضاً وحده. العمل واحد، والاختلاف في التجميع فقط.

من المسؤول عن بيئة الاختبار؟

يختلف ذلك من فريق لآخر. كثيراً ما يبنيها المطورون أو مهندسو DevOps أو مهندسو المنصات وينشرونها، ويتحقق المختبِرون من جاهزيتها للاختبارات التي خططوا لها. وأياً كان من بناها، لا ينبغي أن يبدأ التنفيذ قبل تشغيل قائمة الجاهزية وتسجيل نتيجتها.

المراجع

الأدوات

تدرّب بأدوات متقن

مصنع بيانات الاختبار

مصنع متكامل لبيانات الاختبار الاصطناعية: مستخدمون وعملاء وشركات وعناوين وأرقام وتواريخ وسلاسل نصية بصيغة JSON أو CSV أو SQL أو XML.

بيانات الاختبار

مولّد مستخدمين وهميين

ولّد سجلات مستخدمين وهمية (الاسم واسم المستخدم والبريد الإلكتروني وكلمة المرور وبذرة الصورة الرمزية والدور) لحسابات الاختبار.

بيانات الاختبار

مولّد استجابات API وهمية

ولّد استجابات API وهمية كاملة (الحالة والترويسات وجسم JSON) لحالات النجاح والقوائم والتفاصيل والأخطاء والنتائج الفارغة.

المحاكاة

فاحص صحة API

افحص عدة نقاط نهاية لصحة API دفعة واحدة واحصل على الحالة وزمن الاستجابة وملخّص نجاح/فشل.

اختبار واجهات API

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

قبل هذا الموضوع