مستويات الاختبار
مستوى الاختبار (Test Level) مجموعة من أنشطة الاختبار تُنظَّم وتُدار معاً، وتستهدف البرمجيات في مرحلة معيّنة من تطويرها: من مكوّن واحد حتى النظام كله وهو يعمل مع أنظمة أخرى. ويصف منهج ISTQB للمستوى التأسيسي (CTFL v4.0) خمسة مستويات: اختبار المكوّن، واختبار تكامل المكوّنات، واختبار النظام، واختبار تكامل الأنظمة، واختبار القبول.
في تطبيق لتوصيل الطعام، يفحص المطور دالة رسوم التوصيل (المكوّن)، وتُختبر خدمة الطلبات وخدمة المطاعم معاً (تكامل المكوّنات)، وينفّذ المختبِرون طلبات كاملة في بيئة الاختبار (النظام)، ثم مع البيئة التجريبية (Sandbox) لمزوّد الدفع (تكامل الأنظمة)، ويتأكد ممثلو العمل من أن التطبيق يناسب طريقة عمل المطاعم والعملاء فعلاً (القبول).
لماذا يهم
اختبار كل شيء في النهاية عبر واجهة المستخدم يجعل العيوب بطيئة الاكتشاف وصعبة التحديد: فالمجموع الخاطئ عند الدفع قد يأتي من دالة تقريب، أو من واجهة بين خدمتين، أو من إعداد، أو من مزوّد خارجي. وكل مستوى ينظر إلى عنصر محدد بأساس اختبار خاص به، فيشير الإخفاق إلى منطقة أصغر، ويُكتشف كثير من العيوب مبكراً وقريباً من سببها، وهذا هو مبدأ الاختبار المبكر مطبَّقاً.
وتكشف المستويات أيضاً الثغرات والتكرار: فإذا لم يملك أحدٌ اختبار تكامل الأنظمة، كان العملاء أول من يختبر واجهة الدفع. أما المختبِر، فالمستويات تخبره بالمستندات التي يطلبها، والبيئة التي يحتاجها، والعيوب التي يتوقعها.
ما مستوى الاختبار؟
في درس نموذج V رأيت كل مستوى تطوير يقابله مستوى اختبار. ويعدّ ISTQB كل مستوى اختبار نسخةً من عملية الاختبار: فأنشطة الاختبار، من التخطيط إلى الإتمام، تجري في كل مستوى. وفي النماذج المتتابعة تكون معايير الخروج من مستوى ما غالباً جزءاً من معايير الدخول إلى المستوى التالي. أما في بعض النماذج التكرارية فقد لا ينطبق ذلك: إذ قد تمتد أنشطة التطوير عبر عدة مستويات، وقد تتداخل المستويات زمنياً، وقد يتضمن سبرنت واحد عملاً في كل المستويات.
والمستويات ليست أنواع اختبار. فنوع الاختبار يجمع أنشطة الاختبار بحسب ما تفحصه أو طريقة اشتقاق الاختبارات: فالاختبار الوظيفي وغير الوظيفي يتناولان خصائص جودة مختلفة، بينما يشتق اختبار الصندوق الأسود الاختبارات من المواصفات، واختبار الصندوق الأبيض من البنية الداخلية. ومعظم الأنواع يمكن تنفيذها في كل مستوى: فاختبار الأداء قد يقيس استعلاماً واحداً في قاعدة البيانات أو عملية الدفع كاملة. ويميّز ISTQB بين المستويات بهذه السمات:
- عنصر الاختبار (Test Object): ما يُختبر، من دالة حتى واجهة مع نظام آخر.
- أهداف الاختبار: ما يجب أن يثبته المستوى.
- أساس الاختبار (Test Basis): ما تُشتق منه الاختبارات، مثل التصميم أو قصص المستخدم.
- العيوب والإخفاقات: ما يكون المستوى في أفضل موقع لاكتشافه.
- النهج والمسؤوليات: التقنيات والبيئة ومن يقوم بالعمل.
مستويات الاختبار الخمسة في CTFL v4.0
يعرّف CTFL v4.0 المستويات الخمسة والسمات السابقة، أما أساس الاختبار والعيوب أدناه فهي المعتادة كما وردت في المنهج السابق (2018) وكما تظهر في الممارسة، والأساس الفعلي تحدده مستندات مشروعك. ويسمّي ISTQB اختبار المكوّن أيضاً اختبار الوحدة (Unit Testing)، واختبار تكامل المكوّنات اختبار تكامل الوحدات (Unit Integration Testing).
- اختبار المكوّن (Component Testing): دالة أو صنف أو وحدة برمجية بمعزل عن غيرها، وغالباً ما يُنفَّذ بإطار لاختبارات الوحدة؛ ولعزله يمكن استبدال الأجزاء التي يعتمد عليها ببدائل الاختبار (Test Doubles)، وهي عناصر مبسّطة تحلّ محلها مثل البديل (Stub) والمحاكاة (Mock). الأساس: التصميم التفصيلي والشيفرة. العيوب المعتادة: منطق أو حسابات خاطئة.
- اختبار تكامل المكوّنات (Component Integration Testing): الواجهات والتفاعلات بين المكوّنات، وتشكّله استراتيجية التكامل: من الأسفل إلى الأعلى (Bottom-up) بدءاً بالمكوّنات الدنيا، أو من الأعلى إلى الأسفل (Top-down) بدءاً من القمة مع بدائل للأجزاء غير الجاهزة، أو دفعة واحدة (Big-bang) بدمج كل شيء معاً. الأساس: تصميم البرمجيات ومواصفات الواجهات البرمجية. العيوب المعتادة: عدم تطابق الواجهات، وبيانات ناقصة أو مرمَّزة خطأً، وافتراضات خاطئة عن وحدات القياس في البيانات المتبادلة بين المكوّنات.
- اختبار النظام (System Testing): سلوك النظام كله، بما في ذلك المهام الشاملة والخصائص غير الوظيفية، في بيئة اختبار ممثِّلة. الأساس: المتطلبات وقصص المستخدم وحالات الاستخدام. العيوب المعتادة: سلوك يخالف المتطلبات، ومهام لا يمكن إكمالها، وبطء الاستجابة.
- اختبار تكامل الأنظمة (System Integration Testing): الواجهات مع الأنظمة والخدمات الخارجية، مثل بوابة الدفع أو مزوّد الرسائل النصية، في بيئة قريبة من الإنتاج. الأساس: اتفاقيات الواجهات وتوثيق الواجهات البرمجية الخارجية. العيوب المعتادة: رسائل غير متسقة، وانتهاء مهلة غير معالَج، وافتراضات خاطئة عن البيانات المتبادلة.
- اختبار القبول (Acceptance Testing): التحقق من الصلاحية (Validation) بأن النظام يلبّي حاجات العمل لدى المستخدمين وأنه جاهز للنشر. أشكاله الرئيسية: اختبار قبول المستخدم (UAT)، واختبار القبول التشغيلي، واختبار القبول التعاقدي والتنظيمي، واختبار ألفا، واختبار بيتا. الأساس: عمليات العمل، ومعايير القبول، والعقود، والأنظمة. العيوب المعتادة: مسارات عمل لا تناسب المنشأة، وقواعد عمل خاطئة، ومتطلبات تعاقدية أو تنظيمية غير مستوفاة.
عند طبقة «اختبار القبول»: أوسع نطاق: النظام في سياق العملعند طبقة «اختبار المكوّن»: أضيق نطاق: مكوّن واحد معزول
- 1اختبار القبولالعنصر: النظام مقابل حاجات العمل لدى المستخدمين. الأساس: عمليات العمل، ومعايير القبول، والعقود، والأنظمة
يكشف: مسارات عمل لا تناسب المنشأة، وقواعد عمل خاطئة، وشروطاً تعاقدية أو تنظيمية غير مستوفاة
- 2اختبار تكامل الأنظمةالعنصر: الواجهات مع الأنظمة والخدمات الخارجية. الأساس: اتفاقيات الواجهات، وتوثيق الواجهات البرمجية الخارجية
يكشف: رسائل غير متسقة، وانتهاء مهلة غير معالَج، وافتراضات خاطئة عن البيانات المتبادلة
- 3اختبار النظامالعنصر: النظام كله في بيئة اختبار ممثِّلة. الأساس: المتطلبات، وقصص المستخدم، وحالات الاستخدام
يكشف: سلوكاً يخالف المتطلبات، ومهام لا يمكن إكمالها، وبطء الاستجابة
- 4اختبار تكامل المكوّناتالعنصر: الواجهات والتفاعلات بين المكوّنات. الأساس: تصميم البرمجيات، ومواصفات الواجهات البرمجية
يكشف: عدم تطابق الواجهات، وبيانات ناقصة أو مرمَّزة خطأً، ووحدات قياس خاطئة
- 5اختبار المكوّنالعنصر: دالة أو صنف أو وحدة برمجية بمعزل عن غيرها. الأساس: التصميم التفصيلي والشيفرة
يكشف: منطقاً أو حسابات خاطئة
المسؤولون المذكورون هم المعتادون لا قواعد ثابتة. وفي التطوير التكراري تتداخل المستويات زمنياً، وخطة الاختبار تحدد المستويات التي يستخدمها المشروع.
من يقوم بكل مستوى عادةً
هذه مسؤوليات معتادة لا قواعد ثابتة، وفي الفرق الرشيقة (Agile) كثيراً ما يتقاسم المختبِرون والمطورون العمل. لكن الملكية يجب ألا تضيع: فكل مستوى في خطة الاختبار يحتاج إلى مالك مسمّى، ويراجع المختبِر حتى المستويات التي لا يملكها، فيسأل مثلاً عمّا تستبدله اختبارات التكامل ببدائل (Stubs).
- اختبار المكوّن واختبار تكامل المكوّنات: المطورون عادةً، بشكل مؤتمت في بيئتهم وفي خط التكامل المستمر (CI).
- اختبار النظام: المختبِرون، وغالباً فريق اختبار مستقل أو مختبِرو فريق التسليم.
- اختبار تكامل الأنظمة: المختبِرون عموماً، مع مالكي الأنظمة الأخرى.
- اختبار القبول: المستخدمون المقصودون في الوضع المثالي، أي مستخدمو العمل أو العملاء أو مالك المنتج، أو فريق العمليات في القبول التشغيلي. وكثيراً ما يُعدّ المختبِرون ويسجّلون، أما القرار فلممثلي العمل.
مثال تطبيقي: رموز الخصم عبر المستويات الخمسة
متجر إلكتروني في السعودية يضيف رموز الخصم (Promo Codes). تستدعي خدمة السلة خدمة العروض، ويمر الدفع عبر بوابة خارجية. يتناول كل بند مستوى واحداً: اختباراً في ذلك المستوى والعيب الذي يكتشفه أولاً. ولاحظ أن عيب الهللات والريالات لا تراه اختبارات المكوّن في أي من الجانبين، وأن ثغرة القبول لا يراها أي اختبار مشتق من القصة.
- المكوّن: خصم 10% من 199.99 ريال يجب أن يكون 20.00، لكن الدالة تقتطع 19.999 إلى 19.99 بدلاً من تقريبها.
- تكامل المكوّنات: ترسل السلة 19999 (بالهللات) بينما تتوقع خدمة العروض 199.99 (بالريالات)؛ وقد نجح كل منهما في اختباراته.
- النظام: في مسار الدفع الكامل تُحسب ضريبة القيمة المضافة قبل الخصم، فيدفع العميل أكثر مما ينبغي.
- تكامل الأنظمة: عبر البيئة التجريبية للبوابة، تستلم البوابة المبلغ الأصلي، وانتهاء المهلة يترك الطلب «قيد الانتظار» دون أي رسالة.
- القبول: يكتشف فريق التسويق أن العميل يستطيع استخدام الرمز مرة بعد مرة. لم تذكر القصة «مرة واحدة لكل عميل»، لذا نجحت كل المستويات؛ وهذه ملاحظة تحقق من الصلاحية كما في درس التحقق والتحقق من الصلاحية.
القصة PROMO-12: رموز الخصم عند الدفع
بصفتي عميلاً، أريد إدخال رمز خصم كي أدفع أقل.
AC1 الرمز الصالح يمنح خصم 10% على مجموع المنتجات.
AC2 تُحسب ضريبة القيمة المضافة (15%) على المجموع بعد الخصم.
AC3 رسوم التوصيل لا يشملها الخصم.
AC4 تُقرَّب المبالغ إلى منزلتين عشريتين (أقرب هللة).
AC5 الرمز المنتهي أو غير المعروف يعرض «هذا الرمز غير صالح».جرّبها: المتطلبات ← حالات اختبار جرّبها: قصة المستخدم ← سيناريوهات اختبار
أخطاء شائعة
- تسمية اختبار الأداء أو اختبار الانحدار مستوى اختبار: فاختبار الأداء نوع اختبار، واختبار الانحدار يفحص الآثار الجانبية للتغيير، وكلاهما يمكن تنفيذه في أي مستوى.
- اختبار كل شيء على مستوى النظام عبر واجهة المستخدم، حيث التغذية الراجعة بطيئة والإخفاقات صعبة التحديد.
- افتراض أن النظام يعمل لأن كل مكوّن نجح؛ فالبدائل (Stubs) تخفي عيوب الواجهات.
- اختبار الخدمات الخارجية مقابل المحاكاة (Mock) فقط، وتخطي اختبار تكامل الأنظمة.
- معاملة القبول كتكرار لاختبار النظام على يد المختبِرين أنفسهم، بدلاً من تحقق من الصلاحية مع المستخدمين المقصودين.
- كتابة اختبارات النظام من الشيفرة أو من شرح المطور بدلاً من المتطلبات.
من منظور ضمان الجودة
تظهر المستويات أولاً في استراتيجية الاختبار وخطة الاختبار، اللتين تحددان لكل مستوى الأهداف وأساس الاختبار والبيئة ومعايير الدخول والخروج والمسؤول. وحين تنضم إلى مشروع، اسأل: ما المستويات الموجودة، ومن يملك كلاً منها، وأين يعمل كل منها، وما الذي يستبدله ببدائل؟ والإجابات تكشف لك الثغرات.
وفي العمل اليومي سجّل في كل تقرير خطأ المستوى والبيئة اللذين ظهر فيهما الإخفاق، واسأل في فرز العيوب (Defect Triage)، حيث تُراجَع العيوب الجديدة وتُحدَّد أولوياتها: «أي مستوى كان يجب أن يكتشف هذا؟». فتكرار عيوب الواجهات في اختبار النظام يعني أن اختبار تكامل المكوّنات ضعيف، والعيب في قاعدة عمل يُكتشف عبر واجهة المستخدم سببٌ لاقتراح اختبار مكوّن.
تمرين عملي
صنّف الملاحظات حسب مستوى الاختبار المناسب
تطبيق لعيادة يحجز المواعيد. تستخدم خدمة الحجز مكوّن جدولة داخلياً، وتمر رسائل التأكيد عبر بوابة رسائل نصية خارجية، ويستخدم موظفو الاستقبال التطبيق طوال اليوم.
لكل ملاحظة أدناه، اذكر أدنى مستوى اختبار يجب أن يكتشفها، وأساس الاختبار الذي كان سيكشفها، ومن يقوم بذلك المستوى عادةً.
حجز العيادة: الملاحظات
1. الدالة toMinutes("09:30") تُرجع 560 بدلاً من 570.
2. ترسل خدمة الحجز التاريخ 2026-03-04، ويقرؤه مكوّن الجدولة
على أنه 3 أبريل بدلاً من 4 مارس.
3. مريضان يحجزان الموعد نفسه من هاتفين في اللحظة نفسها،
ويستلم كلاهما تأكيداً. (R3: مريض واحد لكل موعد.)
4. ترفض بوابة الرسائل النصية الرسائل العربية الأطول من 70 حرفاً،
ويعرض التطبيق «تم الحجز» ولا تُرسل أي رسالة.
5. يحتاج الاستقبال إلى قائمة انتظار للمواعيد الملغاة، ولا يذكرها
أي متطلب.
6. مع 200 مستخدم يحجزون في وقت واحد، يستغرق التأكيد 9 ثوانٍ.
(R7: يُؤكَّد الحجز خلال 3 ثوانٍ مع 200 مستخدم متزامن.)- حدّد ما كان قيد الاختبار: مكوّن واحد، أم واجهة بين مكوّنات، أم النظام كله، أم خدمة خارجية، أم حاجة العمل.
- اختر أدنى مستوى يمكنه رؤية العيب.
- سمِّ أساس الاختبار ومن يقوم بذلك المستوى عادةً.
إظهار الإجابة النموذجية
1 — اختبار المكوّن؛ الأساس: تصميم الدالة (09:30 تساوي 570 دقيقة)؛ المطورون.
2 — اختبار تكامل المكوّنات؛ الأساس: مواصفة الواجهة، التي يجب أن تحدد صيغة تاريخ واحدة مثل ISO 8601 YYYY-MM-DD؛ المطورون عادةً.
3 — اختبار النظام؛ الأساس: المتطلب R3؛ المختبِرون، باستخدام جهازين في وقت واحد. وبعد معرفة السبب يمكن للمطورين إضافة اختبار تكامل مكوّنات يحجز الموعد نفسه مرتين بالتوازي.
4 — اختبار تكامل الأنظمة؛ الأساس: توثيق الواجهة البرمجية لمزوّد الرسائل، بما فيه استجابات الأخطاء؛ المختبِرون مع مالك التكامل. وأبلغ أيضاً عن عرض التطبيق للنجاح حين فشل الإرسال.
5 — اختبار القبول (UAT)؛ الأساس: عملية العمل في العيادة؛ موظفو الاستقبال ومدير العيادة. وهي ثغرة في المتطلبات تُرفع إلى مالك المنتج، لا إخفاق مقابل R1–R7.
6 — اختبار النظام، غير الوظيفي (الأداء)؛ الأساس: المتطلب R7؛ المختبِرون أو متخصصو الأداء في بيئة تشبه الإنتاج.
أسئلة شائعة
هل اختبار الوحدة هو نفسه اختبار المكوّن؟
نعم. يستخدم ISTQB مصطلح اختبار المكوّن أساساً، ويذكر مسرده اختبار الوحدة (Unit Testing) واختبار الوحدة البرمجية (Module Testing) مرادفين له. وما يُعدّ «وحدة»، دالةً أو صنفاً أو وحدة برمجية، يختلف بين الفرق ولغات البرمجة، فاتفقوا عليه في استراتيجية الاختبار.
هل الاختبار الشامل (End-to-End) مستوى اختبار؟
ليس ضمن المستويات الخمسة في CTFL v4.0. فالمنهج يضع المهام الشاملة من البداية إلى النهاية داخل اختبار النظام، وكثيراً ما تستخدم الفرق وصف «الشامل» لرحلات تعبر أنظمة خارجية أيضاً، وهذا يمسّ اختبار تكامل الأنظمة. ويتناوله درس الاختبار الشامل لاحقاً في هذه الوحدة التعليمية.
هل يحتاج كل مشروع إلى المستويات الخمسة وبهذا الترتيب؟
لا. المستويات المستخدمة تعتمد على المنتج ومخاطره: فالتطبيق المستقل بلا خدمات خارجية ليس لديه إلا القليل ليُختبر على مستوى تكامل الأنظمة، بينما قد يركز منتج مبني من مكوّنات مشتراة على التكامل والقبول. وفي التطوير التكراري تتداخل المستويات، وقد تمر القصة الواحدة بعدة مستويات في سبرنت واحد. وخطة الاختبار هي التي تحدد المستويات المطبقة.
ماذا يعني SIT وUAT؟
SIT اختصار شائع لاختبار تكامل الأنظمة (System Integration Testing)، وUAT يعني اختبار قبول المستخدم (User Acceptance Testing)، وهو أحد أشكال اختبار القبول. وبعض المؤسسات تستخدم «SIT» لأي اختبار يجري في بيئة تكامل مشتركة، فتأكد مما يقصده فريقك قبل أن تخطط على أساسه.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
تدرّب بأدوات متقن
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
التحقق من مطابقة زوج طلب/استجابة API لعقد OpenAPI الخاص به: المسار والطريقة والمعاملات والجسم ومخطط الاستجابة.
ولّد استجابات API وهمية كاملة (الحالة والترويسات وجسم JSON) لحالات النجاح والقوائم والتفاصيل والأخطاء والنتائج الفارغة.
ولّد معايير قبول بصيغة Given/When/Then وقائمة تحقق لتعريف الإنجاز (Definition of Done) من قصة مستخدم.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.