Тестирование и разработка API с помощью Postman: рабочее руководство

Часть первая: для чего на самом деле нужны тестирование и разработка API с помощью Postman

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

Команды ошибаются не тогда, когда используют коллекции. Ошибка — считать, что коллекция станет регрессионным набором тестов, и при этом ничего больше менять не придётся.

Часть вторая: четыре проблемы

Любой набор API-тестов в любом инструменте рано или поздно упирается в одни и те же четыре. Знать их заранее — это и есть основная часть мастерства.

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

Часть третья: проверки, которые стоит писать

• Проверяйте тело ответа, а не только статус. Ответ 200 с пустым списком там, где должна быть запись, — это баг, который проверка статуса засчитает как успех.

• Проверяйте, что ошибочные сценарии отрабатывают корректно. Запросите то, чего не существует, и проверьте код ответа и структуру ошибки. Сервисы, которые возвращают 200 с ошибкой внутри, встречаются часто.

• Проверяйте связи между эндпоинтами. Если одна запись ссылается на другую — запросите её. Самые интересные баги живут между двумя вызовами.

Часть четвёртая: когда коллекции недостаточно

Сигнал — когда ваши pre-request скрипты превратились в маленький фреймворк, который понимает только один человек. С этого момента четыре проблемы становятся вашей инфраструктурой, а не заботой инструмента, и это тот самый момент, когда регрессионное покрытие пора перенести туда, где эти проблемы решены на уровне продукта. В TestSprite они закрыты возможностями Auto-Authentication, Dynamic Variables, Dependency Chains и Auto-Cleanup, которые описаны в документации по тестированию API.

Коллекцию при этом сохраните. Для исследования и документирования лучше неё у вас ничего нет.

Часть четыре с половиной: скрипты, которые никто не ревьюит

Pre-request и тестовые скрипты внутри коллекции заслуживают отдельного внимания: именно в них живут самые интересные сбои, и их почти никогда не ревьюят.

Это JavaScript, они выполняются в определённом порядке, изменяют общие переменные окружения и хранятся внутри JSON-экспорта, диффы которого бесполезны. Правка в скрипте обновления токена может сломать сорок запросов, а в пул-реквесте будет видна одна изменённая строка JSON. Команды узнают об этом в тот момент, когда два человека впервые правят коллекцию на одной неделе.

Если ваши скрипты доросли до того, что абзац выше звучит знакомо, коллекция превратилась в программное обеспечение. А программному обеспечению нужны ревью, контроль версий и собственные тесты — странное место, чтобы в нём оказаться, когда цель была протестировать нечто совсем другое.

Часть пятая: пусть всё запускается без вас

Подключите репозиторий из панели управления — и прогоны будут стартовать от того деплоя, который вы и так собираете; либо вместо этого добавьте отдельный шаг в свой собственный workflow.

Ту же настройку можно выполнить в панели управления TestSprite, если вы предпочитаете ничего не устанавливать локально. Остальные возможности CLI описаны в репозитории CLI.

Часть шестая: что TestSprite делает с этими четырьмя проблемами

У каждой из четырёх есть своё название, и решается она на стороне продукта, а не в ваших скриптах. Auto-Authentication настраивает сценарий входа один раз и получает свежий токен перед каждым прогоном. Dynamic Variables забирают значение из одного ответа и подставляют его в следующий запрос. Dependency Chains выводят безопасный порядок выполнения из того, что каждому тесту нужно на входе и что он создаёт. Auto-Cleanup удаляет ровно те записи, которые создал прогон.

Покрытие начинается с API Discovery по работающему сервису и той спецификации, что у вас есть, а сгенерированный план включает категории авторизации, обработки ошибок и граничных значений — как раз те, которые обычно пропускают.

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