Testing Stage’19: Technical | Security | Management and Approach — Early bird till 21 Dec. Hurry up!
×Закрыть

Автоматизация тестирования API, или Почему я решил выбрать Postman

Буквально несколько недель назад я принял волевое решение написать API тесты для нашей доски администратора новостного портала. Для решения этой задачи существует масса инструментов и способов, реализованных на различных языках.

Но для начала пара слов о себе. На данный момент я занимаю должность Automation QA в компании Genesis Media. Мы разрабатываем новостные сайты и редакционные системы для 4 стран Африки, а также Филиппин и Казахстана. И вот, в перерыве между поточными задачами, я решил, что не так уж и плохо автоматизировать наш API. Учитывая тот факт, что до меня этого никто не делал и придется все начинать с чистого листа, у меня были развязаны руки.

Какие варианты я рассматривал

В голову мне пришло три наиболее простых решения. Первое — втоматизировать все в тестовом фреймворке для Selenium с использованием Java (я же автоматизатор все таки ;)). Второе - это использовать новомодный Cypress. Или третье — все-таки использовать узконаправленный инструмент по типу Postman или SoupUI.

Первый вариант мне нравился меньше всего по причине сложности внедрения. На данный момент все настроено таким образом, что запуск требует целой кучи параметров на CI или локально. К тому же совмещать UI тесты (end-to-end) с API (integration) — не самая лучшая из моих идей. Ну и не буду лукавить со своими читателями — я давно уже не тестировал API с использованием Java и попросту не мог вспомнить всех подводных камней или хотя бы библиотек.

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

Третий вариант выглядел наиболее простым и чего уж там — более желанным. С Postman, вероятно, работали все, кто хоть как-то связан с веб-разработкой, и в лишних представлениях он не нуждается. Я был не исключением, но то, чего мне ни разу не удавалось, так это не просто протестировать конкретные endpoints, но и написать тесты на его основе.

Для аргументированного решения в выборе инструмента требуется что-то немного большее, чем просто желание (глубокий вздох разочарования). Для сравнения я решил написать пару простых запросов, логин и создание статьи, в Cypress и Postman c одинаковыми проверками. Это могло дать возможность оценить сложность в написании запросов, добавлении тестов к ним и в результате понять, какой из вариантов будет удобнее поддерживать в дальнейшем. Ну и не стоит упускать из виду то, что я смогу запустить эти самые тесты и банально посмотреть, что выполняется быстрее.

Cypress

Я начал с того, что было уже готово  -  запросов в Cypress. Оставалось лишь убрать лишнее из кода и добавить простую проверку статуса. Итак, вот что у меня получилось для запроса регистрации и создания задачи:

Two basic API tests in Cypress

На скриншоте выше мы можем наблюдать запрос на логин и создание задачи с минимальным набором необходимых полей (названия в json схеме такие странные из-за NDA и отсутствия фантазии). После каждого запроса мы сравниваем полученный статус код с ожидаемым. Все довольно просто даже для меня  -  человека, не так давно начавшего свое знакомство с JavaScript. Cypress позволяет выносить общие переменные в файл cypress.json, что делает поддержку и параметризацию тестов весьма удобной. Но что же насчет скорости выполнения?

Test results in Cypress runner

На этом скриншоте вы можете увидеть Cypress runner и время, которое ушло на выполнение двух тестов  - 1.87 секунды. Не такой уж и плохой результат. Но загвоздка кроется в том, что вся инфраструктура уже поднята. Если же запустить тесты из консоли, так как они и должны запускаться в CI/CD, то только на запуск самого Cypress уходит более десяти секунд. А это уже не так приятно. И пускай у нас будет несколько больше запросов, чем сейчас, но поднимать столь немалый клиент для такой простой задачи не кажется уже столь целесообразным.

Итого, мы имеем следующие плюсы Cypress:

  1. Простой синтаксис при написании тестов, в котором сможет за несколько дней разобраться даже новичок.
  2. Готовая инфраструктура с возможностью простого параметризированного запуска.
  3. Наличие интерактивного ранера, где можно посмотреть все ошибки прямо в консоли.

А что же из минусов:

  1. Очень долгий запуск.
  2. Необходимость писать код запросов (пусть он и не сложный).

