Как использовал Charles для тестирования фичи

Использование Charles Proxy для тестирования функциональности

Charles Proxy — это инструмент для анализа и отладки сетевого трафика, который я активно использовал для тестирования различных фич, особенно в веб- и мобильных приложениях. Его применение выходит далеко за рамки простого просмотра запросов и позволяет глубоко анализировать, модифицировать и валидировать поведение системы. Вот как я применял Charles на практике.

Основные сценарии использования

1. Валидация корректности API-запросов и ответов

При тестировании новой фичи, например, добавления товара в корзину, я настраивал Charles на перехват трафика с тестового устройства или браузера. Это позволяло убедиться, что:

• Клиентское приложение отправляет корректный HTTP-запрос (метод, эндпоинт, заголовки, тело).
• Сервер возвращает ожидаемый HTTP-ответ (статус-код, структура JSON/XML).
• Данные в запросе и ответе соответствуют спецификации (например, все обязательные поля присутствуют, типы данных верны).

// Пример анализа тела POST-запроса на добавление в корзину в Charles
{
  "productId": 12345,
  "quantity": 1,
  "sessionId": "abcde-fghij-klmno"
}

2. Модификация трафика (подмена запросов/ответов)

Это одна из самых мощных возможностей Charles для тестирования пограничных случаев и негативных сценариев.

• Breakpoints: Я устанавливал точки останова на конкретные запросы. Это позволяло вручную изменить параметры запроса (например, подставить невалидный productId или отрицательное quantity) перед отправкой на сервер или изменить ответ от сервера (например, смоделировать ошибку 500) перед его получением клиентом.
• Map Local/Remote: Часто использовал функцию Map Local для подмены ответа от удаленного сервера на заранее подготовленный локальный файл. Это было незаменимо при:

    *   Тестировании фичи, когда бэкенд еще не готов. Я мог сымитировать любой ответ API.
    *   Проверке отображения клиентом длинных строк, специальных символов или нестандартных структур данных.
    *   Тестировании поведения приложения при различных состояниях (например, подмена ответа с пустым списком товаров).

3. Тестирование производительности и анализа скорости загрузки

Инструмент Sequence или Chart в Charles предоставляет наглядную временную шкалу выполнения запросов. С его помощью я:

• Выявлял "тяжелые" или медленные запросы, которые могли тормозить работу новой фичи.
• Определял, не дублируются ли лишние запросы (например, двойной вызов API при однократном действии пользователя).
• Замерял общее время, необходимое для завершения цепочки запросов, связанных с фичей.

4. Тестирование безопасности

Charles, выступая в роли прокси-сервера с поддержкой SSL, позволяет расшифровывать HTTPS-трафик (после установки сертификата на устройство). Это критически важно для проверки:

• Не передаются ли в теле запроса или заголовках чувствительные данные в открытом виде.
• Корректно ли реализована аутентификация и авторизация (проверка токенов, сессий).
• Настроены ли безопасные заголовки (например, Secure и HttpOnly для кук).

5. Отладка интеграций со сторонними сервисами

Если фича подразумевала интеграцию с платежным шлюзом, сервисом доставки или аналитикой, Charles был первым инструментом для проверки:

• Формируется ли корректный webhook от стороннего сервиса к нашему приложению.
• Какие данные мы отправляем внешнему API и что получаем в ответ.

Конкретный пример из практики

При тестировании фичи "Умные подсказки при поиске" в мобильном приложении я использовал Charles следующим образом:

1. Настройка: Установил сертификат Charles на тестовый iPhone и настроил прокси в Wi-Fi.
2. Базовый сценарий: Ввел в поисковую строку "тел". Убедился, что приложение отправляет асинхронный GET-запрос на эндпоинт /api/v1/search/suggest?q=тел и получает JSON-массив с подсказками ["телевизор", "телефон", "телескоп"].
3. Негативное тестирование (Map Local): Создал локальный JSON-файл с массивом, содержащим очень длинную строку (200+ символов) и спецсимволы. С помощью Map Local подменил ответ API этим файлом. Проверил, как клиентское приложение отображает такие данные — не ломается ли UI, не возникает ли крашей.
4. Негативное тестирование (Breakpoint): Установил Breakpoint на этот запрос. Изменил статус ответа в точке останова на 504 Gateway Timeout. Проверил, что в приложении появляется адекватное сообщение об ошибке, а не "вылетает" экран.
5. Проверка производительности: В инструменте Sequence увидел, что запрос выполняется 1.2 секунды. Это стало основанием для баг-репорта команде бэкенда о необходимости оптимизации.
6. Проверка кэширования: Повторил тот же запрос. Убедился, что заголовки ответа (Cache-Control) настроены корректно, и при повторном вводе "тел" запрос может не отправляться (если это предполагалось логикой).

Таким образом, Charles Proxy был для меня не просто "сниффером", а многофункциональной песочницей для комплексного тестирования сетевого слоя приложения. Он позволял проводить тестирование "черного ящика" на более глубоком уровне, эффективно находить дефекты на стыке клиента и сервера и значительно ускорять процесс отладки сложных фич.