mitmproxy

Чем mitmproxy интересен QA и когда scriptable proxy даёт больше пользы, чем просто просмотр сетевого трафика.

Обновлено:

Содержание

mitmproxy — набор инструментов для наблюдения и изменения сетевого обмена. Его ценность для QA особенно заметна, когда одного ручного просмотра мало: нужно повторяемо вернуть определённый ответ, добавить диагностический заголовок или проверить несколько сетевых условий. Правила можно выразить Python-кодом и обсуждать вместе со сценарием теста.

Работайте со своим приложением и согласованным тестовым окружением. Прокси влияет на маршрут и TLS, поэтому эксперимент должен иметь узкую область действия и контрольный прогон. Скрипт подмены проверяет реакцию клиента на выбранный ответ, а не корректность настоящего сервера при произвольном отказе.

Интерфейсы и режим работы

mitmproxy предоставляет интерактивный интерфейс, mitmweb — веб-интерфейс, mitmdump — запуск из командной строки. Они используют общие механизмы потоков и addons. Выбор интерфейса меняет удобство наблюдения, но не отменяет необходимость правильно направить трафик.

Начните с обычного явного прокси и одного тестового клиента. Более сложные режимы требуют отдельной настройки маршрута и прав. Если приложение не использует системный прокси, команда запуска сама по себе не заставит его обмен появиться в инструменте. Сначала подтвердите прохождение контрольного запроса.

Как читать flow

HTTPFlow связывает запрос и ответ с контекстом соединения. Для диагностики QA смотрит метод, host, путь, заголовки, body, статус и время. Запросы фонового обновления и аналитики нужно отличать от операции пользователя по данным и последовательности.

Особенно полезно сравнить успешную и ошибочную попытку. Если клиент отправляет другой идентификатор или повторяет запрос после timeout, подмена одного ответа может затронуть только часть цепочки. В отчёте запишите все значимые попытки, чтобы не описать несколько разных операций как один запрос.

HTTPS, CA и pinning

Для расшифровки HTTPS клиент должен доверять CA конкретной установки mitmproxy. Корневой сертификат и закрытый ключ — разные файлы; ключ не передают вместе с инструкцией для клиента. Установленное системное доверие не обязательно используется каждой библиотекой приложения.

Pinning может отвергать сертификат прокси даже при доверенном CA. Для собственного приложения применяют согласованную отладочную конфигурацию и отдельно проверяют защищённую сборку. Не следует отключать проверку сертификатов в рабочем коде ради удобства диагностики. После теста ненужное доверие и прокси-настройки убирают по процедуре команды.

Минимальный addon

Пример ниже возвращает 503 только для GET /api/catalog на собственном тестовом домене. Сохраните код как catalog_fault.py. Он создаёт ответ на этапе request, поэтому совпавший запрос не уходит к серверу. Это важно для интерпретации результата.

python
import json
from mitmproxy import http


def request(flow: http.HTTPFlow) -> None:
    req = flow.request
    if (
        req.pretty_host == "qa.example.test"
        and req.method == "GET"
        and req.path.split("?", 1)[0] == "/api/catalog"
    ):
        payload = {"code": "CATALOG_UNAVAILABLE"}
        flow.response = http.Response.make(
            503,
            json.dumps(payload).encode("utf-8"),
            {"Content-Type": "application/json"},
        )
shell
mitmdump --listen-host 127.0.0.1 --listen-port 8080 -s catalog_fault.py

Команда ограничивает прослушивание локальным компьютером; клиент на этом компьютере настраивают на 127.0.0.1:8080. Телефон не сможет обращаться к такому адресу на другом компьютере: для удалённого клиента нужен отдельный согласованный сетевой маршрут. HTTPS дополнительно требует описанного доверия.

Проверка самой подмены

До проверки интерфейса убедитесь, что addon возвращает ожидаемые статус, заголовок и тело. Затем выполните соседний запрос, который не должен совпасть. Он обязан идти обычным путём. Так проверяются обе стороны правила: нужное воздействие и отсутствие лишнего.

В примере query не влияет на сопоставление пути: все варианты каталога получают ошибку. Если задача касается только одного фильтра, уточните условие через разобранные параметры. Не используйте слишком общий поиск подстроки в URL, когда нужен определённый endpoint; случайное совпадение затруднит расследование.

Практический сценарий клиента

Каталог должен сохранять фильтры при временном отказе. Подготовьте тестовую сборку и непустой каталог. Сначала выполните запрос без addon и зафиксируйте нормальное состояние. Затем включите подмену и повторите ту же последовательность действий.

  1. 1.Откройте каталог с выбранной категорией. Ожидается понятное сообщение об отказе, завершение loading и сохранение выбора.
  2. 2.Нажмите повтор при активной подмене. Ожидается ограниченное, объяснимое поведение, без неконтролируемого цикла запросов.
  3. 3.Отключите addon и повторите загрузку. Ожидается успешный ответ и восстановление списка с исходными фильтрами.
  4. 4.Проверьте соседний раздел. Ожидается обычная работа: узкое правило не должно ломать профиль или авторизацию.

Сопоставьте число нажатий с попытками сети и состоянием клиента. Такой таймлайн помогает обнаружить дублирование обработчика или отсутствие остановки retry.

Ответ после серверной операции

Hook response применяется после получения серверного ответа и имеет другую семантику. Если изменить успешное подтверждение создания заказа на ошибку, сам заказ уже мог сохраниться. Это полезная проверка неопределённого результата, но она требует отдельной проверки конечного состояния.

Различайте отказ до отправки, задержку, обрыв соединения и подмену ответа после выполнения. Они могут выглядеть одинаково на экране, но проверяют разные гарантии. Для операций с побочными эффектами нужны уникальные тестовые данные, правила идемпотентности и план удаления созданных объектов.

Повторяемость и артефакты

Храните addon вместе с описанием предпосылок: сборка, домен, контракт ошибки и ожидаемый эффект. Изменение JSON-контракта может сделать старую подмену невалидной; тогда тест найдёт только несовпадение искусственного ответа. Отрицательный контроль помогает это заметить.

Если сохраняете flows, проверьте наличие токенов, cookie и персональных данных. Ограничивайте запись необходимым трафиком и очищайте артефакты перед передачей. Скрипт тоже может содержать секреты; не вставляйте постоянные credentials прямо в код ради удобного запуска.

Ошибки и границы инструмента

Частые ошибки — забыть выключить addon, неверно выбрать hook, считать mock доказательством серверного отказа и блокировать event loop тяжёлой синхронной работой. Прокси также способен менять тайминги, поэтому его измерения нельзя безусловно переносить на прямое соединение.

Хороший результат QA — маленькое понятное правило, подтверждённая область воздействия и проверенная реакция клиента. Такой сценарий легче повторить вручную и автоматизировать, чем пытаться воспроизвести случайную сеть, условия которой никто не записал.

Что ещё почитать