Какие знаешь типы статус-кодов, кроме 200-х, 400-х и 500-х?

Типы HTTP статус-кодов

Помимо хорошо известных 200-х (Success), 400-х (Client Error) и 500-х (Server Error), в спецификации HTTP (RFC 7231 и другие) существуют другие значимые категории статус-кодов, которые играют важную роль в тестировании API и веб-приложений. Их понимание критично для QA Automation Engineer, так как они определяют различные состояния запроса и требуют корректной обработки в тестах.

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

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

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

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

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

Эта категория требует от клиента выполнения дополнительных действий для завершения запроса. Их корректная обработка в автотестах — залог устойчивого тестового сценария.

• 301 Moved Permanently: Ресурс перемещен на новый постоянный URL. Все будущие запросы должны использовать новый адрес. Тесты должны проверять, что клиент (или браузер в UI-тестах) корректно сохраняет это изменение.
• 302 Found (или 307 Temporary Redirect): Ресурс временно доступен по другому URL. Исходный URL должен использоваться для будущих запросов.
• 304 Not Modified: Ответ на условный запрос (например, с заголовком If-Modified-Since). Клиент может использовать локально сохраненную (кешированную) версию ресурса. Это важно для тестирования эффективности кеширования.
• 308 Permanent Redirect: Аналогичен 301, но также требует, что метод запроса (POST, PUT) не должен изменяться при перенаправлении.

# Пример проверки 301 редиректа в автотесте (Python + requests)
import requests

response = requests.get('http://old-example.com/resource', allow_redirects=False)
assert response.status_code == 301
assert response.headers['Location'] == 'http://new-example.com/resource'

Контекст для QA Automation

Знание всех категорий статус-кодов позволяет:

• Написать более точные и надежные assertions в тестах API. Мы ожидаем не просто "success", а конкретный код, соответствующий бизнес-логике (например, 201 Created после POST или 204 No Content после DELETE).
• Реализовать корректную логику обработки ошибок в тестовых фреймворках и скриптах. Например, 429 требует стратегии retry, а 401 — повторной аутентификации.
• Тестировать нестандартные и edge-case сценарии: Проверка поведения системы при получении 100 Continue, обработка сложных цепочек редиректов (302 -> 200), валидация кеширования через 304.
• Интерпретировать логи и результаты тестов: Понимание, что 503 Service Unavailable — это проблема инфраструктуры, а 422 Unprocessable Entity — ошибка в данных запроса, помогает быстрее локализовать дефект.
• Создавать негативные тесты (Negative Testing): Использование кодов типа 418 I'm a teapot (шутливый код из RFC 2324) может помочь проверить обработку неизвестных статусов сервером или клиентом.

В автоматизированном тестировании особенно важно не только проверять статус-код, но и анализировать сопутствующие заголовки (headers) и тело ответа (body). Например, для кода 301 обязателен заголовок Location, а для 429 — часто присутствуют заголовки Retry-After.