Когда я только начинала работать тестировщиком, снифферы трафика казались мне чем-то далеким. В голове было что-то типа: "Ну, это для тестировщиков мобилок и для разработчиков. Мне оно не надо". Но потом я постепенно начала их использовать и поняла, что сниффер это маст хэв вещь в некоторых случаях!
В этой статье расскажу о нескольких кейсах, где снифферы трафика могут реально сохранить кучу времени и некоторое количество нервов. Let's go!
1. Как поймать ошибку 500 не теряя сервер
Иногда хочется протестировать, как приложение отреагирует на ошибку 500 или 403. Но ведь сервер ради этого не ронять, правда? Или ждать, пока кто-то создаст специальный аккаунт с правами для 403? Сниффер приходит на помощь!
Что делаем:
Открываем сниффер, создаем правило в Map Local с названием "Эмуляция ошибки 500" и вводим нужный URL.
В поле ответа пишем: HTTP/1.1 500 Internal Server Error.
2. Перенаправляем трафик, а не ждем сборку от разработчиков
Иногда тестировать нужно прямо сейчас, а не через неделю, когда разработчики соберут новую версию. Хочется самому перенаправить трафик на другую ветку бэкенда. Сниффер опять помогает!
Действуем так:
Придумываем правило в Map Remote с названием "Перенаправление на новый сервер".
В поле "URL" вводим текущий адрес, на который улетают все запросы.
В поле "Host" вводим новый сервер, куда должны пойти запросы.
Сохраняем и видим, что наши запросы летят куда надо без помощи разработчиков.
3. Подменяем ответы сторонних API
Надо протестировать, как ваше приложение работает с разными ответами от внешних сервисов, но доступа к ним в тестовой среде нет? Не проблема! Подменяем ответ сниффером и радуемся.
Пример: проверяем, как приложение справляется с недоступностью сервиса. Подменяем ответ API на 503 Service Unavailable и смотрим, правильно ли отрабатывает логика приложения.
4. Проверка пустого состояния страницы
Чтобы увидеть, как выглядит пустой список или таблица, иногда нужно убить кучу времени на удаление данных через базу или API. Сниффер же позволяет сделать это за пару кликов. Разберем этот кейс на примере списка курсов пользователя на Stepik.
Вот исходное состояние страницы, когда у пользователя уже есть несколько курсов, которые он проходит:
Теперь давайте проверим, как выглядит страница без курсов. Для этого:
Ловим запрос, который возвращает список данных.
Кликаем правой кнопкой мыши по запросу и выбираем: Tools > Breakpoint > Сохранить.
Выполняем действие на сайте, которое триггерит этот запрос. Откроется окно с "пойманным" запросом.
Экзекьютим запрос, поскольку в самом запросе нам ничего менять не нужно.
В следующем окне открываем тело запроса и удаляем данные о всех записях. На скриншоте ниже показано, что именно нужно удалить:
После отправки измененного запроса снова смотрим на страницу. Теперь отображается пустое состояние с заглушкой. Вот как это выглядит:
5. Тестирование состояний объекта
Допустим, у нас есть заказ со статусом "Cancelled", а мы хотим посмотреть, что будет с другими статусами. Вместо того чтобы просить разработчиков или ждать изменений на сервере, меняем статус прямо в сниффере. На скриншоте ниже видно, что у нас есть заказ со статусом "Cancelled":
Что делаем:
Ловим запрос с данными заказа.
Меняем статус с "Cancelled" на "Just placed".
Отправляем измененный запрос. Теперь на странице отображается новый статус заказа и соответствующая подсказка. Вот как это выглядит:
Дополнительные кейсы
Вот еще несколько полезных сценариев для использования сниффера:
Тестирование таймаутов и медленного соединения. Эмулируем задержку и проверяем, как приложение справляется с этим.
Тестирование пагинации. Быстро подменяем ответы, чтобы увидеть, как работает разбивка на страницы.
Подмена заголовков запросов. Меняем User-Agent или Accept-Language, чтобы протестировать отображение контента для разных устройств и языков.
Заключение
Снифферы трафика — это не только для разработчиков и мобильных тестировщиков. Это мощный инструмент, который может помочь в самых распространенных кейсах. Если вы еще не использовали снифферы в своих проектах, самое время начать!
