الوحدة 16 · اختبار الأداء

اختبار الإجهاد

بقلم فريق ضمان الجودة في متقن سوفت · · 21 دقيقة · متوسط

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

مثال: نجحت واجهة الطلبات في صيدلية إلكترونية في اختبار الحمل عند الذروة المتوقعة البالغة ⁦200⁩ طلب في الثانية. يبدأ اختبار الإجهاد من هناك ويضيف ⁦50⁩ طلباً في الثانية كل خمس دقائق. عند ⁦400⁩ لا تخدم الواجهة إلا نحو ⁦380⁩ وتظهر أولى حالات انتهاء المهلة (Timeout)؛ وعند ⁦500⁩ تنفد ذاكرة أحد مثيلات التطبيق فيُعاد تشغيله. ثم يُخفَّض الحمل إلى ⁦200⁩ مرة أخرى لمعرفة ما إذا كان النظام يتعافى من تلقاء نفسه.

لماذا يهم

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

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

ما بعد الذروة المتوقعة: ملف الإجهاد

يبدأ اختبار الإجهاد حيث انتهى اختبار الحمل. الذروة المتوقعة هي الخط المرجعي؛ ويتجاوزها ملف الإجهاد عمداً ويواصل الصعود حتى ينهار النظام أو تُنهي قاعدة الإيقاف التشغيل. ولأن النتيجة هي «أين وكيف» لا «نجاح أم فشل»، تحمل الخطة أهداف اختبار الحمل بوصفها معيناً على القراءة، إضافةً إلى قاعدة إيقاف تحمي البيئة، مثل «أوقف التشغيل حين تتجاوز الأخطاء ⁦20%⁩ لمدة دقيقة أو ينهار مثيل».

  • خطوات لا قفزة واحدة: ارفع الحمل على خطوات متساوية واثبت عند كل خطوة حتى تستقر المقاييس، مثلاً ⁦+25%⁩ من الذروة المتوقعة كل خمس دقائق. كل خطوة اختبار حمل صغير، والخطوة التي يتغيّر عندها سلوك أحد المقاييس هي النتيجة. الصعود المتصل أسرع لكنه يطمس موضع التغيّر.
  • أكّد الذروة أولاً: تكرر الخطوة الأولى الذروة المتوقعة، ويجب أن تطابق أرقامها اختبار الحمل. والنظام غير السليم عند الذروة أصلاً لديه نتيجة من اختبار الحمل، لا من اختبار الإجهاد.
  • الإجهاد بإنقاص الموارد: أبقِ الحمل المتوقع وأزل بعض الموارد بدلاً من رفع الحمل. أخرج مثيلاً من ثلاثة، أو خفّض حد الذاكرة إلى النصف، أو قيّد عرض النطاق الشبكي (Bandwidth). هذا هو النصف الثاني من تعريف ISTQB، وهو تماماً ما يبدو عليه خادم متعطل في ساعة الذروة في بيئة الإنتاج.
  • التسمية: تسمّي وثائق Grafana k6 التشغيل الذي يواصل الصعود حتى يُخفق النظام «اختبار نقطة الانهيار» (Breakpoint Test)، وتستخدم «اختبار الإجهاد» لتشغيل يثبت فوق الحمل المتوسط. أما ISTQB فيغطي الحالتين باختبار الإجهاد؛ فاكتب في الخطة الملف الذي تقصده.

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

التعرّف على نقطة الانهيار ونمط الإخفاق

