Для какого тест кейса применял Sharles

Сценарии применения Charles Proxy при тестировании

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

1. Тестирование сетевых запросов и API

Это основная область применения Charles. Я использовал его для:

• Валидации корректности запросов и ответов. Просмотр точных HTTP/HTTPS запросов, которые отправляет клиент (заголовки, метод, тело), и сравнение их с ожидаемыми согласно спецификации API.
• Анализа структуры JSON/XML. Убедиться, что структура данных соответствует контракту, все обязательные поля присутствуют, типы данных верны.
• Отладки ошибок 4xx/5xx. Когда приложение получает ошибку от сервера, Charles позволяет мгновенно увидеть полный ответ сервера, включая тело с описанием проблемы, что ускоряет диагностику в разы.

// Пример анализа ответа API в Charles
{
  "status": "error",
  "code": 400,
  "message": "Validation failed", // В Charles видна точная ошибка от сервера
  "details": [
    {"field": "email", "error": "Invalid format"}
  ]
}

2. Мокирование и подмена ответов сервера (Stubbing/Mocking)

Функция Map Local или Rewrite в Charles критически важна для изоляции тестов и проверки поведения клиента при различных ответах бэкенда.

• Тестирование граничных условий и ошибок: Можно подменить реальный ответ сервера на, например, 500 Internal Server Error, 404 Not Found или ответ с некорректным телом данных. Это позволяет проверить, как фронтенд или мобильное приложение обрабатывает такие сценарии, без необходимости "ломать" реальный сервер.
• Тестирование на данных, которые сложно воспроизвести: Например, для проверки отображения длинного списка (пагинации) или специфичного состояния пользователя (например, "isPremium": true). Создаем локальный JSON```json {"user": {"subscription": "premium"}}

и подключаем его через **Map Local** к эндпоинту `/api/user/profile`.
*   **Ускорение разработки и тестирования**: Когда бэкенд еще не готов, можно быстро замокать его ответы и начать тестирование клиентской логики.

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

Инструмент **Timing** в Charles предоставляет детальную информацию о том, сколько времени занимает каждый этап запроса (DNS, Connect, SSL, Request, Response).

*   **Выявление "тяжелых" или медленных запросов**, которые тормозят загрузку страницы или работу приложения.
*   **Анализ влияния размера ответа (например, огромного JSON/изображения) на производительность**.
*   **Сравнение производительности разных окружений** (dev, staging, production).

### 4. **Тестирование безопасности (Security Testing)**

*   **Проверка, что чувствительные данные (токены, пароли) не передаются в URL (GET-параметрах) или в незашифрованном виде в теле запроса**.
*   **Анализ заголовков (headers) на предмет уязвимостей**: Например, проверка наличия и корректности заголовков `Content-Security-Policy`, `X-Content-Type-Options`.
*   **Перехват и изучение трафика HTTPS** (после установки сертификата Charles на устройство) для полного аудита защищенного обмена.

### 5. **Тестирование мобильных приложений**

Здесь Charles особенно мощный инструмент, так как позволяет увидеть весь сетевой трафик приложения.
*   **Отладка взаимодействия мобильного приложения с бэкендом**. Все запросы к аналитике, push-уведомлениям, платежным системам, основному API — все видно в одном месте.
*   **Тестирование работы приложения в условиях плохой сети** (функция **Throttling**). Можно эмулировать различные скорости (3G, Edge), высокую задержку (latency) и потерю пакетов (packet loss), чтобы проверить устойчивость и UX приложения.
*   **Мокирование ответов для мобильного приложения** так же, как и для веба. Это единственный способ быстро протестировать редкие сценарии на реальном устройстве.

### 6. **Тестирование кеширования и обновления данных**

*   Можно отслеживать заголовки `Cache-Control`, `ETag`, `Last-Modified` в запросах и ответах.
*   Проверить, отправляет ли клиент корректные заголовки при условных запросах (`If-None-Match`).
*   Убедиться, что приложение правильно обрабатывает `304 Not Modified` ответы от сервера.

### Конкретный пример тест－кейса

**Кейс:** *"Проверка обработки клиентом ошибки 'Недостаточно средств' при попытке оплаты"*

**Шаги с использованием Charles:**
1.  Найти в ленте Charles реальный запрос на создание платежа (например, `POST /api/v1/payment`).
2.  Через инструмент **Breakpoints** поставить точку останова на этот запрос.
3.  Инициировать оплату в приложении.
4.  Когда запрос "заморозится" в Charles, **подменить (Edit Response)** статус код и тело ответа на симуляцию ошибки от платежного шлюза.
```json
{
  "success": false,
  "error": {

"code": "INSUFFICIENT_FUNDS",
"message": "На вашем счете недостаточно средств"

  }

}

1. "Пропустить" (Execute) модифицированный запрос обратно в приложение.
2. Ожидаемый результат: Приложение корректно отображает пользователю понятное сообщение об ошибке, не падает и не позволяет повторно отправить тот же платеж.
3. Фактический результат: Фиксируется поведение приложения (успех или найденный дефект).

Таким образом, Charles Proxy — это не просто "сниффер трафика", а полноценная среда для активного тестирования, которая позволяет вмешиваться в клиент1Gсерверное взаимодействие, что делает его vital инструментом для QA Engineer при тестировании любого современного приложения, активно работающего с сетью.