دليل عملي لاختبار التحميل لواجهات API باستخدام أرتيلري

Artillery هي مجموعة أدوات مفتوحة المصدر لاختبار التحميل مبنية على Node.js، تدفع حركة مرور عالية التزامن إلى واجهة برمجة التطبيقات (API) الخاصة بك من خلال نص YAML بسيط. تحدد مراحل التحميل وتدفقات الطلبات، وتُشغل artillery run script.yml، وتقرأ نسب زمن الاستجابة المئوية ومعدلات الطلبات وعدد الأخطاء. يرشدك هذا الدليل خلال تثبيت Artillery v2، وكتابة نص اختبار حقيقي، وتشغيله، والتقاط النتائج بالطريقة الحالية للإصدار v2، وربطه بنظام التكامل المستمر (CI).

ما هو Artillery ومتى يجب استخدامه؟

يُنشئ Artillery مستخدمين افتراضيين (VUs) يضربون نقاط النهاية الخاصة بك ويقيس مدى تحمل النظام تحت حركة المرور المستمرة. المستخدم الافتراضي هو عميل مُحاكى يُنفّذ سيناريو، طلبًا تلو الآخر، تمامًا كما يفعل المتصل الحقيقي.

تستخدم Artillery عندما تحتاج إلى إجابات لأسئلة قابلية التوسع. كيف يتصرف زمن الاستجابة p95 عند 50 طلبًا في الثانية؟ عند أي معدل وصول تبدأ الأخطاء في الظهور؟ هل تبقى واجهة برمجة التطبيقات مستقرة لمدة خمس دقائق من الحمل المستمر، أم أنها تتدهور؟

Artillery جيد في هذا لأن الاختبار تصريحي. تصف شكل التحميل في YAML بدلاً من كتابة حلقة تزامن يدويًا. يعمل في أي مكان يعمل فيه Node.js، لذا فإن نفس النص البرمجي يعمل على جهاز الكمبيوتر المحمول الخاص بك وفي نظام التكامل المستمر (CI).

Artillery هو أحد الخيارات المتعددة في هذا المجال. إذا كنت لا تزال تقارن الأدوات، فإن ملخص أفضل أدوات اختبار التحميل وهذا مقارنة برامج اختبار التحميل يغطيان المفاضلات بين k6 و JMeter و Gatling وغيرها.

تثبيت Artillery (الإصدار v2)

اسم الحزمة هو artillery تمامًا، والإصدار الرئيسي الحالي هو v2. قم بتثبيته عالميًا باستخدام npm، ثم تحقق من الإصدار.

npm install -g artillery@latest
artillery version

تحتاج إلى إصدار LTS حديث من Node.js. يعمل Artillery على أنظمة Windows و macOS و Linux.

إذا كنت تفضل عدم تثبيت أي شيء عالميًا، فقم بتشغيله عند الطلب باستخدام npx.

npx artillery@latest run script.yml

كتابة نص اختبار Artillery

اختبار Artillery هو ملف YAML يحتوي على قسمين رئيسيين. يحدد قسم config الهدف وملف تعريف التحميل. يحدد قسم scenarios ما يفعله كل مستخدم افتراضي.

إليك نص برمجي كامل يقوم بالإحماء، ثم يتصاعد إلى الذروة، ثم يحافظ على حمل مستمر.

config:
  target: "https://api.example.com"
  phases:
    - name: "Warm up"
      duration: 60
      arrivalRate: 5
    - name: "Ramp to peak"
      duration: 120
      arrivalRate: 5
      rampTo: 50
    - name: "Sustained load"
      duration: 300
      arrivalRate: 50
      maxVusers: 500
  # Inline variables (or use a CSV via config.payload)
  variables:
    productId:
      - "1001"
      - "1002"

scenarios:
  - name: "Browse and create order"
    flow:
      - get:
          url: "/v1/products/{{ productId }}"
      - post:
          url: "/v1/orders"
          json:
            productId: "{{ productId }}"
            quantity: 2

فهم قسم config

config.target هو المضيف الأساسي الذي تُنفذ كل طلبات الاختبار عليه. تضيف كل خطوة في السيناريو url الخاص بها إلى هذا الأساس.

config.phases هي مصفوفة من مراحل التحميل التي تُشغل بالترتيب. المفاتيح التي ستستخدمها غالبًا هي:

• duration: المدة التي تستغرقها المرحلة، بالثواني أو كسلسلة نصية قابلة للقراءة مثل "5m".
• arrivalRate: عدد المستخدمين الافتراضيين الجدد الذين يبدأون كل ثانية.
• rampTo: يزيد معدل الوصول خطيًا من arrivalRate وصولًا إلى هذه القيمة على مدار المرحلة.
• arrivalCount: عدد ثابت من المستخدمين الافتراضيين موزعين على مدار المرحلة، بدلاً من معدل في الثانية.
• maxVusers: حد أقصى لعدد المستخدمين الافتراضيين الذين يمكن تشغيلهم بالتزامن.
• name: تسمية تظهر في الإخراج.

هناك تفصيل واحد يُربك الناس. يتحكم duration الخاص بالمرحلة في المدة التي يستمر فيها Artillery في إنشاء مستخدمين افتراضيين، وليس إجمالي الوقت الفعلي للاختبار. إذا بدأ مستخدم افتراضي بالقرب من نهاية المرحلة واستغرق سيناريوه بعض الوقت، فإن التشغيل يستمر حتى ينتهي هذا المستخدم.

فهم قسم scenarios

scenarios هي مصفوفة. يحتوي كل سيناريو على flow، وهو قائمة مرتبة بالخطوات التي يُشغلها المستخدم الافتراضي. تتضمن المفاتيح الاختيارية name و weight، حيث يحدد weight الاحتمالية النسبية لاختيار Artillery لهذا السيناريو لمستخدم افتراضي معين.

تستخدم خطوات التدفق مفاتيح أفعال HTTP: get، post، put، delete، و patch. يأخذ كل منها url، وتُوضع أجسام الطلبات تحت json. تُستخدم صيغة الأقواس المعقوفة المزدوجة، {{ productId }}، لسحب متغير.

دفع الطلبات من ملف CSV

تثبيت القيم يدويًا (Hard-coding) جيد لاختبار الدخان (smoke test). للحصول على حمل واقعي، قم بتغذية البيانات من ملف CSV باستخدام config.payload. يختار كل مستخدم افتراضي صفًا، وتصبح أسماء الأعمدة متغيرات.

config:
  target: "https://api.example.com"
  payload:
    path: "./users.csv"
    fields:
      - "email"
      - "password"
  phases:
    - duration: 120
      arrivalRate: 20
scenarios:
  - flow:
      - post:
          url: "/login"
          json:
            email: "{{ email }}"
            password: "{{ password }}"

تشغيل الاختبار

يوجه الأمر الأساسي Artillery إلى النص البرمجي الخاص بك.

artillery run script.yml

# تجاوز الهدف دون تعديل النص البرمجي:
artillery run --target https://staging.example.com script.yml

# تمرير المتغيرات كـ JSON:
artillery run -v '{ "productId": ["1001","1002"] }' script.yml

هناك بعض العلامات التي تستحق المعرفة. تقوم --target (أو -t) بتجاوز config.target حتى تتمكن من توجيه نفس النص البرمجي إلى بيئة التدريج أو الإنتاج. تختار --environment (أو -e) كتلة مسماة ضمن config.environments. تقوم --config (أو -c) بتحميل الإعدادات من ملف منفصل. تتجاهل --insecure (أو -k) التحقق من TLS للشهادات الموقعة ذاتيًا في بيئات الاختبار.

قراءة النتائج

أثناء تشغيل الاختبار، يطبع Artillery مقاييس مجمعة كل 10 ثوانٍ تقريبًا. عند الانتهاء، تحصل على تقرير ملخص. الأرقام الأكثر أهمية هي:

• معدل الطلبات: عدد الطلبات في الثانية التي حققها التشغيل فعليًا.
• النسب المئوية للكمون (Latency percentiles): أوقات الاستجابة p50 (المتوسط)، p95، و p99. تخبرك p95 بتجربة أبطأ 5 بالمائة من الطلبات، وهي عادةً النقطة التي تظهر فيها المشاكل أولاً.
• عدد الأخطاء: الطلبات الفاشلة، مهلات الانتظار، والاستجابات غير 2xx، مجمعة حسب النوع.

راقب أزمنة الكمون النهائية (tail latencies)، وليس فقط المتوسط. قد يبدو المتوسط جيدًا بينما يتصاعد p99 بصمت إلى نطاق عدة ثوانٍ. إذا ظهرت الأخطاء فقط خلال مرحلة الحمل المستمر، فمن المحتمل أنك وجدت نقطة تشبع تستحق التحقيق. لمعالجة أعمق للمقاييس التي يجب تتبعها ولماذا، راجع دليل اختبار أداء API هذا.

إنشاء تقرير في Artillery v2