نقطة الانهيار (Breaking Point) هي الحمل الذي لا يخدم النظام بعده ما يُرسل إليه. ونادراً ما تعلن عن نفسها بانهيار. اقرأ مقاييس درس مقاييس الأداء معاً، خطوة بخطوة: الإنتاجية (Throughput) وزمن الاستجابة ومعدل الأخطاء واستخدام الموارد؛ وابحث عن اللحظة التي تتوقف فيها عن التحرك بالتوازي: الحمل يواصل الارتفاع، لكن الإنتاجية لا تواصله.

  • التشبع: تستوي الإنتاجية بينما يرتفع الحمل المطبَّق، ويتكدّس الفارق في قائمة انتظار ما. وزمن الاستجابة الذي كان ينمو ببطء حتى ذلك الحين يرتفع الآن بحدة، لأن كل طلب ينتظر خلف الطلبات التي قبله.
  • الأخطاء تحل محل الاستجابات: انتهاء المهلة عند البوابة (504)، ورفض الاتصالات، و503 Service Unavailable، وأخيراً إخفاقات ليست من HTTP أصلاً: مثيل يُقتل لاستهلاكه ذاكرة مفرطة، أو قاعدة بيانات ترفض اتصالات جديدة، أو قرص امتلأ بالسجلات.
  • المورد الذي نفد أولاً: المعالج عند ⁦100%⁩، أو مجمّع اتصالات مشغول بالكامل، أو مجمّع خيوط مستنفَد، أو ذاكرة تنمو حتى تُقتل العملية. والمجمّع (Pool) عدد ثابت من اتصالات قاعدة البيانات أو خيوط العمل يُعاد استخدامها؛ وحين تنشغل كلها تنتظر الطلبات الجديدة. هذا هو الاختناق (Bottleneck)، والحقيقة التي يحتاج إليها المطور أكثر من غيرها.
  • نمط الإخفاق (Failure Mode)، الرشيق: يتباطأ النظام ويرفض الفائض بسرعة وصراحة (503 مع ترويسة Retry-After التي تخبر العميل متى يعيد المحاولة، أو قائمة انتظار محدودة، أو نتيجة مختصرة بدل صفحة خطأ) ويواصل خدمة الحمل الذي يستطيعه. ويُسمّى رفض الفائض عمداً إسقاط الحمل الزائد (Load Shedding). والكارثي: يتجمّد أو ينهار أو يُسقط معه خدمات أخرى، وهو الإخفاق المتتالي (Cascading Failure) الذي كثيراً ما تضخّمه إعادات المحاولة من التطبيقات العميلة، أو يقبل عملاً ثم يفقده.
  • سجّل لكل خطوة: الحمل المرسَل، والإنتاجية المخدومة، وp95 وp99، ومعدل الأخطاء حسب النوع، والمورد المتشبع، ودقيقة أول عَرَض. نقطة الانهيار مستوى حمل له قصة، لا رقم واحد.

جرّبها: مرجع رموز حالة HTTP

التعافي: ما يحدث حين ينخفض الحمل

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

  • زمن التعافي: الدقائق من انخفاض الحمل حتى يعود p95 ومعدل الأخطاء واستخدام الموارد إلى خط أساس اختبار الحمل. والنظام الذي يبقى بطيئاً عند الحمل الطبيعي لم يتعافَ: قائمة انتظار ما زالت تُفرَغ، أو مجمّع ما زال يتسرّب، أو مثيل لم يعد قط.
  • تلقائي أم يدوي: المثيلات المنهارة يُعاد تشغيلها، وقواطع الدارة (Circuit Breakers)، وهي مفاتيح توقف الاستدعاءات إلى اعتمادية متعطلة لبعض الوقت، تُغلق من جديد، وتُستأنف الحركة دون إعادة تشغيل يدوية أو تفريغ يدوي لذاكرة التخزين المؤقت. وكل خطوة يدوية نتيجة، لأن أحداً لن يتخذها في الثانية فجراً.
  • الأعمال المتراكمة: العمل المنتظر، مثل رسائل البريد والإشعارات وتأكيدات الدفع وفهرسة البحث، يُعالَج مرة واحدة، فلا يُسقَط ولا يُكرَّر، وتصل قائمة الانتظار إلى الصفر خلال وقت متفق عليه.
  • سلامة البيانات: قارن ما قبله النظام بما سجّله؛ والمعرّفات الفريدة للطلبات أو المستخدمين في بيانات الاختبار تسهّل مطابقة القائمتين. الطلبات المؤكدة للمستخدم دون سجل دفع، والصفوف نصف المكتوبة، والتكرارات الناتجة عن طلبات أُعيدت محاولتها هي أغلى نتائج الإجهاد، ولا يظهرها أي رسم لزمن الاستجابة.

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

