Дизајнирање случаи на неуспех со прокси за отстранување грешки
Изберете HTTP измени, доцнења и прекинати размени според однесувањето на клиентот што треба да го провери тест базиран на прокси.
Проксито за отстранување грешки е корисно кога клиентот треба да наиде на одговор што нормалниот сервер ретко го создава. Прво дефинирајте го однесувањето на клиентот, потоа изберете ја интервенцијата што го создава тоа состојба.
„Барањето не успеа“ е премногу широк тест случај. Важечки HTTP одговор со грешка, одговор што никогаш не пристигнува и врска прекината на средина од преземање бараат различни работи од апликацијата.
| Случај | Однесување што треба да се испита |
|---|---|
| Целосен HTTP одговор со грешка | Дали клиентот го чита статусот и ја применува предвидената политика за грешки |
| Одложен одговор | Дали корисникот може да откаже и дали временското ограничување се применува во предвидената фаза |
| Неочекувано поле во заглавието или телото | Дали парсирањето и валидацијата јасно не успеваат |
| Прекината размена | Дали нецелосните податоци остануваат разликливи од завршен резултат |
Користете интервенција на вистинскиот слој
Charles обезбедува точки на прекин што го паузираат барањето или одговорот пред проследување. Фаќениот порака може да се испита и уреди, да се пропушти или прекине. Неговата алатка Rewrite применува повторливи промени на соодветните заглавија, URL-а или тела. Ограничувањето го контролира пропусниот опсег и додаденото доцнење.
Овие контроли можат да го проверат однесувањето на HTTP клиент, но ограничувањето на пропусниот опсег не е точен модел на случајно губење на IP пакети. Проксито може да ги баферира податоците, повторно да ги користи врските и да отвори одделна врска кон изворот. Изберете алатка за влошување на мрежата кога потребниот услов е конкретно под HTTP.
Задржете го секој случај разбирлив
Тесно усогласете го предвидениот домаќин и патеката. Започнете со нормална размена, овозможете една промена и запишете што е променето. Ако повторниот обид стигне до втор завршен пункт, одлучете дали истото правило треба да влијае на тој обид. Инаку безусловното препишување може да ја претвори секоја патека за закрепнување во првобитниот неуспех.
При поставување или операција слична на плаќање, изгубениот одговор не докажува дека серверот го одбил барањето. Вклучете ја таа нејасност во случајот за повторување наместо да тврдите дека секој транспортен неуспех е безбеден за повторување.
Проверката или уредувањето на HTTPS содржина бара клиентот да учествува во поставувањето за TLS проверка на проксито за отстранување грешки. Прокси што пренесува само CONNECT гледа шифрирани бајти на апликацијата. Користете изолирана тест конфигурација и потоа вратете го неговото насочување и поставките за доверба, за да ги опишат подоцнежните набљудувања нормалниот клиент.