В каких багах указывал информацию из Charles

Отчеты о дефектах с использованием Charles Proxy

При расследовании и описании дефектов (багов), связанных с проблемами в сетевом взаимодействии клиента и сервера, информация из инструмента Charles Proxy является ключевым доказательством. Charles (а также аналогичные инструменты, такие как Fiddler или mitmproxy) позволяет анализировать HTTP/HTTPS трафик, что критично для QA Engineer при тестировании API, веб-приложений и мобильных приложений.

Типы дефектов, где данные из Charles обязательны

Информация из Charles указывается в отчетах о дефектах для следующих категорий проблем:

1. Проблемы с API и сетевыми запросами

• Неверные HTTP статус-коды: Например, вместо ожидаемого 200 OK сервер возвращает 500 Internal Server Error или 404 Not Found.
• Ошибки в структуре ответа (JSON/XML): Ответ содержит неожиданные поля, отсутствуют обязательные данные, или структура нарушает контракт API.
• Проблемы с заголовками (Headers): Отсутствуют необходимые заголовки (например, Content-Type, Authorization), или их значения некорректны.
• Некорректное тело запроса (Request Body): Клиент отправляет данные в неправильном формате или с ошибками.

Пример описания в отчете:

**Ожидаемый ответ API:**
{
  "userId": 123,
  "status": "active"
}

**Актуальный ответ из Charles (Session #12345):**
{
  "userId": 123,
  "status": null  // Поле 'status' возвращается как null вместо строки.
}

2. Проблемы с производительностью и временем ответа

• Длительные задержки (High Latency): Запросы выполняются значительно медленнее, чем ожидается (например, более 2 секунд для ключевого API). В Charles можно увидеть точное время каждого запроса и ответа.
• Многократные вызовы одного эндпоинта (Duplicated Requests): Клиент отправляет несколько идентичных запросов вместо одного, что может приводить к перегрузке сервера или некорректному состоянию данных.

Пример описания:

**Запрос:** POST /api/v1/order
**Время выполнения (из Charles):** 15.2 секунды.
**Ожидаемое время:** < 3 секунды.
Причина: Серверный эндпоинт демонстрирует критическую деградацию производительности.

3. Проблемы с безопасностью и передачей конфиденциальных данных

• Передача чувствительной информации в незашифрованном виде: Запросы, которые должны использовать HTTPS, отправляются через незащищенный HTTP.
• Токены авторизации или пароли в URL-параметрах: Конфиденциальные данные видны в query string, что является нарушением лучших практик безопасности.

Пример:

**Запрос (из Charles):**
GET http://api.example.com/user?authToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...&password=secret123

**Проблема:** Критичные данные (токен и пароль) передаются в незашифрованном URL, подвергаясь риску перехвата.

4. Проблемы с кэшированием и управлением состоянием

• Неверные заголовки кэширования: Сервер возвращает Cache-Control: no-cache для ресурсов, которые должны кэшироваться, или наоборот.
• Сессионные данные не сохраняются: Анализ запросов показывает, что сессионные cookies не отправляются в последовательных запросах, приводя к "потере" сессии пользователя.

5. Дефекты, связанные с конкретной версией API или окружением

• Запросы к неправильному эндпоинту или версии: Клиент отправляет данные на api/v1/resource, хотя согласно документации должен использовать api/v2/resource.
• Различия в поведении между staging и production: Сравнение трафика в Charles в двух окружениях показывает, что staging-сервер возвращает корректные данные, а production — ошибку.

Как структурировать информацию из Charles в отчете о дефекте

В отчете (например, в JIRA, Bugzilla или другой системе) данные из Charles должны быть представлены четко и доказательно:

1. Контекст и шаги воспроизведения: Описать, какие действия пользователя приводят к проблемному сетевому запросу.
2. Ссылка на конкретный Session в Charles: Указать номер или имя записи (Session), чтобы разработчик мог самостоятельно изучить полный контекст.
3. Выделение проблемных частей запроса/ответа: Показать в отчете именно те фрагменты (заголовки, тело, статус-код), которые содержат ошибку, используя блоки кода.
4. Сравнение с ожидаемым поведением: Сослаться на документацию API, спецификацию или корректное поведение в другом сценарии.

Пример структуры описания дефекта:

**Заголовок:** [API] Эндпоинт `/api/v1/profile` возвращает поле `email` как `null` для активных пользователей.

**Шги воспроизведения:**
1. Авторизоваться в мобильном приложении.
2. Перейти в раздел "Мой профиль".
3. Наблюдается отсутствие email-адреса в интерфейсе.

**Доказательство из Charles (Session: 'Profile Load 2024-05-15'):**
Запрос:

GET https://api.example.com/api/v1/profile Headers: Authorization: Bearer <valid_token>

Ответ:
```json
{
  "name": "Иван Иванов",
  "email": null,  // ОШИБКА: ожидается строка с email.
  "phone": "+79001234567"

}

Ожидаемый ответ (согласно Swagger-документации):

{
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "phone": "+79001234567"

}

Окружение: iOS App v2.1.0, Backend Staging. Серьезность: High (нарушение функциональности ключевого модуля).

Таким образом, Charles Proxy предоставляет **неопровержимые технические доказательства** для дефектов, связанных с сетевой коммуникацией. Грамотное использование этих данных в отчетах значительно ускоряет диагностику и исправление проблем разработчиками, поскольку они получают не просто субъективное описание, а точный "снимок" того, что происходит на уровне HTTP/HTTPS.