مثال تطبيقي: واجهة طلبات دُفعت فوق ذروتها على خطوات

نجحت واجهة طلبات الصيدلية (الإصدار ⁦5.1⁩، ثلاثة مثيلات تطبيق، قاعدة بيانات واحدة) في اختبار الحمل عند الذروة المتوقعة البالغة ⁦200⁩ طلب في الثانية بقيمة p95 تساوي ⁦620⁩ مللي ثانية مقابل هدف ⁦800⁩ مللي ثانية. ويضيف تشغيل الإجهاد أدناه ⁦50⁩ طلباً في الثانية كل خمس دقائق، ويتوقف حين تتجاوز الأخطاء ⁦20%⁩ لمدة دقيقة أو ينهار مثيل، ثم يثبت عند ⁦200⁩ طلب في الثانية لمدة خمس عشرة دقيقة. ويقرأه المختبِر بهذا الترتيب:

  • أول تجاوز للهدف عند ⁦350⁩: p95 عند ⁦1,250⁩ مللي ثانية ومجمّع اتصالات قاعدة البيانات مشغول بـ⁦48⁩ من ⁦50⁩ اتصالاً. هذا هو الحد الأول، وهو من نوع الأرقام التي يقيسها اختبار السعة بدقة (انظر درس السعة).
  • نقطة الانهيار عند نحو ⁦385⁩ طلباً في الثانية: في خطوتي ⁦400⁩ و⁦450⁩ لا تخدم الواجهة إلا ⁦380⁩ إلى ⁦385⁩ أياً كان ما يُرسل؛ تنتظر الطلبات المجمّع، ويقفز زمن الاستجابة، وتظهر أولى حالات انتهاء المهلة. الاختناق هو مجمّع اتصالات قاعدة البيانات.
  • نمط الإخفاق: الطلبات المنتظرة تحتجز الذاكرة؛ وعند ⁦500⁩ يُقتل المثيل ⁦2⁩ لاستهلاكه ذاكرة مفرطة، فيرث المثيلان الآخران حمله وتصل الأخطاء إلى ⁦71%⁩. تنطلق قاعدة الإيقاف عند الدقيقة ⁦36⁩. كارثي لا رشيق: لا 503، ولا إسقاط للحمل الزائد، بل انتهاء مهلة عند البوابة (504) وانهيار.
  • التعافي: عند العودة إلى ⁦200⁩ طلب في الثانية يُعاد تشغيل المثيل من تلقاء نفسه ويعود p95 إلى ⁦650⁩ مللي ثانية خلال أربع دقائق؛ وتفرغ قائمة البريد عند الدقيقة ⁦49⁩. ويجد فحص البيانات ⁦12⁩ طلباً مؤكداً دون سجل دفع. تتبع ذلك ثلاثة تقارير عيوب: غياب إسقاط الحمل الزائد حين يمتلئ مجمّع الاتصالات، ونمو الذاكرة أثناء الانتظار، والتأكيد المرسَل قبل تسجيل الدفع.
