Всегда ли успешный статус код двести?

Анализ успешного статус-кода 200 (OK)

Нет, успешный статус-код 200 (OK) не всегда означает, что запрос выполнился корректно с бизнес-логической точки зрения. Хотя код 200 указывает на техническую успешность обработки запроса на транспортном уровне (сервер получил, понял и обработал запрос), он не гарантирует семантической или функциональной корректности ответа. Это важнейший нюанс для QA-инженера, так как слепая проверка на статус 200 может пропустить критические дефекты.

Почему статус 200 ≠ полный успех?

1. Ложная положительность бизнес-логики: Сервер может технически успешно обработать некорректные данные, но вернуть ответ, который не соответствует ожиданиям.

    *   **Пример:** Отправка POST-запроса на создание пользователя с пустым обязательным полем `"username": ""`. Сервер может принять запрос, сохранить в БД запись с `NULL` или пустой строкой и вернуть `200 OK` с ID нового пользователя. С технической стороны всё "ок", но с бизнес-логики — это ошибка. Ожидается `400 Bad Request` или `422 Unprocessable Entity`.

1. Некорректная обработка ошибок в коде: Разработчики иногда возвращают 200 даже при внутренних сбоях, оборачивая ошибку в тело ответа.

   // Пример опасного ответа со статусом 200
   {
     "status": "error",
     "message": "Internal server error: database connection failed"
   }
   

    **Правильным** было бы использовать статус `500 Internal Server Error`. QA-инженер должен валидировать не только статус, но и **body ответа**.

1. Частичный успех: В некоторых API-дизайнах (например, для batch-операций) код 200 может возвращаться для результата, содержащего как успешные, так и неуспешные элементы.

   {
     "results": [
       {"id": 1, "status": "created"},
       {"id": null, "status": "error", "reason": "Validation failed"}
     ]
   }
   

    Необходим парсинг и проверка каждого элемента в коллекции.

1. Мошенничество или безопасность: Злоумышленник может намеренно настроить эндпоинт так, чтобы он всегда возвращал 200, маскируя факт взлома или утечки данных. Это требует проверки целостности и правдивости данных в ответе.

Что должен проверять QA-инженер помимо статуса 200?

• Структура тела ответа (JSON Schema/XML): Соответствует ли контракту (OpenAPI/Swagger)?
• Значения ключевых полей: Корректны ли id, status, total и другие бизнес-поля?
• Бизнес-логика: Привел ли запрос к реальному изменению состояния системы (проверка через БД, лог, другой запрос)?
• Сообщения об ошибках в теле: Нет ли скрытых error, warning?
• Заголовки ответа (Headers): Корректен ли Content-Type, Cache-Control и т.д.?
• Временные характеристики: Укладывается ли ответ в требования по производительности, даже если статус 200?

Рекомендации по тестированию

1. Автоматизируйте проверки комплексно: В автотестах не ограничивайтесь assert response.status_code == 200. Добавляйте:

   # Пример на Python с pytest и requests
   def test_create_user_success():
       response = requests.post(API_URL, json=valid_user_data)
       # Проверка статуса
       assert response.status_code == 201  # Для создания лучше 201 Created
       # Проверка структуры JSON
       json_response = response.json()
       assert "id" in json_response
       assert isinstance(json_response["id"], int)
       assert json_response["username"] == valid_user_data["username"]
       # Проверка через БД (опционально, интеграционный тест)
       user_from_db = db_get_user_by_id(json_response["id"])
       assert user_from_db is not None
   

2. Используйте валидацию по контракту: Инструменты вроде Pact или валидация через OpenAPI гарантируют, что ответ соответствует спецификации.

3. Тестируйте негативные сценарии: Убедитесь, что API возвращает адекватные HTTP-статусы для ошибок (4xx для клиентских, 5xx для серверных), а не 200 с описанием ошибки в теле.

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