الاختبار والتحقق وضمان الجودة

الاختبار غير الوظيفي

18 دقيقة الدرس 8 من 10

الاختبار غير الوظيفي

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

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

منظور المحلل في الجودة غير الوظيفية

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

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

اختبار الأداء

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

يُطبّق اختبار الحمل حمل الإنتاج المتوقع — عدد المستخدمين المتزامنين ومعدل المعاملات وحجم البيانات — ويتحقق من أن النظام يستوفي أهداف وقت الاستجابة في ظروف التشغيل الاعتيادية. في متجر إلكتروني قد يكون المطلب: "يجب أن تكتمل 95% من طلبات البحث عن المنتجات خلال 1.5 ثانية عند وجود 500 مستخدم نشط في آنٍ واحد".

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

يُشغّل اختبار التحمل النظام بحمل معتدل مستمر لفترة طويلة — غالبًا 24-72 ساعة — للكشف عن تسرّب الذاكرة البطيء واستنفاد اتصالات قاعدة البيانات وتضخم ملفات السجل الذي لا يظهر إلا مع مرور الوقت.

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

دور المحلل في اختبار الأداء ليس تشغيل سكريبتات اختبار الحمل — ذلك عمل مهندس الأداء. دوره هو استخلاص متطلبات الأداء المحددة كميًا خلال مرحلة الاستكشاف ("ما أقصى وقت انتظار مقبول لنتيجة البحث؟")، وتوثيقها في وثيقة المتطلبات كمعايير قبول قابلة للقياس، والمشاركة في مراجعة النتائج مقابل تلك المعايير عند اكتمال الاختبار.

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

Performance Testing Types and Their Load Profiles Performance Testing Types — Load Profiles Load (Users) Load Test SLA limit Sustained normal load Stress Test break point Push past capacity Soak Test 24 – 72 hours sustained Spike Test Sudden traffic surge Time → What Each Test Targets Load: Response time & throughput meet SLA at expected concurrency Stress: Failure mode and recovery behaviour under overload Soak: Memory leaks, connection exhaustion, log growth over time Spike: Auto-scaling, queuing, or graceful degradation under sudden surges
أنواع اختبار الأداء الأربعة الرئيسية وأنماط الفشل المتميزة التي يكشفها كل منها.

اختبار الأمان

يتحقق اختبار الأمان من أن النظام يحمي بياناته ووظائفه من الوصول غير المصرح به والتلاعب والإفصاح. بالنسبة للمحلل، تظهر متطلبات الأمان خلال الاستخلاص كقيود على السرية والنزاهة والتوافر — ثالوث CIA الكلاسيكي. ويجب أن تتحقق استراتيجية الاختبار من تطبيق تلك القيود.

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

يتحقق اختبار التحقق من المدخلات والحقن من أن كل نقطة يقبل فيها النظام مدخلات المستخدم مقاومة لهجمات حقن SQL وXSS وحقن الأوامر والهجمات المشابهة. هذا ذو صلة خاصة بالمحللين لأن متطلبات التحقق الضعيفة ("يجب أن يقبل النظام مدخلات المستخدم") غالبًا ما تفتح هذه الثغرات.

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

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

اختبار الأمان ليس اختياريًا للأنظمة التي تتعامل مع البيانات الشخصية. تفرض لوائح مثل GDPR وHIPAA وPCI-DSS التزامات قانونية على المنظمات التي تعالج البيانات الشخصية أو الصحية أو المتعلقة بالدفع. عدم اختبار ضوابط الأمان قبل الإطلاق ليس مجرد مخاطرة تقنية — بل قد يُفضي إلى غرامات تنظيمية وأضرار بسمعة المنظمة ومسؤولية قانونية. يجب على المحلل إبراز هذه الالتزامات خلال مراحل الجدوى والمتطلبات، لا بعد اكتمال التطوير.

اختبار قابلية الاستخدام

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

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