تشغيل إجهاد لواجهة الطلبات: يُرفع الحمل على خطوات من الذروة المتوقعة ⁦200⁩ إلى ⁦500⁩ طلب في الثانية؛ ومن ⁦400⁩ لا تخدم الواجهة إلا نحو ⁦385⁩، وينهار مثيل عند الدقيقة ⁦36⁩، وعند العودة إلى ⁦200⁩ يرجع خط الأساس خلال أربع دقائق.
  1. الحمل المرسَل: خطوات تتجاوز الذروة المتوقعةما ترسله أداة الحمل: ⁦+50⁩ طلباً في الثانية كل ⁦5⁩ دقائق حتى تنطلق قاعدة الإيقاف.

    الخط المرجعي:الذروة المتوقعة: ⁦200⁩ طلب في الثانية (نجح اختبار الحمل عندها)

    1. 1عند الذروة المتوقعة 0–10 minصعود إلى ⁦200⁩ طلب في الثانية وثبات: تأكيد نتيجة اختبار الحمل
    2. 2خطوات بعد الذروة 10–37 minمن ⁦250⁩ إلى ⁦500⁩ طلب في الثانية؛ إيقاف عند الدقيقة ⁦36⁩ حين ينهار المثيل ⁦2⁩
    3. 3التعافي 37–55 minالعودة إلى ⁦200⁩ طلب في الثانية لمدة ⁦15⁩ دقيقة، ثم إلى الصفر
  2. الإنتاجية المخدومة: ما أتمّته الواجهةالطلبات المخدومة في الثانية؛ والفجوة تحت الحمل المرسَل انتظار، ثم إخفاق.

    الخط المرجعي:نقطة الانهيار: نحو ⁦385⁩ طلباً مخدوماً أياً كان المرسَل (مجمّع قاعدة البيانات ممتلئ)

    الدقيقة ⁦36⁩: قُتل المثيل ⁦2⁩ (نفاد الذاكرة)، والأخطاء ⁦71%⁩

    1. 1المخدوم يتابع المرسَل 0–25 minحتى ⁦350⁩ طلباً في الثانية؛ يتجاوز p95 هدف ⁦800⁩ مللي ثانية من ⁦350⁩
    2. 2التشبع، ثم الانهيار 25–37 minلا يُخدم إلا ⁦380–385⁩ بينما يُرسل ⁦400⁩ ثم ⁦450⁩؛ انتهاء مهل، ثم يسقط المثيل ⁦2⁩ عند الدقيقة ⁦36⁩
    3. 3التعافي 37–55 minيُعاد تشغيل المثيل؛ p95 عند ⁦650⁩ مللي ثانية بالدقيقة ⁦41⁩؛ قائمة البريد فارغة عند ⁦49⁩

الأرقام من المثال التطبيقي في الدرس وليست قياسات؛ ورُسمت خطوات الحمل قفزات عمودية.

Stress test: order API, release 5.1, perf environment (3 app instances, 1 database)
Start:       expected peak 200 req/s (load test passed: p95 620 ms, 0.1 % errors)
Profile:     +50 req/s every 5 min; abort if errors > 20 % for 1 min or an instance
             crashes; then back to 200 req/s for 15 min (recovery)
Objectives:  p95 <= 800 ms, errors < 0.5 % (a reading aid here, not pass criteria)
Columns:     Sent and Served in req/s (Served = successful responses);
             Errors = % of the requests sent

Step  Sent  Served         p95 Errors  Observed
200   200   200         620 ms  0.1 %  baseline, as in the load test
250   250   250         690 ms  0.1 %
300   300   300         780 ms  0.2 %  app CPU 85 %
350   350   350       1,250 ms  0.4 %  DB pool 48/50 busy; p95 past the objective
400   400   380       2,900 ms  3.1 %  pool full, requests queue; first timeouts
450   450   385       4,800 ms   14 %  gateway 504s; throughput flat since 400
500   500    90            n/a   71 %  min 36: instance 2 killed (out of memory)
                                       -> abort, load back to 200 req/s

Recovery at 200 req/s (min 37-52)
  min 37-41   instance 2 restarting; p95 2,100 -> 650 ms; errors 8 % -> 0.1 %
  min 41-52   p95 640 ms, errors 0.1 %, DB pool 31/50; email queue empty at min 49
  data check  12 orders confirmed with no payment record; 0 duplicate orders

أخطاء شائعة

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

