Что означают коды ответов?

Коды ответа HTTP: архитектурный фундамент веб-Testing

Коды состояния HTTP (HTTP Status Codes) — это стандартизированные числовые коды, которые сервер возвращает клиенту (например, браузеру или вашему тестовому скрипту) в ответ на его запрос. Они являются ключевым элементом протокола HTTP и выполняют две основные функции:

1. Информирование о результате обработки запроса.
2. Управление поведением клиента (например, перенаправление, повтор запроса).

С точки зрения QA Automation Engineer, понимание этих кодов критически важно. Они — не просто числа в логах или ответе curl. Это прямой индикатор состояния системы, который мы используем для:

• Валидации корректности API-эндпоинтов в автотестах.
• Обработки ошибок и создания устойчивых тестовых сценариев.
• Диагностики проблем при анализе падающих тестов.
• Тестирования негативных сценариев (например, проверка, что при неверных данных возвращается 400 Bad Request, а не 200 OK).

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

Основные классы кодов состояния

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

Встречаются реже, сигнализируют о промежуточном состоянии. Например:

• 100 Continue: Сервер готов принять тело запроса. Клиент может продолжать отправку.

2xx: Успех (Success)

Наиболее желаемые коды в позитивных тестах. Запрос успешно обработан.

• 200 OK: Стандартный ответ на успешные GET, PUT, POST запросы. Тело ответа содержит запрошенные данные.
• 201 Created: Успешно создан новый ресурс (обычно в ответ на POST). В заголовке Location часто возвращается URI созданного объекта.
• 204 No Content: Запрос успешно обработан, но тело ответа отсутствует (например, после успешного DELETE).

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

def test_create_user_returns_201():
    url = "https://api.example.com/users"
    user_data = {"name": "Alice", "email": "alice@example.com"}
    response = requests.post(url, json=user_data)

    # КРИТИЧЕСКАЯ ВАЛИДАЦИЯ: проверяем ожидаемый код ответа
    assert response.status_code == 201, f"Expected 201, got {response.status_code}"
    assert "Location" in response.headers  # Дополнительная проверка для 201

3xx: Перенаправление (Redirection)

Требуют дополнительных действий со стороны клиента для завершения запроса.

• 301 Moved Permanently: Ресурс навсегда перемещен на новый URI.
• 302 Found (или 307 Temporary Redirect): Временное перенаправление.
• 304 Not Modified: Используется для кеширования. Контент не изменился с последнего запроса (ответ на запрос с заголовками If-Modified-Since или If-None-Match).

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

Ошибка на стороне клиента (неверный запрос). Ключевая группа для тестирования негативных сценариев.

• 400 Bad Request: Общая ошибка, сервер не может обработать запрос из-за некорректного синтаксиса (например, невалидный JSON).
• 401 Unauthorized: Требуется аутентификация (клиент не предоставил учетные данные).
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (у клиента нет прав).
• 404 Not Found: Сервер не может найти запрошенный ресурс.
• 409 Conflict: Запрос конфликтует с текущим состоянием сервера (например, попытка создать дублирующий ресурс).
• 422 Unprocessable Entity: Запрос синтаксически корректен, но содержит семантические ошибки (часто при валидации бизнес-логики).

// Пример тестирования негативных сценариев (JavaScript, Jest + axios)
test('should return 400 for invalid user data', async () => {
    const invalidData = { email: 'not-an-email' }; // Невалидное поле
    try {
        await axios.post('/api/users', invalidData);
        fail('Expected request to fail with 400'); // Заставляем тест упасть, если не получили ошибку
    } catch (error) {
        expect(error.response.status).toBe(400);
        expect(error.response.data).toHaveProperty('message'); // Проверяем структуру тела ошибки
    }
});

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

Сервер не смог выполнить допустимый запрос. Это критический индикатор проблем в backend.

• 500 Internal Server Error: Общая ошибка сервера без конкретной причины.
• 502 Bad Gateway: Проблема при проксировании запроса (например, вышележащий сервер не ответил).
• 503 Service Unavailable: Сервер временно не может обработать запрос (перегрузка, техобслуживание).
• 504 Gateway Timeout: Таймаут при ожидании ответа от вышележащего сервера.

Практическое применение в Automation QA

1. Assertions (Утверждения): Каждый тест API должен начинаться с проверки ожидаемого кода состояния. Это базовый критерий прохождения/провала.
2. Тест- дизайн: При проектировании тестовых случаев мы явно указываем ожидаемый код ответа как для happy path, так и для unhappy path сценариев.
3. Логирование и отчетность: Коды ответа — это первое, что мы анализируем в отчетах об упавших тестах. 500 Internal Server Error явно указывает на проблему в окружении или баге в коде приложения, а не в тесте.
4. Нагрузочное тестирование: Процент ответов 5xx — ключевая метрика стабильности системы под нагрузкой.
5. Работа с Retry-логикой: В устойчивых (resilient) фреймворках автотестов часто реализуется повтор запросов при получении определенных кодов (например, 503, 504), но не при 400 или 404.

Понимание нюансов кодов (например, разницы между 401 и 403, или между 502, 503 и 504) позволяет автоматизатору не только писать корректные проверки, но и эффективно сотрудничать с разработчиками, точно описывая найденные дефекты в терминах протокола HTTP.