Какой функционал Charles использовал?

Функционал Charles Proxy: основные возможности для тестирования

Charles Proxy — это инструмент для мониторинга и отладки HTTP/HTTPS-трафика, который я активно использовал в своей практике QA Engineer для решения широкого спектра задач.

Основные функционалы, которые я применял:

1. Перехват и анализ сетевого трафика (Traffic Monitoring и Inspection)

• Просмотр всех HTTP/HTTPS-запросов и ответов между тестируемым приложением (десктоп, мобильное устройство) и сервером. Это позволяет видеть фактические данные, уходящие с клиента и приходящие с бэкенда.
• Анализ структуры запросов: заголовки (headers), метод (GET, POST и т.д.), URL, параметры запроса (query strings).
• Детальный просмотр тела запроса/ответа (body) в удобных форматах: JSON, XML, HTML, plain text. Для JSON есть форматирование и сворачивание/разворачивание узлов.

// Пример просмотра JSON-ответа API в Charles
{
  "user": {
    "id": 12345,
    "name": "Иван Тестов",
    "email": "test@example.com"
  },
  "status": "success"
}

• Расшифровка HTTPS-трафика путем установки сертификата Charles на устройство или в браузер. Это критически важно для анализа защищенных соединений.

2. Маппинг и подмена данных (Map Local / Map Remote)

• Map Local — подмена ответа от удаленного сервера на данные из локального файла. Используется для:

    *   Тестирования различных сценариев ответа API (успех, ошибка 500, пустой ответ, некорректный JSON).
    *   Проверки отображения приложения при измененных данных (длинные строки, спецсимволы, кириллица).
    *   Тестирования при недоступном или недоделанном бэкенде.

• Map Remote — замена одного удаленного адреса (host/path) на другой. Полезно для перенаправления запросов на тестовые, стейджинговые или локальные сервера.

3. Брейкпойнты (Breakpoints)

• Остановка (перехват) выбранных запросов или ответов перед их отправкой. Позволяет:

    *   **Модифицировать запрос** на лету: изменить параметры, headers, тело (например, чтобы отправить неверный токен или несуществующий ID).
    *   **Модифицировать ответ** от сервера: чтобы протестировать, как приложение обрабатывает специфичные данные или ошибки.
    *   **Создавать негативные сценарии**, имитируя проблемы сети или логики бэкенда.

4. Генерация нагрузки и повтор запросов (Repeat / Repeat Advanced)

• Repeat: Быстрая повторная отправка выбранного запроса для проверки идемпотентности или воспроизведения бага.
• Repeat Advanced: Многократная отправка запроса с заданным количеством итераций и параллелизмом. Используется для простейшей проверки стабильности и нагрузки на отдельный эндпоинт.

5. Запись и экспорт сессий (Session Recording & Export)

• Сохранение всей сессии перехвата в файл .chls или .chlsx. Это незаменимо для:

    *   Документирования шагов воспроизведения сложного бага, связанного с API.
    *   Передачи логов трафика разработчикам для анализа.
    *   Создания коллекции реальных запросов для последующего использования в **Map Local** или для написания автотестов.

6. Эмуляция скорости сети (Throttling)

• Настройка ограничения пропускной способности и задержки (latency) для имитации медленных сетей (3G, EDGE). Ключевая функция для проверки:

    *   Поведения приложения в условиях плохого интернета.
    *   Корректности работы лоадеров и таймаутов.
    *   Отображения сообщений об ошибках сети.

7. Структурированный просмотр (Sequence / Structure)

• Режим Sequence: Показывает запросы в хронологическом порядке, что идеально для анализа последовательности действий.
• Режим Structure: Группирует запросы по доменам и путям, что сильно упрощает навигацию при работе с одним API.

Практическое применение в работе QA:

• Валидация API: Сверял фактические запросы приложения с требованиями в Swagger/OpenAPI спецификации.
• Локализация багов: Определял, где возникает проблема — на клиенте (не те данные отправляются) или на сервере (приходят ошибочные ответы).
• Тестирование безопасности: Проверял, не передаются ли в открытом виде чувствительные данные (пароли, токены) по HTTP, анализировал headers на предмет уязвимостей.
• Отладка интеграций: Анализировал взаимодействие с платежными системами, аналитиками (Google Analytics), push-уведомлениями.
• Подготовка тестовых данных: С помощью Map Local легко создавал нужные для теста состояния системы (например, учетную запись с нулевым балансом или определенной историей заказов).

Таким образом, Charles выступал для меня не просто «сниффером трафика», а центральным инструментом для глубокого тестирования клиент-серверного взаимодействия, создания сложных тестовых сценариев и эффективной отладки.