Какие еще ошибки бывают, кроме 400 и 500

Классификация HTTP-ошибок

Помимо известных 400 (Bad Request) и 500 (Internal Server Error), существует обширная классификация HTTP-статус-кодов, которые делятся на 5 классов. Понимание этих кодов критически важно для QA-инженера при анализе логов, тестировании API и составлении тест-кейсов.

1xx: Информационные коды (Informational)

Эти коды указывают на промежуточный статус обработки запроса. Они важны при тестировании долгих асинхронных операций или протоколов вроде WebSocket.

• 100 Continue: Сервер удовлетворён начальными данными запроса. Клиент может продолжать отправку.
• 101 Switching Protocols: Сервер согласен сменить протокол (например, с HTTP на WebSocket).
• 102 Processing (WebDAV): Сервер обрабатывает запрос, но ответ ещё не готов.
• 103 Early Hints: Возвращает часть заголовков ответа до финального ответа, чтобы браузер мог начать предзагрузку ресурсов.

2xx: Успешные коды (Success)

Говорят об успешной обработке запроса. Для QA важно проверять не только факт успеха (200), но и корректный код для конкретной операции.

• 200 OK: Базовый успешный запрос.
• 201 Created: Успешно создан новый ресурс (например, после POST). В ответе часто присутствует заголовок Location с URI созданного ресурса.
• 202 Accepted: Запрос принят, но обработка ещё не завершена (асинхронная задача).
• 204 No Content: Сервер успешно обработал запрос, но не возвращает никакого контента (часто после DELETE или PUT).
• 206 Partial Content: Сервер возвращает только часть контента, как запрошено в заголовке Range. Ключевой для тестирования загрузок/скачивания.

3xx: Коды перенаправления (Redirection)

Указывают на необходимость дополнительных действий со стороны клиента для завершения запроса. Обязательная область тестирования для веб-приложений.

• 301 Moved Permanently: Ресурс навсегда перемещён на новый URI.
• 302 Found (или 307 Temporary Redirect): Ресурс временно доступен по другому URI.
• 304 Not Modified: Используется для кэширования. Говорит клиенту, что можно использовать закэшированную версию ресурса, так как он не изменился.

4xx: Ошибки клиента (Client Error)

Проблема на стороне клиентского запроса. 400 (Bad Request) — лишь одна из них. QA-инженер должен уметь различать эти коды для точного баг-репортинга.

• 401 Unauthorized: Требуется аутентификация (клиент не представил учётные данные). Часто сопровождается заголовком WWW-Authenticate.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (у клиента нет прав). Отличие от 401 принципиально.
• 404 Not Found: Самый известный код — ресурс не найден на сервере.
• 405 Method Not Allowed: Использованный HTTP-метод не поддерживается для данного URI (например, вызвали DELETE для read-only эндпоинта).
• 408 Request Timeout: Сервер не дождался полного запроса от клиента в отведённое время.
• 409 Conflict: Запрос конфликтует с текущим состоянием сервера (например, попытка создать дублирующий ресурс).
• 422 Unprocessable Entity (WebDAV): Сервер понял запрос, синтаксис корректен, но не может выполнить из-за семантических ошибок (например, невалидное поле в JSON-теле запроса). Крайне важен при тестировании REST API.
• 429 Too Many Requests: Клиент исчерпал лимит запросов (Rate Limiting). Ключевой код для тестирования нагрузочных ограничений.

5xx: Ошибки сервера (Server Error)

Сервер не смог выполнить корректный запрос. 500 (Internal Server Error) — общая "неизвестная" ошибка сервера. Остальные коды уточняют проблему.

• 502 Bad Gateway: Сервер, выступая в роли шлюза или прокси, получил недействительный ответ от upstream-сервера.
• 503 Service Unavailable: Сервер временно не может обработать запрос из-за перегрузки или техобслуживания. Часто сопровождается заголовком Retry-After.
• 504 Gateway Timeout: Сервер, выступая в роли шлюза или прокси, не дождался ответа от upstream-сервера.
• 507 Insufficient Storage (WebDAV): На сервере недостаточно места для выполнения запроса.

Практическое значение для QA

Для инженера по качеству эти коды — не просто теория, а инструмент:

• Тестирование API: Валидация, что эндпоинты возвращают корректные и ожидаемые коды для различных сценариев (успех, невалидные данные, отсутствие прав).
• Анализ логов: Быстрая классификация проблем по коду ответа. Рост 5xx ошибок — сигнал для срочного investigation.
• Нагрузочное тестирование: Мониторинг появления 429 или 503 кодов для определения пределов системы.
• Тестирование безопасности: Анализ разницы между 401 и 403 помогает проверять корректность работы авторизации и аутентификации.
• Написание тест-кейсов: Четкие ожидаемые результаты для негативных сценариев.

Пример тест-кейса для проверки разных кодов ошибок при работе с API пользователя:

Сценарий: Попытка получения данных несуществующего пользователя
    Дано: У меня есть валидный access token
    Когда: Я отправляю GET запрос на /api/v1/users/999999
    Тогда: Я получаю ответ с кодом статуса 404
    И: Тело ответа содержит JSON с сообщением "User not found"

Сценарий: Попытка создания пользователя с некорректным email
    Дано: У меня есть валидные данные, кроме email
    Когда: Я отправляю POST запрос на /api/v1/users с телом {"email": "invalid-email", "name": "Test"}
    Тогда: Я получаю ответ с кодом статуса 422
    И: Тело ответа содержит массив ошибок валидации для поля "email"

Таким образом, глубокое понимание полного спектра HTTP-статус-кодов позволяет QA-инженеру не просто находить баги, а точно диагностировать их природу (клиентская/серверная сторона, проблема с авторизацией, валидацией, доступностью ресурса) и эффективно коммуницировать с разработчиками, что напрямую влияет на скорость и качество разработки продукта.