Тестирование API: позитивные и негативные кейсы
Тестирование API: позитивные и негативные кейсы
Что такое тестирование API
Тестирование API — это отправка HTTP-запросов к серверу и проверка ответов без использования пользовательского интерфейса. Ты работаешь напрямую с логикой приложения, минуя браузер.
Это важно, потому что:
- API — контракт между frontend и backend; ошибки здесь ломают весь продукт
- Ты находишь баги раньше, чем UI готов
- Проверки быстрее и стабильнее, чем тесты через браузер
Позитивные тест-кейсы
Позитивный кейс — это сценарий, в котором ты передаёшь корректные данные и ожидаешь успешный ответ.
Примеры:
- Регистрация пользователя с валидным email и паролем →
201 Created, тело содержитidнового пользователя - Получение списка товаров →
200 OK, тело — массив объектов - Удаление существующей записи →
204 No Content
Цель позитивных кейсов: убедиться, что «счастливый путь» работает правильно.
Негативные тест-кейсы
Негативный кейс — это сценарий, в котором ты намеренно передаёшь некорректные данные и ожидаешь понятный ответ об ошибке.
Цель: убедиться, что API не «падает» и возвращает осмысленные коды и сообщения.
Категории кейсов для любого эндпоинта
| Сценарий | Ожидаемый статус |
|---|---|
| Корректные данные | 200 или 201 |
| Отсутствует обязательное поле | 400 или 422 |
| Неверный тип данных | 400 или 422 |
| Нет токена авторизации | 401 Unauthorized |
| Недостаточно прав | 403 Forbidden |
| Ресурс не найден | 404 Not Found |
| Конфликт / дубликат | 409 Conflict |
| Пограничные значения (максимальная длина строки, максимальное число) | 400 или 200 — зависит от правил |
Пограничные значения в API
Не забывай про граничные случаи:
- Строка длиной ровно в максимально разрешённые символы — должна пройти
- Строка длиной на 1 символ длиннее максимума — должна вернуть ошибку
- Число
0, отрицательное число,nullвместо числа
Шаблон тест-кейса для API
ID: TC-API-001
Эндпоинт: POST /api/users
Описание: Успешная регистрация пользователя
Предусловие: пользователь с таким email отсутствует в БД
Шаги:
1. Отправить POST /api/users с телом:
{ "name": "Иван", "email": "ivan@example.com", "password": "Secret123!" }
Ожидаемый результат:
- Статус: 201 Created
- Тело содержит поле id (число или строка)
- Тело содержит поле email равное "ivan@example.com"
- Поле password отсутствует в ответе
Разница между позитивным и негативным тестированием
| Позитивный | Негативный | |
|---|---|---|
| Входные данные | Валидные, корректные | Некорректные, отсутствующие, граничные |
| Цель | «Счастливый путь» работает | Ошибки обрабатываются правильно |
| Ожидаемый статус | 2xx | 4xx (реже 5xx — баг!) |
| Что проверяем | Полезные данные в ответе | Сообщение об ошибке понятное |
Правило: на каждый позитивный кейс должно быть минимум 2–3 негативных.
Что мы запомним
- API-тестирование = запросы + проверка ответов без UI
- Позитивные кейсы: корректные данные → успешный ответ (2xx)
- Негативные кейсы: некорректные данные → понятная ошибка (4xx)
- Каждый эндпоинт нужно проверить по всей матрице: авторизация, обязательные поля, типы данных, граничные значения
- Сообщение об ошибке должно быть информативным — не просто
500 Internal Server Error