Fiddler — семейство инструментов для анализа и изменения HTTP-трафика. Для QA он помогает проверить, что действительно отправил клиент, какой ответ получил и как пережил ошибку. Это полезно в веб-приложениях, настольных клиентах и других системах, которые можно направить через поддерживаемый прокси-маршрут.
Сначала уточните продукт и версию. Fiddler Classic и Fiddler Everywhere имеют разные интерфейсы и механизмы настройки. Названия AutoResponder, Rules и FiddlerScript нельзя механически переносить между инструкциями. В этой статье практическая подмена описана через Rules в Everywhere; для Classic проверяют соответствующий сценарий AutoResponder по его документации.
Какую задачу решает прокси
Представьте форму, которая иногда показывает «неизвестная ошибка». Fiddler позволяет связать её с запросом: был ли вызов, совпали ли параметры, какой статус и тело вернулись. Такое наблюдение помогает отделить ошибку сервера от неверной интерпретации ответа клиентом.
Прокси также возвращает заранее подготовленные ответы. Так можно проверить пустой список, отказ доступа и временную недоступность без ожидания случайного сбоя. Это контролируемая проверка клиента, поэтому результат подмены не следует выдавать за доказательство реального поведения серверной зависимости.
Маршрут и область захвата
Проверьте, что собственное тестовое приложение использует нужный прокси. Системные настройки могут не влиять на отдельный клиент со своим сетевым стеком. Отсутствие записи ещё не означает, что приложение не отправило запрос: возможны обход прокси, другой интерфейс или локальный кэш.
Ограничьте домены и процессы согласно задаче. Сначала выполните один контрольный запрос без подмены и найдите его по методу и пути. Если захватывается весь рабочий трафик компьютера, полезный сигнал теряется среди фоновых запросов, а состав сохраняемого артефакта становится сложнее контролировать.
HTTPS и доверие
Для чтения HTTPS нужно включить соответствующую расшифровку и установить доверие к корневому сертификату выбранного Fiddler на тестовом клиенте. Настройка только на компьютере не гарантирует доверие на телефоне или внутри отдельного runtime.
Pinning и собственное хранилище доверия могут препятствовать работе. Для своего приложения используйте согласованные настройки отладочной сборки. Если защищённая сборка отвергает сертификат прокси, это не повод отключать проверки в рабочем продукте. Факт прохождения через прокси и содержимое TLS-запроса — разные уровни наблюдения.
Сессия как доказательство
Смотрите не только статус. Важны request body, параметры, заголовки авторизации, Content-Type, редиректы и ответ. После действия сравните успешный и ошибочный случаи на одинаковой сборке и данных. Автоматический retry может создать вторую сессию с другим результатом.
Время запроса через прокси отражает выбранный маршрут и обработку инструментом. Оно помогает искать задержанный шаг, но не равно гарантированной серверной задержке. Для серьёзного вывода о производительности требуется контрольное измерение и наблюдение инфраструктуры, иначе причина замедления останется предположением.
Правило подмены в Everywhere
Rules связывает условия с действиями. Для тестового каталога ограничьте совпадение точным host, методом GET и путём /api/catalog. Создайте действие возврата ручного ответа со статусом 503 и JSON-телом, которое соответствует контракту ошибки приложения.
Проверьте порядок правил и факт применения в сессии. Вариант Return Manual Response завершает обращение локальным ответом, поэтому сервер не получает этот запрос. Изменение ответа, уже пришедшего от сервера, имеет другую семантику. Это различие принципиально для операций создания и сохранения.
Практический пример: временный отказ каталога
У собственного магазина каталог должен показывать понятное сообщение и кнопку повтора, сохраняя выбранные фильтры. Подготовьте тестовую сборку, запрос с фильтром и известный непустой результат. Сначала убедитесь, что без Rules сценарий работает.
- 1.Включите узкое правило возврата 503 с Content-Type application/json и согласованной структурой ошибки. Ожидается попадание только нужного запроса под правило.
- 2.Откройте каталог с фильтром. Ожидаются завершение loading, понятная причина временного отказа и доступное действие повтора.
- 3.Выключите правило и нажмите повтор. Ожидается успешная загрузка с тем же фильтром, без лишнего сброса состояния и бесконечных повторов.
- 4.Повторите эксперимент с пустой успешной коллекцией. Ожидается отдельное пустое состояние, которое не должно выглядеть как серверная ошибка.
Так QA проверяет различие бизнес-состояний, а не просто способность интерфейса вывести текст. Если ошибка API имеет другой контракт, учебное тело заменяют реальным согласованным образцом.
Повтор запросов и побочные эффекты
Повтор чтения обычно проще, чем повтор создания заказа, но метод сам по себе не гарантирует отсутствие побочного эффекта. Уточните контракт до повторного отправления. Для изменяющей операции нужны тестовые данные и понимание идемпотентности.
Если клиент не получил подтверждение, сервер мог выполнить действие. Проверьте итоговый объект отдельным чтением, затем повторите с исходным ключом идемпотентности, если он предусмотрен. Новый ключ может означать новую операцию; нельзя использовать его как универсальный способ «повторить без дубля».
Сохранение и передача материалов
Сохраняйте минимальный набор сессий, необходимый для воспроизведения. Укажите продукт Fiddler, версию, правило, сборку приложения и последовательность действий. Без правила коллега получит обычный успешный ответ и не сможет увидеть проблему клиента.
Удалите токены, cookie и личные данные из всего передаваемого материала. Даже запрос, не связанный с дефектом, может оказаться в файле рядом. Правило с секретом в заголовке тоже является чувствительным артефактом; текстовый экспорт не делает его автоматически безопасным для публикации.
Ошибки и завершение проверки
Частые ошибки — использовать инструкцию другой редакции, забыть включённое правило, считать локальный mock реальным отказом сервера и не проверить состояние после ошибки. Слишком широкое совпадение host или пути может затронуть обновление токена и создать вторичные симптомы.
После эксперимента выключите правила, восстановите сетевые настройки и уберите ненужное тестовое доверие по процедуре команды. Полезный результат работы — проверенная реакция на известный контракт, точный запрос и воспроизводимые условия, позволяющие разработчику исправить конкретное поведение.