تغيرت عملية إعداد التقارير عبر إصدارات Artillery، وهذا هو المكان الذي قد تقودك فيه البرامج التعليمية القديمة إلى الضلال. تخبرك الأدلة القديمة بتشغيل artillery run --output report.json ثم artillery report report.json لإنتاج ملف HTML. الجزء الأول لا يزال يعمل. الجزء الثاني لا يعمل.

لا تزال العلامة --output تكتب ملف نتائج JSON يمكن قراءته آليًا.

# كتابة نتائج JSON قابلة للقراءة آليًا (لا تزال مدعومة):
artillery run --output report.json script.yml

تمت إزالة الأمر artillery report، وهو مولد JSON إلى HTML، من واجهة سطر أوامر Artillery. تنص الوثائق الرسمية على أنه "لم يعد مدعومًا وتمت إزالته من Artillery CLI." تم إهمال كود تقارير HTML، ثم تم إسقاطه، مع عدم وجود خطط لإعادته. لا تكتب artillery report report.json؛ فلن يعمل على الإصدار v2 الحالي.

لديك ثلاثة خيارات حالية بدلاً من ذلك.

أولاً، قم بتحليل JSON بنفسك. هذا مثالي للتكامل المستمر (CI)، حيث تريد التأكيد على حد معين. اسحب زمن الكمون p95 المجمع باستخدام jq:

jq '.aggregate.summaries["http.response_time"].p95' report.json

ثانيًا، استخدم Artillery Cloud للحصول على لوحة تحكم مستضافة. هذا هو البديل الرسمي لتقرير HTML القديم. مرر --record مع مفتاح API الخاص بك.

artillery run --record --key $ARTILLERY_CLOUD_API_KEY script.yml

ثالثًا، ادفع المقاييس إلى مكدس المراقبة الخاص بك باستخدام مكون publish-metrics الإضافي أو OpenTelemetry، بحيث تصل معدلات الكمون والأخطاء إلى نفس لوحات المعلومات التي تستخدمها بالفعل للإنتاج.

تشغيل Artillery في CI

نظرًا لأن Artillery هو مجرد واجهة سطر أوامر (CLI) مبنية على Node.js، فإنه يتناسب مع أي مسار عمل (pipeline). إليك سير عمل GitHub Actions يقوم بتثبيت Artillery وتشغيل الاختبار وتحميل تقرير JSON كعنصر بناء.

name: Load test
on: [workflow_dispatch]
jobs:
  artillery:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
      - run: npm install -g artillery@latest
      - run: artillery run --output report.json script.yml
      - uses: actions/upload-artifact@v4
        with:
          name: artillery-report
          path: report.json

يتم تشغيل هذا المثال يدويًا. عادةً ما يتم تشغيل اختبارات التحميل الثقيلة عند الطلب أو بجدول زمني بدلاً من كل عملية التزام (commit)، نظرًا لأنها تستغرق دقائق وتستهلك نطاقًا تردديًا حقيقيًا. بمجرد وجود تقرير JSON، يمكنك إضافة خطوة jq تفشل المهمة إذا تجاوز p95 ميزانيتك.

أين تتلاءم Apidog: الاختبار الوظيفي وحماية CI

تجيب Artillery على السؤال "هل يمكن لواجهة برمجة التطبيقات النجاة من هذا القدر من حركة المرور؟" وهذا هو اختبار التحميل والأداء. يطرح سؤال مختلف بجانبه: "هل لا تزال واجهة برمجة التطبيقات تُرجع استجابات صحيحة بعد هذا التغيير في الكود؟" وهذا هو الاختبار الوظيفي واختبار الانحدار، وهنا يأتي دور Apidog.

Apidog هي منصة API شاملة للتصميم، التصحيح (debugging)، المحاكاة (mocking)، التوثيق، والاختبار الآلي. تقوم سيناريوهات الاختبار الخاصة بها بتجميع نقاط النهاية في خطوات منطقية بشروط مثل if و for و foreach، بحيث يمكنك التحقق من أجسام الاستجابة وأكواد الحالة والعقود. يمكنك تشغيل هذه السيناريوهات في CI باستخدام واجهة سطر أوامر Apidog (CLI) لحماية عمليات الدمج بعد تغييرات الكود.

كن واضحًا بشأن الحدود. تتضمن Apidog ميزة اختبار الأداء، ولكنها محدودة بحد أقصى 100 مستخدم افتراضي. وهذا يكفي لاكتشاف الانحدارات الواضحة، وهو ليس بديلاً لـ Artillery في التزامن العالي. للحمل الموزع والمُصمم بالكود على نطاق واسع، تُعد Artillery الأداة المناسبة. يظهر هذا التأطير الصادق نفسه في مقالنا حول اختبار تحميل واجهات برمجة التطبيقات بدون Python، وتُغطى آليات ميزة 100 مستخدم افتراضي في Apidog في اختبار أداء API في Apidog.

