Proiectarea cazurilor de eșec cu un proxy de depanare
Alegeți modificări HTTP, întârzieri și schimburi întrerupte în funcție de comportamentul clientului pe care trebuie să îl exerseze un test bazat pe proxy.
Un proxy de depanare este util când un client trebuie să întâlnească un răspuns pe care serverul obișnuit îl produce rar. Definiți mai întâi comportamentul clientului, apoi alegeți intervenția care produce acea condiție.
„Cererea a eșuat” este un caz de test prea larg. Un răspuns valid de eroare HTTP, un răspuns care nu sosește niciodată și o conexiune întreruptă la jumătatea unei descărcări cer lucruri diferite aplicației.
| Caz | Comportament de examinat |
|---|---|
| Un răspuns complet de eroare HTTP | Dacă clientul citește starea și aplică politica de eroare dorită |
| Un răspuns întârziat | Dacă utilizatorul poate anula și dacă timeout-ul se aplică în etapa dorită |
| Un câmp de antet sau de corp neașteptat | Dacă analiza și validarea eșuează clar |
| Un schimb întrerupt | Dacă datele incomplete rămân distingibile de un rezultat finalizat |
Folosiți o intervenție la nivelul potrivit
Charles oferă puncte de întrerupere care opresc o cerere sau un răspuns înainte de a-l transmite. Mesajul interceptat poate fi examinat și editat, lăsat să treacă sau anulat. Instrumentul său Rewrite aplică modificări repetabile antetelor, URL-urilor sau corpurilor potrivite. Limitarea controlează lățimea de bandă și latența adăugată.
Aceste controale pot exercita comportamentul unui client HTTP, dar o limită de lățime de bandă nu este un model precis al pierderii aleatorii de pachete IP. Un proxy poate stoca date în tampon, refolosi conexiuni și deschide o conexiune ascendentă separată. Alegeți un instrument de degradare a rețelei când condiția necesară se află în mod specific sub HTTP.
Păstrați fiecare caz interpretabil
Potriviți îndeaproape gazda și calea dorite. Începeți cu un schimb normal, activați o singură modificare și notați ce a fost schimbat. Dacă o reîncercare ajunge la un al doilea punct final, decideți dacă aceeași regulă ar trebui să afecteze acea încercare. Altfel, o rescriere necondiționată poate transforma fiecare cale de recuperare în eșecul original.
La o încărcare sau o operațiune asemănătoare unei plăți, un răspuns pierdut nu dovedește că serverul a respins cererea. Includeți acea ambiguitate în cazul reîncercării în loc să afirmați că orice eșec de transport este sigur de repetat.
Inspectarea sau editarea conținutului HTTPS necesită ca clientul să participe la configurarea inspecției TLS a proxy-ului de depanare. Un proxy care transportă doar CONNECT vede octeți de aplicație criptați. Folosiți o configurație de test izolată și restabiliți apoi rutarea și setările de încredere, astfel încât observațiile ulterioare să descrie clientul normal.