डिबगिंग प्रॉक्सी के साथ विफलता केस डिज़ाइन करना

डिबगिंग प्रॉक्सी तब उपयोगी होती है जब क्लाइंट को ऐसी प्रतिक्रिया मिलनी हो जो सामान्य सर्वर शायद ही उत्पन्न करता है। पहले क्लाइंट का व्यवहार परिभाषित करें, फिर वह हस्तक्षेप चुनें जो वह स्थिति पैदा करता है।

“अनुरोध विफल रहा” बहुत व्यापक परीक्षण केस है। एक वैध HTTP त्रुटि प्रतिक्रिया, ऐसी प्रतिक्रिया जो कभी नहीं आती, और डाउनलोड के बीच में टूटा हुआ कनेक्शन—ये सभी एप्लिकेशन से अलग-अलग चीज़ें मांगते हैं।

सही परत पर हस्तक्षेप का उपयोग करें

Charles ऐसे ब्रेकपॉइंट देता है जो अनुरोध या प्रतिक्रिया को आगे भेजने से पहले रोक देते हैं। रोके गए संदेश की जाँच और संपादन किया जा सकता है, उसे जाने दिया जा सकता है या निरस्त किया जा सकता है। इसका Rewrite टूल मेल खाते हेडर, URL या बॉडी पर दोहराए जा सकने वाले बदलाव लागू करता है। थ्रॉटलिंग बैंडविड्थ और अतिरिक्त विलंब नियंत्रित करती है।

ये नियंत्रण HTTP क्लाइंट के व्यवहार का परीक्षण कर सकते हैं, लेकिन बैंडविड्थ सीमा यादृच्छिक IP पैकेट हानि का सटीक मॉडल नहीं है। प्रॉक्सी डेटा बफ़र कर सकती है, कनेक्शन पुन: उपयोग कर सकती है और अलग अपस्ट्रीम कनेक्शन खोल सकती है। जब आवश्यक स्थिति विशेष रूप से HTTP के नीचे हो तो नेटवर्क क्षय उपकरण चुनें।

हर केस को व्याख्यायोग्य रखें

इच्छित होस्ट और पथ को संकीर्ण रूप से मिलाएँ। सामान्य आदान-प्रदान से शुरू करें, एक बदलाव सक्रिय करें और दर्ज करें कि क्या बदला गया। यदि पुन: प्रयास दूसरे एंडपॉइंट तक पहुँचता है, तो तय करें कि क्या वही नियम उस प्रयास को प्रभावित करना चाहिए। अन्यथा एक बिना शर्त पुनर्लेखन हर रिकवरी पथ को मूल विफलता में बदल सकता है।

अपलोड या भुगतान जैसे ऑपरेशन में, खोई हुई प्रतिक्रिया यह सिद्ध नहीं करती कि सर्वर ने अनुरोध अस्वीकार कर दिया। हर परिवहन विफलता को दोहराना सुरक्षित है—यह दावा करने के बजाय उस अनिश्चितता को पुन: प्रयास केस में शामिल करें।

HTTPS सामग्री का निरीक्षण या संपादन करने के लिए क्लाइंट को डिबगिंग प्रॉक्सी के TLS निरीक्षण सेटअप में भाग लेना होता है। जो प्रॉक्सी केवल CONNECT ले जाती है, वह एन्क्रिप्टेड एप्लिकेशन बाइट्स देखती है। अलग परीक्षण कॉन्फ़िगरेशन का उपयोग करें और बाद में उसका रूटिंग और ट्रस्ट सेटअप बहाल करें ताकि बाद के अवलोकन सामान्य क्लाइंट का वर्णन करें।