DEV Community

Cover image for اختبار أداء API: دليل شامل
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

اختبار أداء API: دليل شامل

يمكن لواجهة برمجة التطبيقات (API) أن تجتاز كل الاختبارات الوظيفية ثم تفشل في الإنتاج عند أول موجة استخدام حقيقية. قد تُرجع البيانات الصحيحة، ورمز الحالة الصحيح، والمخطط الصحيح، لكنها تتباطأ أو تتعطل عند وصول 1000 مستخدم في الوقت نفسه. الاختبار الوظيفي يثبت أن الـ API صحيحة. اختبار الأداء يثبت أنها صحيحة وسريعة بما يكفي لحركة المرور الفعلية.

جرّب Apidog اليوم

في هذا الدليل ستتعلم ما هو اختبار أداء واجهة برمجة التطبيقات، ما أنواع الاختبارات التي تحتاجها، ما المقاييس التي يجب مراقبتها، وكيف تشغّل اختبار أداء عمليًا باستخدام Apidog.

ما هو اختبار أداء واجهة برمجة التطبيقات API؟

اختبار أداء API يقيس سلوك الواجهة تحت الضغط:

  • كم تستغرق الاستجابة؟
  • كم طلبًا يمكنها معالجة في الثانية؟
  • عند أي مستوى تحميل تبدأ بالتباطؤ؟
  • متى تظهر الأخطاء أو الانهيارات؟

لا يجيب هذا الاختبار عن سؤال: "هل الاستجابة صحيحة؟" فهذا دور الاختبار الوظيفي.

بل يجيب عن سؤال: "هل تصل الاستجابة بسرعة وموثوقية عندما يكون النظام تحت الضغط؟"

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

واجهات API مناسبة جدًا لاختبار الأداء لأنها مباشرة وحتمية:

Request -> Response -> Metrics
Enter fullscreen mode Exit fullscreen mode

لا توجد واجهة مستخدم، ولا متصفح، ولا انتظار لعرض صفحات. ترسل طلبًا وتقيس النتيجة.

أنواع اختبار الأداء

مصطلح "اختبار الأداء" يشمل عدة أنواع. كل نوع يجيب عن سؤال مختلف.

1. اختبار التحميل Load Testing

يطبّق حجم المرور المتوقع فعليًا، سواء الحمل الطبيعي أو حمل الذروة.

استخدمه للإجابة عن سؤال:

هل تستطيع الـ API التعامل مع الحمل المتوقع ضمن زمن استجابة مقبول؟

مثال:

100 مستخدم متزامن لمدة 10 دقائق
هدف الأداء: p95 أقل من 300ms
معدل الخطأ: أقل من 1%
Enter fullscreen mode Exit fullscreen mode

هذا غالبًا أول اختبار يجب أن تبدأ به.

2. اختبار الإجهاد Stress Testing

يدفع النظام إلى ما بعد الحمل المتوقع حتى يتدهور أو يفشل.

استخدمه للإجابة عن سؤال:

أين نقطة الانهيار؟ وكيف يفشل النظام؟

أمثلة لما تريد مراقبته:

  • هل ترتفع أزمنة الاستجابة تدريجيًا؟
  • هل تظهر أخطاء 500؟
  • هل تنتهي الطلبات بمهلة Timeout؟
  • هل يفشل النظام بشكل آمن أم يفقد بيانات؟

3. اختبار الارتفاع المفاجئ Spike Testing

يحاكي قفزة حادة ومفاجئة في المرور.

مثال:

من 50 مستخدمًا إلى 1000 مستخدم خلال 30 ثانية
Enter fullscreen mode Exit fullscreen mode

هذا مهم للأنظمة التي تتعرض إلى:

  • حملات تسويقية
  • مبيعات فورية
  • محتوى ينتشر فجأة
  • إشعارات Push ترسل لعدد كبير من المستخدمين

قد يتعامل النظام جيدًا مع حمل ثابت، لكنه يفشل عند الارتفاع المفاجئ.

4. اختبار التحمل Soak Testing

يشغّل حملًا متوسطًا لفترة طويلة: ساعات أو أيام.

