Всем привет! Меня зовут Алена и я QA engineer :)
В этой статье хотела бы поделиться опытом автоматизации REST API с помощью таких инструментов как Postman, Newman и Jenkins.
Postman — популярный клиент API, который позволяет тестировать, делиться, создавать, сотрудничать и документировать процесс разработки API внутри команды. Немаловажной функцией Postman является возможность писать и выполнять тесты на основе JavaScript для API. Postman предлагает встроенные инструменты для интеграции API для некоторых инструментов непрерывной интеграции (CI), например Jenkins.
Создание коллекций и написание автотестов в Postman
Для начала необходимо создать коллекцию, наполнив ее запросами. После того, как коллекция будет готова, можно приступать к написанию автотестов. Есть два способа добавления кода JavaScript:
Можно добавить скрипт перед отправкой запроса на сервер. Это делается на вкладке Pre‑request Script.
Второй способ — добавление скрипта, который будет выполнен после получения ответа от сервера. Его можно добавить на вкладке Tests.
Я пользуюсь вкладкой Tests. После добавления кода во вкладку он будет запущен при выполнении запроса. Результат запуска будет доступен на вкладке Test Results ответа от сервера. В тестовых скриптах можно использовать динамические переменные. Добавлять проверки для данных из ответа и передавать полученные значения между запросами.
Очень удобно, что Postman предлагает готовые куски кода (code snippets) для стандартных задач, которые можно отредактировать под свои нужды для экономии времени. Тем самым этот вид автоматизации возможно осилить и тому, кто знает только основы JavaScript.
Первый простой автотест — это проверка того, что запрос прошел успешно и мы получили status code 200 (или любой другой код, который мы ожидаем). Удобнее всего включить этот тест на уровне коллекции, чтобы все запросы под ним наследовали эту проверку:
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);Следующий пример теста — это проверка схемы json. Почему требуется проверка схемы JSON? Потому что:
Мы отслеживаем ответы API и гарантируем, что формат, который мы получаем, совпадает с ожидаемым.
Мы получаем оповещение всякий раз, когда в ответе JSON есть какое‑либо критическое изменение.
Для интеграционных тестов полезно проверять схему, её можно сгенерировать один раз из ответа сервиса, чтобы тестировать с ней все будущие версии сервиса.
let schema = {
"items": {
"type": "boolean"
}
};
pm.test("Схема корректна", () => {
pm.response.to.have.jsonSchema(schema);
});Таким образом, мы имеем уже две автоматизированные проверки REST API. Не буду утомлять примерами автотестов, их можно найти и изучить в документации - https://learning.postman.com/docs/writing-scripts/test-scripts/ , лучше сразу перейдем к самому интересному, а именно дальнейшей интеграции нашей коллекции с Jenkins.
Интеграция Postman c системой сборки CI
Первый вопрос, который возникает – это как связать Postman и Jenkins. Здесь нужно использовать CLI (command-line interface). Для того, чтобы коллекцию Postman разложить на язык командой строки используется Newman – приложение, которое позволяет запускать и тестировать коллекцию Postman непосредственно из командной строки.
Приведу упрощенный список шагов, как нужно дальше действовать:
Установить Jenkins локально и запустить его. Для получения дополнительной информации см. документацию Jenkins по адресу https://www.jenkins.io
Установить Node.js и Newman в Jenkins:
a. перейти на свой сервер Jenkins и войти в систему.
b. перейти в раздел «Управление Jenkins» > «Управление плагинами» и установить плагин NodeJS.
с. перейти в Manage Jenkins > Global Tool Configuration и в разделе NodeJS выбрать "Добавить NodeJS".
d. ввести имя для установки Node.js.
e. в поле "Глобальные пакеты npm" для установки ввестиnewmanВыбрать "Сохранить".
Подробная инструкция тут - https://learning.postman.com/docs/collections/using-newman-cli/integration-with-jenkins/Убедиться, что вместе с node.js установился
npm(пакетный менеджер, который работает с JavaScript). Для этого необходимо ввести в командную строку:
node -v
npm -vПосле нужно открыть консоль и установить сам Newman с помощью команды:
npm install -g newmanДальше нам нужно сохранить нашу коллекцию тестов, и тут есть два варианта - мы можем сгенерировать URL для тестов (share) или сохранить файлом (export).
Теперь запускаем тесты в консоли следующей командой:
a. Если используем ссылку —newman run https://www.getpostman.com/collections/.....(URL тот, что получили при шаринге из коллекции).
b. Если используем файл, то нужно использовать команду с директорией файла коллекции, напримерnewman run /Users /Postman postman_collection.json
После запуска тесты прогоняются в консоли и выводится результат:
Далее можно исполнять Newman из Jenkins после каждого коммита, чтобы тестировать образ на корректность ответов.
Желательно подготовить шаблоны в postman — вынести адрес хоста и другие изменяющиеся параметры запроса — в переменные и передать их из credentials‑плагина в Jenkins.
Конфигурируем задачи — добавляем shell-команду, а внутри нее вызов Newman.
После этого Jenkins будет прогонять тесты. Можно настроить нужную частоту (в окне сборки -> Configure -> build Triggers -> build periodically) и Jenkins будет сообщать была ли сборка успешной или неудачной.
Для других членов команды можно настроить рассылку информации о последних сборках и их статусе по электронной почте. Это позволяет активно отслеживать свои сборки API вместе с другими компонентами API. Можно использовать множество других конфигураций, чтобы сделать коллекцию более динамичной.
В заключение хотелось бы привести за и против использования такого вида автоматизации.
Начну с преимуществ: Postman интуитивно-понятен и простой в использовании, не требует какой-то сложной настройки, поддерживает разные API (REST, SOAP, GraphQL), легко интегрируется в CI/CD с помощью рассмотренного Newman. Newman также очень простой в использовании, идеально подойдет для тех, кто часто использует Postman и хочет немного большего с минимальными затратами по времени.
Данные инструменты очень выручат, если есть желание добавить автоматизацию в тестирование, подойдут на начальных этапах.
Но и хотелось бы отменить несколько недостатков такой интеграции, а именно полного построения автоматизированных тестов для больших проектов, которые имеют большое количество REST-сервисов. Из-за отсутствия возможности переиспользовать код, написание автотестов может превратиться в копипаст, поддерживать такие тесты будет сложно (например, когда количество сценариев может переваливать за 1000).
Также этот подход не подойдет, если в системе CI исполняется много задач (собирается билд, прогоняются автотесты, внутри есть зависимости, деплоится билд, поднимается на каком-то окружении). В таком случае нужно увеличивать количество машин, на которых прогоняются автотесты, и каждую настраивать с нуля, ничего не забыв при этом.