المقاييس الرئيسية التي يُسجّلها اختبار قابلية الاستخدام:

  • معدل إتمام المهمة — نسبة المستخدمين الذين أتموا كل مهمة بنجاح
  • الوقت المستغرق في المهمة — كم يستغرق المستخدم الممثل لإتمام كل مهمة؛ يُقارن بهدف الكفاءة المحدد
  • معدل الخطأ — عدد الأخطاء غير القابلة للتعافي لكل مهمة؛ معدل يتجاوز 10% في مهمة حرجة يُعدّ نتيجة خطيرة
  • مقياس قابلية الاستخدام للنظام (SUS) — استبيان قياسي مؤلف من عشرة أسئلة يُعطى بعد الجلسة ويُنتج نتيجة من 0 إلى 100؛ تُعدّ النتيجة التي تتجاوز 68 مقبولة وفق المعيار الصناعي
  • الامتثال لإمكانية الوصول — مدى استيفاء النظام لمعايير WCAG 2.1 AA للمستخدمين ذوي الإعاقات، وهو متطلب قانوني في كثير من الولايات القضائية
Non-Functional Testing — Analyst Responsibility Map Analyst Responsibilities Across Non-Functional Test Types Analyst Activity Performance Security Usability Elicit & quantify requirements ✔ Response time SLA ✔ CIA constraints ✔ Task & SUS targets Define acceptance criteria ✔ Load conditions ✔ Pen-test scope ✔ Task scenarios Participate in test review ✔ Review results vs SLA ✔ Triage findings ✔ Observe sessions Raise defects / drive fixes ✔ Block if SLA missed ✔ Severity rating ✔ Prioritise redesign Who executes? Performance engineers (JMeter, k6, Gatling) Security specialists (OWASP ZAP, Burp Suite) UX researchers (+ real end-users)
ما يملكه المحلل مقابل ما ينفذه المتخصصون عبر مجالات الاختبار غير الوظيفي الثلاثة.

كتابة معايير القبول غير الوظيفية

أكثر المهارات العملية التي يطوّرها المحلل في هذا المجال هي كتابة معايير قبول دقيقة بما يكفي للاختبار. يستخدم القالب المفيد البنية: بالنظر إلى [ظرف الحمل/السياق]، عندما [الإجراء]، إذن [النتيجة القابلة للقياس].

الأداء: بالنظر إلى 500 مستخدم متزامن خلال ساعات الذروة في أيام الأسبوع، عندما يُرسل مستخدم استعلام بحث عن منتج، يجب أن تُعاد 95% من الردود خلال 1.5 ثانية ولا يتجاوز أي رد 4 ثوانٍ. الأمان: بالنظر إلى أي مستخدم موثق دون دور المالية، عندما يحاول الوصول إلى نقطة نهاية /reports/revenue (مباشرةً أو بالتلاعب بالعنوان), يجب أن يُعيد النظام HTTP 403 ويسجّل محاولة الوصول غير المصرح به. قابلية الاستخدام: بالنظر إلى مستخدم يستخدم النظام لأول مرة وأتم جولة التعريف، عندما يحاول تقديم أمر شراء جديد، يجب أن يُتم ما لا يقل عن 80% من المستخدمين الممثلين المهمة خلال 4 دقائق بخطأ ملاحي واحد على الأكثر.
أشرك أصحاب المصلحة عند تحديد العتبات. يجب أن تأتي أهداف الأداء من السياق التجاري: بوابة حجز مرضى يستخدمها موظفو الاستقبال الذين يعالجون 30 مكالمة في الساعة لديها تسامح مختلف مع زمن الاستجابة مقارنةً بكشك الخدمة الذاتية في غرفة الانتظار. يجب التحقق من مستويات خطورة الأمان مع الفريق القانوني أو التوافق. يجب تحديد أهداف قابلية الاستخدام مقارنةً بالمنافسين أو الأداء الأساسي للنظام الحالي — لا أن تُخترع تعسفيًا من قِبل المحلل.

دمج الاختبار غير الوظيفي في دورة حياة المشروع

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

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