Как тестировать бэкенд

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

Видите ли вы бэкенд глубже, чем «отправил запрос в Postman, пришло 200». Интервьюер ждёт уровни проверки, инструменты и понимание побочных эффектов. Следом обычно просят рассказать, как вы убедитесь, что заказ действительно записался и ушёл в очередь.

Как отвечать

Юнит-тесты пишут разработчики, поэтому тестировщик сосредоточен на уровнях выше:

• API: методы и коды ответа (201 на создание, 204 без тела, 401 без авторизации против 403 без прав, 400 или 422 на невалидные данные), заголовки, тело и его схема, пагинация, фильтры, сортировка;
• бизнес-логика: правила расчёта, статусы и допустимые переходы между ними, граничные значения;
• данные: после запроса проверить базу через SQL, транзакционность (упал второй шаг, откатился ли первый), идемпотентность PUT и DELETE, повторный POST с тем же ключом идемпотентности;
• интеграции: сообщения в Kafka или RabbitMQ, вызовы внешних сервисов, которые на стенде подменяет WireMock, поведение при таймауте и ошибке соседа;
• безопасность: доступ к чужим объектам подменой id (IDOR), инъекции, лишние поля в ответе. Удобный ориентир: OWASP API Security Top 10;
• нагрузка: JMeter, Gatling, k6 или Locust с целевыми цифрами из требований, а не «сколько выдержит».

Инструменты называйте свои: Postman с Newman для запуска в CI, REST Assured на Java или pytest с requests, Testcontainers для настоящей базы в тестах. Упомяните логи и трассировку: найти запрос по trace id в Kibana или Grafana часто быстрее, чем гадать по ответу. Тесты запускаются в пайплайне на каждое изменение и сами готовят себе данные.

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

Проверяют только код ответа. Сервер может вернуть 200 и при этом записать не то или вообще ничего.

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

Пишут тесты, которые зависят от общих данных стенда. Кто-то удалил пользователя, и половина прогона краснеет без реальной причины.