Изменял ли параметры сети с помощью Charles

Настройка параметров сети с помощью Charles Proxy

Да, я активно использовал Charles Proxy для изменения параметров сети при тестировании веб- и мобильных приложений. Это мощный инструмент для анализа и модификации HTTP/HTTPS-трафика, который незаменим для QA-инженера при проверке устойчивости приложения к различным сетевым условиям, обработке ошибок и валидации бизнес-логики.

Ключевые сценарии использования Charles для изменения параметров сети

• Модификация запросов и ответов (Rewrite Tool):

    *   **Изменение заголовков (Headers):** Например, добавление или изменение `User-Agent` для эмуляции запросов с разных устройств или браузеров. Или модификация `Authorization` токенов для проверки сценариев истечения сессии.
    *   **Подмена параметров запроса (Query Parameters / Body):** Изменение данных, отправляемых на сервер (например, ID товара, суммы платежа), для проверки валидации на стороне сервера и обработки некорректных данных.
    *   **Подмена тела ответа (Response Body):** Локальная замена JSON/XML ответа от сервера. Это позволяет проверить, как клиентское приложение отображает различные данные (например, длинные тексты, специальные символы, отрицательные значения) без необходимости изменять бэкенд.

```javascript
// Пример правила Rewrite для подмены JSON-ответа
// Location: Response Body
// Match: "status": "success"
// Replace: "status": "error", "code": 500
```

• Симуляция различных сетевых условий (Throttling):

    *   Вкладка **Proxy -> Throttle Settings** позволяет эмулировать медленные сети (2G/3G), высокую задержку (latency) и потерю пакетов (packet loss). Это критически важно для тестирования:
        *   Таймаутов и механизмов повторных запросов (retry logic).
        *   Отображения лоадеров и состояния "скелетона" (skeleton screens) в UI.
        *   Работы приложения в условиях нестабильного соединения.

• Манипуляции с доменами и DNS (Map Remote / Map Local):

    *   **Map Remote:** Перенаправление запросов с одного домена на другой. Например, для тестирования на стейджинг-окружении, когда приложение жестко завязано на продакшн-домен.
    *   **Map Local:** Замена ответа от удаленного сервера на заранее подготовленный локальный файл (например, `.json`, `.xml`, `.html`). Идеально для тестирования конкретных сценариев, новых функций или ошибок, которые сложно воспроизвести на реальном бэкенде.

```bash
# Пример настройки Map Local для API endpoint
Map From: https://api.example.com/v1/user/profile
Map To: /Users/qa/local_responses/user_profile_error_404.json
```

• Прерывание и модификация запросов на лету (Breakpoints):

    *   Установка точек останова на конкретные запросы позволяет перехватить их до отправки на сервер или до получения клиентом. Это дает возможность вручную изменить любую часть запроса или ответа прямо в процессе выполнения, что полезно для отладки сложных последовательностей.

• Работа с SSL/TLS (SSL Proxying):

    *   Установка корневого сертификата Charles на тестовое устройство или в эмулятор позволяет расшифровывать и анализировать **HTTPS-трафик**, что является базовым требованием для современного тестирования. Без этого большинство манипуляций были бы невозможны.

Практический пример из опыта

При тестировании мобильного банковского приложения нам нужно было проверить сценарий, когда сервер обработки платежей возвращает редкую ошибку "INSUFFICIENT_FUNDS" с определенным кодом. Вместо того чтобы организовывать реальную нехватку средств на тестовом счете, я использовал Charles:

1. Включил SSL Proxying для домена платежного шлюза.
2. Нашел POST-запрос на /api/v1/payments.
3. Создал Rewrite Rule, которая перехватывала успешный ответ 200 OK и заменяла тело ответа на заранее заготовленный JSON с ошибкой.
4. Инициировал платеж в приложении и убедился, что:

    *   Приложение корректно отображает сообщение об ошибке пользователю.
    *   Сумма не списалась со счета.
    *   В истории операций не появился ошибочный платеж.
    *   Не возникло крешей или неконсистентных состояний UI.

Итог: Charles Proxy — это не просто "сниффер" трафика, а полноценная среда для контролируемого тестирования сетевого слоя приложения. Умение виртуозно изменять параметры сети позволяет проактивно находить дефекты, связанные с обработкой ошибок, безопасностью (например, реакция на подделанные ответы) и устойчивостью приложения, что напрямую повышает его качество и надежность.