Не так уж и много.

Postman

Теперь давайте посмотрим, как пойдет процесс с Postman. И вот вам сразу же скриншот запроса:

Request view in Postman

Здесь все достаточно банально, в особенности для тех, кто уже использовал Postman в целях тестирования API. Просто записываем все параметры и их значения в таблицу, добавляем к ним описания по необходимости. Выносим url в переменную окружения и с ее помощью прописываем endpoint. А во вкладке «Tests» выбираем сниппет для проверки статуса ответа. Единственное, с чем могут быть проблемы у начинающих, — это как передать токен из ответа логина в следующие запросы. Но это решается снова же через запись переменной в окружение. А код для этого можно взять в сниппете с говорящим названием «Set environment variable».

Окей, запускаю тесты в качестве коллекции из самого Postman и получаю следующую картину:

API test run in Postman runner

Результат —  несколько меньше двух секунд на два запроса. Примерно тот же результат (на самом деле он должен был быть лучше, но интернет в новом офисе на момент написания статьи не оставил мне шансов). Но вот что мы увидим, если запустим все это из консоли?

Для решения этой задачи существует npm пакет Newman. Что ж, устанавливаем, читаем минимальную документацию и запускаем. Для этого экспортируем нашу коллекцию с запросами и тестами в них, а также не забываем экспортировать окружение, как обычное, так и глобальное, если его используем. Команда для запуска проста:

newman run имя_файла_коллекции -e имя_файла_окружения -g имя_файла_глобального_окружения

Newman run results in CLI

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

И после давайте быстро поговорим о плюсах и минусах (а то мне еще выводы писать, а вы и так уже поди устали все это читать).

Плюсы:

  1. Инструмент, с которым знакомы многие, и он крайне прост в обращении.
  2. Запросы пишутся быстро, и для этого не требуется никакого кода, а следовательно ими смогут воспользоваться все без исключения.
  3. Крайне быстрый старт тестов.
  4. Встроенная возможность шеринга коллекций внутри рабочей команды для платных аккаунтов.
  5. Генерация документации по созданным запросам и сохраненным ответам.

Минусы:

  1. При написании параметров запроса в форме form-data по-прежнему встречаются досадные неприятности, вроде невозможности передачи булевого значения. Они просто приводятся к строке, хотя числовые значения работают нормально.
  2. Примерно такая же проблема со вложенными параметрами.

Оба минуса с легкостью можно обойти, если использовать raw форму записи, но все же неприятно. А вот плюсы выглядят куда более впечатляюще.

Что же мы имеем в сухом остатке

Написание запросов в Postman проходит проще, быстрее и выглядит читабельнее. Что касается выполнения самих запросов — то тут, скорее всего, разница не существенна. Но вот что точно можно сказать, так это то, что на запуск тестов с использованием Newman не нужно дополнительное время, как в случае с Cypress.

К примеру, на данный момент наша коллекция включает в себя 60 запросов и более 100 проверок, но на их выполнение локально уходит в среднем 15 секунд. На удаленном сервере же эта цифра еще меньше и порой достигает 9 секунд, что сопоставимо со временем запуска одного Cypress.

Также просто не могу не отметить восхитительный функционал по генерации документации. Это необходимо, если ваш API все еще не имеет ничего подобного. В ней вы можете описать весь API в целом, дать примеры запросов, ответов и описание отдельным параметрам. Для всего этого можно выбрать один из нескольких предложенных языков. Все это счастье можно разместить как публично, так и приватно.

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

Выводы

В этой статье я хотел передать свой опыт в выборе инструмента, но не в коей мере не настаиваю на том, что он единственно правильный. Ваш выбор может зависеть от ваших задач, потребностей и ограничений и может отличаться от текущего. В следующий раз я расскажу более подробно о самом тестировании в Postman и в частности о такой библиотеке, как tiny-json-validator, которая уже входит в набор подключенных библиотек Postman и позволяет проверять схему ответа и типы данных в нем. На этом желаю вам легких и правильных решений :)

LinkedIn

59 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Чому не curl?

автоматизировать наш API
Selenium
Postman

ясно, дальше не читал

