Запускали ли коллекции Postman локально или через CI/CD

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

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

Как отвечать

Опирайтесь на свой опыт, но покажите, что знаете оба режима:

• локально: Collection Runner в самом Postman, прогон по разным окружениям (dev, stage), data-driven прогон с CSV или JSON-файлом. Удобно, пока тесты пишутся, и для разовой проверки;
• из командной строки: Newman, например newman run collection.json -e stage.json -r cli,junit. Есть и официальный Postman CLI (postman collection run), который умеет запускать коллекцию прямо из рабочего пространства и отправлять результаты в Postman;
• в CI/CD: джоба в GitLab CI, Jenkins или GitHub Actions, часто на образе postman/newman. Newman завершается с ненулевым кодом при упавшем тесте, и пайплайн останавливается. JUnit-отчёт CI показывает как обычные тесты, а для людей добавляют HTML-отчёт через сторонний репортер htmlextra;
• секреты: токены не хранят в экспортированной коллекции в репозитории, их передают из переменных CI через --env-var.

Назовите, когда запускались тесты: на каждый merge request, после деплоя на стенд или по расписанию. Добавьте, как устроены сами проверки: pm.test и pm.expect по статусу, схеме ответа и ключевым полям, передача токена между запросами через переменные.

Если в CI вы коллекции не подключали, скажите честно и опишите, как сделали бы: экспорт коллекции в репозиторий, отдельная джоба с Newman, отчёт в артефактах сборки.

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

Проверяют только код ответа 200. Такой тест пройдёт, даже если в теле пустой список или чужие данные.

Строят коллекцию так, что запросы зависят от порядка и от данных, оставшихся после прошлого прогона. Локально всё проходит, а в CI на чистом стенде падает.

Путаются, где лежит актуальная версия: коллекцию правят в облаке Postman, а в CI уезжает устаревший экспорт из репозитория.