كيفية اختبار تحميل الـ APIs بدون بايثون (بديل Locust)

ترغب في معرفة ما يحدث لواجهة برمجة التطبيقات (API) الخاصة بك عندما يقوم 80 شخصًا بالدفع في نفس الوقت. لذلك تفتح Locust، وأول شيء يطلب منك فعله هو كتابة فئة Python. تقوم بتعريف HttpUser. تزين الدوال باستخدام @task. تبني locustfile.py، وتعد بيئة افتراضية، وتثبت بعض التبعيات، ثم تحاول اكتشاف سبب عدم إعادة استخدام رمز المصادقة الخاص بك عبر الطلبات. لا شيء من هذا هو الاختبار الحقيقي. إنها تكلفة الدخول قبل أن يبدأ الاختبار.

Locust أداة ممتازة، وتصميمها الذي يركز على الكود هو جوهرها. ولكن إذا كان هدفك هو إجابة مباشرة على سؤال "هل يتحمل نقطة نهاية تسجيل الدخول الخاصة بي 100 مستخدم متزامن؟"، فإن كتابة وصيانة أداة Python تتطلب الكثير من الجهد للحصول على رقم واحد. هناك مسار أسرع عندما تكون طلبات API التي تريد اختبارها موجودة بالفعل في عميل API. باستخدام Apidog، يمكنك توجيه اختبار أداء إلى سيناريو اختبار موجود، وتحديد عدد المستخدمين الافتراضيين والمدة، وقراءة معدل النقل وزمن الاستجابة ومعدل الأخطاء من مخطط مباشر. لا يوجد locustfile، ولا تثبيت pip، ولا Python على الإطلاق.

ما يفعله Locust جيدًا بالفعل

Locust هي أداة اختبار حمل مفتوحة المصدر مكتوبة بلغة بايثون، وهي جيدة فيما صممت من أجله. تصف سلوك المستخدم كشفرة برمجية. المستخدم الافتراضي هو فئة بايثون، والأشياء التي يقوم بها هذا المستخدم هي دوال تقوم بوضع علامات عليها كمهام. إليك الشكل الكنسي لـ locustfile.py:

from locust import HttpUser, task, between

class CheckoutUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def browse_products(self):
        self.client.get("/api/products")

    @task(1)
    def add_to_cart(self):
        self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})

يمكنك تشغيله باستخدام locust -f locustfile.py، وفتح واجهة المستخدم الويب على localhost:8089، وتعيين عدد المستخدمين ومعدل التوليد، ومشاهدة الأرقام ترتفع. نظرًا لأن السلوك عبارة عن كود، فإنك تحصل على قوة تعبيرية حقيقية. منطق شرطي، توزيعات مهام مرجحة، رحلات مستخدمين متسلسلة، عملاء مخصصون لبروتوكولات تتجاوز HTTP، حالة مشتركة عبر الطلبات. التوزين @task(3) مقابل @task(1) أعلاه يعني أن التصفح يحدث ثلاث مرات أكثر من إضافة إلى سلة التسوق، وهو نوع من الواقعية لا يمكن لقائمة طلبات مسطحة التقاطه.

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

التكلفة هي الكود. كل اختبار هو برنامج تكتبه وتصححه وتحافظ عليه. إذا تغيرت واجهة برمجة التطبيقات الخاصة بك، يتغير locustfile. إذا احتاج مهندس جديد لتشغيل الاختبار، فإنه يحتاج إلى بيئة بايثون مطابقة. وإذا كنت لا تكتب بايثون بالفعل، تصبح اللغة نفسها متطلبًا أساسيًا للإجابة على سؤال لا علاقة له ببايثون.

حيث يصبح نموذج الكود أولاً مصدر احتكاك

يظهر الاحتكاك في ثلاثة أماكن.

أولاً، الإعداد. قبل أن تقيس أي شيء، تقوم بتثبيت بايثون، وإنشاء بيئة افتراضية، pip install locust، وكتابة الأداة. لإجراء فحص سريع "هل يمكن لنقطة النهاية هذه استيعاب 50 مستخدمًا"، فإن هذا يتطلب جهدًا تحضيريًا أكبر من الحمولة الفعلية.

ثانيًا، التكرار. ربما تكون لديك هذه الطلبات معرفة بالفعل في مكان ما. ربما في Postman، ربما في ملف .http، ربما في عميل API يستخدمه فريقك يوميًا. يعيد locustfile وصف الطلبات الموجودة بالفعل، بما في ذلك تدفق المصادقة، الرؤوس، وأجسام الطلبات. الآن أنت تحتفظ بنسختين من نفس المعرفة بواجهة برمجة التطبيقات، وتتباعدان.

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

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