Очень странные варианты тестирования api, тем более для автоматизатора. Просто для наглядности, загуглить автоматизация апи на js, предложит как минимум 3-4 хороших либы.

SoupUI — це щось про суп?

є нармальна тєма — Spring Boot Feign — рекомендую)

Агонь) Дійсно рекомендую — навіть моя бабця його вивчила за 2 години!

моя бандерівка — я хз про шо ти кароч)))

а чого нема каментів про Rest Assured або Jersey?))))

Бо всі кодять на спрінгу)

это вроде интеграционные тесты, а здесь тестирование АПИ. или я чего-то не знаю? :)

ем, ну дивлячись хто чим вважає API тести.... Rest Assured то є just a http client з красівим інтерфейсом програмним ... www.google.com.ua/...​_AUIDigB&biw=1280&bih=567 — тут навіть в самій піраміді плутанина з термінологією)

oh, ok, я значит чего-то не знаю. Я сам пишу тесты на RestAssured, потому что «TDD» и используются они только разработчиками, тестеры пишут свои тесты. Я так понимаю, что не у всех так :)

Автор,извините за оффтоп, конечно, но лого вашего Genesis очень похож на лого моего Genesis Energy. Интересно, кто у кого позаимствовал:)

У тестуванні API за допомогою Postman набагато більше мінусів. Особливо коли тести пишуть девелопери.

— Автору мабуть не доводилось мерджити JSON колекції в репозиторії, з декількома вкладеними папками, з тисячами рядків, від кількох development команд.
— Імплементація тестів з преріквестами — забавка не для слабкодухих.
— Також у більшості випадків треба перевіряти більше, ніж просто статус респонзу, а дебагання API тестів в Postman.....
— Підготовка даних в тестовій базі даних для конкретних кейсів (PUT, GET) теж займає час.

Нам вдалося вчасно виділити всі недоліки і розглянути варіант з автоматизацією на Java, поки що обрали RestAssured (rest-assured.io). Serenity дозволяє інтегрувати ці тести будь-де (навіть тікети в Jira можна реджектати, якщо якийсь тест падає), звіти виглядають інформативніше чим в Postman (можна навіть перейти на тікет фічі, до якої цей тест має стосунок в тій же Jira).

P.S: Хотів наголосити, що не все так однозначно з Postman, як згадується в статті. Вислухаю (і буду вдячний за) будь-які коментарі вище описаного.

Спасибо за комментарий. Я не пытался убедить всех в правильности использования Postman и только его. Цель была ознакомить с такой возможностью незнакомых через собственный опыт использования.
Вы правы, мерджить json не приходилось и едва ли появится в ближайшем будущем. Тесты пишутся одним человеком и меняться часто не будут. Postman позволил достаточно просто написать тесты и сгенерировать приемлемую документацию. И это стало решающим фактором в выборе.

Насправді, для маленьких команд Postman шикарне рішення, яке дозволяє вже з мінімальним знанням js пилити автотести. Доступна і паралелізація — описано на гіті постманлабс, досягається викликами ньюмана через лібу async. Альтернативний варіант — powershell скрипт з викликами Start-Job. Навіть в режимі паралельного виконання newman-teamcity-reporter відпрацьовував адекватно і його цілком вистачало.
З коробки доступні lodash (3 версія, для підтримки 4 потрібно викликати через require), moment.js, валідація json схем, cheerio.
З категоричних мінусів — не очевидно в яких випадках енвайрмент persistent, а коли — ні, в деяких кейсах навіть не допомагає виклик api update environment і танці з галочкою в налаштуваннях.
Ну і GUI, який напиляний на електроні і при великих кількостях колекцій/синхронізацій просто загинається і вижирає ресурси.
Тому не зовсім зрозумілі спалахи п’ятих точок деяких коментаторів — для ’входу’ в автоматизацію Postman хороший варіант, а з новим Test API в bdd стилі не проблема ті ж тести перенести згодом в будь-який js тест раннер.

Теж на попередньому проекті юзали Postman, але так хотів замовник. В результаті ніхто й не ревьював ці тисячі стрічок коду(писало їх 5 чоловік). На рахунок пре-ріквестів згідний, в IDE-шці простіше.
Єдиний плюс Postman це зручність, коли треба швидко дьорнути якийсь endpoint і експортнути робочий ріквест в curl формат для шарення.
A Rest-Assured годнота однозначно, завжди наствоював на ньому + в BDD стилі.
PS: Allure Report луччє. trollface.jpg :D

