Проверка заголовков, статусов, тел запроса и ответа
Проверка заголовков, статусов, тел запроса и ответа
Что нужно проверять в каждом API-тесте
Когда ты отправляешь запрос, недостаточно просто убедиться, что сервер не вернул ошибку. Полноценная проверка включает три уровня: статус-код, тело ответа и заголовки.
1. Статус-код
Статус-код — это первое, что ты смотришь. Он говорит о том, как сервер интерпретировал запрос.
| Диапазон | Смысл |
|---|---|
2xx | Успех |
3xx | Перенаправление |
4xx | Ошибка клиента (неверный запрос, нет прав) |
5xx | Ошибка сервера (баг!) |
Важно: статус-код должен точно соответствовать сценарию. 200 OK при создании ресурса — это ошибка; должен быть 201 Created. 200 OK при удалении — сомнительно; ожидается 204 No Content.
2. Тело ответа
После статус-кода проверяй содержимое ответа:
Позитивный сценарий — что проверить:
- Все обязательные поля присутствуют
- Типы данных совпадают с ожиданием (
id— число,email— строка,active— boolean) - Значения соответствуют тому, что было отправлено в запросе
- Чувствительные данные отсутствуют (пароли, токены не должны возвращаться)
- Нет лишних неожиданных полей (хотя это менее критично)
Негативный сценарий — что проверить:
- Поле
messageилиerrorсодержит понятное описание ошибки - Ошибка указывает на конкретное поле (например:
"email is required", а не просто"bad request") - Нет стек-трейса Node.js или SQL-запроса в ответе (это утечка информации)
Пример хорошего тела ошибки:
{
"error": "Validation failed",
"details": [
{ "field": "email", "message": "Email is required" },
{ "field": "password", "message": "Password must be at least 8 characters" }
]
}
3. Заголовки ответа
Заголовки содержат метаинформацию об ответе.
| Заголовок | Что проверять |
|---|---|
Content-Type | Должен быть application/json для JSON API |
Authorization | Токен не должен быть в ответе (если не предусмотрено) |
X-Request-Id | Полезен для трейсинга — должен быть уникальным |
Cache-Control | Важен для endpoint'ов с кешированием |
Минимум: всегда проверяй, что Content-Type: application/json присутствует, когда ты ожидаешь JSON.
4. Валидация схемы
Контракт API — это документ (например, Swagger), который описывает, как выглядит ответ.
Схема-валидация означает: ответ API соответствует описанному контракту.
Ты должен проверить:
- Все поля из контракта присутствуют
- Типы данных совпадают
- Обязательные поля не пустые (
nullили пустая строка вместо значения — это баг)
5. Производительность
Время ответа — тоже часть проверки.
| Ориентиры | |
|---|---|
| Хорошо | < 200 мс |
| Приемлемо | 200–1000 мс |
| Повод для внимания | > 1 секунды |
| Критично | > 3 секунд |
В Postman время ответа отображается рядом со статус-кодом.
Типичные ошибки тестировщиков
- Проверяют только статус-код. Сервер может вернуть
200 OKс пустым телом или с неверными данными — это баг. - Не проверяют тело при ошибке. Сообщение
"Something went wrong"— плохое; должно быть конкретное описание. - Игнорируют Content-Type. API, возвращающий HTML вместо JSON, сломает клиентское приложение.
Чеклист для каждого API-теста
[ ] Статус-код соответствует сценарию
[ ] Content-Type: application/json
[ ] Все обязательные поля в ответе присутствуют
[ ] Типы данных верные
[ ] Значения соответствуют входным данным
[ ] Чувствительные данные не утекают
[ ] При ошибке — сообщение информативное
[ ] Время ответа в допустимых пределах
Что мы запомним
- Три уровня проверки: статус-код, тело ответа, заголовки
- Один только статус-код — недостаточно; всегда проверяй тело
- Для JSON API обязателен
Content-Type: application/json - Тело ошибки должно содержать информативное сообщение
- Пароли и токены не должны попасть в ответ
- Схема ответа должна соответствовать контракту (документации)