Тестирование POST-запроса в Postman: валидные и невалидные сценарии

При разработке и отладке REST API с методом POST, принимающего данные пользователя (имя, email, пароль), критически важно правильно подобрать тестовые данные. Многие начинающие разработчики ограничиваются только валидными значениями, однако на практике для обеспечения надёжности API необходимо тестировать как корректные, так и некорректные сценарии. В этой статье мы разберём, какие тестовые кейсы чаще всего используют профессионалы и как настроить их в Postman.

Почему важно тестировать невалидные данные?

API, работающий только с идеальными запросами, уязвим к ошибкам ввода, атакам (например, SQL-инъекциям) и некорректному поведению клиентов. Проверка невалидных данных позволяет:

• Убедиться, что сервер возвращает понятные коды ошибок (400, 422) и сообщения
• Предотвратить сохранение мусора в базу данных
• Защитить систему от злоумышленников
• Проверить корректную работу валидации на стороне бэкенда

Какие тестовые сценарии использовать?

1. Валидные данные (Happy Path)

Базовый сценарий: отправьте корректные данные, чтобы убедиться, что API работает. Пример тела запроса:

{
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "password": "Qwerty123!"
}

Ожидаемый ответ: HTTP 201 Created или 200 OK, в теле - ID пользователя или подтверждение.

2. Невалидные данные (Negative Testing)

Обязательно проверьте следующие случаи:

• Пустые поля: отправьте запрос без имени, email или пароля. Сервер должен вернуть 400 Bad Request с указанием обязательных полей.
• Некорректный email: test@, user@.com (без домена), пустая строка. Ожидайте 422 Unprocessable Entity.
• Слабый пароль: меньше 8 символов, без цифр или спецсимволов. Проверьте, что сервер отклоняет такие значения.
• Дубликат email: повторная отправка уже зарегистрированного email. Должен вернуться 409 Conflict.
• Спецсимволы и XSS-инъекции: имя вида <script>alert('xss')</script>. Убедитесь, что данные экранируются или отклоняются.

3. Граничные значения (Boundary Testing)

Проверьте:

• Имя из 1 символа и из 255 символов (максимальная длина)
• Email с максимальной длиной (254 символа)
• Пароль из 7 символов (меньше минимума) и из 129 символов (больше типичного лимита)

4. Отсутствие обязательных полей

Отправьте запрос только с name и password (без email). Сервер должен вернуть ошибку валидации. Аналогично - только с email.

Как организовать тесты в Postman?

Используйте коллекции и переменные среды для автоматизации. Для каждого сценария создайте отдельный запрос с предустановленным телом. Вкладка Tests позволяет писать скрипты на JavaScript для проверки статус-кода и тела ответа. Пример простого теста:

pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);
});
pm.test("Response has user id", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.id).to.not.be.null;
});

Также можно использовать Runner для прогона всех тестов сразу.

Что чаще всего проверяют на практике?

По опыту продакшен-проектов, наиболее частые проверки:

• Валидация email (формат, уникальность)
• Минимальная длина пароля и его сложность
• Обработка пустых и отсутствующих полей
• Защита от дубликатов (уникальный email)
• Корректная обработка UTF-8 символов в имени

В итоге, для качественного тестирования POST-запроса в Postman обязательно используйте комбинацию валидных и невалидных данных. Это повысит надёжность вашего API и снизит количество багов в production.