استخدمه لاكتشاف مشاكل لا تظهر في اختبار قصير، مثل:

  • تسرب الذاكرة
  • استنزاف تجمع الاتصالات Connection Pool
  • امتلاء ملفات السجلات
  • بطء تدريجي في قاعدة البيانات
  • تراكم المهام الخلفية

مثال:

200 مستخدم متزامن لمدة 8 ساعات
Enter fullscreen mode Exit fullscreen mode

5. اختبار الدخان Smoke Testing

اختبار خفيف قبل تشغيل اختبار أطول وأكثر تكلفة.

مثال:

10 مستخدمين لمدة دقيقتين
Enter fullscreen mode Exit fullscreen mode

هدفه التأكد من أن:

  • نقطة النهاية تعمل
  • بيانات الاختبار صحيحة
  • التوثيق Authentication مضبوط
  • إعدادات الاختبار لا تحتوي أخطاء

المقاييس التي يجب مراقبتها

اختبار الأداء ينتج أرقامًا كثيرة. ركّز على هذه المقاييس أولًا.

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

هو الوقت بين إرسال الطلب واستلام الاستجابة.

لا تعتمد على المتوسط فقط. راقب النسب المئوية:

  • p50: نصف الطلبات أسرع من هذا الرقم
  • p95: أبطأ 5% من الطلبات
  • p99: أبطأ 1% من الطلبات

المتوسط قد يبدو جيدًا بينما يعاني بعض المستخدمين من بطء شديد.

مثال:

Average latency: 180ms
p95 latency: 900ms
p99 latency: 1800ms
Enter fullscreen mode Exit fullscreen mode

هنا المتوسط مضلل. المستخدمون في الطرف البطيء سيشعرون بالمشكلة.

المعالجة Throughput

عدد الطلبات المكتملة في الثانية.

مثال:

Requests per second: 1200 RPS
Enter fullscreen mode Exit fullscreen mode

هذا الرقم يخبرك بقدرة النظام الفعلية، بغض النظر عن عدد المستخدمين المتصلين.

المستخدمون المتزامنون Concurrent Users

عدد المستخدمين الافتراضيين الذين يحاكيهم الاختبار في الوقت نفسه.

مثال:

50 -> 100 -> 200 -> 500 concurrent users
Enter fullscreen mode Exit fullscreen mode

السعة العملية للنظام غالبًا تُقاس بأكبر عدد مستخدمين متزامنين يمكن دعمه مع بقاء زمن الاستجابة ضمن الميزانية المحددة.

معدل الخطأ Error Rate

النسبة المئوية للطلبات الفاشلة.

مثال:

Error rate: 2.5%
Enter fullscreen mode Exit fullscreen mode

حتى إذا كان زمن الاستجابة جيدًا، فإن API تفشل في الاختبار إذا بدأت بإرجاع:

  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout
  • أخطاء مهلة Timeout

استخدام الموارد Resource Usage

راقب موارد الخادم بالتوازي مع نتائج الاختبار:

  • CPU
  • Memory
  • Disk I/O
  • Network I/O
  • Database connections
  • Queue length

مثال عملي:

p95 يرتفع
CPU = 100%
Enter fullscreen mode Exit fullscreen mode

غالبًا لديك عنق زجاجة في المعالجة.

مثال آخر:

p95 يرتفع
CPU = 35%
Database connections = maxed out
Enter fullscreen mode Exit fullscreen mode

المشكلة غالبًا في قاعدة البيانات أو تجمع الاتصالات.

كيفية تشغيل اختبار أداء API في Apidog

تتضمن Apidog اختبار تحميل داخل نفس مساحة العمل التي تستخدمها لتصميم واختبار واجهات API وظيفيًا. هذا يقلل الحاجة إلى نقل السيناريوهات بين أدوات متعددة عند البدء.

الخطوة 1: اختر نقطة النهاية أو السيناريو

ابدأ بشيء له أثر حقيقي على المستخدم.

أمثلة جيدة:

GET /products
POST /login
GET /orders
POST /checkout
Enter fullscreen mode Exit fullscreen mode

إذا كان التدفق الحقيقي يتكون من أكثر من طلب، استخدم سيناريو اختبار متعدد الخطوات.

مثال سيناريو:

1. POST /login
2. GET /profile
3. GET /products
4. POST /cart/items
5. POST /checkout
Enter fullscreen mode Exit fullscreen mode

