ما المقصود باختبار النظام؟

تخيَّل أنك تنظر إلى نظام برمجي تحت المجهر، بدءًا من أعلى مستوى تكبير ممكن، مع التركيز على الوحدة. هذه هي الوحدة الأساسية لبناء النظام البرمجي. ثم تتسع الرؤية لتشمل المستوى التالي من التكبير - الوحدات النمطية التي تم إنشاؤها بواسطة تلك الوحدات الفردية. وأخيرًا، عند تكبير الصورة بالكامل، تصل إلى مستوى النظام. عند هذا المستوى من التكبير، يمكنك رؤية كل ما يحتويه النظام وكيفية تعاون جميع العناصر التي أنشأتها تلك الوحدات البرمجية معًا.

بطرق معينة، يشبه اختبار النظام تلك الرؤية المجهرية - مع وجود اختلاف جوهري. يُعَد اختبار النظام شكلًا من أشكال الاختبار الصندوق الأسود، ما يعني أن المختبِرين يهتمون أقل بعناصر النظام وطريقة تجميعها، ويركِّزون بشكل أكثر على الوظائف العامة للنظام. من هذا المنظور القائم على "النجاح/الفشل"، يصبح سلوك النظام جديرًا بالملاحظة فقط بقدر ما يتعلق بأداء النظام. يُتيح اختبار الصندوق الأبيض رؤية أكبر لطبيعة العناصر داخل النظام.

غالبًا ما يتضمن اختبار النظام تحليل عدة أنظمة برمجية منفصلة قد تعمل معًا أو لا تعمل في تناغم ضمن نظام برمجي معين.

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

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

يتم تظليل كل استعلام وفقًا لوظائف النظام:

• هل يعمل كل عنصر كما هو متوقع؟

• هل تعمل العناصر بالتنسيق الصحيح مع بعضها؟

• هل البرنامج مستعد لدعم واجهة مستخدم سلسة وتقديم تجربة المستخدم (UX) المطلوبة؟

عند مناقشة اختبار النظام، سنواجه بطبيعة الحال موضوع التبعيات، وهي العلاقات الموجودة في حالات الاختبار. في مثل هذه المواقف، قد تعتمد نتيجة حالة اختبار واحدة جزئيًا أو كليًا على نتائج حالات اختبار أخرى. يمكن أن تتضمن التبعيات أيضًا الوظائف أو بيئات الاختبار أو سياسات الأمان، ويمكن أن تؤثِّر حتى في عملية الاختبار بأكملها التي تحتفظ بها المؤسسة.

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

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

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

تهدف عملية الاختبار إلى عكس بيئة الإنتاج نفسها التي سيتم استخدامها، لضمان وظائف البرنامج حسب الحاجة على الرغم من الظروف المتغيّرة في العالم الحقيقي. وبالمثل، يتم إنشاء بيانات الاختبار لمحاكاة البيانات والظروف الواقعية. بمجرد إجراء حالات الاختبار، يمكن تحديد العيوب الموجودة في البرنامج وإصلاحها.

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

• اختبار القبول: يهدف اختبار قبول المستخدم إلى تضمين اختبارات الأداء التي يُجريها الأشخاص الذين يمثِّلون الفئة المستهدفة من مستخدمي البرنامج قيد الإنتاج. يُضفي هؤلاء المستخدمون مزيدًا من الواقعية على عملية الاختبار من خلال اختبار البرنامج في ظروف واقعية.

• اختبار التكامل: يُعَد أحد المجالات المهمة للغاية في الاختبار الوظيفي ويتولى دراسة مدى "توافق" الوحدات أو العناصر المختلفة معًا عند إجبارها على العمل في انسجام وثيق. ويُعرَف باسم اختبار تكامل النظام. يوفر النظام المتكامل بالكامل للمختبِرين القدرة على تقييم التفاعلات الرئيسية.

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

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

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

يوفر اختبار النظام غير الوظيفي وسيلة لتقييم كيفية عمل النظام. يمكن تلخيص الفرق الأساسي بين الاختبار الوظيفي والاختبار غير الوظيفي في المقارنة البسيطة التالية:

• الاختبار الوظيفي: هل يعمل النظام؟

• الاختبار غير الوظيفي: هل يعمل النظام بشكل جيد؟

ومع وضع ذلك في الاعتبار، إليك بعض الأشكال الرئيسية للاختبار غير الوظيفي للنظام:

