Какой опыт работы с REST API и какими инструментами пользовалась
QA EngineerREST APIинструменты тестированияопыт работыпроекты
Что проверяют
Понимаете ли вы, что именно проверяется в API, помимо кода ответа.
Как отвечать
Расскажите через список проверок, это и есть содержание работы:
- коды ответов: успех, создание, отсутствие содержимого, ошибки клиента и сервера. Отдельно различие между отсутствием аутентификации и отсутствием прав;
- структура ответа: соответствие схеме, обязательные поля, типы, форматы дат, поведение при пустых значениях;
- валидация ввода: пустые значения, превышение длины, неверные типы, спецсимволы, границы диапазонов, лишние поля;
- права доступа: самая частая находка. Можно ли обратиться к чужому ресурсу, подставив его идентификатор, работает ли проверка роли на каждом методе, а не только в интерфейсе;
- идемпотентность: повторная отправка не создаёт дубль;
- пагинация и сортировка: границы, слишком большой размер страницы, поведение на последней;
- ошибки: понятный текст и стабильный код, отсутствие технических деталей и стека в ответе;
- версионирование и обратная совместимость;
- ограничение частоты запросов.
Инструменты и что именно ими делали:
- Postman: коллекции по сценариям, переменные окружения, цепочки запросов с сохранением токена, проверки в скриптах, прогон коллекции и запуск в конвейере;
- curl для быстрой проверки и для приложения к отчёту, чтобы разработчик воспроизвёл одной командой;
- автотесты на уровне API как основа регрессии;
- описание OpenAPI как источник кейсов и как эталон для сверки ответа;
- перехват трафика для просмотра реальных запросов приложения и подмены ответов.
Сильный ответ включает конкретную находку: например, обнаружили доступ к чужому заказу подстановкой идентификатора.
Где спотыкаются
Проверяют только успешный сценарий и код двести.
Не проверяют права доступа на уровне API.
Используют Postman без переменных и проверок.
Не сверяют ответ со схемой и пропускают изменения формата.