أدوات اختبار أداء API: أي أداة تجيب عن أي سؤال

مطابقة أدوات اختبار أداء API بالأسئلة الثلاثة

الفئة التي تفتقدها معظم الفرق

كل فريق تقريبًا يقول إنه يجري اختبارات أداء لديه مولّد حِمل. وقليل جدًا منها لديه ما يراقب التراجع عند كل تغيير. وهذا ترتيب مقلوب من حيث التكلفة والعائد معًا.

نادرًا ما تتغير السعة بين إصدار وآخر، ولذلك لا يخبرك اختبارها المستمر بالكثير. أما تراجع الأداء فيأتي عبر طلب سحب واحد في كل مرة، وحين يلتقطه تشغيل سعة ربع سنوي تكون أمام ستة أشهر من الـ commits دون أن تعرف أيها أضاف الاستعلام غير المفهرس.

ما الذي تبحث عنه في كل فئة

• مولّدات الحِمل: هل يمكنك التحقق من أجسام الاستجابات، ولو على عيّنة منها. معظمها يتيح ذلك وقليل من الفرق يفعّله، وهكذا يخرج اختبار الحِمل بنتيجة نظيفة بينما كل استجابة فارغة.

• أدوات رصد التراجع: هل تقارن بسجلّك التاريخي أنت لا بعتبة مطلقة. فالأهداف المستعارة لا تخبرك بشيء عن منتجك.

• التحقق الوظيفي: هل يشمل الحالات الحدّية. فالاستعلام الذي يتدهور أداؤه مع حجم صفحة كبير مشكلة بنيوية ستجدها هنا قبل أن يكشفها اختبار السعة بوقت طويل.

قراءة المئين بأمانة

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

المئين p50 الذي يبدو جيدًا يخبرك عن الطلب الوسيط ولا يقول شيئًا عن تجربة من لم يحالفه الحظ. وp99 الذي يبدو جيدًا على endpoint يُستدعى ألف مرة في الساعة يعني مع ذلك عشرة طلبات بطيئة في الساعة، أي عشرة مستخدمين مستائين. أما المتوسط عبر جميع الـ endpoints فيكاد يكون بلا معنى، لأنه يخلط فحص السلامة بتوليد تقرير.

عادتان تُصلحان معظم ذلك. انظر إلى المئينات لكل endpoint لا مجمّعة، وانظر إلى p95 وp99 لا إلى المتوسط. والـ endpoints المهمة ستكون عادةً قائمة قصيرة، ومتابعة تلك الأرقام الأربعة عبر الزمن أنفع من أي لوحة معلومات تعرض كل شيء دفعة واحدة.

الترتيب الذي يوفّر المال

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

الإعداد نفسه متاح في لوحة تحكم TestSprite إن كنت تفضّل عدم تثبيت أي شيء محليًا. وبقية واجهة CLI موجودة في مستودع CLI.

الجلسات والقيم الملتقَطة والترتيب والتنظيف مشروحة في توثيق اختبار API.

مساران، والاختيار بينهما يتعلق حقًا بمن يملك خط الإنتاج. فربط GitHub App من لوحة التحكم لا يتطلب أي تغيير في مستودعك على الإطلاق، لأنه يتفاعل مع النشر الذي يُصدره بناؤك أصلًا. أما إضافة خطوة GitHub Actions فتضع الفحص داخل المستودع حيث يُراجَع كسائر عمليات البناء.

ما الذي يضيفه TestSprite

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

تُولَّد التغطية من جولة اكتشاف إضافةً إلى مواصفاتك. تُبقي Auto-Authentication الجلسات حيّة طوال التشغيل، وتنقل Dynamic Variables القيم بين الاستدعاءات، وتستنتج Dependency Chains ترتيب التنفيذ، ويزيل Auto-Cleanup ما أنشأه التشغيل بالضبط.

والقيمة في ذلك أن أرقام السعة لديك تبدأ في وصف خدمة تعمل فعلًا. فالاستعلام الذي يتدهور مع حجم صفحة كبير يظهر هنا بجزء يسير من تكلفة اكتشافه في تشغيل حِمل، وendpoint يعيد نتائج فارغة بصمت يتوقف عن تسجيل نتائج جيدة في الإنتاجية.