Как работал в Sharles

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

Моё понимание и применение Charles Proxy

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

1. Анализ и валидация сетевых запросов и ответов (Core Functionality)

Это базовая, но критически важная функция. Я использовал Charles для:

• Верификации корректности отправляемых данных (Request). Убеждался, что клиентское приложение (веб, мобильное) формирует запросы с правильными:

    *   **HTTP-методами** (GET, POST, PUT, DELETE).
    *   **Заголовками** (Headers), особенно `Authorization`, `Content-Type`, `User-Agent`.
    *   **Параметрами** (Query parameters для GET) и **телом запроса** (Body для POST/PUT), например, в форматах JSON или XML.

• Верификации корректности получаемых данных (Response). Анализировал:

    *   **Коды состояния HTTP** (200 OK, 400 Bad Request, 401 Unauthorized, 500 Internal Server Error).
    *   **Структуру и данные в теле ответа.** Сравнивал с ожиданиями из спецификации (OpenAPI/Swagger) или с эталонными ответами.
    *   **Заголовки ответа** (например, `Cache-Control`, `Set-Cookie`).

// Пример анализа тела POST-запроса в Charles (вкладка "JSON Text")
{
  "user": {
    "email": "test@example.com",
    "password": "securePass123"
  }
}
// В ответе ожидал увидеть структуру с токеном и данными пользователя.

2. Отладка и расследование дефектов (Debugging & Troubleshooting)

Когда тест выявлял баг, Charles становился первым инструментом расследования.

• Локализация проблемы: Определял, где именно возникает ошибка — на стороне клиента (некорректный запрос) или сервера (ошибочный или пустой ответ).
• Анализ ошибок 4xx/5xx: Детально изучал тело ответа с ошибкой, которое часто содержит ключевую информацию для разработчиков.
• Сравнение с рабочим сценарием: Записывал трафик успешного и неуспешного сценария, сравнивал запросы «поблочно» в вкладке "Compare" или с помощью diff-инструментов, что часто сразу указывало на различие.

3. Модификация трафика (Map Local, Map Remote, Rewrite, Breakpoints)

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

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

    *   Тестирования обработки клиентом **новых структур данных API**, ещё не реализованных на бэкенде.
    *   **Эмуляции различных ответов:** пустых массивов, `null`-значений, очень длинных строк, специфических ошибок.

• Rewrite: Создавал правила для динамического изменения запросов и ответов «на лету». Например:

    *   Добавлял/удалял заголовки.
    *   Подменял значение конкретного поля в JSON-ответе (например, изменить статус заказа с `"active"` на `"expired"` для проверки соответствующей логики в UI).

• Breakpoints (Точки останова): Останавливал выбранный запрос или ответ, позволяя инспектировать и модифицировать его перед отправкой. Незаменим для:

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

// Пример правила Rewrite в Charles для подмены поля в ответе:
// Match: URL содержит "/api/user/profile"
// Response: Body (JSON)
// Replace: $.data.balance → "999999"
// Это позволило проверить отображение больших сумм в интерфейсе.

4. Тестирование производительности и оптимизации (Performance)

• Анализ времени отклика (Timing): Вкладка "Timing" визуализирует водопад запросов (Waterfall Chart), помогая выявить:

    *   Самые «тяжёлые» по времени ответа запросы.
    *   Последовательные запросы, которые можно было бы сделать параллельными.
    *   Лишние или дублирующиеся запросы.

• Throttling (Имитация медленных сетей): Настройка Preset: "3G" или "GPRS" через меню Proxy → Throttle Settings. Это критически важно для:

    *   Проверки **поведения мобильного приложения** в условиях плохой связи.
    *   Тестирования **лоадеров, таймаутов и обработки ошибок** сети.
    *   Оценки юзабилити на низких скоростях.

5. Работа с HTTPS трафиком (SSL Proxying)

Для анализа зашифрованного трафика необходимо:

1. Установить корневой сертификат Charles на устройство/в эмулятор.
2. Включить SSL Proxying для нужных доменов (часто *.example.com). Эта настройка — обязательный шаг для тестирования современных приложений. Я всегда строго следовал правилам безопасности компании при работе с таким трафиком, не анализируя данные, не предназначенные для тестирования.

Вывод и ценность для процесса QA

Моя работа с Charles не была изолированной. Она интегрировалась в общий процесс:

• Документирование: Сохранение сессий (.chls файлы) и скриншоты конкретных запросов-ответов для прикрепления к баг-репортам в Jira, что значительно ускоряло работу разработчиков.
• Коллаборация: Демонстрация воспроизведения бага на уровне сети на созвонах с бэкенд- и фронтенд-командами.
• Автоматизация: Понимание структуры API, полученное через Charles, — это фундамент для написания стабильных и корректных API-автотестов (на Python + Requests, JavaScript + Axios и т.д.).

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