من منظور ضمان الجودة

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

اسأل قبل التشغيل: كيف يبدو «الإخفاق المقبول» لهذا المنتج، وهل البديل (503 مع رسالة إعادة المحاولة، أو ميزة مختصرة) محدد في أي مكان؟ أي اعتمادية ستعاني أولاً؟ من يعيد تشغيل ماذا اليوم، وهل ينبغي أن يكون ذلك تلقائياً؟ أبلغ عن نقطة الانهيار بوصفها مستوى حمل مع اختناقه، وعن نمط الإخفاق رشيقاً أو كارثياً مع الدليل، وعن زمن التعافي وفحص البيانات. ويصبح كل سلوك كارثي وكل خطوة يدوية وكل مشكلة في سلامة البيانات تقرير عيب مستقلاً.

تمرين عملي

اقرأ تشغيل إجهاد لواجهة حجز تذاكر

المطلوب

نجحت واجهة الحجز لدى بائع تذاكر في اختبار الحمل عند ذروة متوقعة تبلغ ⁦300⁩ طلب في الثانية (الأهداف: p95 ≤ ⁦700⁩ مللي ثانية، والأخطاء أقل من ⁦1%⁩). المادة أدناه هي سجل خطوات تشغيل الإجهاد ومرحلة التعافي. حدّد الخطوة التي يُتجاوز فيها هدف ما أول مرة، ونقطة الانهيار واختناقها، وصنّف نمط الإخفاق، واحكم على التعافي، واكتب العيوب التي ستبلغ عنها.

المادة
Booking API, 4 instances, 1 database, 1 payment provider (sandbox)
Expected peak 300 req/s; objectives p95 <= 700 ms, errors < 1 %
Profile: +75 req/s every 5 min from 300; then back to 300 req/s for 15 min
Abort rule: errors > 20 % for 1 min, or any instance down
Columns: Sent and Served in req/s (Served = successful responses);
         Errors = % of the requests sent

Step  Sent  Served         p95 Errors  Observed
300   300   300         480 ms  0.2 %  baseline
375   375   375         560 ms  0.3 %
450   450   450         690 ms  0.6 %  app CPU 78 %; payment calls 1.1 s on average
525   525   518         980 ms  1.2 %  payment thread pool 64/64 busy
600   600   522       3,400 ms    9 %  queue in front of payment calls; 503s with
                                       Retry-After from the API gateway
675   675   518       4,100 ms   23 %  abort at min 32; no instance down

Recovery at 300 req/s (min 33-48)
  min 33-36   p95 1,900 -> 500 ms; errors 4 % -> 0.2 %; 503s stop at min 34
  min 36-48   p95 490 ms, errors 0.2 %, payment pool 22/64 busy
  backlog     confirmation SMS queue: 9,400 messages, empty at min 47
  data check  0 bookings without payment; 37 payments charged twice (retried
              requests created a second booking for the same seat, later cancelled)
الخطوات
  1. ابحث عن أول خطوة يفشل فيها هدف ما، وسجّل أيّ هدف هو.
  2. ابحث عن الخطوة التي تتوقف فيها الإنتاجية المخدومة عن متابعة الحمل، وسمّ المورد الذي تشبّع.
  3. صنّف نمط الإخفاق رشيقاً أو كارثياً، مع الدليل من السجل.
  4. احكم على التعافي: زمن العودة إلى خط الأساس، والخطوات اليدوية، والأعمال المتراكمة، وسلامة البيانات.
  5. اكتب قائمة تقارير العيوب، تقريراً لكل سلوك.
إظهار الإجابة النموذجية
الإجابة النموذجية

أول تجاوز للهدف عند ⁦525⁩ طلباً في الثانية: p95 عند ⁦980⁩ مللي ثانية مقابل ⁦700⁩، والأخطاء ⁦1.2%⁩ مقابل ⁦1%⁩، مع مجمّع خيوط الدفع مشغول بالكامل (⁦64⁩ من ⁦64⁩).