لذا استخدم كليهما. اختبر التحميل باستخدام Artillery من أجل قابلية التوسع. وقم بتشغيل فحوصات وظيفية وانحدارية في CI باستخدام Apidog CLI لاكتشاف السلوكيات المعطلة قبل نشرها.

يتم تثبيت واجهة سطر أوامر Apidog (CLI) من npm، و apidog run يعتمد على العلامات فقط.

# واجهة سطر أوامر Apidog: تشغيل وظيفي/انحدار في CI (يعتمد على العلامات فقط، بدون ملف موضعي)
npm install -g apidog-cli
apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t <TEST_SCENARIO_ID> \
  -e <ENVIRONMENT_ID> \
  -r cli,junit \
  --out-dir ./apidog-reports

العلامة -t هي معرف سيناريو الاختبار، و -e هي معرف البيئة المطلوب، و -r cli,junit تُصدر كلاً من مخرجات وحدة التحكم وتقرير JUnit XML الذي يمكن لأنظمة CI قراءته. للحصول على شرح خطوة بخطوة، راجع البرنامج التعليمي لواجهة سطر أوامر Apidog، ولأنماط تصميم مسارات العمل، راجع أفضل الممارسات لـ CI/CD لاختبار API.

هل تريد اختبارات وظيفية وتعاقدية لحماية CI الخاص بك جنبًا إلى جنب مع عمليات تشغيل تحميل Artillery؟ قم بتنزيل Apidog مجانًا وقم ببناء أول سيناريو اختبار لك.

الأسئلة الشائعة

ما هو اختبار التحميل باستخدام Artillery؟

اختبار التحميل باستخدام Artillery هو ممارسة استخدام مجموعة أدوات Artillery مفتوحة المصدر لمحاكاة العديد من المستخدمين الافتراضيين المتزامنين الذين يضربون واجهة برمجة التطبيقات (API) الخاصة بك. تصف شكل التحميل وتدفق الطلبات في نص YAML، وتقوم بتشغيله، وتقيس النسب المئوية للكمون ومعدلات الطلبات والأخطاء لترى كيف يتصرف نظامك تحت الضغط.

هل Artillery مجانية ومفتوحة المصدر؟

نعم. واجهة سطر أوامر Artillery الأساسية (CLI) مجانية ومفتوحة المصدر، وموزعة على npm كحزمة artillery. هناك أيضًا خدمة مدفوعة مستضافة، Artillery Cloud، توفر لوحة تحكم للنتائج، ولكن يمكنك تشغيل اختبارات تحميل كاملة محليًا وفي CI بدونها.

كيف تشغل اختبار تحميل باستخدام Artillery؟

قم بتثبيته باستخدام npm install -g artillery@latest، اكتب نص YAML بكتلة config (الهدف والمراحل) وكتلة scenarios (تدفق الطلب)، ثم قم بتشغيل artillery run script.yml. يطبع Artillery مقاييس حية كل 10 ثوانٍ وملخصًا في النهاية.

كيف تُنشئ تقرير Artillery؟

شغل artillery run --output report.json script.yml لكتابة ملف نتائج JSON. تمت إزالة أمر artillery report القديم الذي كان ينتج HTML من واجهة سطر الأوامر (CLI). بدلاً من ذلك، قم بتحليل JSON باستخدام أداة مثل jq، أو استخدم Artillery Cloud عبر --record --key، أو ادفع المقاييس باستخدام مكون publish-metrics الإضافي أو OpenTelemetry.

Artillery مقابل k6 أو JMeter: أيهما يجب أن تستخدم؟

جميع الثلاثة تتعامل مع أحمال عالية النطاق. تستخدم Artillery YAML التصريحية و Node.js، مما يناسب الفرق الموجودة بالفعل في نظام JavaScript البيئي. يقوم k6 بكتابة نصوص برمجية بلغة JavaScript بنموذج يعتمد على الكود أولاً. JMeter يعتمد على واجهة المستخدم الرسومية (GUI) ويستند إلى Java مع تاريخ طويل من المكونات الإضافية. تغطي مقارنة Gatling vs JMeter المفاضلات بتعمق أكبر. اختر الأداة التي يتوافق نموذج كتابة النصوص البرمجية الخاص بها مع فريقك، ثم قم بإقرانها باختبارات CI الوظيفية للتغطية الكاملة.