Нужно ли вручную запускать регрессионные тесты в Postman или есть варианты автоматизации

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

Знаете ли вы, что коллекция запускается не только кнопкой в интерфейсе, и понимаете ли границы применимости Postman как регрессионного набора. Ответ «запускаю руками перед релизом» на позиции автоматизатора закрывает вопрос сразу.

Как отвечать

Опишите цепочку. Проверки пишутся скриптами на вкладке тестов через pm.test и pm.expect, стенды разводятся по окружениям и переменным, данные между запросами передаются через pm.collectionVariables. Запуск без интерфейса делает Newman, консольный раннер тех же коллекций:

newman run api.json -e stage.json -r cli,junit

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

Обязательно обозначьте потолок: Postman хорош как смоук и контрактные проверки API, где важна скорость написания. Когда регресс требует подготовки данных в базе, параллельного запуска, общих фикстур и сложных сверок, дешевле переписать набор кодом (pytest с requests, RestAssured) и оставить в коллекции только быстрый набор на живом стенде.

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

Держат коллекцию только в облачном рабочем пространстве и правят её мышкой. Истории изменений нет, кто сломал общий запрос, непонятно, ревью тоже нет. Лечится экспортом в репозиторий и правкой через merge request.

Второе: тесты зависят от порядка и от данных, оставшихся с прошлого прогона. Один упавший запрос роняет половину набора, а на чистом стенде набор не проходит вовсе. Каждый сценарий должен сам создавать и убирать за собой данные.

Третье: складывают токены и пароли в файл окружения и коммитят его. Секреты подставляются переменными CI, в репозиторий едет шаблон без значений.