Проєктування сценаріїв відмови за допомогою налагоджувального проксі
Обирайте правки HTTP, затримки та перервані обміни відповідно до поведінки клієнта, яку має перевірити тест на основі проксі.
Налагоджувальний проксі корисний, коли клієнтові треба зустріти відповідь, яку звичайний сервер створює рідко. Спершу визначте поведінку клієнта, потім виберіть втручання, що створює цю умову.
«Запит не вдався» — надто широкий тестовий випадок. Коректна відповідь із помилкою HTTP, відповідь, яка так і не надходить, і з’єднання, розірване посеред завантаження, вимагають від застосунку різного.
| Випадок | Поведінка для перевірки |
|---|---|
| Повна відповідь із помилкою HTTP | Чи читає клієнт статус і застосовує задану політику помилок |
| Затримана відповідь | Чи може користувач скасувати і чи тайм-аут спрацьовує на потрібному етапі |
| Неочікуване поле заголовка або тіла | Чи завершуються розбір і перевірка явною помилкою |
| Перерваний обмін | Чи залишаються неповні дані відрізнюваними від завершеного результату |
Втручайтеся на правильному рівні
Charles надає точки зупинки, які призупиняють запит або відповідь перед пересиланням. Перехоплене повідомлення можна оглянути й змінити, пропустити або перервати. Його інструмент Rewrite застосовує повторювані зміни до відповідних заголовків, URL або тіл. Обмеження смуги керує пропускною здатністю та доданою затримкою.
Ці засоби можуть перевірити поведінку HTTP-клієнта, але обмеження смуги не є точною моделлю випадкової втрати IP-пакетів. Проксі може буферизувати дані, повторно використовувати з’єднання та відкривати окреме з’єднання з джерелом. Виберіть засіб погіршення мережі, коли потрібна умова лежить саме нижче HTTP.
Зберігайте кожен випадок інтерпретовним
Зіставляйте потрібний хост і шлях вузько. Почніть зі звичайного обміну, увімкніть одну зміну й запишіть, що саме змінено. Якщо повторна спроба потрапляє на другу кінцеву точку, вирішіть, чи має те саме правило впливати на цю спробу. Інакше безумовне переписування може перетворити кожен шлях відновлення на початкову відмову.
Під час завантаження або операції, схожої на платіж, втрачена відповідь не доводить, що сервер відхилив запит. Включіть цю неоднозначність у випадок повторної спроби, а не стверджуйте, що будь-який збій передавання безпечно повторювати.
Перевірка або редагування вмісту HTTPS потребує, щоб клієнт брав участь у налаштуванні перевірки TLS налагоджувального проксі. Проксі, що передає лише CONNECT, бачить зашифровані байти застосунку. Використовуйте ізольовану тестову конфігурацію і після цього відновіть її маршрутизацію та налаштування довіри, щоб пізніші спостереження описували звичайного клієнта.