نهج Apidog: اختبار حمل للطلبات الموجودة لديك بالفعل

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

إليك التدفق الكامل.

1. افتح سيناريو الاختبار الذي تريد إجراء اختبار الحمل عليه. هذا هو نفس السيناريو الذي كنت ستشغله كاختبار وظيفي عادي، بنفس الطلبات ونفس متغيرات البيئة.
2. اختر تشغيله كاختبار أداء بدلاً من تمريرة واحدة.
3. حدد عدد المستخدمين الافتراضيين. يدعم Apidog ما يصل إلى 100 مستخدم افتراضي، كل منهم يقوم بالتكرار عبر كل طلب في السيناريو بالتوازي طوال فترة الاختبار.
4. حدد مدة الاختبار. هذه هي المدة التي يستمر فيها المستخدمون الافتراضيون في التكرار.
5. حدد مدة تصاعد إذا كنت ترغب في زيادة تدريجية. خلال الدقائق X الأولى، يقوم Apidog بإحضار المستخدمين عبر الإنترنت بشكل تدريجي بدلاً من كلهم مرة واحدة؛ اضبطها على 0 وسيبدأ كل مستخدم افتراضي فورًا.
6. إذا كان السيناريو الخاص بك يعتمد على البيانات، فاختر وضع المطابقة. "المطابقة العشوائية" تجعل كل مستخدم افتراضي يسحب صفًا عشوائيًا من بيانات الاختبار الخاصة بك في كل حلقة؛ "المطابقة المتسلسلة" تتصفح الصفوف بالترتيب.
7. ابدأ الاختبار وشاهد اللوحة الحية.

يتم تحديث الرسم البياني في الوقت الفعلي. لكل واجهة برمجة تطبيقات في السيناريو، تحصل على إجمالي الطلبات، ومتوسط معدل النقل، ومتوسط زمن الاستجابة، وأقصى وأدنى زمن استجابة، والأخطاء. مرر مؤشر الماوس فوق الرسم البياني لرؤية الأرقام لشريحة زمنية معينة. يفكك تبويب "الأخطاء" الطلبات الفاشلة حتى تتمكن من رؤية نقطة النهاية التي بدأت في الانهيار ومتى. عندما ينتهي التشغيل، يحتفظ تبويب "تقارير الاختبار" بالسجل حتى تتمكن من مقارنة تشغيل اليوم بتشغيل الأسبوع الماضي بعد شحن تغيير.

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

مقارنة ملموسة

لنفترض أنك تريد التأكد من أن نقطة نهاية تسجيل الدخول تتعامل مع 100 مستخدم متزامن لمدة دقيقتين، مع تصاعد لمدة 30 ثانية.

في Locust، تكتب فئة مستخدم بمهمة تنشر بيانات الاعتماد، وتتعامل مع الرمز المميز الذي تعيده الاستجابة، وتخزنه لأي مكالمات متابعة، وتحفظ الملف، وتبدأ locust -f login_test.py، وتفتح واجهة المستخدم الويب، وتدخل 100 مستخدم، ومعدل توليد، ووقت تشغيل. إذا كانت معالجة الرمز المميز خاطئة، فإنك تقوم بتصحيح أخطاء بايثون قبل تصحيح أخطاء واجهة برمجة التطبيقات الخاصة بك.

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

كلاهما يصل إلى نفس نوع الإجابة. أحدهما يطلب منك كتابة برنامج وصيانته أولاً. والآخر يعيد استخدام ما لديك بالفعل. لرحلات المستخدم المعقدة التي يتم نمذجتها بواسطة الكود، يكون البرنامج يستحق العناء. أما بالنسبة لسؤال "هل نقطة النهاية الخاصة بي سريعة ومستقرة تحت الحمل"، فإن إعادة الاستخدام توفر الوقت.

حدود صادقة من كلا الجانبين

كن واضحًا بشأن المقايضات، لأن اختيار الأداة الخاطئة يضيع يومًا في كلتا الحالتين.

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

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

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

قراءة الأرقام التي تحصل عليها

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

معدل النقل (RPS/TPS) هو عدد الطلبات أو المعاملات في الثانية، وهو المعدل الذي خدمته واجهة برمجة التطبيقات الخاصة بك بالفعل. إنه الحد الأقصى لما يمكن لنظامك التعامل معه. إذا استقر معدل النقل بينما تستمر في إضافة مستخدمين افتراضيين، فقد وجدت نقطة تشبع.

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

