Charles Proxy помогает увидеть HTTP-обмен между приложением и сервером, а также управляемо изменить сетевые условия или ответы. Для QA это способ связать действие на экране с конкретным запросом: какие данные отправлены, что вернул сервер и как клиент обработал результат. Инструмент особенно полезен для труднодоступных состояний интерфейса.
Работа начинается с собственного тестового приложения и ограниченного набора доменов. Прокси становится частью пути запроса, поэтому сам способен изменить поведение. В отчёте нужно различать проблему продукта и эффект настроенного эксперимента. Наблюдение через прокси дополняет прямой контрольный запуск без него.
Как устроен маршрут
Клиент отправляет трафик через Charles, а Charles обращается к серверу. На компьютере прокси может быть задан системно или в конкретном приложении. На телефоне указывают адрес компьютера и порт в настройках используемой сети, если приложение поддерживает этот маршрут.
Проверьте доступность компьютера, правила доступа Charles и выбранный интерфейс сети. Если запросов нет, сначала выясните, использует ли клиент прокси. Не нужно сразу менять сертификаты: отсутствие маршрута, VPN, кэш и другой сетевой стек дают похожий внешний симптом.
Что требуется для HTTPS
Чтобы читать содержимое HTTPS, клиент должен доверять тестовому корневому сертификату Charles, а нужный домен должен быть включён в SSL Proxying. Наличие CONNECT или имени хоста без тела запроса ещё не означает, что расшифровка работает.
Системное доверие не гарантирует доверие внутри каждого приложения. Pinning и собственное хранилище сертификатов могут блокировать подключение. Для своего приложения используйте согласованную отладочную сборку и настройки доверия. Отключение проверки сертификата в рабочем продукте не является решением тестовой задачи; поведение защищённой сборки проверяют отдельно.
Как читать сессию
Очистите старые записи и выполните одно действие. Найдите запрос по домену, методу и пути. Сравните query, headers, body, статус, ответ и время. Убедитесь, что выбран именно запрос операции, а не фоновая аналитика или предварительная проверка.
Например, при сохранении профиля запрос может уйти дважды, ответить 200, но вернуть прежние данные. Это разные направления расследования: повторная отправка, контракт сервера или клиентское обновление состояния. Один скриншот списка запросов редко передаёт эту разницу без пояснения контекста.
Map Local для состояния интерфейса
Map Local позволяет вернуть содержимое локального файла вместо ответа подходящего URL. Для собственного каталога подготовьте JSON с пустым массивом items и свяжите файл с точным путём /api/catalog на тестовом домене. После запроса ожидается предусмотренное пустое состояние без падения клиента.
Проверьте Content-Type и фактически полученное тело; несогласованные заголовки могут создать другой дефект. Учитывайте правила сопоставления URL: у Map Local есть особенности обработки query. Если нужны разные варианты одного пути по параметрам, проверьте выбор правила и применяйте подходящий инструмент, вместо предположения о точном совпадении.
Rewrite и breakpoints
Rewrite удобен для повторяемого изменения заголовка или части ответа. Breakpoint позволяет остановиться перед отправкой запроса или выдачей ответа и изменить выбранные данные вручную. Выбирайте максимально узкое условие, чтобы не повлиять на вход, обновление токена и посторонние endpoint.
При изменении ответа уже выполненная серверная операция не отменяется. Если сервер создал заказ, а прокси подменил подтверждение ошибкой, заказ может существовать. Поэтому такие эксперименты требуют проверки конечного состояния и различения «сервер не выполнил» и «клиент не получил подтверждение».
Практический пример: ошибка сохранения
В собственном тестовом приложении форма профиля должна сохранять введённые данные после сетевой ошибки и предлагать повтор. Подготовьте отдельный аккаунт, исходное имя и новое тестовое значение. Сначала выполните успешный контрольный запрос и сохраните очищенный образец контракта.
- 1.Ограничьте правило точным тестовым доменом, методом и путём сохранения. Ожидается отсутствие влияния на загрузку профиля и авторизацию.
- 2.Подмените ответ на согласованную ошибку 503 с корректным для контракта телом. Ожидаются понятное сообщение, завершение loading и сохранение введённого значения.
- 3.Проверьте фактический профиль через независимое чтение. Если запрос дошёл до сервера, новое имя могло сохраниться несмотря на ошибку на экране.
- 4.Выключите правило, повторите действие и обновите экран. Ожидается согласованное состояние клиента и сервера, без повторных побочных операций.
Такой эксперимент проверяет обработку выбранного ответа. Он не моделирует все виды отказа сети и не доказывает, что настоящий сервер при перегрузке выдаёт точно такое тело.
Задержка и ограничение скорости
Снижение пропускной способности помогает исследовать загрузку ресурсов и поведение при медленном обмене. Задержка, пропускная способность и потеря соединения — разные факторы. Один режим throttling не заменяет реальные условия мобильной сети, переключение интерфейсов и все особенности транспорта.
Запишите параметры и посмотрите, к какому трафику они применены. Проверьте доступность отмены операции, понятность прогресса и восстановление после снятия ограничения. Если интерфейс остаётся заблокированным после успешного ответа, это важнее абстрактной оценки «медленно».
Почему результат может обманывать
Ответ способен прийти из браузерного кэша или service worker и не появиться в ожидаемом месте сессии. Приложение может повторить запрос автоматически, а глобальное правило затронет также повтор. Проверяйте количество попыток и их последовательность.
Прокси влияет на TLS и сетевой маршрут, поэтому измерения времени через него имеют ограничения. Для вывода о производительности сервера нужен подходящий эксперимент и контрольное измерение. Charles удобен для диагностики и моделирования ответа; сам по себе он не создаёт доказательство серверной ёмкости.
Артефакты, очистка и выводы
В баг-репорте укажите сборку, устройство, маршрут, правило, исходное действие и ожидаемое поведение. Приложите нужный запрос и ответ, удалив токены, cookie и личные данные. Перед передачей файла сессии проверьте весь его состав, включая фоновые обращения.
После проверки выключите правила, восстановите прокси-настройки и удалите ненужное тестовое доверие по процедуре команды. Частые ошибки — забыть активную подмену, считать ошибку ответа отменой операции и проверять только визуальное сообщение. Полезный результат Charles — точное объяснение реакции приложения на известные сетевые условия.