Что будешь делать, если пришла ошибка 400

Стратегия исследования и исправления ошибки HTTP 400 (Bad Request)

При получении ошибки 400 (Bad Request) мои действия как QA-инженера будут структурированы и методичны. Эта ошибка указывает на проблему на стороне клиента — сервер не может обработать запрос из-за неверного синтаксиса, недопустимого формата или размера данных. Моя основная цель — локализовать причину, воспроизвести проблему и обеспечить её корректное исправление, а не просто «заглушить» ошибку.

1. Первичный анализ и сбор контекста

Прежде всего, я собираю максимальный объём информации:

• Источник ошибки: Откуда пришла ошибка? (UI-интерфейс, API-тесты, лог-файлы, мониторинг). Для API это особенно критично.
• Воспроизводимость: Стабильна ли ошибка? При каких условиях повторяется?
• Данные запроса: Какие именно данные и параметры отправлялись? Это ключевой момент.
• Стек технологий и окружение: На каком окружении возникла проблема (Prod, Stage, Dev), какая версия приложения/API.

Например, вижу такую ошибку в логах API:

{
  "timestamp": "2024-01-15T10:30:00Z",
  "status": 400,
  "error": "Bad Request",
  "message": "JSON parse error: Unexpected character ('@' (code 64)): expected a valid value...",
  "path": "/api/v1/users"
}

2. Воспроизведение и локализация проблемы

Я воссоздаю сценарий, используя инструменты для тестирования API (Postman, cURL, Swagger) или UI-автоматизацию. Это позволяет изолировать проблему.

# Пример проблемного запроса через cURL
curl -X POST https://api.example.com/v1/users \
  -H "Content-Type: application/json" \
  -d '{"email": "user@@domain.com", "name": "John "Doe""}' # Ошибка: двойной '@' и некорректные кавычки

Основные направления поиска причины 400 Bad Request:

• Невалидный формат данных:

    *   Несоответствие **Content-Type** (например, отправка XML при ожидании JSON).
    *   Синтаксические ошибки в JSON/XML (пропущенные кавычки, запятые, скобки).
    *   Передача данных в неверной кодировке.

• Нарушение контракта API/валидации:

    *   Отсутствие обязательного поля.
    *   Поле неверного типа (строка вместо числа).
    *   Значение поля вне допустимого диапазона (например, отрицательный возраст).
    *   Несоответствие формату (email, телефон, дата).
    *   Превышение максимального размера запроса или длины поля.

• Проблемы с URL и параметрами:

    *   Неверно сформированная URL-строка.
    *   Некорректные или недопустимые значения query-параметров.

3. Углубленное исследование и документирование

Если причина неочевидна, я углубляю анализ:

1. Сравниваю запрос, вызывающий ошибку, с успешными запросами (diff-анализ).
2. Изучаю спецификацию API (OpenAPI/Swagger) или документацию, чтобы проверить корректность ожиданий от контракта.
3. Проверяю, не изменился ли контракт API без уведомления (проблема compatibility).
4. Рассматриваю корреляцию с недавними деплоями или изменениями в коде.
5. Взаимодействую с командой: обсуждаю проблему с разработчиком (бэкенд/фронтенд), чтобы понять логику валидации.

Все шаги и найденные артефакты (логи, запросы, ответы) фиксирую в баг-репорте. Качественный отчёт должен содержать:

• Четкий заголовок (например: "API POST /api/v1/users возвращает 400 при email с двойным '@'").
• Шаги для воспроизведения (включая точные тестовые данные).
• Фактический и Ожидаемый результат.
• Приоритет/Серьезность (обычно высокий, так как это блокирующая ошибка клиентской части).
• Доказательства (скриншоты, логи, raw-запросы).
• Контекст (окружение, версия приложения).

4. Верификация фикса и меры на будущее

После того как разработчик устранит дефект, я выполняю:

• Проверку исправления: Удостоверяюсь, что исходный сценарий теперь работает корректно и возвращает ожидаемый успешный статус (например, 200 или 201).
• Регрессионное тестирование: Проверяю смежные сценарии, которые могли быть затронуты изменением (другие похожие endpoints, методы валидации).
• Инициация улучшений процессов:

    *   Предлагаю дополнить **автоматизированные тесты API** (например, в фреймворке **pytest + requests**) негативными сценариями, покрывающими найденный кейс. Это предотвратит регрессию.

```python
# Пример автотеста для проверки валидации email
def test_create_user_with_invalid_email_should_return_400():
    response = requests.post(
        API_URL + "/users",
        json={"email": "invalid-email@@domain.com", "name": "Test"},
        headers={"Content-Type": "application/json"}
    )
    assert response.status_code == 400
    assert "email" in response.text.lower()  # Проверка сообщения об ошибке
```

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

Таким образом, мой подход к ошибке 400 — это не просто констатация факта, а полноценное расследование, направленное на выявление коренной причины, эффективное взаимодействие с командой и внедрение превентивных мер для повышения качества продукта в долгосрочной перспективе.