Performance Testing Automation using Apache JMeter

عنوان المشروع: اختبار أداء متكامل (UI & API) باستخدام JMeter

وصف المشروع: هذا المشروع عبارة عن تمرين شامل لاختبار الأداء (Performance Testing) يغطي دورة حياة الاختبار الكاملة: بدءاً من إنشاء السكريبتات (Scripting) وانتهاءً بتنفيذ الاختبارات وتحليل النتائج وإعداد نماذج الأحمال المتقدمة.

تم تقسيم العمل إلى ثلاث مراحل رئيسية:

المرحلة الأولى: بناء السكريبتات (Scripting)

قمت بتطوير نوعين مختلفين من سكريبتات JMeter لاختبار تطبيقين:

1. سيناريو واجهة المستخدم (Web UI - PetStore E-commerce):

الهدف: محاكاة رحلة مستخدم كاملة على موقع تجارة إلكترونية.

الخطوات: تم بناء سكريبت يغطي التدفق التالي:

الانتقال للصفحة الرئيسية.

التسجيل كمستخدم جديد (ملء جميع البيانات).

تصفح قسم "الأسماك" (Fish) واختيار منتج.

إضافة المنتج إلى عربة التسوق.

تحديث كمية المنتج في العربة إلى 10.

المتابعة إلى "الدفع" (Checkout) وتأكيد الطلب.

الدفع (Pay by bank wire) وتأكيد الطلب نهائياً.

التحقق من نجاح الطلب عبر (Text Assertion) للتأكد من ظهور رسالة "Thank you, your order has been submitted".

2. سيناريو واجهات برمجة التطبيقات (API - Restful-Booker):

الهدف: اختبار تدفق كامل من الـ APIs الخاصة بنظام حجز.

الخطوات:

Auth (POST): إرسال طلب للحصول على Token مصادقة.

Create Booking (POST): إنشاء حجز جديد باستخدام بيانات (JSON).

Get Booking (GET): استدعاء جميع الحجوزات واستخراج ID محدد (مثل ID=1) باستخدام (JSON Extractor).

Update Booking (PUT): تعديل بيانات الحجز الذي تم استخراجه (Correlation).

Delete Booking (DELETE): حذف الحجز الذي تم تعديله.

معايير الجودة التي تم تطبيقها (Script Quality):

Parametrization: تم استخدام ملفات (CSV) و (User Defined Variables) لجعل السكريبتات معتمدة على بيانات خارجية بدلاً من البيانات الثابتة (Hardcoded values).

Assertions: تمت إضافة (Text Response Assertion) لكل طلب للتحقق من أن المستخدم يتنقل بشكل صحيح بين الصفحات.

Timers: تم استخدام (Constant Timers) لوضع فواصل زمنية بين الطلبات لمحاكاة سلوك مستخدم حقيقي.

Config Elements: تم استخدام (HTTP Request Defaults) لتوحيد معلومات السيرفر، و (Cookie Manager) لإدارة الجلسات، و (Cache Manager) لمسح الـ cache مع كل تكرار.

المرحلة الثانية: تنفيذ الاختبار وتحليل النتائج (Running & Analyzing)

الهدف: تشغيل اختبار تحمل (Load Test) بسيط وتحليل النتائج.

التنفيذ: تم إعداد (Thread Group) بسيط لتشغيل السكريبت الأول (Web UI) بـ 2 مستخدمين لمدة 10 دقائق.

التحليل: قمت بمراقبة (Aggregate Report) أثناء التشغيل.

التقرير: تم أخذ لقطة شاشة للنتائج النهائية وتحليلها بناءً على اتفاقيات مستوى الخدمة (SLAs) المحددة:

نسبة الأخطاء: يجب ألا تتجاوز 10%.

90th Percentile: يجب أن يكون 90% من الطلبات أسرع من 3 ثوانٍ.

99th Percentile: يجب أن يكون 99% من الطلبات أسرع من 5 ثوانٍ.

المخرجات: تم إنشاء ملف (Report.pdf) يحتوي على لقطة الشاشة وجدول يوضح مدى الالتزام بالـ SLAs (باللون الأخضر للناجح والأحمر للفاشل).

المرحلة الثالثة: تصميم نماذج الأحمال (Load Profiling)

الهدف: إظهار القدرة على تصميم نماذج أحمال (Load Models) متقدمة.

النموذج الأول (Stepping Load):

تم استخدام "jp@gc - Stepping Thread Group".

تم إعداده لزيادة الحمل تدريجياً (Ramp-up) ليصل إلى 100 مستخدم (بمعدل 1 مستخدم/ثانية)، ثم تقليل الحمل تدريجياً (Ramp-down) بنفس المعدل.

النموذج الثاني (Spike Test - Bonus):

تم استخدام "jp@gc - Ultimate Thread Group".

تم إعداده لمحاكاة "اختبار الذروة" (Spike Test) بالسيناريو التالي:

حمل أساسي (Base Load): 60 مستخدمًا لمدة 10 دقائق.

Spike A (بعد دقيقتين): إضافة 60 مستخدمًا إضافيًا بشكل مفاجئ (بمعدل 10 مستخدمين/ثانية) وإزالتهم بنفس السرعة.

Spike B (بعد 6 دقائق): تكرار نفس الـ Spike A لاختبار مرونة النظام (Resilience).