تغطية الاختبار

لماذا يهم

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

أما بالنسبة إلى المختبِر، فالتغطية تحوّل الجهد إلى عبارة يستطيع الآخرون التحقق منها والعمل بها: «لكل معايير القبول الـ⁦14⁩ اختبارات ناجحة، ولم يُختبر خطران متوسطان لأن بيئة الدفع التجريبية كانت متوقفة». وهي أيضاً ما يجعل معايير الخروج قابلة للقياس، ويحمي الفريق من ثقة زائفة برقم واحد كبير.

تغطية ماذا؟ المتطلبات والمخاطر والشيفرة

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

• تغطية المتطلبات (Requirements Coverage): أيّ المتطلبات أو معايير القبول لها اختبارات، وأيّها لها اختبارات ناجحة. وبنود التغطية هنا هي المعايير الموجودة في أساس الاختبار، وتُعدّ عبر التتبّع (Traceability): ربط كل اختبار بالمعيار الذي يتحقق منه.
• تغطية المخاطر (Risk Coverage): أيّ مخاطر المنتج المحددة لها اختبارات نُفّذت، وأيّها لها اختبارات نجحت، مع عرضها حسب مستوى الخطر. فعبارة «الخطران العاليان مُختبَران واختباراتهما ناجحة، و⁦2⁩ من ⁦5⁩ مخاطر متوسطة لم تُختبر بعد» تدعم قرار الإصدار أفضل من أي نسبة مئوية منفردة.
• تغطية الشيفرة (Code Coverage): أيّ أجزاء الشيفرة جرى تشغيلها أثناء الاختبارات، وتقيسها أداة. فتغطية التعليمات (Statement Coverage) تعدّ التعليمات القابلة للتنفيذ، وتغطية الفروع (Branch Coverage) تعدّ الفروع، أي انتقالات التحكم في الشيفرة، وتعرضها أدوات التغطية على أنها نتائج القرارات، مثل جانبَي جملة if. وتغطية الفروع أقوى: فتغطية الفروع بنسبة ⁦100%⁩ تتضمن تغطية التعليمات بنسبة ⁦100%⁩، والعكس غير صحيح.

بنود التغطية وكيف تقيسها

يقيس منهج ISTQB للمستوى التأسيسي (الإصدار ⁦4.0⁩) التغطية من خلال بنود التغطية: أشياء يمكن عدّها، تُستخرج من شروط الاختبار بتطبيق تقنية اختبار، كما في درس نشاط تصميم الاختبار. يحدّدها تصميم الاختبار، ويشغّلها التنفيذ. والمعادلة لا تتغيّر: coverage = items exercised ÷ items identified × 100%، أي البنود التي شُغِّلت مقسومةً على البنود المحددة.

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

• المتطلبات: معايير القبول أو المتطلبات منفردةً.
• المخاطر: المخاطر المحددة، مجمّعةً حسب مستوى الخطر.
• تقسيم التكافؤ (Equivalence Partitioning): الأقسام. تحليل القيم الحدّية (Boundary Value Analysis): القيم الحدّية.
• جداول القرار: الأعمدة التي تحوي تركيبات ممكنة من الشروط.
• انتقالات الحالة: الحالات، أو الانتقالات الصالحة، أو جميع الانتقالات.
• الشيفرة: التعليمات القابلة للتنفيذ، أو الفروع (في أدوات التغطية: كل نتيجة لكل قرار).

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

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

ميزة في صفحة الدفع تطبّق رمز خصم. معايير القبول: AC1، الرمز الصالح يخفّض الإجمالي بنسبته؛ AC2، الرمز المنتهي يُرفض برسالة واضحة؛ AC3، الرموز لا تنطبق إلا على إجمالي ⁦100.00⁩ ريال فأكثر؛ AC4، رمز واحد لكل طلب. ومخاطر المنتج: R1 (عالٍ) تطبيق الرمز مرتين على طلب واحد؛ R2 (عالٍ) قبول رمز منتهي الصلاحية؛ R3 (متوسط) تطبيق حدّ ⁦100.00⁩ على الجانب الخطأ.