اختبار تدفق واقعي يعطيك أرقامًا أقرب للإنتاج من اختبار نقطة نهاية معزولة.

الخطوة 2: شغّل الاختبار الوظيفي أولًا

قبل قياس السرعة، تأكد أن الطلب صحيح.

تحقق من:

  • رمز الحالة
  • شكل الاستجابة
  • القيم المطلوبة
  • التوثيق
  • الرؤوس Headers
  • المتغيرات المستخدمة بين الخطوات

مثال تأكيد وظيفي:

Status code == 200
response.data.id exists
response.time < 1000ms
Enter fullscreen mode Exit fullscreen mode

يمكنك استخدام تأكيدات API للتأكد من صحة الاستجابة قبل تحميلها.

لا تختبر أداء نقطة نهاية تُرجع بيانات خاطئة. أصلح الصحة أولًا، ثم قِس السرعة.

الخطوة 3: اضبط نموذج التحميل

حدد:

  • عدد المستخدمين الافتراضيين
  • مدة الاختبار
  • طريقة الزيادة التدريجية Ramp-up
  • البيئة المستهدفة
  • بيانات الاختبار

مثال إعداد أولي:

Virtual users: 100
Duration: 10 minutes
Ramp-up: 2 minutes
Target: staging environment
Enter fullscreen mode Exit fullscreen mode

استخدم الزيادة التدريجية بدل تشغيل كل المستخدمين دفعة واحدة. هذا يساعدك على رؤية النقطة التي يبدأ عندها الأداء بالتدهور.

مثال:

0 users   -> بداية الاختبار
100 users -> بعد دقيقتين
300 users -> بعد 5 دقائق
500 users -> بعد 10 دقائق
Enter fullscreen mode Exit fullscreen mode

الخطوة 4: شغّل الاختبار وراقب المؤشرات

أثناء التشغيل، راقب:

  • متوسط زمن الاستجابة
  • p95
  • p99
  • عدد الطلبات في الثانية
  • معدل الخطأ
  • تغيّر المقاييس مع زيادة التزامن

ابحث عن نقطة الانعطاف:

يزداد عدد المستخدمين
لكن Throughput يتوقف عن الزيادة
و p95 يبدأ بالارتفاع بسرعة
Enter fullscreen mode Exit fullscreen mode

هذه غالبًا بداية الوصول إلى سقف النظام.

الخطوة 5: اقرأ النتائج وحدد عنق الزجاجة

لا تكتفِ بسؤال: "هل نجح الاختبار؟"

اسأل:

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

مثال نتيجة:

p95 تحت 200ms حتى 250 مستخدمًا
p95 يصل إلى 600ms عند 320 مستخدمًا
Error rate يتجاوز 1% عند 420 مستخدمًا
Enter fullscreen mode Exit fullscreen mode

الاستنتاج:

السعة المريحة: 250 مستخدمًا متزامنًا
السقف العملي: حوالي 320 مستخدمًا
بداية الفشل: حوالي 420 مستخدمًا
Enter fullscreen mode Exit fullscreen mode

بعد تطبيق أي إصلاح، أعد الاختبار بنفس الإعدادات لتتأكد أن السقف تغيّر فعلًا.

الخطوة 6: صدّر إلى JMeter عند الحاجة

إذا احتجت إلى حمل أكبر أو تشغيل موزع يتجاوز جهازًا واحدًا، يمكن لـ Apidog تصدير السيناريو إلى JMeter. بهذه الطريقة تحتفظ بتعريف الاختبار نفسه وتوسّع مصدر الحمل عند الحاجة.

يمكنك تنزيل Apidog لتشغيل أول اختبار تحميل على نقطة نهاية لديك بالفعل.

مثال عملي: قراءة نتيجة أداء حقيقية

لنفترض أنك تختبر:

GET /products
Enter fullscreen mode Exit fullscreen mode

وإعداد الاختبار كالتالي:

Virtual users: من 0 إلى 500
Duration: 5 دقائق
Performance budget: p95 أقل من 200ms
Enter fullscreen mode Exit fullscreen mode

النتائج:

0 - 200 مستخدم:
p95 ≈ 180ms
Throughput يزيد مع الحمل
Error rate ≈ 0%
Enter fullscreen mode Exit fullscreen mode

