Charles и mitmproxy помогают увидеть сетевой обмен мобильного приложения: запросы, ответы, заголовки, задержки и последовательность обращений. Для QA это способ понять, что стоит за симптомом на экране, и воспроизвести ответ сервера, который сложно получить обычными действиями.
Инструмент особенно полезен для ошибок, пустых данных и медленных ответов. Но proxy показывает только трафик, который действительно проходит через него. Отсутствие запроса в списке ещё не доказывает, что приложение вообще не общалось с сетью.
Как работает перехватывающий proxy
В обычной схеме устройство отправляет поддерживаемый трафик через компьютер с proxy. Для HTTPS инструмент устанавливает отдельные TLS-соединения и использует собственный центр сертификации. Чтобы читать содержимое, клиент должен доверять этому CA.
Это отличие принципиально: просто указать IP и порт недостаточно для расшифровки HTTPS. При этом часть метаданных или туннель CONNECT может быть видна даже тогда, когда содержимое запросов остаётся недоступным.
Подготовка безопасной среды
Используй тестовое устройство, тестовые аккаунты и согласованное окружение. Уточни, какой билд предназначен для сетевой диагностики и какие домены разрешено изменять. Перед началом запиши исходные настройки сети.
Обычно устройство и компьютер должны иметь доступ друг к другу; затем задаётся HTTP-proxy и проверяется доступность инструмента. В Charles настройка SSL Proxying определяет нужные HTTPS-хосты. В mitmproxy используются режим запуска и доверенный сертификат выбранной установки.
Почему сертификата может быть недостаточно
На Android доверие пользовательскому CA зависит от конфигурации приложения и его целевой платформы. Современное приложение не обязано принимать установленный пользователем сертификат только потому, что браузер его принимает. Для диагностики команда может подготовить debug-only trust configuration.
На iOS вручную установленный профиль с CA не включает доверие для SSL/TLS автоматически. На версиях с соответствующим разделом настроек включи full trust для нужного тестового сертификата в Certificate Trust Settings; расположение пункта сверяй с документацией своей ОС. Для сертификатов, установленных через MDM или Apple Configurator, правила доверия отличаются.
Certificate pinning дополнительно ограничивает допустимые сертификаты или ключи. Наличие pinning не является багом proxy. Для тестирования используй предусмотренную командой тестовую конфигурацию; изменение защиты production-приложения не должно становиться обычным шагом инструкции QA.
Какие данные искать в сессии
Начни с конкретного действия и короткого временного окна. Полезно сопоставить запрос интерфейсному событию, затем проверить метод, URL, тело, код ответа и фактическое содержимое.
- →Ушёл ли запрос после нажатия и сколько раз.
- →В правильное ли окружение и под правильным аккаунтом он направлен.
- →Совпадают ли параметры с введёнными данными.
- →Корректно ли приложение обрабатывает тело успешного ответа.
- →Есть ли повтор, редирект, отмена или зависший запрос.
Код 200 не доказывает правильность бизнес-результата. Например, ответ может содержать пустой список, а приложение ошибочно показывать прежний кэш.
Практический пример: обработка ошибки корзины
Представь, что нужно проверить временную недоступность корзины. Подмена выполняется только на тестовом endpoint и по согласованному сценарию.
- 1.Пройди получение корзины без изменений и сохрани исходный запрос с обычным ответом.
- 2.Настрой точечное правило для нужного URL и метода. Верни согласованный ответ 503 вместо штатного ответа.
- 3.Открой корзину. Ожидается понятное состояние ошибки, сохранение безопасного локального контекста и доступная повторная попытка.
- 4.Нажми повторить несколько раз. Проверь отсутствие неконтролируемого потока одинаковых запросов.
- 5.Отключи правило и повтори загрузку. Приложение должно восстановить актуальную корзину без перезапуска и без дублирования товаров.
- 6.Очисти активные правила и проверь обычный сценарий ещё раз, чтобы не оставить искусственную неисправность следующему тестировщику.
Подмена доказывает реакцию клиента на выбранный ответ. Она не подтверждает, что настоящий backend корректно формирует именно такой ответ в аварийной ситуации.
Подмена данных и границы эксперимента
Breakpoints, rewrite и локальные ответы позволяют проверить отсутствующее поле, пустой массив, нестандартное значение или задержанный ответ. Меняй по одному условию и сохраняй точное правило рядом с результатом.
Не смешивай тест клиентской устойчивости и проверку серверной валидации. Если ответ изменён после сервера, нельзя делать вывод, что backend сохранил подменённые данные. Для этого требуется отдельный запрос и проверка серверного состояния.
Медленная сеть и разрывы
Charles умеет ограничивать пропускную способность и добавлять задержку. Это полезно для загрузки экрана, таймаутов и повторных нажатий. Запиши параметры профиля и область его применения.
Однако HTTP-throttling не равен полноценной модели мобильной сети. Он не воспроизводит автоматически радиопомехи, handover между сетями, все особенности TCP и работу приложения через протоколы, обходящие proxy. Критичные сетевые сценарии дополняй реальными устройствами и подходящими сетевыми средствами.
Что делать, если трафика не видно
Проверь по порядку доступность компьютера, адрес и порт, разрешение соединения в proxy, активную сеть устройства, HTTPS-настройки и доверие CA. Затем выясни, использует ли приложение системный proxy и какой протокол применяет.
Не отключай проверки TLS вслепую. Если приложение продолжает работать, но сессия пуста, возможны другой маршрут, кэш, VPN или особенности сетевого стека. Если приложение перестало работать только с proxy, полезно изучить ошибку TLS и конфигурацию тестового билда.
Типичные ошибки и вывод
Самые частые ошибки — оставить активную подмену, забыть вернуть сетевые настройки и прикрепить сессию с действующими токенами. Перед передачей экспортов убирай секреты, cookies и персональные данные; после работы удаляй ненужное доверие тестовому CA.
Хороший сетевой эксперимент связывает действие, запрос, контролируемое изменение и ожидаемое поведение интерфейса. Charles и mitmproxy делают эти связи видимыми, если QA понимает границы перехвата и не переносит выводы клиента на всю систему.