Расскажи про свой опыт работы с Charles

Опыт работы с Charles

Charles — это HTTP/HTTPS proxy для отладки сетевого трафика. Это незаменимый инструмент для QA Engineer при тестировании мобильных приложений и веб-приложений.

Что такое Charles?

Charles — это man-in-the-middle proxy, который перехватывает весь трафик (HTTP и HTTPS) между клиентом и сервером. Позволяет смотреть, редактировать, и переигрывать сетевые запросы.

Основные возможности

1. Просмотр трафика

• Все HTTP/HTTPS запросы видны в интерфейсе
• Видны headers, body, response, status codes
• Группировка по доменам

2. Редактирование запросов

• Перед отправкой можно изменить параметры
• Изменить headers
• Изменить body (параметры POST запроса)
• Очень полезно для тестирования edge cases

3. Проксирование мобильных приложений

• Подключаешь телефон к сети через Charles
• Видишь весь трафик из мобильного приложения
• Можешь перехватывать и редактировать запросы
• Тестируешь поведение при плохом интернете

4. Throttling (имитация плохого интернета)

• Можешь замедлить скорость интернета
• Simulate offline mode
• Тестируешь, как приложение работает при 2G/3G/LTE

5. Mocking и Recording

• Записываешь реальные запросы
• Потом можешь их переигрывать
• Создавать mock responses

6. Breakpoints

• Остановить запрос перед отправкой
• Отредактировать
• Отправить изменённый
• Или отменить запрос

Мой опыт использования

Сценарий 1: Тестирование мобильного приложения

Подключил iPhone к Charles (через WiFi прокси). Запустил приложение и видел все API запросы:

• GET /api/users?page=1
• POST /api/auth/login с credentials
• PUT /api/profile с обновлением профиля

Нашёл, что приложение отправляет plain-text пароль в POST body. Это было security issue. Подал баг.

Сценарий 2: Тестирование обработки ошибок

Использовал Charles Breakpoints:

1. Отправляю запрос на создание заказа
2. Charles останавливает запрос перед отправкой
3. Я изменяю response status code с 201 на 500
4. Отправляю изменённый response
5. Проверяю, как приложение обрабатывает ошибку сервера

Так я найденный баг — приложение падало вместо показания error message.

Сценарий 3: Имитация плохого интернета

Использовал Throttle:

• Установил скорость: 2G (~50 кbps)
• Запустил приложение
• Видел, что интерфейс зависает при загрузке изображений
• Разработчик добавил loading spinner и retry logic

Сценарий 4: Тестирование кэширования

Проверил Cache-Control headers в ответе:

• Некоторые ресурсы имели Cache-Control: max-age=3600 (час)
• Другие: no-cache (не кэшировать)
• Использовал Rewrite Rules в Charles для изменения headers и проверки поведения

Сценарий 5: Проверка HTTPS сертификатов

Установил Charles certificate на телефон. Это позволило перехватывать HTTPS трафик. Нашёл, что приложение не валидирует сертификат сервера — security issue.

Как использовать Charles пошагово

1. Скачать и установить Charles с официального сайта
2. Запустить Charles на компьютере
3. Для веб: открыть браузер, настроить proxy (обычно 127.0.0.1:8888)
4. Для мобильного:
   • Подключить телефон к той же WiFi сети
   • На телефоне настроить WiFi proxy на IP компьютера:8888
   • При первом запросе разрешить Charles перехватывать
5. Просмотреть трафик — все запросы видны в главном окне

Основные фичи которые использую постоянно

Breakpoints (главная фича для тестирования):

• Ставлю breakpoint на нужный endpoint
• Запускаю операцию в приложении
• Charles останавливает запрос
• Я редактирую параметры
• Отправляю изменённый запрос

Map Local (очень полезно):

• Настраиваю, чтобы запрос на api.production.com направлялся на localhost:3000
• Тестирую локальную версию с real mobile приложением
• Не трогаю production API

Rewrite (для сложных сценариев):

• Автоматически заменяю определённые значения в запросах
• Например, все Authorization: Bearer XXX заменяю на XXX_INVALID
• Тестирую обработку истёкших токенов

Типичные баги, найденные через Charles

1. Утечки sensitive data:

   • Пароли в plain-text
   • API ключи в headers
   • Personal info в query parameters

2. Отсутствие HTTPS:

   • Запросы идут по HTTP вместо HTTPS
   • Credentials передаются в незашифрованном виде

3. Плохая обработка ошибок:

   • Приложение падает при 500 ошибке
   • Не показывает user-friendly error message
   • Нет retry logic при timeout

4. Проблемы с кэшированием:

   • Кэш не обновляется
   • Кэш хранит sensitive данные
   • Outdated data показывается пользователю

5. Проблемы с сетью:

   • Приложение не работает при медленном интернете
   • Нет offline mode
   • Timeout слишком короткий

Альтернативы

• Burp Suite: мощнее, но платный
• Fiddler: для Windows, хорош для веб
• Wireshark: более низкий уровень, сложнее использовать
• Browser DevTools: встроено, для веб приложений

Мой совет

Charles — must-have инструмент для QA Engineer, особенно если тестируешь мобильные приложения или REST API. С ним можешь:

• Найти security issues
• Тестировать обработку ошибок
• Проверить данные, отправляемые на сервер
• Имитировать плохой интернет
• Модифицировать responses

Я использую Charles в 70% мобильных тестов. Это экономит массу времени и находит баги, которые невозможно найти обычным тестированием.