تصميم حالات الفشل باستخدام وكيل تصحيح

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

عبارة «فشل الطلب» حالة اختبار واسعة جدًا. فاستجابة خطأ HTTP صالحة، واستجابة لا تصل أبدًا، واتصال ينقطع في منتصف التنزيل، تطلب من التطبيق أشياء مختلفة.

استخدم تدخلًا في الطبقة الصحيحة

يوفر Charles نقاط توقف تُجمّد الطلب أو الاستجابة قبل تمريره. ويمكن فحص الرسالة المعترضة وتعديلها أو السماح بمرورها أو إجهاضها. وتطبّق أداة Rewrite تغييرات قابلة للتكرار على الترويسات أو عناوين URL أو الأجسام المطابقة. ويتحكم الخنق في عرض النطاق والزمن المضاف.

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

اجعل كل حالة قابلة للتفسير

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

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

يتطلب فحص محتوى HTTPS أو تعديله أن يشارك العميل في إعداد فحص TLS الخاص بوكيل التصحيح. الوكيل الذي ينقل CONNECT فقط يرى بايتات تطبيق مشفّرة. استخدم إعداد اختبار معزولًا وأعِد إعداد التوجيه والثقة بعده كي تصف الملاحظات اللاحقة العميل العادي.