يمكن لواجهة برمجة التطبيقات (API) أن تجتاز جميع الاختبارات الوظيفية ومع ذلك تفشل في بيئة الإنتاج. فهي تعيد البيانات الصحيحة، مع رمز الحالة الصحيح، وفقًا للمخطط الصحيح، ثم تتعطل لحظة وصول ألف مستخدم إليها في وقت واحد. يخبرك الاختبار الوظيفي بأن واجهة برمجة التطبيقات صحيحة. بينما يخبرك اختبار الأداء بأنها صحيحة وسريعة بما يكفي لتحمل حركة المرور الحقيقية.
يشرح هذا الدليل ماهية اختبار أداء واجهة برمجة التطبيقات (API)، وأنواع الاختبارات المهمة، والمقاييس التي يجب مراقبتها، وكيفية إجراء اختبار الأداء خطوة بخطوة في Apidog.
ما هو اختبار أداء واجهة برمجة التطبيقات (API)
يقيس اختبار أداء واجهة برمجة التطبيقات (API) كيفية تصرف الواجهة تحت الضغط: مدى سرعة استجابتها، وعدد الطلبات التي يمكنها التعامل معها، والنقطة التي تتدهور فيها أو تتعطل. لا يتعلق الأمر بما إذا كانت الاستجابة صحيحة؛ فهذا هو الاختبار الوظيفي. بل يتعلق الأمر بما إذا كانت الاستجابة تصل بسرعة وموثوقية عندما يكون النظام تحت الضغط.
الهدف هو العثور على الحدود القصوى قبل أن يصل إليها المستخدمون. كل واجهة برمجة تطبيقات لها سقف، نقطة ترتفع فيها أوقات الاستجابة، وتظهر الأخطاء، أو تتوقف الخدمة عن الاستجابة. يحدد اختبار الأداء هذا السقف في بيئة خاضعة للتحكم حتى تتمكن من رفعه، أو التخطيط للسعة بناءً عليه، أو على الأقل معرفة وجوده.
تُعد واجهات برمجة التطبيقات أهدافًا جيدة لاختبار الأداء لأنها حتمية وسريعة الاستدعاء. لا يوجد متصفح للعرض، ولا واجهة مستخدم للانتظار. أنت ترسل طلبًا، وتقيس الاستجابة. وهذا يجعل اختبارات أداء واجهة برمجة التطبيقات أرخص في التنفيذ وأكثر استقرارًا من اختبارات التحميل الشاملة من البداية إلى النهاية.
أنواع اختبار الأداء
"اختبار الأداء" هو مصطلح شامل. ويندرج تحته عدة أنواع مختلفة من الاختبارات، يجيب كل منها على سؤال مختلف.
يطبق اختبار التحميل حركة المرور التي تتوقعها بالفعل، وحجم الطلبات الطبيعي وذروته، ويؤكد أن واجهة برمجة التطبيقات تتعامل معها ضمن أوقات استجابة مقبولة. هذا هو الاختبار الأساسي الذي تجريه معظم الفرق أولاً.
يدفع اختبار الإجهاد بما يتجاوز حركة المرور المتوقعة، ويزيد التحميل حتى تتدهور واجهة برمجة التطبيقات أو تفشل. الهدف هو العثور على نقطة الانهيار ومعرفة كيف تتعطل. هل تتباطأ بسلاسة، أم أنها تعيد الأخطاء وتفقد البيانات؟
يطبق اختبار الارتفاع المفاجئ (Spike testing) قفزة حادة ومفاجئة في حركة المرور، من النوع الذي ينتج عن بيع فوري أو لحظة انتشار واسع، ويتحقق مما إذا كانت واجهة برمجة التطبيقات تمتصها أو تنهار. يمكن لنظام يتعامل مع حمل ثابت أن يفشل في التعامل مع الارتفاع المفاجئ.
يحتفظ اختبار التحمل (Soak testing)، الذي يُطلق عليه أيضًا اختبار المتانة، بحمل متوسط لفترة طويلة، ساعات أو أيام، لكشف المشكلات البطيئة: تسرب الذاكرة، استنفاد تجمع الاتصالات، امتلاء ملفات السجلات للقرص. لا تظهر هذه المشكلات أبدًا في اختبار تحميل مدته خمس دقائق.
اختبار الدخان (Smoke testing) هو الفحص المسبق الخفيف: حمل صغير لتأكيد أن واجهة برمجة التطبيقات وإعداد الاختبار يعملان قبل الالتزام بتشغيل طويل ومكلف.
تحتاج معظم الفرق إلى اختبار التحميل والإجهاد والتحمل كحد أدنى. يهم اختبار الارتفاع المفاجئ إذا كانت حركة المرور لديك متقطعة.
المقاييس المهمة
ينتج اختبار الأداء أرقامًا. هذه هي الأرقام التي يجب قراءتها.
وقت الاستجابة هو المدة التي تستغرقها واجهة برمجة التطبيقات لتلقي الطلب ومعالجته وإعادته. انظر إلى النسب المئوية، وليس فقط المتوسط. يمكن أن يبدو المتوسط جيدًا بينما تكون النسبة المئوية 95 و 99، وهي أبطأ 5% و 1% من الطلبات، غير مقبولة. يتأثر المستخدمون الفعليون بأسوأ أوقات الاستجابة.
المعالجة (Throughput) هي عدد الطلبات التي تكملها واجهة برمجة التطبيقات في الثانية. تخبرك بالقدرة الحقيقية للنظام، بغض النظر عن عدد المستخدمين المتصلين.
المستخدمون المتزامنون أو المستخدمون الافتراضيون هو عدد المتصلين المتزامنين الذين يحاكيها الاختبار. غالبًا ما يتم التعبير عن السعة على أنها أقصى تزامن تحافظ عليه واجهة برمجة التطبيقات قبل أن تتجاوز أوقات الاستجابة ميزانيتك المحددة.
معدل الخطأ هو النسبة المئوية للطلبات التي تفشل تحت الضغط. واجهة برمجة تطبيقات تظل سريعة ولكنها تبدأ في إعادة الأخطاء 500 عند التزامن العالي تكون قد فشلت في الاختبار.
استخدام الموارد، وحدة المعالجة المركزية والذاكرة على الخادم، يخبرك لماذا يتدهور الأداء. إذا ارتفعت أوقات الاستجابة بينما تكون وحدة المعالجة المركزية عند 100%، فأنت مقيد بالحوسبة؛ وإذا كانت وحدة المعالجة المركزية خاملة ولكن زمن الوصول يرتفع، فإن عنق الزجاجة موجود في مكان آخر، غالبًا ما يكون قاعدة بيانات أو استدعاء خدمة تابعة.
يربط تقرير الأداء الجيد هذه الأمور معًا: عند هذا التزامن، وصلت المعالجة إلى ذروتها، وكان وقت الاستجابة للنسبة المئوية 95 هو كذا، وكان معدل الخطأ كذا.
كيفية تشغيل اختبار أداء واجهة برمجة التطبيقات (API) في Apidog
تتضمن Apidog اختبار التحميل المدمج في نفس مساحة العمل حيث تقوم بتصميم واختبار واجهات برمجة التطبيقات وظيفيًا، لذلك لا تحتاج إلى أداة منفصلة للبدء.
الخطوة 1: اختر نقطة النهاية أو السيناريو للاختبار. اختر نقطة نهاية واحدة حيوية، أو سيناريو اختبار متعدد الخطوات يحاكي تدفق مستخدم حقيقي، مثل تسجيل الدخول متبوعًا بجلب البيانات. يمنح اختبار تدفق واقعي أرقامًا أكثر صدقًا من اختبار نقطة نهاية واحدة بمعزل عن غيرها.
الخطوة 2: تأكد من اجتيازه للاختبار الوظيفي أولاً. قم بتشغيل الطلب مع تأكيداته مرة واحدة. لا توجد قيمة في اختبار تحميل نقطة نهاية تعيد بيانات خاطئة؛ قم بإصلاح الصحة قبل قياس السرعة.
الخطوة 3: تهيئة التحميل. حدد عدد المستخدمين الافتراضيين ومدة الاختبار. يتيح لك Apidog زيادة التحميل تدريجيًا، محاكيًا انضمام المستخدمين بمرور الوقت بدلاً من جميعهم في وقت واحد، مما ينتج عنه صورة أكثر واقعية ويساعد في تحديد مستوى التزامن الذي يتغير عنده الأداء.
الخطوة 4: تشغيل الاختبار. ينفذ Apidog التحميل ويقدم تقارير حية: أوقات الاستجابة، المعالجة، معدل الخطأ، وكيف يتغير كل مقياس مع ارتفاع التزامن. راقب نقطة الانعطاف حيث يبدأ وقت الاستجابة في الارتفاع بشكل أسرع من التحميل.
الخطوة 5: قراءة النتائج والعثور على عنق الزجاجة. إذا تجاوز وقت الاستجابة للنسبة المئوية 95 ميزانيتك عند 300 مستخدم متزامن، فهذا هو سقفك الحالي. قارن ذلك بوحدة المعالجة المركزية والذاكرة للخادم لفهم السبب. أعد التشغيل بعد الإصلاح للتأكد من أن السقف قد تغير.
الخطوة 6: للحاجات الأثقل، التصدير إلى JMeter. عندما تحتاج إلى إنشاء تحميل موزع يتجاوز جهازًا واحدًا، يمكن لـ Apidog تصدير السيناريو إلى JMeter، بحيث تحتفظ بنفس تعريف الاختبار بينما تقوم بتوسيع نطاق مصدر التحميل.
قم بتنزيل Apidog لتشغيل اختبار التحميل الأول الخاص بك على نقطة نهاية لديك بالفعل.
قراءة نتيجة أداء حقيقية
الأرقام بدون تفسير هي ضوضاء. لنأخذ تشغيلًا ملموسًا: تقوم باختبار تحميل لـ GET /products مع زيادة عدد المستخدمين الافتراضيين من 0 إلى 500 على مدار خمس دقائق.
لأول 200 مستخدم، يبقى وقت الاستجابة للنسبة المئوية 95 ثابتًا حول 180 مللي ثانية وتزداد المعالجة بالتوازي مع التحميل. هذه هي المنطقة الصحية؛ واجهة برمجة التطبيقات تواكب الأداء. عند حوالي 280 مستخدمًا، يبدأ وقت النسبة المئوية 95 في الارتفاع، 240 مللي ثانية، ثم 400 مللي ثانية، ثم 900 مللي ثانية، بينما تتسطح المعالجة بدلاً من الارتفاع. هذا التسطح هو الإشارة: لقد وصلت واجهة برمجة التطبيقات إلى سقفها. إضافة المزيد من المستخدمين الآن ينتج استجابات أبطأ، وليس المزيد من العمل المكتمل. بعد 420 مستخدمًا، يتسلل معدل الخطأ فوق 1% حيث تبدأ الطلبات في الانتهاء وقتها.
الحكم واضح وملموس. هذه الواجهة تخدم بشكل مريح حوالي 250 مستخدمًا متزامنًا ضمن ميزانية 200 مللي ثانية. سقفها العملي يقترب من 280، وتبدأ في الفشل حوالي 420. إذا كنت تتوقع ذروة حركة مرور تبلغ 200 مستخدم متزامن، فلديك سعة إضافية (مساحة للتوسع). إذا كنت تتوقع 350، فلديك مشكلة تحتاج إلى إصلاح قبل الإطلاق، وليس بعده.
هذا ما يقدمه اختبار الأداء: ليس "نجاحًا" أو "فشلًا"، بل خريطة واضحة لمواضع راحة واجهة برمجة التطبيقات، ومواضع إجهادها، ومواضع انهيارها.
عنق الزجاجة الشائعة في أداء واجهة برمجة التطبيقات (API)
عندما يكشف الاختبار عن سقف، يكون السبب عادةً أحد الجناة المألوفين القلائل.
استعلامات قاعدة البيانات البطيئة هي الأكثر شيوعًا. عمود غير مفهرس، أو نمط استعلام N+1، أو حد استعلام مفقود يحول نقطة نهاية سريعة إلى بطيئة لحظة ارتفاع حجم البيانات أو التزامن. إذا ارتفع زمن الوصول بينما تظل وحدة المعالجة المركزية للخادم منخفضة، فاشتبه في قاعدة البيانات أولاً.
تسحب الاستدعاءات الخارجية المعيقة نقطة نهاية إلى سرعة أبطأ تبعية لها. واجهة برمجة تطبيقات تستدعي مزود دفع أو خدمة طرف ثالث بشكل متزامن ترث زمن الوصول لتلك الخدمة وتعطلاتها.
يظهر استنزاف تجمع الاتصالات تحت الحمل المستمر: تنفد اتصالات قاعدة البيانات أو عملاء HTTP من واجهة برمجة التطبيقات وتنتظر الطلبات في قائمة الانتظار. هذا اكتشاف كلاسيكي لاختبار التحمل.
التسلسل غير الفعال لحمولات الاستجابة الكبيرة يستهلك وحدة المعالجة المركزية. إرجاع بيانات أكثر مما يحتاجه العميل يجعل كل استجابة أبطأ في البناء وأبطأ في النقل.
يشير اختبار الأداء إلى أين يقع السقف؛ وربطه بمقاييس جانب الخادم يخبرك لماذا.
دمج اختبار الأداء في عمليتك
اختبار الأداء الذي يتم تشغيله مرة واحدة قبل إطلاق كبير مفيد. اختبار الأداء الذي يتم تشغيله بانتظام أكثر قيمة بكثير، لأن الأداء يتدهور بصمت. يمكن لاستعلام قاعدة بيانات جديد، أو استدعاء تابع مضاف، أو عمود غير مفهرس أن يضيف زمن وصول لا يلاحظه أي اختبار وظيفي.
حدد ميزانية لوقت الاستجابة ومعدل الخطأ لنقاط النهاية الحيوية لديك، وتعامل مع أي تجاوز كمشكلة (فشل)، بنفس الطريقة التي تتعامل بها مع تأكيد معطل. قم بتشغيل اختبار تحميل أخف كجزء من التكامل المستمر/النشر المستمر (CI/CD) حتى يظهر أي تدهور عند طلب السحب، واحتفظ باختبارات الإجهاد والتحمل الثقيلة للاختبارات المجدولة قبل الإصدار.
احتفظ باختبارات الأداء بجانب الاختبارات الوظيفية. عندما يتعايشان معًا، يتم فحص كل تغيير في واجهة برمجة التطبيقات لكل من الصحة والسرعة، وتتوقف عبارتا "إنه يعمل" و"إنه يعمل بالسرعة الكافية" عن أن تكونا سؤالين منفصلين، يسهل نسيانهما.
الأسئلة المتداولة
ما الفرق بين اختبار التحميل واختبار الإجهاد؟ يطبق اختبار التحميل حركة المرور التي تتوقعها ويؤكد أن واجهة برمجة التطبيقات تتعامل معها. يدفع اختبار الإجهاد بما يتجاوز ذلك للعثور على نقطة الانهيار. يتحقق اختبار التحميل من التشغيل العادي؛ بينما يرسم اختبار الإجهاد خريطة لنمط الفشل.
هل يجب أن أنظر إلى متوسط أوقات الاستجابة أم النسب المئوية؟ النسب المئوية. يخفي المتوسط الجزء البطيء الأقصى. تُظهر النسب المئوية 95 و 99 ما يختبره فعليًا المستخدمون الأقل حظًا، وهذا ما يثير الشكاوى.
هل يمكنني اختبار أداء واجهة برمجة التطبيقات قبل الانتهاء من الواجهة الخلفية؟ يمكنك اختبار العقد والتصميم، لكن أرقام زمن الوصول ذات المغزى تتطلب بنية تحتية حقيقية. استخدم خادمًا وهميًا للعمل الوظيفي المبكر، وقم بإجراء اختبارات تحميل على التنفيذ الحقيقي.
كم مرة يجب تشغيل اختبارات الأداء؟ قم بتشغيل اختبار تحميل خفيف في CI عند كل تغيير لنقاط النهاية الحيوية، واختبارات إجهاد وتحمل كاملة قبل كل إصدار رئيسي. يتدهور الأداء بصمت، لذا فإن الفحوصات المنتظمة أفضل من تشغيل واحد كبير قبل الإطلاق.