اختبار الحمل في تطوير التطبيقات المحمولة — ما هو، السيناريوهات وكيف يتم

ما هو اختبار الحمل؟

اختبار الحمل (Load Test) هو عملية التحقق من كيفية أداء النظام تحت عدد متوقع من الطلبات أو المستخدمين المتزامنين. في سياق تطوير التطبيقات المحمولة، يُطبق اختبار الحمل على كل من الجانب الخاص بالخادم (API، قاعدة البيانات، الذاكرة المؤقتة) والجانب العميل (معالجة إشعارات push، مزامنة البيانات). الفرق الرئيسي عن اختبارات الإجهاد هو أن اختبار الحمل يحاكي حمولة حقيقية وليست متطرفة. وفقًا AWS Well-Architected Framework (2024)، يجب إجراء اختبارات الحمل باستخدام ملفات حمولة مبنية على تحليل الاستخدام الحقيقي.

يُمكن إجراء اختبار الحمل على مستوى طلبات HTTP للواجهة البرمجية (API)، اتصالات WebSocket أو معاملات قاعدة البيانات. الهدف هو ضمان أن وقت استجابة كل طلب لا يتجاوز حدًا محددًا (عادة 500–1000 مس للواجهة البرمجية)، وتلبي الإنتاجية (RPS — طلب في الثانية) المتطلبات. Google Cloud Armor (2024) يحدد قيمًا حدية بناءً على النسب المئوية: وقت استجابة p95 يجب ألا يتجاوز ثانيتين للنقاط النهائية الحرجة.

تشمل اختبارات الحمل للبكيند المحمول محاكاة السيناريوهات النموذجية: التسجيل، تحقق الهوية، تحميل الخلاصة، إرسال النماذج. السيناريوهات تُسجّل كملفات HAR (HTTP Archive) وتُشغل بواسطة أداة اختبار الحمل. وفقًا لوثائق k6 (2025)، يُقلل تحويل HAR وقت تحضير اختبار الحمل بنسبة 60%.

أهداف اختبار الحمل

الهدف الأول لاختبار الحمل هو تأكيد الإنتاجية للنظام. إذا كانت المواصفات تتطلب معالجة 1000 RPS، فيجب على اختبار الحمل تأكيد ذلك بهامش بنسبة 20%. وفقًا Netflix Tech Blog (2024)، تجرى اختبارات الحمل في Netflix بهامش ضرب 2x من الحمولة الذروية: إذا كان من المتوقع 10000 RPS، يتحقق الاختبار من 20000 RPS. يضمن هذا النهج الاستقرار أثناء ارتفاعات حركة المرور المفاجئة.

الهدف الثاني هو تحديد الاخناقات (bottlenecks) في الهيكلة. الاخناقات النموذجية في البكيندات المحمولة هي قاعدة البيانات (استعلامات بطيئة)، الذاكرة المؤقتة (إستراتيجية إبطال غير صحيحة) والواجهات البرمجية الخارجية (خدمات جهات ثالثة بطيئة). التتبع الموزع (Jaeger، Zipkin) يساعد في تحديد المشكلة عند مستوى خدمة أو طلب محدد.

الهدف الثالث هو تحديد نقطة الإشباع (saturation point). هذه هي اللحظة التي يتوقف فيها إضافة مستخدمين جدد عن زيادة الإنتاجية. في التطبيقات المحمولة، نقطة الإشباع تحدث عادة عند 70–80% من حمولة وحدة المعالجة المركزية (CPU) على خوادم قاعدة البيانات. التوسع التلقائي (Auto-scaling) يجب أن ينشط قبل الوصول إلى هذه النقطة.

سيناريوهات اختبار الحمل

اختبار الذروة (Spike Test) — يحاكي ارتفاعًا حادًا في النشاط، مثل حملة إشعارات push صباحية أو إطلاق حملة تسويقية. وفقًا Grafana k6 (2025)، يحاكي Spike Test نمو الحمولة من 100 إلى 10000 RPS في 30 ثانية. يجب على النظام التعامل معه دون فقدان الطلبات ودون تجاوز وقت الاستجابة بأكثر من 50%.

اختبار التحمل (Endurance Test) — يتحقق من استقرار النظام أثناء العمل المطول تحت الحمولة. المدة النموذجية هي 1–4 ساعات. يكشف Endurance Test تسريبات الذاكرة في تطبيقات الخادم، مشاكل مجموعة اتصالات قاعدة البيانات وتدهور أداء الذاكرة المؤقتة. مجموعة اتصالات PostgreSQL تحت حمولة مطولة دون تهيئة صحيحة قد تستنفذ الاتصالات المتاحة خلال 2–3 ساعات من التشغيل.

اختبار الحمل المتدرج (Step Load Test) — زيادة تدريجية في الحمولة بخطوة 10–20% كل 2–5 دقائق. يساعد هذا السيناريو في العثور على الحد الدقيق بعد الذي يتدهور النظام. InfluxDB و Prometheus يجمعان المقاييس في كل خطوة لبناء رسم بياني لوقت الاستجابة مقابل RPS.

