اختبار النظام
اختبار النظام (System Testing) مستوى الاختبار الذي يفحص نظاماً متكاملاً كاملاً مقابل متطلباته المحددة. وموضوع الاختبار (test object) هنا هو المنتج كله كما يتعامل معه المستخدم أو نظام آخر: الواجهة الأمامية والخدمات الخلفية وقاعدة البيانات والإعدادات والمهام التي تعمل في الخلفية، منشورةً وتعمل معاً.
مثال: في موقع لحجز تذاكر الفعاليات، يسجّل اختبار النظام الدخول بصفته عميلاً، ويحجز مقعدين، ويدفع في وضع الاختبار لدى مزوّد الدفع، ثم يتأكد من ظهور الحجز في «تذاكري» ومن وصول التذكرة الإلكترونية بالبريد الإلكتروني. ويفحص المستوى نفسه مدى جودة سلوك النظام: السرعة تحت الحمل، والنسختان العربية والإنجليزية، ومن يستطيع رؤية أي حجز.
لماذا يهم
تُثبت اختبارات المكوّنات واختبارات التكامل أن الأجزاء تعمل وأنها تتخاطب فيما بينها، لكنها لا تُثبت أن المنتج المجمَّع يفعل ما تقوله متطلباته. فكثير من الإخفاقات لا يظهر إلا حين يعمل كل شيء معاً بإعدادات واقعية: مقاعد تبقى محجوزة ساعات لأن خادمين يستخدمان منطقتين زمنيتين مختلفتين، أو عميل يفتح حجز شخص آخر بتغيير رقم في الرابط. وإن لم يكشفها اختبار النظام كشفها العملاء.
أما المختبِر، فهذا هو المستوى الذي تكون فيه نظرته المستقلة أعظم قيمة: فاختبارات النظام تُشتق من المتطلبات والمخاطر لا من الكود، ونتائجها هي الدليل الذي يُبنى عليه قرار جاهزية البناء (build) لاختبار القبول.
ماذا يفحص اختبار النظام، ومقابل ماذا
يصف منهج ISTQB للمستوى التأسيسي (CTFL v4.0) اختبار النظام بأنه يركّز على السلوك العام لنظام أو منتج كامل وعلى قدراته، ويشمل غالباً الاختبار الوظيفي للمهام الشاملة من البداية إلى النهاية والاختبار غير الوظيفي لخصائص الجودة، وقد ينفذه فريق اختبار مستقل. أما الواجهات مع الأنظمة الأخرى، مثل مزوّد الدفع، فهي محور اختبار تكامل الأنظمة (System Integration Testing) الذي تعرّفت إليه في الدرس السابق.
أساس الاختبار (test basis) هنا هو مواصفات مستوى النظام: المتطلبات الوظيفية وغير الوظيفية، وحالات الاستخدام، وقصص المستخدم، وقواعد العمل، وتحليل المخاطر، ووثائق المستخدم. وتُنفَّذ الاختبارات عبر الواجهات الخارجية للنظام، أي واجهة المستخدم والواجهة البرمجية العامة والملفات والرسائل التي يتبادلها، لا باستدعاء دوال داخلية. ومن الإخفاقات المعتادة في هذا المستوى:
- قاعدة تمتد عبر عدة مكوّنات تعطي نتيجة خاطئة، مثل خصم يُطبَّق مرتين بين سلة الشراء والفاتورة.
- مهمة شاملة لا تكتمل: يُحفظ الحجز، لكن رسالة التأكيد لا تُرسَل.
- إخفاق سببه الإعدادات أو النشر لا الكود: إعداد مفقود، أو منطقة زمنية خاطئة، أو شهادة منتهية الصلاحية.
الاختبار الوظيفي وغير الوظيفي على مستوى النظام
يفحص الاختبار الوظيفي للنظام ماذا يفعل النظام: كل متطلب وقاعدة عمل ومهمة شاملة، بما في ذلك المدخلات غير الصالحة ومعالجة الأخطاء، لا المسار الرئيسي وحده. ويفحص الاختبار غير الوظيفي مدى جودة أدائه لذلك، مقابل خصائص الجودة مثل كفاءة الأداء والأمان والتوافق والموثوقية وقابلية الاستخدام (ويسمّي المعيار ISO/IEC 25010:2023 قابلية الاستخدام «قدرة التفاعل»). واختبار النظام يحتاج إلى النوعين معاً.
وبعض الخصائص لا يمكن الحكم عليها إلا على النظام الكامل: فزمن الاستجابة يعتمد على كل طبقة وعلى الشبكة بينها، وسهولة الاستخدام تعتمد على الرحلة كلها. لذلك يشير منهج ISTQB إلى أن بعض الخصائص غير الوظيفية يُفضَّل اختبارها على نظام كامل في بيئة اختبار ممثِّلة. وهي تحتاج أيضاً إلى متطلبات قابلة للقياس: «خريطة المقاعد سريعة» لا يمكن أن ينجح أو يفشل، أما «تُحمَّل خلال ثانيتين في 95% من الطلبات مع 500 مستخدم متزامن» فيمكن.
بيئة اختبار تحاكي بيئة الإنتاج
لا تكون نتيجة اختبار النظام جديرة بالثقة إلا بقدر البيئة التي نُفِّذ فيها: فالاختبار الذي ينجح فيها يجب أن ينجح في الإنتاج، والفشل فيها يجب أن يشير إلى المنتج لا إلى طريقة الإعداد. ويتحدث منهج ISTQB عن بيئة اختبار ممثِّلة، وتسمّيها الفرق Staging أو ما قبل الإنتاج (pre-production) أو بيئة اختبار النظام. و«ممثِّلة» لا تعني «مطابقة»: أبقِ كل ما يؤثر في السلوك كما هو في الإنتاج، واجعل الفروق التي لا مفر منها مقصودة، وسجّل كل فرق.
- مطابق: حزمة البناء (build artefact) نفسها التي ستُصدَر، منشورةً بالسكربتات نفسها؛ وإصدارات نظام التشغيل وبيئة التشغيل (runtime) وقاعدة البيانات؛ والإعدادات مثل مفاتيح تفعيل الميزات (feature flags) والمنطقة الزمنية والمهام المجدولة.
- مختلف عن قصد، البيانات: بيانات اصطناعية، أو، حيث تسمح السياسة، نسخ مقنَّعة (masked) من بيانات الإنتاج تُستبدل فيها الأسماء وبيانات الاتصال وسائر البيانات الشخصية؛ وفي الحالتين بشكل وحجم واقعيين. ولا بيانات شخصية غير مقنَّعة لعملاء حقيقيين أبداً.
- مختلف عن قصد، الخدمات الخارجية: مزوّدو الدفع والرسائل القصيرة والبريد في بيئتهم التجريبية (sandbox) أو وضع الاختبار، أو تُحاكى، فلا تنتقل أموال حقيقية ولا تصل رسالة إلى عميل حقيقي. ويذكر منهج ISTQB أن محاكاة الأنظمة الفرعية ممكنة في هذا المستوى.
- مختلف غالباً، السعة: البيئة الأصغر تكشف العيوب الوظيفية، لكن نتائج الأداء فيها لا تنتقل مباشرة إلى الإنتاج.
- الحسابات: حساب اختبار لكل دور، مثل العميل ومنظّم الفعالية والمسؤول.
بيئة الإنتاج
عملاء حقيقيون ومدفوعات حقيقية ورسائل حقيقية
- البناء:
- الإصدار 2.3 كما يُسلَّم
- الإصدارات والإعدادات:
- نظام التشغيل وبيئة التشغيل ومحرك قاعدة البيانات والمنطقة الزمنية ومفاتيح الميزات والمهام المجدولة
- البيانات:
- عملاء وحجوزات ومدفوعات حقيقية
- الدفع والبريد والرسائل القصيرة:
- المزوّدون الفعليون
- السعة:
- العدد الكامل لخوادم التطبيق
- الحسابات:
- عملاء ومنظّمون ومسؤولون حقيقيون
بيئة اختبار النظامStaging أو ما قبل الإنتاج
ممثِّلة للإنتاج وآمنة للاختبار
- البناء:
- حزمة البناء نفسها، منشورةً بالسكربتات نفسها
- الإصدارات والإعدادات:
- نفسها؛ وأي تغيير فرقٌ يُسجَّل
- البيانات:
- اصطناعية أو مقنَّعة، بشكل وحجم واقعيينتنبيه
- الدفع والبريد والرسائل القصيرة:
- بيئات تجريبية أو محاكيات: لا أموال حقيقية ولا رسائل حقيقيةتنبيه
- السعة:
- نصف الخوادم: تُذكر نتائج الأداء مع حجم البيئةتنبيه
- الحسابات:
- حساب اختبار لكل دور
«تنبيه» يعني فرقاً مقصوداً عن الإنتاج: مقبول، لكنه يُكتب في تقرير الاختبار حتى تُقرأ النتائج قراءة صحيحة.
مثال تطبيقي: اختبارات النظام لموقع تذاكر فعاليات
للإصدار 2.3 من موقع لحجز التذاكر خمسة متطلبات. FR-1: يستطيع العميل المسجِّل دخوله حجز ما بين 1 و6 تذاكر لكل فعالية، وتصله تذكرة إلكترونية بالبريد. FR-2: تبقى مقاعد عملية الدفع غير المكتملة محجوزة مؤقتاً 10 دقائق ثم تُحرَّر. NFR-1: تُحمَّل خريطة المقاعد خلال ثانيتين في 95% من الطلبات مع 500 مستخدم متزامن. NFR-2: لا يرى العميل إلا حجوزاته. NFR-3: يعمل الموقع بالعربية والإنجليزية.
نجح اختبار التكامل، وأظهر اختبار الدخان (smoke test)، وهو تشغيل قصير لأهم الوظائف، أن الإصدار المرشَّح قابل للاختبار. فيصمّم المختبِر اختبارات النظام من المتطلبات، ويربط كلاً منها بمتطلب:
- ST-01 (FR-1، وظيفي): احجز مقعدين وادفع في وضع الاختبار ← يُؤكَّد الحجز وتصل تذكرة إلكترونية لمقعدين.
- ST-02 (FR-1، وظيفي): حاول حجز 7 تذاكر ← يُرفض الطلب برسالة واضحة ولا يُحجز شيء.
- ST-03 (FR-2، وظيفي): افتح صفحة الدفع ولا تدفع ← تعود المقاعد متاحة بعد 10 دقائق.
- ST-04 (NFR-1، أداء): 500 مستخدم افتراضي (virtual users)، تحاكيهم أداة اختبار حمل، يفتحون خريطة المقاعد ← 95% على الأقل من مرات التحميل خلال ثانيتين.
- ST-05 (NFR-2، أمان): العميل A يفتح رابط حجز العميل B ← يُرفض الوصول ولا تظهر أي بيانات.
- ST-06 (NFR-3، توطين): احجز بالعربية في متصفحين مدعومين ← تخطيط من اليمين إلى اليسار وتذكرة إلكترونية بالعربية.
جرّبها: المتطلبات ← حالات اختبار جرّبها: مولّد سيناريوهات الاختبار
قراءة النتائج
فشل ST-03: حُرِّرت المقاعد بعد ثلاث ساعات وعشر دقائق. فقد حفظ خادم الويب وقت بدء الحجز المؤقت بتوقيت الرياض المحلي (UTC+3) دون ذكر المنطقة الزمنية، وقرأته مهمة التحرير، على خادم مضبوط على UTC، على أنه بتوقيت UTC. كانت كل اختبارات المكوّنات ناجحة، ولم يُظهر الإخفاقَ إلا النظامُ كاملاً بعد نشره. ويذكر تقرير العيب البناء والبيئة وإعدادات الخادمين.
ونجح ST-04، لكن في البيئة نصف عدد خوادم الإنتاج، لذا يذكر التقرير ذلك بجانب النتيجة. ثم يعرض تقرير اختبار النظام النتائج لكل متطلب، والعيوب المفتوحة مع خطورتها (severity)، أي درجة تأثير كل منها، وفروق البيئة: وهو الدليل الذي يُبنى عليه قرار انتقال البناء إلى اختبار القبول.
أخطاء شائعة
- تنفيذ المسار الرئيسي وحده، كأنه عرض توضيحي، وإهمال المدخلات غير الصالحة ومعالجة الأخطاء.
- تأجيل اختبارات الأداء والأمان والتوافق إلى «لاحقاً»، بينما لا يترك موعد الإصدار وقتاً لذلك.
- الاختبار في بيئة تختلف عن الإنتاج دون تسجيل أوجه الاختلاف، أو إلقاء اللوم في كل فشل على «البيئة» دون تحقق.
- نسخ البيانات الشخصية لعملاء حقيقيين إلى بيئة الاختبار بدلاً من استخدام بيانات اصطناعية أو مقنَّعة.
- كتابة اختبارات نظام لا تذكر المتطلب الذي تغطيه، فلا يعرف أحد ما الذي لم يُختبر بعد.
من منظور ضمان الجودة
يبدأ اختبار النظام قبل وصول البناء. فالمختبِر يراجع متطلبات النظام من حيث قابليتها للاختبار، ويصمّم اختبارات النظام مع ربطها بالمتطلبات (التتبع)، ويتفق على البيئة مع المطورين أو مهندسي DevOps: البناء والإعدادات والبيانات والبيئات التجريبية والحسابات. ويتفق الفريق أيضاً على معايير الدخول، وهي عادةً نجاح اختبار التكامل واجتياز اختبار الدخان، وعلى معايير الخروج في خطة الاختبار.
أثناء التنفيذ، سجّل رقم البناء والبيئة وبيانات الاختبار في كل تشغيل، فإعادة إنتاج إخفاقات مستوى النظام صعبة من دونها. وارفع مبكراً ما لا تستطيع البيئة تغطيته، مثل دفعة حقيقية أو حمل بحجم الإنتاج، واتفق مع مالك المنتج على طريقة التعامل مع هذا الخطر.
تمرين عملي
خطّط اختبارات النظام لطلب بقالة عبر الإنترنت
تطبيق لطلب البقالة عبر الإنترنت جاهز لاختبار النظام. صمّم اختبار نظام واحداً على الأقل لكل متطلب أدناه مع نتيجته المتوقعة، وحدّد ما يجب أن توفره بيئة اختبار النظام.
R1 يستطيع العميل طلب ما يصل إلى 30 صنفاً والدفع بالبطاقة أو نقداً عند الاستلام.
R2 تصل العميلَ رسالة SMS عندما يخرج الطلب للتوصيل.
R3 لا يرى العميل إلا سجل طلباته.
R4 تستجيب صفحة الدفع خلال 3 ثوانٍ في 95% من الطلبات مع 300 مستخدم متزامن.
R5 التطبيق متاح بالعربية والإنجليزية.- صنّف كل متطلب: وظيفي أم غير وظيفي.
- اكتب اختبار نظام أو أكثر لكل متطلب، ومنها اختبار سلبي (negative test) للمتطلب R1: إدخال غير صالح يجب أن يُرفض.
- اكتب ما يجب أن توفره البيئة: البناء والبيانات والخدمات الخارجية والحسابات.
- سمِّ فرقاً واحداً عن الإنتاج ستسجّله في التقرير، وأي سؤال تتركه المتطلبات مفتوحاً.
إظهار الإجابة النموذجية
وظيفي: R1 وR2. غير وظيفي: R3 (الأمان)، وR4 (كفاءة الأداء)، وR5 (التوطين، وبعض الفرق تعدّه وظيفياً).
الاختبارات: 3 أصناف تُدفع ببطاقة اختبار في البيئة التجريبية لمزوّد الدفع ← يُؤكَّد الطلب بالإجمالي الصحيح؛ 30 صنفاً مع الدفع نقداً عند الاستلام ← يُؤكَّد الطلب؛ اختبار سلبي: الصنف رقم 31 ← يُرفض برسالة واضحة؛ يضع المتجر الطلب في حالة «خرج للتوصيل» ← تصل إلى هاتف الاختبار رسالة SMS برقم الطلب الصحيح؛ العميل A يفتح طلب العميل B ← يُرفض الوصول؛ 300 مستخدم افتراضي في صفحة الدفع ← 95% على الأقل من الاستجابات خلال 3 ثوانٍ؛ طلب كامل بكل لغة ← كل النصوص مترجمة والعربية من اليمين إلى اليسار.
البيئة: الإصدار المرشَّح منشوراً كما في الإنتاج؛ منتجات وعملاء اصطناعيون؛ البيئتان التجريبيتان لمزوّدَي الدفع والرسائل مع بطاقات اختبار وأرقام هواتف اختبار؛ حسابات لعميلين ولمشغّل متجر؛ وإعدادات المنطقة الزمنية واللغة نفسها التي في الإنتاج.
ما يُسجَّل: في البيئة خوادم أقل من الإنتاج، لذا تُذكر نتيجة R4 مع حجم البيئة. أسئلة مفتوحة: هل حدّ الـ30 يَعُدّ المنتجات المختلفة أم الوحدات (3 زجاجات من الماء نفسه)؟ وبأي لغة تُرسَل رسالة SMS؟
أسئلة شائعة
من ينفذ اختبار النظام؟
عادةً المختبِرون، وكثيراً ما يكون فريق اختبار مستقلاً، لأن هذا المستوى يقارن المنتج بمواصفاته ويستفيد من نظرة مستقلة عن الكود. ويدعمه المطورون ومهندسو DevOps ومحللو الأعمال بالإصلاحات والبيئات والإجابات عن المتطلبات. وفي الفرق الرشيقة (Agile) ينفذ مختبِرو الفريق اختبارات النظام عادةً خلال دورة العمل (sprint) وقبل الإصدار.
ما الفرق بين اختبار النظام واختبار القبول؟
اختبار النظام يفحص النظام مقابل متطلباته المحددة، وينفذه عادةً فريق التسليم، فهو في الأساس تحقق (Verification). أما اختبار القبول فيفحص هل يلبّي النظام احتياجات مستخدميه واحتياجات العمل، وكثيراً ما ينفذه المستخدمون أو ممثلو العميل، وينتهي بقرار قبوله، فهو في الأساس تحقق من الصلاحية (Validation). ويتناول الدرس التالي اختبار القبول.
هل اختبار النظام هو نفسه الاختبار من طرف إلى طرف (End-to-End)؟
ليس تماماً، وإن كانت بعض الفرق تستخدم المصطلحين للشيء نفسه. اختبار النظام مستوى اختبار يحدده موضوعه، أي نظام واحد كامل، وأساسه، أي متطلبات النظام. أما الاختبار من طرف إلى طرف فيتبع رحلات مستخدم كاملة، كثيراً ما تمر عبر عدة أنظمة، ويمكن أن يجري أثناء اختبار النظام أو اختبار تكامل الأنظمة أو اختبار القبول. ويقارن بينهما درس الاختبار من طرف إلى طرف.
هل يمكن أتمتة اختبارات النظام؟
جزئياً. فالفحوص المستقرة التي تتكرر في كل إصدار، عبر الواجهة البرمجية أو واجهة المستخدم، واختبارات الأداء مرشّحة جيدة للأتمتة. أما الجلسات الاستكشافية وأحكام قابلية الاستخدام والفحوص التي تُجرى مرة واحدة فتكون يدوية عادةً. ومعظم الفرق تجمع بين الاثنين.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelنموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsالمعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
تدرّب بأدوات متقن
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
اشتق سيناريوهات اختبار من المتطلبات الوظيفية مع خريطة للتغطية.
ولّد سيناريوهات اختبار عالية المستوى تغطي الجوانب الوظيفية والسلبية والأمنية وسهولة الاستخدام والتوافق لأي ميزة.
مصنع متكامل لبيانات الاختبار الاصطناعية: مستخدمون وعملاء وشركات وعناوين وأرقام وتواريخ وسلاسل نصية بصيغة JSON أو CSV أو SQL أو XML.
ولّد سجلات مستخدمين وهمية (الاسم واسم المستخدم والبريد الإلكتروني وكلمة المرور وبذرة الصورة الرمزية والدور) لحسابات الاختبار.
للتعمّق أكثر
- ضمان جودة المنتج من البداية إلى النهايةمستويات الاختبار: الوحدة والتكامل والنظام والقبول
- ضمان جودة المنتج من البداية إلى النهايةبيانات الاختبار والبيئات
- كيف تكتب خطة اختبار (Test Plan)معايير الدخول والخروج والتعليق والاستئناف
- ما هو اختبار الأداء؟شرح اختبار الأداء: الفرق بين اختبارات الحمل والإجهاد والذروة المفاجئة والتحمّل، والمقاييس المهمة (p95 والإنتاجية ومعدل الأخطاء)، والتخطيط لأول اختبار، والأدوات.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.