كتب المطور اختبار وحدة واحداً لدالة الخصم، ونفّذ المختبِر ثلاثة اختبارات نظام على البناء ⁦57⁩، يفحص فيها TC-03 الإجماليين ⁦99.99⁩ و⁦100.00⁩. والشيفرة والتقارير أدناه. وهذا ما يقوله كل رقم:

• تغطية التعليمات ⁦100%⁩ (⁦4⁩ من ⁦4⁩): نُفّذت كل تعليمة في applyDiscount أثناء اختبار الوحدة، ومع ذلك لم يجرّب أي اختبار وحدة إجمالياً أقل من ⁦100.00⁩.
• تغطية الفروع ⁦50%⁩ (⁦1⁩ من ⁦2⁩): النتيجة false للشرط total >= 100 لم تُنفَّذ قط. واختبار وحدة بإجمالي ⁦99.99⁩ يغطيها.
• معايير القبول: ⁦3⁩ من ⁦4⁩ لها اختبار (⁦75%⁩)، لكن ⁦2⁩ فقط من ⁦4⁩ لها اختبار ناجح (⁦50%⁩). فقد فشل TC-02، وليس لـAC4 أي اختبار.
• المخاطر: خطران من ⁦3⁩ لهما اختبار، لكنّ خطراً واحداً فقط من ⁦3⁩ له اختبار ناجح، وليس لأيٍّ من الخطرين العاليين اختبار ناجح: فلا اختبار لـR1، واختبار R2 فشل. وهذا هو الرقم الذي يحتاجه قرار الإصدار.
• لا شيء في applyDiscount يعالج «رمز واحد لكل طلب». فإن لم يُنفَّذ AC4 أصلاً، فلن يكشف ذلك أيُّ تقرير لتغطية الشيفرة: فالأداة لا تقيس إلا شيفرة موجودة.

// discount.ts
export function applyDiscount(total: number, percent: number): number {
  let result = total;
  if (total >= 100) {
    result = total - (total * percent) / 100;
  }
  return result;
}

// discount.test.ts (Jest): the only unit test
import { applyDiscount } from './discount';

test('10% off an order of 150', () => {
  expect(applyDiscount(150, 10)).toBe(135);
});

Code coverage (unit tests)   Statements   Branches
discount.ts                  4/4  100%    1/2  50%

Traceability, system tests on build 57
Criterion   Test     Result     Risk
AC1         TC-01    passed     -
AC2         TC-02    failed     R2 (high)
AC3         TC-03    passed     R3 (medium)
AC4         -        no test    R1 (high)

جرّبها: المتطلبات ← حالات اختبار جرّبها: مولّد الاختبار المبني على المخاطر

لماذا لا تعني تغطية ⁦100%⁩ خلوّ البرنامج من العيوب

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

• المقام لا يضم إلا ما حدّدته. فالمتطلب المفقود أو الخطر غير المدرج لا يظهر في النسبة أبداً، لذا تبقى تغطية ⁦100%⁩ لقائمة ناقصة تغطيةً ناقصة.
• التنفيذ ليس تحققاً. فاختبار بلا تأكيد (Assertion)، أي بلا فحص للناتج، يستدعي applyDiscount(150, 10) يعطي تغطية التعليمات نفسها ⁦100%⁩ التي يعطيها اختبار يتحقق من أن الناتج ⁦135⁩.
• البيانات مهمة. فالاستدعاء applyDiscount(150, 110) يُعيد إجمالياً سالباً، ولن تكشف ذلك تغطية الفروع الكاملة. ومثال المنهج نفسه قسمةٌ لا تُخفق إلا حين يكون المقسوم عليه صفراً.
• تغطية الشيفرة لا ترى الإغفال: فالشيفرة التي لم تُكتب أصلاً ليس فيها تعليمات تفوتك.
• قد يتحوّل الهدف إلى لعبة: فيضيف الناس اختبارات تشغّل الشيفرة دون أن تتحقق من شيء. ومراجعة التأكيدات، أو اختبار الطفرات (Mutation testing)، أي تغييرات صغيرة متعمدة في الشيفرة يجب أن تكشفها حزمة اختبارات جيدة، تساعد على معرفة ما إذا كانت الشيفرة المغطّاة يُتحقق منها فعلاً.

جرّبها: محلّل تغطية الاختبار بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022المعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.