نقطة الانهيار عند نحو ⁦520⁩ طلباً في الثانية: من الخطوة ⁦525⁩ فصاعداً تخدم الواجهة بين ⁦518⁩ و⁦522⁩ أياً كان ما يُرسل، فمجمّع خيوط الدفع هو الاختناق؛ واستدعاءات مزوّد الدفع البطيئة (⁦1.1⁩ ثانية في المتوسط عند الخطوة ⁦450⁩) هي ما ملأه.

نمط الإخفاق: رشيق في معظمه. رفضت البوابة الفائض بـ503 وRetry-After، ولم يسقط أي مثيل، وثبتت الإنتاجية عند نحو ⁦520⁩. الاستثناء هو فحص البيانات: ⁦37⁩ عملية خصم مزدوجة من طلبات أُعيدت محاولتها، وهي نتيجة كارثية داخل شكل رشيق.

التعافي: تلقائي؛ عاد p95 والأخطاء إلى خط الأساس خلال ثلاث دقائق، وتوقفت أخطاء 503 عند الدقيقة ⁦34⁩، وفرغت قائمة رسائل SMS المتراكمة خلال ⁦14⁩ دقيقة، وهو ما ينبغي مقارنته بما تقبله جهة العمل.

العيوب: طلب الحجز غير متكافئ (non-idempotent)، فإعادة محاولة طلب سبقت معالجته تُنشئ حجزاً ثانياً وخصماً ثانياً، وهذه أخطر النتائج؛ وبطء تفريغ تراكم ⁦9,400⁩ رسالة SMS، إن تجاوزت مدته البالغة ⁦14⁩ دقيقة الحد المتفق عليه. أما مجمّع خيوط الدفع فأبلغ عنه بوصفه الاختناق لا بوصفه عيباً، لأن الواجهة تدهورت برشاقة: وهو أول ما يُغيَّر إذا احتجنا هامش أمان أكبر. وسجّل أيضاً هامش الأمان لمالك المنتج: بين ⁦450⁩ و⁦525⁩ طلباً في الثانية، أي أعلى من الذروة المتوقعة بنسبة ⁦50%⁩ إلى ⁦75%⁩، قبل أن يفشل الهدف الأول.

أسئلة شائعة

ما الفرق بين اختبار الإجهاد واختبار الحمل؟

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

هل نقطة الانهيار هي السعة نفسها؟

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

هل يفشل النظام في اختبار الإجهاد حين ينهار؟

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

هل يمكنني إجهاد بيئة الإنتاج؟

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

المراجع

  • Certified Tester Performance Testing (CT-PT)ISTQB · 2018منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
  • ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
  • Load test types — Grafana k6 documentationGrafana Labsتعريفات أنواع اختبار الحمل الشائعة — الاختبار الدخاني والحمل المتوسط والإجهاد والتحمّل الطويل (Soak) والذروة المفاجئة (Spike) ونقطة الانكسار — وما يُراد من كلٍّ منها كشفه.
  • Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016أهداف مستوى الخدمة وميزانيات الخطأ ومراقبة «الإشارات الذهبية الأربع» والتعامل مع الحمل الزائد — الجانب التشغيلي للمرونة.
الأدوات

تدرّب بأدوات متقن

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

ولّد مدخلات اختبار الأداء بتوزيعات واقعية: أزمنة التفكير، ومزيج الطلبات، وأحجام الحمولات، ومنحنيات التدرّج.

الأداء

محلّل زمن الاستجابة

قِس زمن استجابة نقطة نهاية عبر عدة عيّنات: الحد الأدنى والأقصى والمتوسط والوسيط وp95.

الأداء

مرجع رموز حالة HTTP

ابحث عن أي رمز حالة HTTP لمعرفة معناه ومرجعه في RFC ومتى يُستخدم.

الويب

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

قبل هذا الموضوع

الموضوعات التالية