Что означает 400 ошибка?

Что означает HTTP статус 400 "Bad Request"?

Ошибка 400 "Bad Request" — это клиентский код состояния HTTP, который указывает, что сервер не может или не будет обрабатывать запрос из-за того, что он воспринимает как ошибку клиента (например, неправильный синтаксис запроса, неверную структуру сообщения или обманчивую маршрутизацию). В отличие от ошибок 5xx, проблема заключается не на стороне сервера, а в том, как запрос был сформирован и отправлен клиентом (браузером, мобильным приложением, другим сервисом).

Основные причины возникновения ошибки 400

• Некорректный синтаксис URL: Например, использование недопустимых символов (пробелы, неправильное кодирование), неправильная структура.
• Повреждённые или слишком большие заголовки (headers): Размер или содержание заголовков запроса (Cookies, Referer, User-Agent и т.д.) не соответствуют ожиданиям сервера.
• Некорректное тело запроса (для POST, PUT):

    *   Несоответствие формата (например, отправка XML, когда сервер ожидает JSON).
    *   Ошибки в синтаксисе JSON/XML (пропущенная запятая, кавычка).
    *   Несоответствие данных ожидаемой схеме (валидации).

• Проблемы с файлами cookie или кешем браузера: Устаревшие или повреждённые данные могут привести к отправке серверу непонятного запроса.
• Неверная кодировка данных или тип контента (Content-Type): Указание Content-Type: application/json при отправке данных в формате x-www-form-urlencoded.
• Проблемы с загрузкой файлов: Файл превышает допустимый размер, имеет неподдерживаемый формат или загрузка была прервана.
• Ошибки в веб-приложении (на стороне клиента): Скрипт может некорректно формировать AJAX-запросы или данные формы.

Роль QA Engineer в диагностике и предотвращении ошибок 400

Для инженера по обеспечению качества понимание этой ошибки критически важно для эффективного тестирования API и веб-приложений. Вот ключевые активности:

1. Тестирование негативных сценариев API:

    *   Намеренная отправка запросов с нарушением контракта API (спецификации OpenAPI/Swagger).
    *   Проверка валидации входных данных: пустые поля, неверные типы, значения вне допустимых диапазонов, SQL-инъекции.
    *   Тестирование граничных значений для параметров запроса.

    Пример теста на Python с использованием библиотеки `requests`:

```python
import requests
import pytest

BASE_URL = "https://api.example.com/v1/users"

def test_create_user_with_invalid_json():
    """Отправка некорректного JSON должен вернуть 400."""
    headers = {'Content-Type': 'application/json'}
    # Нарушен синтаксис JSON: нет закрывающей кавычки у email
    invalid_payload = '{"name": "John", "email": "john@example.com}'

    response = requests.post(BASE_URL, data=invalid_payload, headers=headers)
    assert response.status_code == 400, f"Ожидался статус 400, получен {response.status_code}"
    # Дополнительно можно проверить структуру тела ошибки от сервера
    error_body = response.json()
    assert "error" in error_body
    assert "Invalid JSON" in error_body["error"] or "Bad Request" in error_body["error"]
```

2. Анализ логов и деталей ответа:

    *   Сервер часто возвращает более детальное описание ошибки в теле ответа (в JSON или HTML). QA должен уметь находить и анализировать эту информацию.
    *   Пример тела ошибки в JSON:

```json
{
  "statusCode": 400,
  "message": "Validation failed",
  "errors": [
    {
      "field": "email",
      "message": "Invalid email format"
    }
  ]
}
```

3. Работа с сетевыми инструментами:

    *   Использование **вкладки Network** в браузере (Chrome DevTools) для просмотра точного запроса и ответа.
    *   Использование **Postman** или **Charles Proxy** для формирования запросов с преднамеренными ошибками и анализа сырых HTTP-заголовков и тела.

1. Воспроизведение багов: Когда пользователь сообщает об ошибке 400, QA должен уметь воспроизвести сценарий, изолировать проблему (браузер, данные, аккаунт) и предоставить разработчикам четкие шаги и логи.

Краткий алгоритм диагностики для пользователя/разработчика

• Шаг 1: Обновите страницу (F5) – возможно, разовый сбой.
• Шаг 2: Очистите кеш и куки браузера.
• Шаг 3: Проверьте URL на опечатки.
• Шаг 4: Попробуйте другой браузер или режим инкогнито.
• Шаг 5: Для API: проверьте корректность запроса с помощью инструментов (Postman), убедитесь в правильности формата тела и заголовков.
• Шаг 6: Изучите детали ответа от сервера (тело ошибки).

Вывод для QA: Ошибка 400 — это прямой сигнал о проблеме во взаимодействии клиента с сервером на уровне протокола или данных. Наша задача — не только находить такие сценарии в процессе тестирования, но и разрабатывать тесты, которые предотвращают попадание клиентов в такие ситуации, а также уметь быстро диагностировать коренную причину при поступлении баг-репорта.