هذه منطقة صحية. النظام يواكب الطلب.

ثم:

280 مستخدمًا:
p95 = 240ms

330 مستخدمًا:
p95 = 400ms

380 مستخدمًا:
p95 = 900ms
Throughput يتسطح
Enter fullscreen mode Exit fullscreen mode

هنا تظهر الإشارة المهمة: إضافة مستخدمين لا تزيد العمل المكتمل، بل تجعل الاستجابات أبطأ.

ثم:

420 مستخدمًا:
Error rate > 1%
Timeouts تبدأ بالظهور
Enter fullscreen mode Exit fullscreen mode

الاستنتاج العملي:

السعة المريحة: حوالي 250 مستخدمًا متزامنًا
السقف العملي: حوالي 280 مستخدمًا
بداية الفشل: حوالي 420 مستخدمًا
Enter fullscreen mode Exit fullscreen mode

إذا كانت ذروة المرور المتوقعة لديك 200 مستخدم متزامن، لديك هامش أمان.

إذا كانت الذروة المتوقعة 350، لديك مشكلة يجب إصلاحها قبل الإطلاق.

اختبار الأداء لا يعطيك فقط "نجاح" أو "فشل". يعطيك خريطة واضحة:

أين النظام مستقر؟
أين يبدأ بالتباطؤ؟
أين يبدأ بالفشل؟
Enter fullscreen mode Exit fullscreen mode

أعناق الزجاجة الشائعة في أداء API

عندما يكشف الاختبار عن سقف منخفض، يكون السبب غالبًا واحدًا من هذه الأسباب.

1. استعلامات قاعدة بيانات بطيئة

أمثلة شائعة:

  • عمود غير مفهرس
  • استعلام N+1
  • SELECT * على جداول كبيرة
  • غياب Pagination
  • عمليات Join مكلفة
  • قفل على الجداول أو الصفوف

مؤشر محتمل:

Latency يرتفع
CPU التطبيق منخفض
Database CPU أو query time مرتفع
Enter fullscreen mode Exit fullscreen mode

ابدأ بتحليل الاستعلامات البطيئة وإضافة الفهارس المناسبة.

2. استدعاءات خارجية متزامنة

إذا كانت نقطة النهاية تعتمد على خدمة خارجية، فهي ترث بطء تلك الخدمة.

مثال:

POST /checkout
 -> Payment provider
 -> Fraud check
 -> Email service
Enter fullscreen mode Exit fullscreen mode

إذا كان أي استدعاء خارجي بطيئًا، ستتأثر الاستجابة كلها.

حلول محتملة:

  • استخدام Timeout واضح
  • استخدام Retry محدود
  • نقل بعض العمليات إلى Queue
  • تنفيذ العمليات غير الحرجة بشكل غير متزامن

3. استنزاف تجمع الاتصالات

يظهر عادة تحت الحمل المستمر.

أمثلة:

  • نفاد اتصالات قاعدة البيانات
  • نفاد اتصالات HTTP clients
  • انتظار طويل للحصول على connection
  • ارتفاع زمن الاستجابة دون ارتفاع CPU

مؤشر محتمل:

Connection pool usage = 100%
Requests waiting
p95 يرتفع تدريجيًا
Enter fullscreen mode Exit fullscreen mode

راجع حجم الـ pool، وأوقات المهلة، وتسريب الاتصالات غير المغلقة.

4. تسلسل Serialization غير فعال

إذا كانت الاستجابة كبيرة جدًا أو يتم بناؤها بكلفة عالية، سيزيد استهلاك CPU والذاكرة.

أمثلة:

  • إرجاع حقول لا يحتاجها العميل
  • JSON ضخم
  • كائنات متداخلة بعمق
  • تحويلات كثيرة قبل الإرسال

حلول عملية:

  • استخدم Pagination
  • أرجع الحقول المطلوبة فقط
  • اضغط الاستجابة عند الحاجة
  • راجع شكل الـ DTO أو Response model

5. غياب التخزين المؤقت Caching

بعض نقاط النهاية تقرأ بيانات لا تتغير كثيرًا، لكنها تضرب قاعدة البيانات في كل طلب.

أمثلة مناسبة للتخزين المؤقت:

  • قوائم التصنيفات
  • إعدادات التطبيق
  • بيانات المنتجات العامة
  • نتائج بحث متكررة

