Projektowanie przypadków awarii za pomocą proxy debugującego
Wybierz modyfikacje HTTP, opóźnienia i przerwane wymiany zgodnie z zachowaniem klienta, które ma sprawdzić test oparty na proxy.
Proxy debugujące jest przydatne, gdy klient musi napotkać odpowiedź, której zwykły serwer rzadko wytwarza. Najpierw zdefiniuj zachowanie klienta, a następnie wybierz ingerencję, która wytwarza ten warunek.
„Żądanie nie powiodło się” to zbyt szeroki przypadek testowy. Prawidłowa odpowiedź błędu HTTP, odpowiedź, która nigdy nie dociera, i połączenie przerwane w połowie pobierania wymagają od aplikacji różnych rzeczy.
| Przypadek | Zachowanie do zbadania |
|---|---|
| Pełna odpowiedź błędu HTTP | Czy klient odczytuje status i stosuje zamierzoną politykę błędów |
| Opóźniona odpowiedź | Czy użytkownik może anulować i czy limit czasu działa na zamierzonym etapie |
| Nieoczekiwane pole nagłówka lub treści | Czy parsowanie i walidacja zawodzą w sposób jasny |
| Przerwana wymiana | Czy niepełne dane pozostają odróżnialne od ukończonego wyniku |
Użyj ingerencji na właściwej warstwie
Charles udostępnia punkty przerwania, które zatrzymują żądanie lub odpowiedź przed przekazaniem. Przechwycony komunikat można zbadać i edytować, przepuścić lub przerwać. Jego narzędzie Rewrite stosuje powtarzalne zmiany do pasujących nagłówków, adresów URL lub treści. Ograniczanie przepustowości kontroluje szerokość pasma i dodane opóźnienie.
Te mechanizmy mogą sprawdzić zachowanie klienta HTTP, ale limit szerokości pasma nie jest dokładnym modelem losowej utraty pakietów IP. Proxy może buforować dane, ponownie używać połączeń i otwierać osobne połączenie do źródła. Wybierz narzędzie do degradacji sieci, gdy wymagany warunek znajduje się konkretnie poniżej HTTP.
Zadbaj o to, by każdy przypadek był interpretowalny
Dopasuj zamierzony host i ścieżkę wąsko. Zacznij od zwykłej wymiany, włącz jedną zmianę i zapisz, co zostało zmienione. Jeśli ponowna próba dociera do drugiego punktu końcowego, zdecyduj, czy ta sama reguła ma wpływać na tę próbę. W przeciwnym razie bezwarunkowe przepisanie może zamienić każdą ścieżkę odzyskiwania w pierwotną awarię.
Przy przesyłaniu lub operacji podobnej do płatności utracona odpowiedź nie dowodzi, że serwer odrzucił żądanie. Uwzględnij tę niejednoznaczność w przypadku ponownej próby, zamiast twierdzić, że każdą awarię transportu można bezpiecznie powtórzyć.
Sprawdzanie lub edycja treści HTTPS wymaga, aby klient uczestniczył w konfiguracji inspekcji TLS proxy debugującego. Proxy, które przenosi tylko CONNECT, widzi zaszyfrowane bajty aplikacji. Użyj odizolowanej konfiguracji testowej i przywróć następnie jej routing oraz ustawienia zaufania, aby późniejsze obserwacje opisywały zwykłego klienta.