مقاييس اختبار الحمل

وقت الاستجابة

وقت الاستجابة (Response Time) هو المقياس الرئيسي في Load Test. يُقاس بالميلي ثانية ويحلل حسب النسب المئوية: p50 (الوسيط)، p95 و p99. Google SRE (2024) يوصي بعدم تجاوز p95 حدَّ 1000 مس لواجهة REST API و 200 مس لتقنية gRPC. النسب المئوية أهم من المتوسطات لأنها تظهر سلوك أسوأ الطلبات، التي يلاحظها المستخدمون أولاً. Apdex (مؤشر أداء التطبيق) هو مقياس مركب يأخذ في الاعتبار نسبة المستخدمين الراضين والمتسامحين والمحبطين.

الإنتاجية

الإنتاجية (Throughput) — عدد الطلبات الناجحة في وحدة الزمن. تُقاس بـ RPS (طلب في الثانية) أو TPS (صفقة في الثانية). يجب أن يكون رسم الإنتاجية بإحداثيات «الزمن — RPS» خطيًّا حتى نقطة الإشباع. انخفاض حاد في الإنتاجية مع زيادة الحمولة هو علامة على الوصول إلى حد النظام. Apache Bench و wrk هما أدوات CLI بسيطة للتحقق السريع من الإنتاجية أثناء التطوير.

نسبة الأخطاء

نسبة الأخطاء (Error Rate) — نسبة الاستجابات بحالة HTTP 4xx أو 5xx من إجمالي الطلبات. الحد المقبول هو أقل من 1%. تشير الأخطاء 429 (طلبات كثيرة جدًا) و 503 (الخدمة غير متاحة) تحت الحمولة العالية إلى الحاجة لتكوين تحديد المعدل والتوسع التلقائي. يحمي محدد المعدل على جانب API Gateway البكيند من تجاوز الحمولة المسموح بها. سياسة إعادة المحاولة مع التراجع الأسي تساعد العملاء على معالجة الأخطاء المؤقتة بشكل صحيح.

أدوات اختبار الحمل

k6 (Grafana)

k6 — الأداة الرئيسية مفتوحة المصدر لاختبارات الحمل من Grafana. تُكتب النصوص البرمجية بلغة JavaScript، مع دعم السيناريوهات النمطية والحدود (thresholds) والتكامل مع Prometheus و InfluxDB. يمكن تشغيل k6 في كل من CLI وفي سحابة Grafana Cloud k6. Grafana Cloud تبني لوحات المعلومات تلقائيًا من نتائج Load Test وتقارنها مع البيانات التاريخية. k6 تدعم Protocol Buffers و gRPC عبر وحدة k6/net/grpc المنفصلة.

Apache JMeter

Apache JMeter — أداة كلاسيكية لاختبار الحمل بواجهة رسومية. تدعم مجموعة واسعة من البروتوكولات: HTTP، JDBC، JMS، FTP و TCP. JMeter أكثر ملائمة للسيناريوهات المعقدة مع أنواع متعددة من الطلبات ولكنها تتطلب تهيئة يدوية أكثر مقارنة بـ k6. إضافات JMeter تُوسع الوظائف لاختبار WebSocket و gRPC. للتشغيل الموزع، يستخدم JMeter هيكلة الخادم الرئيسي والتابع مع وحدة تحكم واحدة.

Locust

Locust — أداة قائمة على Python تسمح بوصف سيناريوهات الحمولة في الكود. Locust مناسبة للفرق التي تستخدم Python كلغة رئيسية للأتمتة. بالخلاف من k6 و JMeter، يدعم Locust التشغيل الموزع من المركز: عقدة ماستر واحدة تُنسق عدة عقد عاملة. التشغيل الموزع يسمح بتوليد حمولة تصل إلى 100000 RPS من عدة آلات. كما يدعم Locust اختبار WebSocket عبر الإضافات المخصصة.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

مثال كتابة اختبار حمل باستخدام k6

يظهر نص k6 المعروض أعلاه هيكلة نموذجية لاختبار الحمل. تحدد Options ملف الحمولة: زيادة تدريجية لمدة دقيقتين إلى 100 مستخدم، ثم 5 دقائق من الحمولة الثابتة ثم زيادة أخرى إلى 200 مستخدم. الحدود (Thresholds) تحدد معايير نجاح الاختبار: وقت طلب p95 لا يتجاوز 500 مس، نسبة الأخطاء أقل من 1%. إذا تم تجاوز الحدود، يخرج k6 برمز غير صفري — مما يسمح بدمج Load Test في CI/CD.

في تطوير التطبيقات المحمولة، يُعد Load Test للجانب الخاص بالخادم مهمًا وخاصة عند إطلاق ميزات جديدة تضيف حمولة إضافية: إعجابات، تعليقات، بث مباشر. توصية — إجراء Load Test على كل بيئة staging قبل النشر في الإنتاج. يساعد إنشاء ملف حمولة أساسي خلال مرحلة تصميم API في تجنب المشاكل الهيكلية في المراحل المتأخرة.