Что такое сниферы трафика и какие функции они выполняют?
Что проверяют
Умеете ли вы смотреть на систему ниже интерфейса и локализовать дефект: клиент отправил не то, сервер ответил не то или проблема в сети. От тестировщика ждут не определения из словаря, а понимания, что в перехвате видно, чего не видно и какой вывод из этого допустимо делать.
Как отвечать
Снифер перехватывает трафик на сетевом интерфейсе и показывает пакеты: адреса и порты, протокол, заголовки, тело, тайминги. Пассивные инструменты вроде tcpdump и Wireshark слушают интерфейс, прокси-перехватчики вроде mitmproxy, Charles и Fiddler встают между приложением и сервером и умеют ещё и вмешиваться.
Что это даёт в тестировании:
видно фактический запрос, а не то, что обещает документация; ловятся лишние, повторные и параллельные вызовы, которых по логике быть не должно; проверяются заголовки, коды ответов, сжатие, кеширование и поведение при ретраях; видно, где уходит время: установка соединения, ожидание ответа, размер тела; подменой ответа или обрывом соединения проверяется поведение клиента на ошибке и в офлайне; контролируется, что токены и персональные данные не уходят открытым текстом и не торчат в строке запроса.
Важная оговорка: для HTTPS пассивный перехват покажет только установление соединения, имя хоста, размеры и тайминги. Чтобы читать тело, нужен прокси со своим корневым сертификатом, доверенным на устройстве.
Где спотыкаются
Ожидают, что Wireshark покажет тело запроса к боевому API, и не понимают, почему видны одни шифрованные записи. Для разбора обмена нужен прокси с установленным сертификатом, а не пассивный снифер.
Забывают, что в коммутируемой сети виден только собственный трафик. Чужой требует зеркалирования порта на коммутаторе, и на чужой инфраструктуре такое не делается вовсе, это уже не тестирование.
На мобильных упираются в закрепление сертификата и объявляют, что сервер недоступен. На деле приложение само отвергло подставной сертификат, и это не дефект, а защита, для обхода которой нужна отладочная сборка.