معدل الخطأ هو نسبة الطلبات التي فشلت. اختبار نظيف عند حمل منخفض يبدأ في إظهار أخطاء 500 أو مهلات مع زيادة المستخدمين الافتراضيين يخبرك بالضبط أين يتعطل النظام. النقطة التي تبدأ عندها الأخطاء غالبًا ما تكون أكثر إثارة للاهتمام من رقم معدل النقل الخام.

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

إذا كنت تريد نسخة أعمق من هذا، فإن دليلنا لاختبار أداء API يوضح المقاييس وأنواع الاختبارات وكيفية قراءة المنحنيات، وتغطي مقالة أساسيات اختبار الأداء الانضباط الأوسع.

كيف يتناسب هذا مع الأدوات التي تقارنها بالفعل

إذا كنت قد استخدمت JMeter، فإن النموذج الذهني مشابه لـ Apidog، حيث يتيح كلاهما لك تهيئة اختبار الحمل من خلال واجهة مستخدم بدلاً من الكود. JMeter يقدم خطة اختبار أثقل تعتمد على XML ومنحنى تعلم أكثر حدة مقابل ذلك؛ يغطي البرنامج التعليمي لاختبار الحمل باستخدام JMeter هذا بالتفصيل. إذا كنت قد قمت بتشغيل حمل عبر Postman's collection runner، فقد رأيت نسخة أخف من نفس الفكرة، والتي تمت تغطيتها في اختبار الحمل باستخدام Postman، ويضيف Apidog تقارير أداء مخصصة بالإضافة إلى الطلبات التي يمكنك استخدامها أيضًا لاختبار API بدون Postman. يقع Apidog بين بساطة عدم الكود التي يريدها الناس وإعادة استخدام الطلبات التي تمنعك من صيانة أداة منفصلة.

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

البدء

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

قم بتنزيل Apidog ووجه اختبار أداء إلى نقطة نهاية تختبرها بالفعل. ستحصل على منحنيات معدل النقل، والكمون، ومعدل الخطأ قبل أن تكون قد انتهيت من كتابة locustfile المكافئ. يبقى Locust الإجابة الصحيحة للحمل الموزع والمصمم بالكود على نطاق واسع. أما بالنسبة للسؤال الذي يطرحه معظم المطورين بالفعل، فقم بتشغيل الطلبات الموجودة لديك بالفعل.

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

هل Apidog بديل مباشر لـ Locust؟

ليس لكل مهمة. لاختبار حمل طلبات API بما يصل إلى 100 مستخدم افتراضي دون كتابة كود، يحل Apidog محل سير عمل Locust بالكامل لأنه يشغل سيناريوهات الاختبار الموجودة لديك مباشرة. أما بالنسبة للحمل الموزع بأعداد مستخدمين عالية جدًا أو بروتوكولات غير HTTP مخصصة يتم نمذجتها في الكود، لا يزال Locust هو الأنسب.

هل أحتاج إلى كتابة أي كود لاختبار الحمل في Apidog؟

لا. تقوم بتهيئة المستخدمين الافتراضيين، ومدة الاختبار، ووقت التصاعد في واجهة المستخدم، ويقوم الاختبار بتشغيل الطلبات من سيناريو اختبار قمت ببنائه بالفعل. لا يوجد locustfile ولا بيئة بايثون لإعدادها.

كم عدد المستخدمين الافتراضيين الذين يمكن لـ Apidog محاكاتهم؟

ما يصل إلى 100 مستخدم افتراضي في اختبار أداء واحد. يقوم كل منهم بالتكرار عبر كل واجهة برمجة تطبيقات في السيناريو بالتوازي طوال المدة التي تحددها. إذا كنت بحاجة إلى أكثر من ذلك بكثير أو لحمل من مناطق متعددة، فإن أداة موزعة تعتمد على الكود مثل Locust هي الخيار الصحيح.

ما هي المقاييس التي يبلغ عنها اختبار أداء Apidog؟

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

هل يمكنني إجراء اختبار حمل بطلبات تعتمد على البيانات؟

نعم. إذا كان السيناريو الخاص بك مدعومًا ببيانات اختبار، فاختر "مطابقة عشوائية" لجعل كل مستخدم افتراضي يسحب صفًا عشوائيًا في كل حلقة، أو "مطابقة متسلسلة" لتصفح الصفوف بالترتيب.

هل يجب أن أستمر في استخدام Locust لأي شيء؟

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