اطلب اختبارًا لرحلات ومعدلات عمل محددة، لا شهادة أن التطبيق «يتحمل عددًا كبيرًا من المستخدمين». ألف مستخدم يقرأون صفحة محفوظة يختلفون عن ألف مستخدم يبحثون ثم يرسلون طلبات تغيّر قاعدة البيانات. قيمة الاختبار في نموذج حمل مفهوم ونتائج يمكن ربطها به، مع حدود أمان تمنع إضرار الاختبار بخدمات أو بيانات خارج نطاقه.
قبل التعاقد، اكتب السؤال الذي تريد الإجابة عنه: هل يستطيع إصدار معين معالجة مزيج متوقع من البحث والإرسال خلال فترة متفق عليها، مع زمن واستقرار وجودة نتائج مقبولة؟ لا تثبت التجربة كل أحمال المستقبل، ولا تمنح ضمان توافر. وهي لا تُجرى على الإنتاج أو مزود خارجي لمجرد أن العميل يملك واجهة التطبيق.
ابدأ بالرحلات ومصدر افتراضاتك
حدد الخطوات التي ينفذها المستخدم، ونسبة كل نوع من العمل، وحجم البيانات، وفترات الانتظار، والذروة المتوقعة. اذكر هل استندت الافتراضات إلى قياسات حالية أو توقعات صاحب المنتج أو سيناريو تعليمي. إذا كان التطبيق جديدًا، يمكن اختبار فرضيات معلنة، لكن لا تسمها أحمالًا واقعية مثبتة بلا دليل.
تدعو وثائق AWS الخاصة باختبار الحمل إلى بيئة ممثلة للإنتاج وبيانات اصطناعية أو منقحة ومقارنة النتائج بمعايير محددة. هذه مبادئ لتصميم التجربة، لا إذنًا بالضغط على أي مورد سحابي. دليل AWS لاختبار الحمل.
يمكن أن يندرج تشخيص الاختناقات وإعادة اختبار الإصلاحات ضمن تحسين الأداء وتعزيز الأمان. ويحدد اختبار وضمان جودة البرمجيات صحة الرحلات والنتائج، لأن استجابة سريعة ببيانات خاطئة لا تحقق معيار الأداء المطلوب.
ميّز معدل الوصول عن عدد الجلسات
عندما تقول «100 مستخدم»، اسأل ماذا يفعلون وكم مرة. قد تبقى جلسة مفتوحة دون نشاط، وقد تنتج جلسة واحدة طلبات كثيرة. لهذا يجب أن يتضمن وصف الحمل معدل بدء العمليات، ومزيجها، ومدتها، وطريقة زيادتها، لا عدد جلسات فقط. كذلك لا تفترض أن مستخدمي الاختبار يتوقفون تلقائيًا عندما يتباطأ النظام إذا كان السيناريو المتوقع استمرار وصول طلبات جديدة.
| جزء النموذج | ما يجب توضيحه؟ |
|---|---|
| التصفح والبحث والإرسال | تعريف كل عملية وعدد الطلبات التقنية الناتجة عنها |
| بيانات الاختبار | حجمها وتنوعها وإمكانية إعادة التجربة دون تلوث |
| المراحل | التدرج والثبات والانخفاض والمدة المصرح بها |
| التبعيات | ما هو حقيقي وما هو محاكى وما هو مستبعد |
| النتيجة | الزمن والإخفاق وصحة البيانات وسلوك ما بعد الحمل |
مثال افتراضي: ثلاثة أنواع من الطلبات
لنفترض نظام حجز يريد اختبار مرحلة ثابتة مدتها عشر دقائق، تبدأ فيها 20 عملية في الثانية: 12 تصفحًا، و6 عمليات بحث، وعمليتا إرسال. يصبح العدد المخطط في هذه المرحلة 12,000 عملية إجمالًا، منها 1,200 إرسال. هذه أرقام افتراضية لشرح الحساب وليست قدرة متوقعة أو معيار سوق.
يحدد الفريق أن الاتصال بمزود الرسائل سيُحاكى حتى لا يرسل الاختبار رسائل حقيقية أو يتجاوز إذن المورد. بذلك لا تثبت التجربة قدرة المزود نفسه، ويذكر التقرير هذا الحد. تُجهّز بيانات اصطناعية تكفي لتجنب إعادة استخدام حجز واحد بصورة لا تمثل العمل، ويُتفق على معنى إرسال ناجح لا ينشئ سجلًا مكررًا.
قبل المرحلة الثابتة يوجد تدرج مصرح، وبعدها فترة مراقبة لزوال الطلبات المعلقة. قد ينجح متوسط الزمن بينما تتراكم أعمال خلفية لا تنتهي؛ لذلك لا تُعلن النتيجة قبل مراجعة اكتمالها. وإذا لم يستطع مولد الحمل إنتاج المعدل المطلوب، يسجل التقرير ذلك بدل نسبة حدود أداة الاختبار إلى قدرة التطبيق.
اتفق على الإيقاف قبل البدء
اذكر الجهة المخولة بالإيقاف، والقناة التي تصل إليها، وما الذي يوقف التجربة فورًا. من أمثلة الشروط: ظهور اتصال غير متوقع بالإنتاج، أو خروج بيانات حساسة، أو أثر على طرف غير مشمول، أو تجاوز حد تكلفة وافق عليه المالك. هذه حدود تنفيذية تحتاج ضبطًا في المشروع وليست أرقامًا ثابتة يمكن نسخها لكل نظام.
حدد كذلك ما إذا كان الهدف التحقق من حمل متفق عليه أو استكشاف نقطة تدهور داخل سقف مصرّح. لا توسّع الحمل تلقائيًا لأن المرحلة الأولى نجحت. راجع شروط المزود الحالي وأذونات الاختبار اللازمة مع صاحب الحساب قبل التشغيل، وأكد توفر المختص المناسب للتنفيذ الآمن.
اقرأ النتيجة دون تحويلها إلى وعد
يجب أن يذكر التقرير الإصدار والبيئة ومصدر الحمل والفروق عن الإنتاج. اعرض الزمن بتوزيع مناسب، لا متوسطًا يخفي الحالات الأبطأ، وبيّن الإخفاقات حسب الرحلة وصحة النتائج بعد انتهاء الحمل. اربط الاختناق بدليل متزامن بدل الاستنتاج من ارتفاع مؤشر وحيد.
تساعد مراقبة الأنظمة وهندسة الموثوقية في توفير إشارات تفسر التدهور. وإذا استدعت النتائج تغيير السعة أو تقسيم المكونات، فناقش الخيارات عبر تصميم ومراجعة البنية السحابية. لا تفترض أن أكبر مورد هو الحل أو أن نتيجة بيئة أصغر تتضاعف خطيًا في بيئة أكبر.
معايير قبول اختبار مفيد
- نموذج حمل معتمد يوضح الافتراضات ومصدرها وحدودها.
- إذن محدد للأهداف والبيئة والمدة والتبعيات والتكلفة.
- تحقق من أن مولد الحمل والقياسات عملا كما هو مطلوب.
- نتائج لكل رحلة مرتبطة بمعايير وافق عليها المالك قبل التشغيل.
- تحقق من عدم فقد أو تكرار العمل ومن تصريف الأعمال المعلقة.
- قائمة اختناقات بدرجة ثقة، مع اقتراح إعادة اختبار محدود بعد الإصلاح.
- نتيجة صريحة: اجتاز السيناريو، لم يجتزه، أو لم تتوفر أدلة كافية للحكم.
أسئلة شائعة
هل الاختبار على بيئة صغيرة عديم الفائدة؟
لا، قد يكشف مشكلة محددة، لكن يجب توضيح حدود الاستدلال على الإنتاج. لا تحوّل النتيجة إلى رقم سعة نهائي بلا اختبار مناسب.
هل نختبر جميع الأطراف الخارجية فعليًا؟
فقط ضمن أذونها وشروطها ونطاقها المعتمد. المحاكاة خيار مفيد، مع التصريح بما لا تثبته.
هل نجاح الاختبار يغني عن المراقبة بعد الإطلاق؟
لا. الأحمال والبيانات والتبعيات قد تتغير. الاختبار دليل لسيناريو وإصدار وبيئة محددة، وليس ضمانًا دائمًا.
ماذا نرسل لتحديد النطاق؟
أرسل الرحلات المهمة وبيانات الحمل المنقحة إن وجدت، ووصف البيئة والتبعيات، والقرار المطلوب. نبدأ من هذه المعلومات قبل اختيار أداة أو وعد بعدد مستخدمين.
مرجع
AWS: اختبار الحمل، تمت مراجعته في 26 أكتوبر 2026. أرقام المثال تعليمية وجميع الاختبارات تتطلب تفويضًا مناسبًا.
