Какие виды тестирования применяются для POST-запроса регистрации

Что проверяют

Умеете ли вы превратить один эндпоинт в осмысленный набор проверок, а не перечислить виды тестирования из учебника. Следом обычно просят назвать конкретные кейсы, и сильнее всего звучат те, что про повторы, гонки и безопасность.

Как отвечать

Идите слоями, от функциональных проверок к нефункциональным:

• позитивные: корректное тело даёт 201 Created или то, что прописано в контракте; в ответе нет пароля, пользователь есть в базе, пароль хранится хешем, письмо подтверждения ушло;
• валидация: пропущенные поля, null, пустые строки и пробелы, неверный тип, невалидный email, граничные значения длины, пароль не по политике. Ждём 400 или 422 с понятным телом ошибки;
• бизнес-правила: повторный email отклоняется, часто с 409 Conflict, а адрес в другом регистре считается тем же;
• протокол: неверный Content-Type даёт 415, битый JSON 400, другой метод 405;
• конкурентность: двойное нажатие и два параллельных запроса с одним email создают ровно одного пользователя;
• безопасность: SQL-инъекции и XSS в полях, лишнее поле "role": "admin" игнорируется (mass assignment), ответы не позволяют перебором узнать занятые email, есть лимит частоты (429), пароль не попадает в логи;
• контракт: схема ответа сверяется с OpenAPI;
• производительность: bcrypt или Argon2 нагружают процессор, так что регистрацию стоит прогнать в k6 или JMeter.

Назовите инструменты: Postman или curl вручную, REST Assured или pytest с requests в автотестах, запрос в базу для проверки результата.

Где спотыкаются

Проверяют только код ответа. 201 без взгляда в базу ничего не доказывает: пользователь мог не записаться или записаться дважды.

Говорят о «кроссбраузерном тестировании POST-запроса». API безразличен браузер, это проверка формы, а не эндпоинта.

Считают, что POST сам защищает данные. Защищает только HTTPS, тело запроса по HTTP видно так же, как параметры GET.