اختبار الحمل

لماذا يهم

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

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

الحمل المتوقع: الرقم الذي تختبر عنده

الحمل المتوقع هو الحركة التي يجب أن يتحمّلها النظام، ويُوصف بنموذج عبء العمل (Workload model) من درس المستخدمين المتزامنين ونماذج عبء العمل: أيّ المعاملات، وبأيّ مزيج، وبأيّ معدل. ثبّته قبل كتابة السكربت، وسجّل مصدر كل رقم.

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

جرّبها: مولّد بيانات اختبار الأداء

مخطط الحمل: الصعود التدريجي والحالة المستقرة والهبوط التدريجي

يصف مخطط الحمل (Load profile) كيف يتغيّر الحمل المطبّق مع الزمن. ومن مراحله الثلاث، واحدة فقط هي مرحلة القياس. وفي مثال المتجر: صعود إلى ⁦120⁩ طلباً في الثانية خلال ⁦10⁩ دقائق، ثم ثبات ⁦30⁩ دقيقة، ثم هبوط خلال ⁦5⁩ دقائق.

• الصعود التدريجي (Ramp-up): يرتفع الحمل تدريجياً كما تفعل الحركة الحقيقية، بينما تصل الذاكرة المؤقتة ومجمّعات الاتصالات والتوسع التلقائي إلى وضعها المعتاد. والبدء بالحمل الكامل يصنع ذروة مفاجئة لم يطلبها أحد، ويقيس نظاماً بارداً.
• الحالة المستقرة (Steady state): يُثبَّت الحمل عند الهدف. ويكون النظام مستقراً عندما تساوي الإنتاجية (Throughput) الحمل المطبّق وتبقى أزمنة الاستجابة واستهلاك الموارد ثابتة؛ أما زمن استجابة يواصل الارتفاع والحمل ثابت فيعني أن العمل يتراكم في طابور، وهذه نتيجة تُسجَّل. ثبّت الحمل مدة تكفي لعينات كثيرة من كل معاملة، وهي عادةً عشرات الدقائق؛ أما التشغيل لساعات طويلة فهو اختبار التحمّل (Soak Testing).
• الهبوط التدريجي (Ramp-down): يعود الحمل إلى الصفر، ويجب أن تعود أزمنة الاستجابة والطوابير واستهلاك الموارد إلى خط الأساس. فالنظام الذي يبقى بطيئاً بعدها لم يتعافَ.

جرّبها: مولّد اختبارات الطلبات المتزامنة

معايير النجاح: يُتفق عليها قبل التشغيل

معايير النجاح (Pass criteria) هي ما يمنح اختبار الحمل نتيجته المتوقعة. وتأتي من المتطلبات غير الوظيفية أو أهداف مستوى الخدمة (SLO) أو معايير القبول، وتغطي خاصية كفاءة الأداء في ISO/IEC 25010 (السلوك الزمني، واستخدام الموارد، والسعة)، ويُتفق عليها مع مالك المنتج والمطورين قبل التشغيل الأول، لا بعد رؤية الأرقام.

• زمن الاستجابة لكل معاملة بالمئينات (Percentiles): ⁦p95 ≤ 300 ms⁩ للبحث و⁦p95 ≤ 800 ms⁩ لإتمام الشراء.
• معدل الأخطاء: استجابات HTTP ⁦5xx⁩ واستجابات ⁦4xx⁩ غير المتوقعة وانتهاء المهلة وأخطاء الاتصال وفحوص المحتوى الفاشلة، أقل من ⁦0.5%⁩ مثلاً.
• الإنتاجية المتحققة: ⁦95%⁩ على الأقل من الحمل المخطط البالغ ⁦120⁩ طلباً في الثانية. فالتشغيل الذي لم يبلغ الهدف لا يثبت شيئاً عنه.
• سقوف للموارد تحفظ هامش أمان، مثل استخدام معالج قاعدة البيانات أقل من ⁦75%⁩.
• صلاحية الاختبار نفسه: لم يكن مولّد الحمل (Load generator) مُثقلاً (المعالج أقل من ⁦80%⁩)، وفُحص محتوى الاستجابات لا رمز الحالة ⁦200⁩ وحده.
• النافذة: احكم على الحالة المستقرة فقط. فأدوات الحمل كثيراً ما تحسب عتباتها المدمجة على كل العينات، بما فيها مرحلتا الصعود والهبوط، لذا اقتصر أولاً على عينات نافذة الحالة المستقرة.

التخطيط لاختبار الحمل وتنفيذه

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