لكن لا تضف Cache عشوائيًا. حدد:

  • مدة الصلاحية TTL
  • سياسة الإبطال Invalidation
  • ما إذا كانت البيانات حساسة للمستخدم

دمج اختبار الأداء في عملية التطوير

اختبار الأداء قبل إطلاق كبير مفيد، لكنه غير كافٍ. الأداء يتدهور بصمت مع الوقت.

قد يضيف تغيير صغير:

  • استعلامًا جديدًا
  • علاقة غير مفهرسة
  • استدعاء خدمة خارجية
  • حمولة Response أكبر
  • عملية Serialization مكلفة

ولا يلاحظ ذلك أي اختبار وظيفي.

ضع ميزانية أداء

حدد أرقامًا واضحة لنقاط النهاية الحيوية.

مثال:

GET /products
p95 < 250ms
Error rate < 0.5%

POST /checkout
p95 < 700ms
Error rate < 0.1%
Enter fullscreen mode Exit fullscreen mode

إذا تجاوزت نقطة النهاية الميزانية، اعتبر ذلك فشلًا مثل فشل الاختبار الوظيفي.

شغّل اختبار تحميل خفيف في CI/CD

لا تحتاج إلى اختبار إجهاد كامل مع كل Pull Request. لكن يمكنك تشغيل اختبار خفيف لنقاط النهاية المهمة ضمن CI/CD.

مثال:

20 مستخدمًا
3 دقائق
p95 يجب أن يبقى تحت 300ms
Error rate يجب أن يكون 0%
Enter fullscreen mode Exit fullscreen mode

ثم احتفظ بالاختبارات الأثقل للإصدارات الرئيسية:

Load test قبل كل إصدار
Stress test أسبوعيًا أو قبل الإطلاق
Soak test قبل الإصدارات الكبيرة
Enter fullscreen mode Exit fullscreen mode

احتفظ باختبارات الأداء بجانب الاختبارات الوظيفية

عندما تكون اختبارات الصحة والسرعة في نفس سير العمل، يصبح كل تغيير في API مسؤولًا عن أمرين:

هل يعمل؟
هل يعمل بسرعة كافية؟
Enter fullscreen mode Exit fullscreen mode

وهذا يقلل احتمال وصول تدهور الأداء إلى الإنتاج.

الأسئلة المتداولة

ما الفرق بين اختبار التحميل واختبار الإجهاد؟

اختبار التحميل يستخدم المرور المتوقع للتحقق من أن API تعمل ضمن الحدود المقبولة.

اختبار الإجهاد يتجاوز المرور المتوقع لاكتشاف نقطة الانهيار وطريقة الفشل.

باختصار:

Load testing = هل يتحمل الحمل الطبيعي والمتوقع؟
Stress testing = أين ومتى ينهار؟
Enter fullscreen mode Exit fullscreen mode

هل أراقب متوسط زمن الاستجابة أم النسب المئوية؟

راقب النسب المئوية، خصوصًا p95 و p99.

المتوسط يخفي الطلبات البطيئة. المستخدمون الذين يواجهون أبطأ 5% أو 1% من الطلبات هم غالبًا من سيشتكون.

هل يمكن اختبار أداء API قبل اكتمال الواجهة الخلفية؟

يمكنك اختبار العقد والتصميم مبكرًا، لكن أرقام زمن الاستجابة ذات المعنى تحتاج إلى بنية حقيقية وتنفيذ فعلي.

استخدم خادمًا وهميًا للعمل الوظيفي المبكر، ثم شغّل اختبارات تحميل على التنفيذ الحقيقي.

كم مرة يجب تشغيل اختبارات الأداء؟

اقتراح عملي:

اختبار تحميل خفيف: مع تغييرات نقاط النهاية الحيوية في CI
اختبار تحميل كامل: قبل كل إصدار مهم
اختبار إجهاد: قبل الإطلاق أو عند تغييرات البنية
اختبار تحمل: قبل الإصدارات الكبيرة أو للأنظمة عالية الحركة
Enter fullscreen mode Exit fullscreen mode

الأداء يتدهور تدريجيًا، لذلك الاختبارات المنتظمة أفضل من اختبار كبير واحد قبل الإطلاق.

Top comments (0)