اختبار التحمّل طويل المدة
اختبار التحمّل (Soak Testing، ويُسمّى أيضاً Endurance Testing) نوع من اختبار الأداء يُبقي على النظام حملاً واقعياً ثابتاً مدةً طويلة، ساعاتٍ كثيرة وأحياناً أياماً، لكشف المشكلات التي لا تظهر إلا مع مرور الوقت. ويستخدم منهج ISTQB لاختبار الأداء اسم Endurance Testing، ويربط المدة بسياق تشغيل النظام، أي عملياً: كم يعمل فعلاً بين إعادة تشغيل وأخرى، أو بين عمليات النشر، أو بين نوافذ الصيانة. ويحدّد كذلك ما يبحث عنه هذا الاختبار: مشكلات في سعة الموارد، مثل تسرّب الذاكرة أو استنفاد اتصالات قاعدة البيانات ومجمّعات الخيوط، تُضعف الأداء تدريجياً أو تنتهي بإخفاقات.
مثال: واجهة برمجية للطلبات تنجح في اختبار حمل مدته 30 دقيقة بمعدل 180 طلباً في الثانية، وزمن استجابتها عند المئين 95 (p95) يبلغ 310 ملّي ثانية. لكن الحمل نفسه إذا استمر 12 ساعة يروي قصة أخرى: تزداد الذاكرة نحو 0.24 غيغابايت كل ساعة، ويتجاوز p95 حدود 1.4 ثانية، وبعد نحو 11.5 ساعة تُقتل الحاوية لتجاوزها حدّ الذاكرة البالغ 4 غيغابايت. لم يتغيّر الحمل قط؛ كل ما حدث أن الوقت مضى.
لماذا يهم
الاختبارات القصيرة تقيس نظاماً بدأ لتوّه: مجمّعات الاتصالات نظيفة، والسجلات صغيرة، وكل تسرّب ما زال ضئيلاً. أما في بيئة الإنتاج فقد تعمل الخدمة نفسها أياماً أو أسابيع بين عمليتي نشر. والعيب الذي يسرّب بضعة ميغابايتات في الساعة، أو يحتفظ باتصال بقاعدة البيانات بعد كل عملية دفع انتهت مهلتها، لا يظهر في تشغيل مدته 30 دقيقة، ثم يصبح انقطاعاً للخدمة في اليوم الرابع، وكثيراً ما «يُصلَح» بإعادة تشغيل تخفي السبب إلى أن يتكرر.
بالنسبة إلى المنتج، اختبار التحمّل هو الدليل على أن الأداء والاعتمادية يصمدان طوال فترة التشغيل الحقيقية لا في الدقائق الأولى فقط؛ وبمصطلحات ISO/IEC 25010 فهو يفحص استخدام الموارد والسلوك الزمني على امتداد الوقت. وبالنسبة إلى المختبِر، يغيّر السؤال من «هل النظام سريع؟» إلى «هل يبقى سريعاً، وهل يبقى قائماً؟»، والتسرّب الذي يُكتشف في بيئة اختبار، مع مراقبة كاملة ودون أن يتأثر أي عميل، أسهل تشخيصاً بكثير من التسرّب نفسه في الإنتاج.
ما الذي يميّز اختبار التحمّل
في الدروس السابقة كان كل نوع من الاختبارات يغيّر الحمل: اختبار الحمل يطبّق عبء العمل المتوقع، واختبار الإجهاد يتجاوز الذروة المتوقعة، واختبار الذروة المفاجئة يجعل الحمل يقفز فجأة. أما اختبار التحمّل فيُبقي الحمل ثابتاً ويجعل المدة هي المتغيّر. لذلك فالنتيجة التي تبحث عنها اتجاه (Trend): هل يستمر شيء ما في الارتفاع أو الانخفاض بينما الحمل ثابت؟
الاسمان Soak Testing وEndurance Testing يدلّان على نشاط واحد. يستخدم ISTQB اسم Endurance Testing، بينما يستخدم كثير من الأدوات والفرق، ومنها توثيق k6، اسم Soak Testing. وبعض الفرق تضع حدّاً خاصاً بها بين الاسمين، كأن تفرّق بينهما بمستوى الحمل، لكن لا يوجد تقسيم معياري، فاكتب المعنى المقصود في خطة الاختبار.
- الحمل: عادةً متوسط حمل الإنتاج المتوقع، أو حمل واقعي لفترة ازدحام، ويبقى ثابتاً. ابقَ دون نقطة الانهيار التي وجدتها في اختبار الإجهاد بهامش واضح، وإلا فلن تميّز بين الحمل الزائد والتسرّب البطيء.
- المدة: تؤخذ من سياق التشغيل، فهي على الأقل دورة عمل كاملة، مثل يوم كامل بما فيه مهام الدُفعات الليلية، أو أطول مدة تعمل فيها الخدمة بين إعادة تشغيل وأخرى أو بين عمليتي نشر.
- السؤال: هل يتصرف النظام في الساعة 12 كما تصرّف في الساعة الأولى، وهل يعيد موارده عندما يتوقف الحمل؟
ما الذي يتدهور مع الوقت: التسرّب والاستنفاد والانجراف
يحدث تسرّب الذاكرة (Memory Leak) عندما يظل البرنامج محتفظاً بذاكرة لم يعد يحتاج إليها، فلا تُحرَّر أبداً. وكثير من بيئات التشغيل (Java و.NET وJavaScript وGo) تحرّر الذاكرة تلقائياً: يزيل جامع المهملات (Garbage Collector، ويُختصر GC) بانتظام من الكومة (Heap)، وهي منطقة الذاكرة التي يحفظ فيها البرنامج كائناته، كلَّ كائن لم يعد يشير إليه شيء. لذلك يعني التسرّب في هذه البيئات أن البرنامج ما زال يحتفظ بمراجع إلى كائنات لم يعد يستخدمها: ذاكرة تخزين مؤقت داخل التطبيق بلا حدّ للحجم، أو قائمة جلسات لا تُنظَّف، أو مستمع أحداث يُضاف مع كل طلب ولا يُزال. وترتفع الذاكرة وتنخفض على شكل أسنان المنشار كلما عمل جامع المهملات. والإشارة المهمة هي المستوى بعد كل عملية جمع: في الخدمة السليمة يستقر بعد مرحلة الإحماء، ومع التسرّب يواصل الصعود حتى تنفد ذاكرة العملية أو تقتلها المنصة. وقبل ذلك يزداد عمل جامع المهملات فيزداد زمن الاستجابة.
واستنفاد الموارد (Resource Exhaustion) هو النمط نفسه مع مورد له حدّ ثابت. فمسار الشيفرة الذي لا يعيد اتصال قاعدة البيانات إلى مجمّع الاتصالات (Connection Pool) عند حدوث خطأ يسرّب اتصالاً واحداً في كل مرة يُنفَّذ فيها. وعندما يفرغ المجمّع تنتظر الطلبات الجديدة ثم تنتهي مهلتها، مع أن المعالج والذاكرة يبدوان طبيعيين.
- الذاكرة: ذاكرة العملية أو الكومة بعد جمع المهملات ترتفع ساعة بعد ساعة.
- المجمّعات والمقابض: اتصالات قاعدة البيانات أو الخيوط (Threads) أو الملفات المفتوحة أو المقابس المستخدمة تزحف نحو الحد الأقصى المضبوط لها.
- القرص: السجلات أو الملفات المؤقتة أو الملفات المرفوعة تملأ القرص؛ ومن دون تدوير السجلات (Log Rotation) تتوقف الخدمة عندما يمتلئ القرص.
- الطوابير: مستهلك أبطأ قليلاً من المنتِج، فيكبر الطابور المتراكم ويطول زمن الانتظار بلا نهاية.
- تدهور بلا تسرّب: الجداول التي تكبر أثناء التشغيل تُبطئ الاستعلامات غير المفهرسة، والمهام المجدولة مثل النسخ الاحتياطي تنافس الحركة في ساعة محددة. هذه نتائج حقيقية أيضاً، لكن إصلاحها مختلف، فسمّها بدقة.
- خدمة سليمة: الذاكرةترتفع الذاكرة بعد جمع المهملات أثناء إحماء الخدمة، ثم تبقى مستقرة بعيداً عن الحدّ.
الخط المرجعي:حدّ الذاكرة (4 غيغابايت)
- 1الإحماء 0–1 h
- 2الحالة المستقرة 1–12 h
- تسرّب الذاكرة (المثال التطبيقي)تنمو الكومة بعد جمع المهملات نحو 0.24 غيغابايت في الساعة، من 1.2 غيغابايت في الساعة الأولى إلى 3.6 غيغابايت في الساعة 11، ولا تستقر أبداً.
الخط المرجعي:حدّ الذاكرة (4 غيغابايت)
قُتلت الحاوية عند 11:35: نفاد الذاكرة
- تسرّب الاتصالاتتزداد اتصالات قاعدة البيانات المستخدمة بضعة اتصالات كل مرة؛ وعندما يفرغ المجمّع تنتظر الطلبات الجديدة ثم تنتهي مهلتها.
الخط المرجعي:حجم المجمّع
استُنفد المجمّع: تنتهي مهلة الطلبات
شكل توضيحي: 12 ساعة من الحمل الثابت، وكل مورد معروض نسبةً من حدّه. منحنى تسرّب الذاكرة يتبع المثال التطبيقي، والمنحنيان الآخران للتوضيح فقط.
تخطيط اختبار التحمّل وتنفيذه
اختبار التحمّل من دون مراقبة على جانب الخادم لا يخبرك إلا بأن النظام أصبح أبطأ. اجمع، على فترات ثابتة وعلى الخط الزمني نفسه لأزمنة الاستجابة، الإشارات الذهبية الأربع من كتاب SRE الصادر عن Google، وهي زمن الاستجابة والحركة والأخطاء والتشبّع (Saturation)، ومعها كل مورد قابل للتسرّب: الذاكرة بعد جمع المهملات، والاتصالات والخيوط المستخدمة، والملفات المفتوحة، والمساحة الحرة على القرص، وطول الطابور.
اكتب معايير النجاح قبل التشغيل، وقارن بين نوافذ زمنية بدلاً من حساب المتوسط. فمتوسط 12 ساعة يخفي الاتجاه؛ قارن الساعة المستقرة الأولى بالساعة الأخيرة، وافحص النوافذ القصيرة بحثاً عن الأخطاء.
- استخدم مزيج عبء العمل الواقعي وبيانات اختبار متمايزة بما يكفي: 20 حساباً يُعاد استخدامها 12 ساعة تُبقي كل شيء في الذاكرة المؤقتة وتخفي النمو، والقيم الفريدة مثل أرقام الطلبات يجب ألا تنفد في منتصف التشغيل.
- اجعل البيئة مشابهة للإنتاج، بحدود الذاكرة ومستوى السجلات والمهام المجدولة نفسها، واتفق مع الفريق على ألا ينشر أحد شيئاً أو يعيد تشغيل شيء أثناء الاختبار.
- راقب مولّد الحمل أيضاً: إذا نقصت ذاكرته أو منافذه، بدا النظام قيد الاختبار بطيئاً وهو ليس كذلك.
- بعد مرحلة التخفيض (Ramp-down) استمر في المراقبة: يجب أن تعود الذاكرة والاتصالات والخيوط قريباً من مستواها في البداية.
Soak test plan: order API
Workload: 180 requests/s (expected weekday average), held constant
60% browse, 25% search, 10% add to cart, 5% checkout
5,000 distinct test users
Duration: 15 min ramp-up, 12 h steady state, 10 min ramp-down,
then 30 min observation with no load
Monitor: every minute: p95 and p99 per endpoint, throughput, errors,
heap after GC, DB connections in use (pool max 50),
threads, open files, free disk, queue depth
Pass if: 1. p95 in the last hour <= 1.2 x p95 in the first steady hour
2. error rate < 0.5% in every 15-minute window
3. heap after GC: no upward trend over the last 6 hours
4. no restarts and no out-of-memory kills
5. after ramp-down: heap and connections back near baselineجرّبها: مولّد بيانات اختبار الأداء جرّبها: مولّد بيانات اختبار التحميل جرّبها: مولّد اختبارات الطلبات المتزامنة
مثال تطبيقي: قراءة تشغيل مدته 12 ساعة
شُغّلت واجهة الطلبات الواردة في الخطة 12 ساعة بمعدل ثابت قدره 180 طلباً في الثانية. ويعرض الجدول أدناه ساعات مختارة صدّرها المختبِر من لوحة المراقبة.
اقرأه عموداً عموداً. الإنتاجية ثابتة، فالبطء ليس سببه زيادة الحركة. والاتصالات تبقى بين 12 و14 من 50، فالمجمّع ليس المشكلة. أما الكومة بعد جمع المهملات (GC) فترتفع نحو 0.24 غيغابايت في الساعة دون أن تستقر: إنه تسرّب ذاكرة. ويرتفع p95 معها لأن جامع المهملات يعمل مدة أطول ومرات أكثر كلما امتلأت الكومة، وتظهر الأخطاء في الساعات الأخيرة. يفشل التشغيل في المعايير من 1 إلى 4، ولم يمكن فحص المعيار 5 لأن التشغيل لم يصل إلى مرحلة التخفيض.
يذكر تقرير العيب الحقائق والاتجاه، لا تخميناً للسبب: رقم البناء (Build)، وملف الحمل، والمدة، ومخطط الكومة، ووقت قتل الحاوية، والتقدير بأن الإنتاج عند الحمل المتوسط سيبلغ الحدّ نفسه كل 11 إلى 12 ساعة تقريباً. واطلب من المطورين التقاط تفريغين للكومة (Heap Dump) في بيئة الاختبار، في الساعة الأولى والساعة السادسة؛ فالمقارنة بينهما تُظهر الكائنات التي تواصل النمو. وبعد الإصلاح أعد تشغيل الملف نفسه بوصفه اختبار تأكيد (Confirmation Testing) وقارن المنحنيات.
Hour Req/s p95 ms Errors Heap after GC DB conns in use
1 180 310 0.1% 1.2 GB 12 of 50
3 180 325 0.1% 1.7 GB 13 of 50
6 180 410 0.2% 2.4 GB 12 of 50
9 180 690 0.4% 3.1 GB 14 of 50
11 180 1450 1.9% 3.6 GB 13 of 50
11:35 container killed: memory limit (4 GB) exceededأخطاء شائعة
- تسمية اختبار حمل طويل اختبارَ تحمّل دون مراقبة الموارد: سترى أن النظام صار أبطأ، لكنك لن تعرف السبب.
- التشغيل فوق نقطة الانهيار التي كشفها اختبار الإجهاد، فيختلط الحمل الزائد بالتسرّب البطيء ولا يمكن تشخيص أيٍّ منهما.
- الحكم على التشغيل بمتوسطه العام بدلاً من مقارنة الساعات الأولى بالأخيرة وفحص النوافذ القصيرة.
- اختيار المدة بحسب ما يناسب («ساعة قبل الغداء») بدلاً من استنتاجها من فترة التشغيل الحقيقية.
- إعادة استخدام عدد قليل من المستخدمين أو السجلات فتخفي الذاكرة المؤقتة النمو، أو نفاد البيانات الفريدة في منتصف التشغيل فيفشل الاختبار لسبب خاطئ.
- قبول إعادة تشغيل مجدولة أو رفع حدّ الذاكرة إصلاحاً للمشكلة: فهذا يؤخّر الإخفاق فقط.
من منظور ضمان الجودة
يكلّف اختبار التحمّل وقتاً تقويمياً ووقت بيئة، فخطّط له مبكراً. اتفق مع مالك المنتج وفريق العمليات على المدة التي يجب أن تعمل فيها الخدمة دون تدخّل، واحجز بيئة مشابهة للإنتاج ليلاً أو في عطلة نهاية الأسبوع، وتأكد من ألا ينشر أحد عليها أثناء الاختبار. واسأل المطورين وفريق العمليات عن الموارد ذات الحدود الصارمة، مثل حدود الذاكرة وأحجام المجمّعات وحصص القرص وأحجام الطوابير، لتعرف ما تراقبه قبل بدء التشغيل لا بعد فشله.
سجّل البناء وملف عبء العمل والمدة ومعايير النجاح مع النتائج، واحتفظ بالمخططات: أقوى دليل في تقرير اختبار التحمّل هو مورد يرتفع تحت حمل ثابت. وكثير من الفرق تشغّل اختبار تحمّل أقصر لكل نسخة مرشحة للإصدار، وآخر طويلاً قبل الإصدارات الكبرى أو تغييرات البنية التحتية. وقارن كل تشغيل بالذي قبله: الذاكرة التي تستقر أعلى بنسبة 20% من الشهر الماضي، أو p95 الذي ينجرف أكثر داخل التشغيل، أمر يستحق الإبلاغ حتى لو نجحت كل المعايير.
تمرين عملي
شخّص تشغيل تحمّل مدته 8 ساعات
شُغّل اختبار تحمّل على خدمة مدفوعات بحمل ثابت قدره 60 طلباً في الثانية لمدة 8 ساعات. معايير النجاح: ألا يتجاوز p95 1.2 ضعف p95 في الساعة الأولى، وأن يبقى معدل الأخطاء دون 0.5% في كل ساعة، وألا يظهر اتجاه صاعد في أي مورد مراقَب. تصدير المراقبة أدناه.
قرّر هل نجح التشغيل، وحدّد ما الذي تدهور ولماذا تظن ذلك، وقدّر متى ستصيب المشكلة الإنتاج عند هذا الحمل، واكتب الأدلة التي ستضعها في تقرير العيب.
Payment service soak test: 60 requests/s, 8 hours, DB pool max 40
Hour Req/s p95 ms Errors Heap after GC DB conns in use Threads
1 60 220 0.0% 610 MB 8 of 40 52
2 60 225 0.0% 615 MB 12 of 40 52
4 60 230 0.0% 612 MB 20 of 40 53
6 60 235 0.1% 618 MB 29 of 40 52
7 60 610 1.8% 615 MB 34 of 40 53
8 60 5000 9.6% 614 MB 40 of 40 52
Most frequent error from hour 7: "Timeout waiting for a connection from the pool"
Bank simulator timeouts (planned in the test data): 4 to 6 per hour
Request timeout configured in the service: 5 s- تحقّق من أن الحمل بقي ثابتاً.
- انظر إلى كل عمود من أعمدة الموارد وقرّر أيها يتجه صعوداً وأيها ثابت.
- اربط الخطأ الأكثر تكراراً بالمورد الذي يتجه صعوداً.
- قارن النتائج بكل معيار من معايير النجاح وقرّر النجاح أو الفشل.
- قدّر الوقت حتى الإخفاق، واكتب الأدلة والأسئلة الموجهة إلى المطورين.
إظهار الإجابة النموذجية
بقي الحمل ثابتاً عند 60 طلباً في الثانية، فالتغيّر سببه الوقت لا الحركة. الكومة بعد جمع المهملات (610–618 ميغابايت) والخيوط (52–53) ثابتة: لا تسرّب في الذاكرة ولا في الخيوط. أما اتصالات قاعدة البيانات المستخدمة فتصعد من 8 إلى 40 من 40، بنحو 4 إلى 6 اتصالات في الساعة، حتى يُستنفد المجمّع.
والأخطاء تؤكد ذلك: ابتداءً من الساعة السابعة صار أكثر الأخطاء تكراراً انتهاءَ المهلة أثناء انتظار اتصال من المجمّع، ويقفز p95 من 235 إلى 610 ثم إلى 5,000 ملّي ثانية، وهي مهلة الطلب المضبوطة في الخدمة. التشغيل فاشل: p95 في الساعتين 7 و8 يتجاوز 1.2 × 220 = 264 ملّي ثانية، ومعدل الأخطاء فوق 0.5% في الساعتين 7 و8، والاتصالات في اتجاه صاعد منذ الساعة الأولى. ولو توقف التشغيل عند الساعة السادسة لفشل أيضاً بمعيار الاتجاه، مع أن زمن الاستجابة والأخطاء كانا يبدوان سليمين؛ ولهذا يراقب اختبار التحمّل الموارد.
الوقت حتى الإخفاق: عند هذا الحمل يعمل النظام طبيعياً نحو 6 ساعات بعد بدء تشغيل جديد؛ ومن الساعة السابعة تقريباً يتلقى المستخدمون ردوداً بطيئة وأخطاء، وعند الساعة الثامنة تقريباً يفرغ المجمّع (40 اتصالاً، يتسرّب منها 4 إلى 6 في الساعة). وقد يكون أقصر في الإنتاج: فمعدل التسرّب يطابق 4 إلى 6 مهلات منتهية من محاكي البنك في الساعة، فيوم تكثر فيه مهلات البنك سيُفرغ المجمّع أسرع. تعامل مع هذا الربط على أنه فرضية للمطورين لا سبب مُثبت.
أدلة تقرير العيب: البناء والبيئة، وملف الحمل والمدة، ومخطط الاتصالات المستخدمة إلى جانب الكومة والخيوط الثابتة، وأول وقت تجاوز فيه p95 والأخطاء المعايير، ورسالة الخطأ مع أعدادها، والارتباط بمهلات البنك. اسأل المطورين هل يعيد مسار انتهاء المهلة اتصاله إلى المجمّع، وهل يوفّر المجمّع المستخدم إعداداً لكشف التسرّب يسجّل المكان الذي أُخذ منه الاتصال، فبعض المجمّعات توفّر ذلك. وبعد الإصلاح أعد تشغيل ملف الساعات الثماني نفسه وتأكد من أن عدد الاتصالات يبقى ثابتاً.
أسئلة شائعة
كم يجب أن يستمر اختبار التحمّل؟
بقدر فترة التشغيل التي تحتاج إلى الثقة بها: دورة عمل كاملة على الأقل بما فيها المهام المجدولة، أو أطول مدة تعمل فيها الخدمة بين إعادة تشغيل وأخرى أو بين عمليتي نشر. وإذا كان المورد ينمو ببطء فشغّل الاختبار مدة كافية لترى اتجاهاً واضحاً وتقدّر متى سيبلغ حدّه. والأنظمة التي تعمل أسابيع قد تحتاج إلى أيام من الاختبار.
هل اختبار التحمّل مجرد اختبار حمل طويل؟
قد يبدو ملف الحمل متشابهاً، لكن الهدف والأدلة مختلفان. اختبار الحمل يتحقق من تحقيق الأهداف عند الحمل المتوقع؛ أما اختبار التحمّل فيتحقق من بقاء السلوك مستقراً مع الوقت، ولذلك يحتاج إلى مراقبة الموارد ومقارنة النوافذ المبكرة بالمتأخرة، لا إلى أهداف زمن الاستجابة وحدها.
إذا استمرت الذاكرة في النمو، فهل هذا تسرّب دائماً؟
لا. قد تنمو الذاكرة نمواً مشروعاً أثناء امتلاء الذاكرة المؤقتة، ما دامت تستقر عند حدّ مضبوط. انظر إلى المستوى بعد جمع المهملات على مدى ساعات كثيرة: المنحنى الذي يستقر يعني الإحماء، والمنحنى الذي يواصل الصعود تحت حمل ثابت يشير إلى تسرّب. أبلغ عن الاتجاه ودع المطورين يؤكدون السبب بتحليل الكومة.
هل يمكنني تشغيل اختبار تحمّل بأدوات متقن؟
ليس التشغيل نفسه: يحتاج اختبار التحمّل إلى أداة حمل مثل Apache JMeter أو k6 أو Gatling أو Locust تعمل ساعات على بيئة مسموح لك بتحميلها. وتساعد أدوات متقن في التحضير: مزيج الطلبات وملفات التصاعد، ومجموعات كبيرة من بيانات الاختبار المتمايزة، وسكربت أولي لأداة الحمل.
المراجع
- Certified Tester Performance Testing (CT-PT)منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
- Load test types — Grafana k6 documentationتعريفات أنواع اختبار الحمل الشائعة — الاختبار الدخاني والحمل المتوسط والإجهاد والتحمّل الطويل (Soak) والذروة المفاجئة (Spike) ونقطة الانكسار — وما يُراد من كلٍّ منها كشفه.
- Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelنموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
تدرّب بأدوات متقن
ولّد مدخلات اختبار الأداء بتوزيعات واقعية: أزمنة التفكير، ومزيج الطلبات، وأحجام الحمولات، ومنحنيات التدرّج.
ولّد مجموعات معاملات كبيرة (مستخدمين ورموزاً ومعرّفات وحمولات) لاختبارات التحميل في k6 وJMeter وGatling وLocust.
ولّد سكربتات اختبار التزامن (k6 وJMeter JMX وLocust وArtillery وNode.js) بإعدادات افتراضية آمنة لنقطة نهاية مستهدفة.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.