• الخطة: النطاق، والمعاملات ومزيجها، ومستويات الحمل، ومخطط الحمل، ومعايير النجاح، ومعايير الإيقاف، مثل «توقّف إذا تجاوزت الأخطاء ⁦5%⁩ لمدة دقيقتين».
• البيئة والبيانات: حجم وإعدادات تشبه الإنتاج، دون مشاركة أثناء التشغيل، مع المراقبة؛ وما يكفي من المستخدمين والمنتجات المختلفة لتتصرف الذاكرة المؤقتة والقيود الفريدة بواقعية؛ ومزوّدو الدفع والرسائل النصية بمحاكاة أو في بيئاتهم التجريبية (Sandbox).
• الإذن: لا تطبّق الحمل إلا على أنظمة تملكها أو لديك إذن مكتوب باختبارها، ومن أجهزة توليد حمل منفصلة، وأبلغ فريق العمليات قبل البدء.
• التشغيل التمهيدي (Smoke run) ثم الكامل: مستخدم افتراضي أو اثنان لبضع دقائق يثبتان أن السكربت يسجّل الدخول ويستخدم البيانات ويتلقى استجابات صحيحة؛ ثم خط أساس بحمل منخفض، ثم مخطط الحمل كاملاً وأنت تراقب لوحات المتابعة.
• التقييم والتكرار: احكم على الحالة المستقرة، وكرّر التشغيل لتتأكد أن النتيجة قابلة للتكرار، وسجّل نسخة البناء والإعدادات والبيانات والنافذة الزمنية.

جرّبها: مولّد بيانات اختبار التحميل جرّبها: محلّل زمن الاستجابة جرّبها: قياس أداء طلبات HTTP

مثال تطبيقي: متجر إلكتروني قبل موسم التخفيضات

يُختبر الإصدار ⁦4.2⁩ قبل موسم تخفيضات. الذروة المتوقعة ⁦100 × 1.2 = 120⁩ طلباً في الثانية: ذروة العام الماضي مضروبة في معامل النمو. الخطة ونتائج التشغيل الأول في الكتلة أدناه، ويقرؤها المختبِر بهذا الترتيب:

• الصلاحية أولاً: تحققت إنتاجية ⁦119.6⁩ طلباً في الثانية، وكان مولّد الحمل عند ⁦41%⁩ من المعالج، فيمكن الوثوق بالأزمنة.
• المعايير: ينجح البحث ومعدل الأخطاء؛ ويفشل إتمام الشراء، إذ بلغ ⁦p95⁩ لديه ⁦1,140⁩ مللي ثانية مقابل ⁦800⁩.
• الاتجاه: بدأ ⁦p95⁩ لإتمام الشراء قرب ⁦600⁩ مللي ثانية وارتفع كل دقيقة والحمل ثابت، أي أن طلبات إتمام الشراء كانت تتراكم في طابور.
• الإبلاغ والتأكيد: تقرير عيب يذكر مستوى الحمل والنافذة والمقياس والرسوم البيانية ونسخة البناء. ويتتبّع المطورون السبب إلى مجمّع اتصالات قاعدة البيانات في خدمة إتمام الشراء، وسقفه ⁦20⁩ اتصالاً؛ وبعد الإصلاح يُعاد تشغيل المخطط نفسه بالبيانات نفسها (اختبار التأكيد) وتُقارن النتائج بالتشغيل الأول.

Load test plan: online store, release 4.2, perf environment
Expected peak:  100 req/s (busiest hour last year) x 1.2 growth = 120 req/s
Mix:            search 70 %, product page 20 %, checkout 10 %
Profile:        ramp-up 0 -> 120 req/s in 10 min, steady state 30 min
                (minutes 10-40), ramp-down 5 min
Pass criteria:  search p95 <= 300 ms, checkout p95 <= 800 ms,
                error rate < 0.5 %, throughput >= 114 req/s
Validity:       load generator CPU < 80 %, response content checked

Run 1, steady state (min 10-40)   Target      Result      Verdict
  throughput                      >= 114      119.6       pass
  search p95                      <= 300 ms   210 ms      pass
  checkout p95                    <= 800 ms   1,140 ms    fail
  error rate                      < 0.5 %     0.2 %       pass
  load generator CPU (max)        < 80 %      41 %        valid

أسئلة شائعة

المراجع

• Certified Tester Performance Testing (CT-PT)ISTQB · 2018منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Load test types — Grafana k6 documentationGrafana Labsتعريفات أنواع اختبار الحمل الشائعة — الاختبار الدخاني والحمل المتوسط والإجهاد والتحمّل الطويل (Soak) والذروة المفاجئة (Spike) ونقطة الانكسار — وما يُراد من كلٍّ منها كشفه.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.