Хочу немного прояснить откуда появилось упоминание Cypress и Selenium в разрезе статьи про тестирование API: на данный момент на проекте используются оба эти инструмента. И если Selenium вообще не про это, то Cypress позволяет и мало того, настаивает на использовании его и в контексте интеграционного тестирования. И дилемма была в том, засунуть ли тесты в один из готовых фреймворков или же сделать отдельный проект. А так как Postman давал массу возможностей по мимо самого тестирования (простота понимания для не программистов, автогенирация документации), он и был выбран.

Конечно Postman из этих трех будет лучше всего для API тестирования, потому что cypress и selenium вообще на другом уровне работают.

Получается что-то вроде — «Нам нужно переплыть речку, выбирая между самолетом, дельтапланом, и лодкой — удобней всего оказалась лодка».

OMG. Postman/Automation QA. Мужчина, зачем позорить нашу профессию, удалите, пжл.

Непоганий туторіал для початківців, хоча деякі моменти (напочтаку про сайпрес, селеніум та апі) досить противоречиві..
Але всеж таки раджу подивитись записи виступів конференцій Selenium Camp, QA Fest, Heіsenbug, чи просто на івенти походити та дізнатись в людей як вони автоматизовують свої апі та який в них досвід є з постмен

два вопроса:
1) где проверка значений ответа, кроме HttpStatus?
2) Эндпоинты руками пишете? Проект не использует Swagger? Из него же можно спокойно сделать темплейты для тестов

вот мне тоже жаль,что автор не упомянул в статье, что можно импортировать все запросы из Swagger, многим новичкам кучу времени бы сэкономило

Может я чего-то не понимаю в тестировании, но для человека, занимающего позицию Automation QA, должно быть стыдно за то, что он Postman-ом пользуется, а не статьи об этом писать, не?

внезапно. С чего бы, товарищ?

Ну, у нас коллекции для Postman-а мануальщик делал. И то, мы на openapi-3.0 переезжаем, для текущего проекта вообще можно конвертнуть со спецификации.

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

Не знал, спасибо за информацию. Просто с статьи я сделал вывод, что автор занимался примерно тем же, т.к.

Запросы пишутся быстро, и для этого не требуется никакого кода

Я вообще надеялся что статья будет в стиле:
— вот коллекция эндпоинтов
— вот таким алгоритмом (написаным на джава\с++\коленке) мы делаем коллекцию вызовов и базовые тесты на эдж-кейсы прописаные в swagger
— тут вообще просто, на джава скрипте пишем тесты на бизнес логику, вызывая логин, и прочие нужные методы, вот так обходим бан .рсс для не-браузеров, тут еще кое что добавили. вуа-ля 10 строк и все протестировано.
— теперь добавим пару строк, вызовем все 100500 раз и проверим на отказоустойчивость.

а так, детский сад :(

— теперь добавим пару строк, вызовем все 100500 раз и проверим на отказоустойчивость.

load testing не поддерживается ни в постмане, ни в ньюмане github.com/...​manlabs/newman/issues/744

1) Здесь говорится обратное blog.getpostman.com/...​ns-new-collection-runner
2) ссылка на гитхаб для postmanlabs а не postman

и да, я не тестер, так что глубоко этим не занимался, может действительно не поддерживатся load testing в промышленных стандартах :)

эээ, postmanlabs — это мета репо и для консольного newman, и для юайного postman.

Здесь говорится обратное

там имеется в виду параллельный запуск нескольких итераций github.com/...​n-app-support/issues/4198
возможно, вам этого будет достаточно, не подумал.
мы же бомбили определенные эндпоинты через ab.

и да, я не тестер, так что глубоко этим не занимался, может действительно не поддерживатся load testing в промышленных стандартах :)

как я уже говорил, промышленных стандартов в автоматизированом тестировании не знаю :) не горжусь этим, просто факт что даже не знаю откуда начать это дело

В названии статьи ничего подобного не говорилось. Ее цель описать опыт и послушать решения других команд.
А что касается вызова «100500 раз» — это больше про нагрузочное тестирование, а не про проверку работы API в целом (интеграционное тестирование).