• اختبار إمكانية الوصول: هل المحتوى الرقمي المعروض متاح للجميع، بما في ذلك الأشخاص ذوو الإعاقات المختلفة؟ يسعى اختبار إمكانية الوصول إلى التحقيق في هذا السؤال ويعمل على ضمان توصيل المحتوى إلى جميع المستخدمين المحتملين، بطرق تتجاوز الإعاقات الجسدية والعقلية وتضمن التوافق مع معايير الإدماج التي وضعها قانون الأمريكيين ذوي الإعاقة (ADA).

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

• اختبار التحميل: في فرع متخصص يتناول الخصائص الفريدة لمفهوم التحميل وكيف يؤثِّر في قدرة النظام على معالجة الطلبات، يركِّز اختبار التحميل على ما يحدث عندما يحدث التوسع على نطاق واسع جدًا. نحن نفترض أن النظام لن يواجه أي مشكلة في معالجة طلب نظام واحد، ولكن ماذا لو تم ضرب هذا الحمل بآلاف الطلبات - أو حتى أكثر من ذلك بكثير؟

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

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

• اختبار الأمن: لا يخفى على أحد أن أمن البيانات أصبح اليوم ذا أهمية قصوى. ومن ثمّ، فمن المنطقي أن يستهدف أحد أشكال الاختبار الأمن على وجه التحديد. يتم اختيار طرق اختبار الأمن وفقًا لنوع التهديدات المحتملة التي تتلقاها الشركة.

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

• اختبار قابلية الاستخدام:هذا النوع من الاختبارات غير الوظيفية يتعلق بالكامل بجودة تجربة المستخدم (UX). يُعَد اختبار قابلية الاستخدام عملية اختبار يدوية يتم استخدامها عمليًا على نطاق صغير. ومع ذلك، ربما ينبغي تطبيقه بشكل متكرر - خاصةً عند تنفيذ تحركات معقدة مثل توطين التطبيقات.

هناك أنواع أخرى من اختبار النظام مفيدة على الرغم من أنها لا تندرج تحت فئات الاختبارات الوظيفية أو غير الوظيفية. وفيما يلي بعض من أبرز هذه المنهجيات:

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

• الاختبار الآلي: كما يوحي اسمه، فإن الاختبار الآلي (ويُعرَف أيضًا باسم الأتمتة) يوفر قوة الأتمتة لاختبار التطبيقات البرمجية. يتم ذلك من خلال إنشاء واستخدام نصوص اختبار مصممة لتنفيذ حالات الاختبار على التطبيقات البرمجية، ويتم ذلك على نطاق واسع جدًا ودون تدخل بشري. تُعرَف مجموعات الإرشادات والأدوات والممارسات المنظمة التي تساعد على أتمتة عملية الاختبار باسم "أطر العمل".

• الاختبار اليدوي:على النقيض المباشر للاختبار الآلي، يعتمد الاختبار اليدوي على الاختبار البشري للتجربة على البرنامج الذي يتم تقييمه، وفقًا لتوجيهات سيناريوهات الاختبار المختلفة والنصوص البرمجية للاختبار. يتم تشجيع المختبِرين على وضع البرنامج تحت الاختبار لتحديد المشكلات التي تحتاج إلى علاج.

• اختبار الترحيل:تحتاج المؤسسات التي تعمل على تحديث أو تحويل ثقافتها الرقمية المؤسسية إلى اختبار الترحيل. عندما تشارك الشركات في مثل هذه الجهود التحويلية، فإنها تحتاج إلى التحقق من أن البيانات والبرامج الرئيسية يتم نقلها بشكل صحيح من نظام خارجي إلى نظام داخلي.

• اختبار الانحدار: في حين أن تغييرات الكود تهدف إلى تحسين البرنامج أو تعزيز قدراته، فإنها قد تؤدي عن غير قصد إلى إدخال صعوبات إذا تمت إضافة الخطأ البشري بطريقة أو بأخرى إلى المزيج. تُتيح اختبارات الانحدار للمختبِرين التأكد من التشغيل الثابت والصحيح من خلال إعادة تشغيل الاختبارات حسب الحاجة.

على الرغم من أن عملية اختبار النظام توفِّر اختبار الأداء الشامل المتاح، فإن إجراء اختبار النظام ليس خاليًا من المشكلات المحتملة: