Как проверить метод POST при тестировании API?

Question

[SokSokol]

У нас есть API с методом POST, который принимает данные пользователя (имя, email, пароль).
Я тестирую его через Postman.
Какие тестовые данные и сценарии лучше использовать: только валидные или и невалидные тоже?
Что чаще всего проверяют на практике?

Comments

[shurshur]

Тестировщик вошёл в бар, заказал кружку пива, заказал 10 кружек пива, заказал -1 кружку пива, заказа пиво на имя Bill Gates, заказал foobar кружек, заказал сахарную пудру, заказал [запрещено РКН]...

Если API доступен в публичном Internet, то запросить у него могут что угодно. В том числе белые и чёрные хакеры. Сервис должен всё это адекватно обработать, не упасть, не сделать что-то неправильное.

Например, если сервис требует авторизации, то надо проверять, что сервис работает с правильными кредами и корректно ругается с неправильными. Причём речь не только о валидности токена авторизации, но и о возможности и правомерность пользователя совершить действия. Например, чтобы пользователь не мог изменить пароль другого пользователя, только свой.

Регулярно вижу, как разработчики сайтов, например, не показывают данные пользователю без регистрации, но вся "защита" этого - ограничения на фронте. Прямые вызовы API возвращают всё вообще и никак не контролируют авторизацию пользователя.

[Voland69]

только валидные или и невалидные тоже?

и валидные, и невалидные, и всякие невероятные (длина 4к+, спецсимволы, всякие обратные кавычки и прочее)
базово что проверяют:
1. что пускает с правильными кредами
2. что не пускает с неправильными
3. что не падает при кривом запросе (символы, невалидный json, очень длинный или наоборот пустой запрос)
4. что не пролезает например SQL инъекция (те самые кавычки, и да, в 2025 году иногда можно встретить построение запроса конкатенацией сырых вводных)
5. отдельной строкой ретраи и rate limit - что будет если бомбить эндпойнт в 16 потоков спамом запросами (и какое при этом ожидаемое поведение? - отдать 500 не ок, отдать если не успеваем 429 - ок, например)

Answer 1

[Василий Банников]

Нужно проверять и то и другое.
Представьте что будет, если форма входа позволит пользователь залогиниться с неправильным паролем или что будет, если форма регистрации позволит зарегистрироваться с невалидным адресом почты.

Читайте про тест-дизайн

Answer 2

[Михаил Р.]

Learn how API testing can help
What is API Testing? (with Examples)
Ultimate Guide to Mastering API Testing in 2025

Answer 3

[Анатолий Емелин]

Надо проверить на всех вариантах тела запроса. Проверить не валится ли обработчик запроса на неожиданных данных, всяком мусоре в строках, хотя бы формально проверить почтовый адрес, а лучше сделать проверку с отправкой на почту кода и форму ввода проверочного кода и метод обработки (может быть как POST так и GET). Сделать нормальные ответы, в том числе и для ошибок, особенно 400 Bad Request, с описанием , что нет так. Это если вашим api будет пользоваться внешний разработчик.

Без проверки почты рискуете собрать кучу мусора, а юзеры потеряют возможность восстановления доступа к вашему сервису.