Проблема в уровне владения постманом для решения самой задачи. Статья не даёт ничего, что нельзя понять за пять минут копания в самом постмане. А судя по комментариям именно в этом заинтересован народ.
Это как сказать что будет анонс дяблы и выпустить дяблу на мобильный

Open Api v3 не поддерживатся постманом github.com/...​n-app-support/issues/3390, на данный момент

Т.е. тестов не было и человек сам искал способ их написать? Это не лучшие практики а первая попытка, так что-ли?

Как по мне у связки Postman+Newman есть гиганский недостаток это отсутствие человеческого рипортинга. Allure аллюр прикрутить у меня так и не вышло. Фраза про то что для Postman не надо писать код меня сильно удивляет. Разве вы в своих тестах не делаете валидацию json схем ? Подскажите каким образом вы генерируете тестовые данные без написания кода ? Вы не используете переменные среды хотя бы в части авторизации ? а если используете то как вы получаете токены без минимального парсинга риспонса ?

Согласен, красивого отчета нету и были мысли что-то написать. Но по факту на данный момент хватает консольного вывода и нотификаций в Slack.
На счёт кода — я имел в виду простоту входа. Мануальному тестировщику и человеку не связанному с программированием куда как проще посмотреть все графическом интерфейсе.
Парсинг и проверка схем конечно присутствует и возможно будет освещена в следующей статье, если Вам всем будет интересно.

Как потом запускаются тесты из постмена? Руками? По триггеру? По крону?

Postman+Newman вполне успешно интегрируются с Jenkins

Через npm пакет Newman. Запускается из Jenkins по крону. Но это временное решение и в скором будущем будет тригерится по пулл реквесту.

SoupUI..хм, интересненько :)

мне казалось, никто уже и не вспоминает про SoupUI, но нет

Я думал такого вообще не существует SoupUI, а о нем еще и кто то вспоминает)

хатэтэпэ мок на коленке забацать за 5 минут — самое то, а так да, унылая вещь.

первое правило SoupUI — никому не говорить про SoapUI

К тому же совмещать UI тесты (end-to-end) с API (integration) — не самая лучшая из моих идей. Ну и не буду лукавить со своими читателями — я давно уже не тестировал API с использованием Java

Дальше можно не читать

А можно немного детальнее? Там два предложения, а у вас один ответ
Ято вас все таки больше возмутило:
— нежелание совмещать e2e с integration
— нежелание использовать Java для тестирования

Зачем делать 2 отдельных проекта на разных технологиях для тестирования одного и того же функционала. Имея у себя в ui проекте доступ к ендпоинтам можно облегчить тестирование ui и лучше контролировать систему. Да и гибкости на много больше (генерация репорта, встраивание в CI, подготовка тестовых данных, фишки ООП и т.д и т.п)

то не так уж и плохо автоматизировать наш API.
Первое — втоматизировать все в тестовом фреймворке для Selenium с использованием Java (я же автоматизатор все таки ;)). Второе - это использовать новомодный Cypress

вам потрібно розібратися з інструментарієм.
Вебдрайвер це суто керування браузером. Вебдрайвер лише вміє запускати браузер та шукати елементи в DOM сторінки. Все.
Ніколи не працював з cypress.io, але те, що читав — він працює на подобі Selenium RC. У випадку cypress — це завантаження веб аплікації в середину cypress, де він може моніпулювати з DOM. Тобто, це також інструмент роботи з веб сторінкою. Я чув, що там можна мокати http api, можливо можна якось і відправляти\отримувати http (судячи з коду, так), але тестувати http api за допомогою інструменти для UI — дічь.

p.s. — api поняття широке. в такій статті краще уточнювати про яке саме API йде мова

Сейчас народ когда говорить API подразумевает REST, а когда говорит REST, подразумевает обычные http запросы.

згідний. я так і розглядав. але, імхо, краще уточнювати

Від цього прям бомбануло.. Автоматизація апі за допомогою селеніум та cypress

Вот вопрос почему бы не использовать rest assured или подобное, есть возможности проверки моделей и все что угодно и бд и....

Подписаться на комментарии