اكسر واجهة برمجة التطبيقات (API) الخاصة بك
وجّه أي عميل إلى الوكيل، ثم حاكِ استجابة 500، أو أوقِف طلبًا مؤقتًا في منتصف الطريق، أو صدّر بالضبط ما حدث كملف HAR يمكنك تسليمه لزميلك.
إعادة إنتاج خطأ في واجهة برمجة التطبيقات يعني
نقطة نهاية بطيئة، أو جسم خطأ مشوّه، أو تنافس بين نداءين — لا شيء من هذا يسهل إثارته عند الطلب من خادم حقيقي.
لمهندسي الواجهة الخلفية والفل ستاك الذين يبنون أو يختبرون عميل واجهة برمجة تطبيقات — تطبيق جوال، واجهة أمامية، أداة سطر أوامر، أو مهمة CI — ويحتاجون لرؤية والتحكم في البايتات الدقيقة على السلك، لا فقط الاستجابة التي تعيدها حزمة SDK.
يقف proxy-server الخاص بـ Busymate بين عميلك وواجهة برمجة التطبيقات الحقيقية. يتم التقاط كل طلب مباشرة، ويعمل هنا أيضًا نفس محرك قواعد الحظر/المحاكاة/الإسقاط الذي يعمل في التقاط iOS وChrome — بحيث يمكنك الرد على طلب حقيقي باستجابة جاهزة، أو إسقاطه تمامًا، دون لمس الواجهة الخلفية.
عنوان PAC واحد،
بلا SDK، بلا وكيل يجب تثبيته — أي عميل يمكن توجيهه إلى وكيل يكون مدمجًا بالفعل.
محاكاة أو حظر أو إسقاط على السلك
أجب عن طلب مطابق بحالتك ورؤوسك وجسمك الخاص — أو أسقطه — باستخدام قواعد تعمل مباشرة داخل الوكيل نفسه، قبل أن يصل الطلب إطلاقًا إلى واجهة برمجة التطبيقات الحقيقية.
نقطة توقف، تعديل، إعادة إرسال
أوقف طلبًا مؤقتًا في منتصف الطريق، وعدّل HTTP الخام يدويًا، ثم واصل أو أعد الإرسال — أعِد إنتاج حالة تنافس أو حمولة مشوّهة دون كتابة سطر واحد من كود الاختبار.
صدّر إلى HAR، أو استخدمه عبر REST
صدّر التبادل بالضبط كملف HAR لزميلك أو لتقرير خطأ، أو صِل إلى نفس البيانات الملتقطة عبر واجهة REST البسيطة المبنية على PostgREST — لا حاجة لأي SDK في كلتا الحالتين.
- Proxy
- Dashboard
- REST
- MCP
من عميل غير مستقر إلى
بلا أي تغييرات في الكود على أي طرف.
- 01
توجيه العميل إلى الوكيل
قم بتهيئة العميل — هاتف، متصفح، خدمة خلفية، مهمة CI — من عنوان URL واحد للتهيئة التلقائية PAC. تبدأ الحركة بالتدفق فورًا.
- 02
إعادة إنتاج الفشل
حاكِ نقطة النهاية لإعادة الاستجابة المعطوبة التي تحتاجها، أو ضع نقطة توقف وعدّل الطلب أو الاستجابة الحقيقية يدويًا قبل أن تستمر.
- 03
تصدير أو استعلام النتيجة
صدّر التبادل كملف HAR لإرفاقه بتقرير خطأ، أو اسحب نفس الإدخالات الملتقطة من مجموعة اختباراتك عبر REST API.
كيف يعمل
يقف وكيل واحد بين عميلك وواجهة API الحقيقية؛ وتعمل القواعد داخله.
- 01
وجّه عميلًا إلى وكيلك
لكل جهاز هوية وكيل خاصة به وعنوان تكوين تلقائي للوكيل. الصق ذلك العنوان في إعدادات Wi-Fi للهاتف، أو ملف تعريف متصفح، أو متغيّر وكيل HTTP الذي تقرؤه خدمة خلفية أو مهمة CI، فتبدأ طلباته بالوصول إلى تدفق لوحة التحكم فورًا.
- 02
اكتب قاعدة، أو أوقف الطلب مؤقتًا
افتح إدخالًا واختر ما يجب أن يحدث في المرة التالية: أجب عن الطلب بحالتك وترويساتك وجسمك الخاص، أو أسقطه، أو ضع نقطة توقف ليتوقف الطلب المطابق التالي في منتصف الطريق. عدّل الطلب أو الاستجابة الخام يدويًا، ثم تابع أو أعد الإرسال.
- 03
سلّم التبادل إلى شخص آخر
صدّر الطلب والاستجابة كملف HAR لتقرير خطأ، أو اقرأ الإدخالات المُلتقَطة نفسها من مجموعة اختبارات عبر واجهة REST. يحمل كلاهما البايتات الفعلية التي عبرت السلك، لا تفسير SDK لها.
قبل توجيه عميل،
هل يحتاج عميلي إلى SDK أو تغيير في الشيفرة؟
لا. كل ما يمكن توجيهه إلى وكيل HTTP مُدمَج بالفعل — الهواتف والمتصفحات والخدمات الخلفية ومهام CI. يتولى الوكيل الالتقاط والقواعد؛ ويواصل عميلك التحدث إلى ما يظنه واجهة API الحقيقية.
هل يمكنني محاكاة نقطة نهاية واحدة فقط وترك البقية حقيقية؟
نعم. تتطابق القواعد مع أنماط المضيف والمسار، فيمكن لنقطة نهاية واحدة أن تعيد 500 مُعدًّا مسبقًا بينما تمر كل الطلبات الأخرى إلى الخلفية الحقيقية دون مساس.
هل تعطّل نقطة التوقف بقية حركة المرور؟
لا. يتوقف الطلب المطابق فقط؛ ويستمر كل شيء آخر في التدفق. تابع أو عدّل أو أعد الإرسال حين تكون جاهزًا، فيرى العميل النتيجة كما لو أن الخادم قد أجاب.
هل تستطيع اختباراتي قراءة حركة المرور المُلتقَطة؟
نعم. الإدخالات المُلتقَطة متاحة عبر واجهة REST بسيطة، فيستطيع اختبار التكامل التحقق مما أرسله العميل فعليًا بدلًا مما توقّعته المحاكاة.
توقف عن تزييف الواجهة الخلفية —
وجّه أول عميل لديك إلى الوكيل وحاكِ أو اكسر أو أعد إرسال طلبك الأول خلال دقائق.