talend api tester что это
10 лучших инструментов для тестирования API
10 лучших инструментальных средств тестирования интерфейсов прикладного программирования 2018 года.
Интерес к тестированию неудержимо растёт на протяжении нескольких последних лет, согласно исследованиям Google Trends. Опрос, проведенный компанией Smartbear в 2017 году среди 5000 профессионалов в области разработки программного обеспечения, показал, что более 50% опрошенных респондентов используют автоматические средства тестирования API, и ожидается рост их количества на 30% ( с 59% до 77%) в течении следующих двух лет, причем 80% участников опроса указали, что отвечают за тестирование API.
Наличие правильных процессов, инструментов и технических решений для автоматических тестирований API становится важным, как никогда ранее. И с помощью тенденции shift-left, тестирование API становится больше, чем просто решение по контролю за качеством, теперь это критически важный компонент успешной непрерывной интеграции и развёртывания программного обеспечения.
В данной статье предоставлен обзор лучших средств тестирования API, как с открытым доступом, так и коммерческих решений, из которых команды тестировщиков могут выбрать наиболее подходящие для себя.
5 лучших средств тестирования API в 2018 году
1. SoapUI
SoapUI представляет собой консольный инструмент, предназначенный для тестирования API и позволяющий пользователям легко тестировать API REST и SOAP, а также Web-сервисы.
При помощи SoapUI, пользователи могут получить полный исходный документ и встроить предпочтительный набор функций, в дополнение к перечисленным ниже:
2. Postman
Будучи изначально плагином браузера Chrome, теперь Postman расширяет свои технические решения вместе с оригинальными версиями как для Mac, так и для Windows.
Postman является отличным выбором API тестирования для тех, кто не желает иметь дела с кодировками в интегрированной среде разработки, используя тот же язык программирования, что и разработчик.
3. Katalon Studio
Katalon Studio является бесплатным инструментом автоматического тестирования, предоставляющим общую среду для создания и выполнения UI функционала, служб API/Web и тестирования мобильных платформ.
Способность комбинировать уровни UI и Business (службы API/Web) для различных операционных сред (Windows, Mac OS, Linux) расценивается как значительное преимущество Katalon Studio перед аналогичными продуктами.
Katalon Studio поддерживает запросы SOAP и RESTful с различными типами команд (GET, POST, PUT, DELETE) с параметризованными возможностями.
Основные свойства:
4. Tricentis Tosca
Tricentis Tosca представляет собой платформу непрерывного тестирования для Agile и DevOps. Среди преимуществ Tricentis Tosca следует отметить:
5. Apigee
Apigee является кросс-«облачным» средством тестирования API, позволяющим пользователям измерять и тестировать производительность API, обеспечивать техническую поддержку и разработку API при помощи других редакторов, таких как Swagger.
6. JMeter
JMeter (открытое программное обеспечение) широко используется для функционального тестирования API, однако изначально он создавался для нагрузочного тестирования.
7. Rest-Assured
Rest-Assured является общедоступным предметно-ориентированным Java-языком, который делает службу тестирования REST более простой и удобной.
8. Assertible
Assertible представляет собой инструмент тестирования API, который в первую очередь акцентируется на автоматизации процессов и надежности.
9. Karate DSL
Karate DSL это новый инструмент для тестирования API, который помогает разрабатывать сценарии для BDD тестов на основе API простым способом, без написания характеристик этапов. Эти характеристики создаются самим KarateDSL, а поэтому пользователи могут запустить тестирование API легко и быстро.
10. Ни одно решение не может совместить все инструменты
Это больно осознавать, однако, это правда!
Мы верим, что приведенный выше список представляет наилучшие решения, доступные на текущий момент, если Вы решили использовать автоматическое тестирование API. Однако, как и в случае с большинством продуктов в данной сфере, найти один инструмент, который совмещает все указанные функции, практически невозможно.
Некоторые могут посчитать, что свойств коммерческих продуктов (Postman, Tricentis Tosca,…) будет достаточно, однако цена вопроса будет служить серьезным сдерживающим фактором. Бесплатные и общедоступные решения (Rest-Assured, Karate DSL,…) являются довольно-таки приемлемыми, но требуют квалифицированных умений и много усилий для имплементации правильной платформы. Инструменты, которые удерживают баланс между ценой и другими факторами (Katalon Studio, Postman), могут иметь недостатки для некоторых типов проектов, и эти недостатки требуют пристальной оценки.
Тестирование API создало свой собственный тренд в области автоматического тестирования, и чем дальше, тем больше инструментов будет создаваться для удовлетворения растущих запросов от команд разработки программного обеспечения. Найти идеальный инструмент по-прежнему сложно, но у нас есть и хорошие новости — теперь Ваш выбор стал намного шире, чем был раньше. Тщательно обдумайте Ваши требования, взвесьте все «за» и «против» каждого решения — постарайтесь быть не слишком придирчивым на ранних стадиях и попробуйте 5 лучших кандидатов из нашего списка. Когда Вы создадите список всех «за» и «против» для этих решений, Вы получите более адекватную картину критических факторов Вашего проекта и сможете отредактировать список инструментов. Данный подход предоставит Вам хорошую возможность идентифицировать подходящий инструмент для текущего этапа и информацию о следующем инструменте, когда Ваши проекты станут более комплексными, сложными и опытными.
Мне было бы очень приятно услышать Ваши отзывы, поэтому — если Вы знаете другие инструменты, которые могут использоваться для аналогичных целей — буду признателен за Ваш вклад в исследование темы.
Расширения Chrome для программистов и сочувствующих
На Хабре уже есть посты в духе «10 браузерных расширений, которые нужны КАЖДОМУ УВАЖАЮЩЕМУ СЕБЯ РАЗРАБОТЧИКУ». Но меня смущает, что там вперемешку совсем разные вещи для разных людей. От React Developer Tools до съёмки скринкастов — и всё это просто списком через запятую. Очевидно, что с React работает не каждый.
Поэтому захотелось сделать более структурированный пост с разделением на тематические категории. По которому можно и получить представление «что вообще бывает», и найти что-то конкретно для себя.
Конечно, приветствуются дополнения в комментариях, мне известно далеко не всё. И необязательно ограничиваться Chrome, можно рекомендовать и расширения к другим браузерам.
Неайтишное
Для разминки — универсальные расширения, которые могут помочь не только IT-специалистам, но и другим людям.
Браузер — сам по себе рабочий инструмент, которым тоже нужно уметь пользоваться: если открыт миллион вкладок и в итоге нужную не найти, это печально. Некоторым на этом пути становится недостаточно дефолтной системы работы с вкладками и нужно что-то мощнее. Для таких есть целая россыпь разных расширений, по-разному модифицирующих вкладки: Tree Style Tab, OneTab, Toby и другие.
Раз вы на Хабре, явно читаете длинные тексты — Pocket создан, чтобы сохранять их «на попозже» и с комфортом читать даже в офлайне (например, в самолёте). Тут расширение — это лишь часть сервиса: собственно чтение происходит на отдельном сайте или в приложении, но благодаря расширению любой открытый текст можно добавить в Pocket одним кликом.
Если ощущаете, что слишком отвлекаетесь на Хабр или другие сайты — в StayFocusd можно выставить временные ограничения, после которых Chrome просто перестаёт их открывать. А DF Tube убирает с YouTube всё отвлекающее вроде рекомендаций: не получится так, что зашёл посмотреть что-то нужное, а в итоге залип на котиках.
Понятно, что в категории продуктивности вообще есть много всего: и «помидорные» тайм-трекеры (вроде Marinara), и todo-листы (скажем, Todoist), и сюда же можно отнести проверку грамотности (Grammarly для тех, у кого рабочая переписка на английском, а LanguageTool и в русский умеет).
Общеайтишное
Теперь о том, что как-либо связано с IT, но без строгой привязки к специализации пользователя.
Моя любимая ниша: «чтобы браузер напоминал редактор vim» (как можно догадаться, такое подойдёт не всем, зато любителей очень порадует). Расширения Vimium, cVim и Surfingkeys придуманы для управления браузером с клавиатуры и используют некоторые идеи vim (но без мучений «как отсюда выйти»). Нажимаешь хоткей — и рядом с каждым кликабельным элементом появляется буквенное сочетание для перехода по нему. Проще всего показать это в действии:
То ли смеяться, то ли плакать, но существует целый ряд расширений вроде Stack Copy Button, которые добавляют на Stack Overflow в каждый сниппет кода кнопку «скопировать в буфер обмена». Если что, я вам об этом не рассказывал!
Любопытный факт: популярный сервис Postman, помогающий в работе над API, когда-то начинался именно как расширение для Chrome. С тех пор он разросся в большой отдельный продукт, зато в расширениях появились новые игроки: Talend API Tester позволяет отправлять запросы с помощью удобного UI.
Есть расширения со следующей идеей: из всех страниц в мире чаще всего мы видим страницу «new tab», и можно превратить её в агрегатор полезной информации для айтишников, чтобы при открытии новых вкладок заодно держать руку на пульсе. Самый известный такой проект — daily.dev, показывающий подборку англоязычных материалов о разработке.
Есть ещё похожий проект Devo, позволяющий видеть новости сразу из нескольких разных источников (вроде Hacker News и Product Hunt). А ещё два проекта, GitHunt и HackerTab, предлагают видеть на новой вкладке репозитории, попавшие в trending на Гитхабе.
GitHub
Вот о Гитхабе дальше и поговорим. Есть целая россыпь расширений, призванных улучшить работу с ним. И прямо на самом GitHub даже есть их подборка. Можете посмотреть её целиком, а здесь упомяну те варианты, у которых особенно много звёздочек.
Octotree (21k звёзд). Называет себя «GitHub на стероидах», то есть смысл в том, чтобы дать сервису дополнительные возможности. Самая заметная из них — слева появляется дерево файлов и каталогов:
Но вообще тут целый ряд фич, поэтому есть даже несколько версий: базовая бесплатная, а дополнительные штуки можно получить в платных Octotree Pro и Octotree Team. Ещё вы могли слышать про OctoLinker, но не путайте эти расширения: второе про то, чтобы в коде на GitHub после слов вроде import и include всё становилось активными ссылками, по которым можно перейти.
Refined-Github (16k звёзд). Тоже «допиливание гитхаба», но если дерево Octotree сразу бросается в глаза, то тут работа с нюансами, на уровне «сколько пробелов в табе». Вот пример такого нюанса — в issues показывает не только количество лайков, но и аватарки поставивших:
GitHub-Dark (9k звёзд). Это тоже есть в подборке расширений на GitHub, хотя технически это не само расширение, а стиль для расширения Stylus. Ну, если знаете про Greasemonkey, то идею понимаете: есть механизм применения пользовательских стилей к разным сайтам, а есть сами эти стили. И тут тёмный стиль набрал тысячи звёзд. Чем он всем так понравился, если у GitHub и так есть тёмная тема? Например, по сравнению с ней он помягче, с менее жёстким контрастом. Слева без расширения, справа с ним:
Ещё есть куча мелких расширений, предназначенных для выполнения какой-то конкретной маленькой цели. Зачастую эта цель понятна уже из названия: про GitHub Repository Size и Github npm stats сразу ясно, какую статистику они позволяют видеть при просмотре репозитория.
Понятно, какая часть IT-работы лучше всего сочетается с браузерными расширениями: та, где результат самой работы видно в браузере.
В то время как Web Developer предназначен «для всех сразу», ряд других расширений рассчитан на разработчиков, использующих конкретный фреймворк: они дополняют Chrome DevTools тем, что характерно именно для этого фреймворка. Самый популярный такой пример — React Developer Tools (больше трёх миллионов установок!). И такое найдется и по Vue.js, и по Angular, и по Ember.
Есть разнообразный аудит сайтов: этот сегмент заметно обмельчал, когда гугловский Lighthouse переехал в DevTools, но остались проекты вроде проверялки битых ссылок Check My Links.
Расширения вроде PerfectPixel и Pixel Parallel предназначены для того, чтобы при работе над вёрсткой накладывать на неё макет и сравнивать попиксельно.
Ну и мелочи для конкретных задач, которые не переворачивают мир, но кому-то экономят усилия и нервы. Например, Window Resizer: конечно, можно и вручную размеры окна браузера менять, но если это необходимо делать часто, проще с расширением. Или Lorem Ipsum Generator: если постоянно приходится использовать тексты-заглушки, их тоже можно создавать парой кликов в браузере. Мне нравится вариация Corporate Ipsum, которая генерирует настолько «энтерпрайзные» тексты, что даже не сразу замечаешь их бессмысленность:
«А какой тут использован. »
Тут снова про веб, но под определённым углом: есть целый ряд расширений, позволяющих понять «а что использовали на этом сайте» (зачастую это можно узнать и без расширения, но менее удобно). Понятно, такие пригодятся прежде всего тем, кто хочет понять, что использовать в своём веб-проекте (не только разработчикам, но и дизайнерам).
«А какой тут фреймворк»: Wappalyzer и Library Sniffer призваны показывать, какие технологии используются сайтом (от языков до систем аналитики). Вроде бы первый сообщает заметно больше.
«А какой тут шрифт»: WhatFont и Fonts Ninja позволяют узнавать это, просто наводя курсором на текст.
«А какой тут цвет»: понятно, что идея color picker из графических редакторов отлично работает и в браузере, и таких есть целый ряд. Но если какие-то из них совсем простенькие, то другие вроде ColorZilla идут дальше: тут есть и история «какие цвета уже определял», и автокопирование hex-кода в буфер обмена, и выковыривание цветов из CSS страницы.
«А какой тут CSS»: всякие CSS Viewer, CSS Peeper и Code Cola предлагают с комфортом смотреть (а то и менять) CSS открытой страницы.
«А какая тут мета»: META Seo Inspector — это не про переименовавшуюся компанию Facebook, Inc., а про метаданные страницы. Как видно из названия, ориентировано на сеошников, но думаю, может пригодиться не только им.
И даже «А какой тут редирект», как у RedirectPath. Поможет разобраться, когда вроде кликал на что-то сексуальное, а попал к сборкам OpenJDK от Алексея Шипилёва!
Что дальше
Надеюсь, кто-то узнал что-то подходящее ему из поста, а завершу его минуткой рекламы.
Если расширения вашей мечты в списке не оказалось — смело пишите о нём в комментариях.
А вот если расширение вашей мечты вообще ещё не создано — как раз для вас есть объявление. Мы на следующей неделе мы проведём конференцию HolyJS, и там будет двухчасовой воркшоп о том, как их делать с нуля. Так что сможете создать его сами.
И ещё для тех, кто заинтересовался расширениями, но переживает про безопасность («GitHub-расширение для работы с приватными репозиториями хочет доступ, что-то мне дискомфортно»). Вообще говоря, переживание правильное: расширения могут быть и вредоносными. И на той же HolyJS будет доклад как раз об их безопасности: что плохого они могут сделать и как от них защититься?
Как тестировать API, или Postman для чайников
Привет! Меня зовут Игорь Гросс, я руководитель проектов в Test IT — это такая система управления тестированием. В этом посте я расскажу об одном интересном инструменте тестировщика — Postman — а также о том, как с его помощью решать распространённый тип задач — тестирование API.
Что это вообще такое?
API — это Application Programming Interface, или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой. API позволяет слать информацию напрямую из одной программы в другую, минуя интерфейс взаимодействия с пользователем.
Как это работает? Представьте, что вы сидите в ресторане, выбираете блюдо в меню. Подходит официант, и вы делаете заказ. Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ.
Какие бывают? API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения.
Чтобы программам общаться между собой, их API нужно построить по единому стандарту. Одним из них является REST — стандарт архитектуры взаимодействия приложений и сайтов, использующий протокол HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие.
Как тестировать API?
Тестирование API проводят, основываясь на бизнес-логике программного продукта. Тестирование API относится к интеграционному тестированию, а значит в ходе него можно отловить ошибки взаимодействия между модулями системы или между системами. Для тестирования используют специальные инструменты, где можно отправить входные данные в запросе и проверить точность выходных данных. Одним из таких инструментов как раз и является Postman. Вот что он умеет:
Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT.
Работа с запросами и отправка запросов в Postman
У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request.
Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться.
Создадим запрос на получение проектов. Назовём его соответственно: /api/v2/projects
По умолчанию открывается форма создания GET-запроса:
Для удобства мы указали на иллюстрации выше пункты, соответствующие порядку действий:
1. Выбираем тип запроса. Postman предлагает внушительный список, нам нужен GET.
2. Указываем URL запроса. Первая часть ссылки должна содержать адрес сервера, где развёрнута наша TMC. Мы используем публичное API Test IT, а при составлении запросов опираемся на Swagger-документацию. В нашем случае полная ссылка будет выглядеть так: https://testit.geekbrains.ru/api/v2/projects.
3. На вкладке параметров указываем ключи и значения запроса. Мы хотим получить только удалённые проекты, и API Test IT предоставляет нам такую возможность. Укажем в параметрах isDeleted=true.
4. Переходим на вкладку Authorization, указываем данные для идентификации пользователя. Postman поддерживает множество типов авторизации, параметры для каждого из них отличаются. Используем авторизацию по API Key, полученному из личного кабинета в Test IT.
Мы заполнили все необходимые данные. Теперь выполним запрос, нажав кнопку Send.
Видим, что запрос прошёл успешно: код 200, тело ответа, время ответа и сколько занимают полученные данные. Правда, в нашем случае тело ответа будет пустое, поскольку удалённых проектов у нас нет. Советуем в ключ isDeleted ставить значение true.
Отправляемый запрос или ответ мы можем сохранить с помощью меню справа:
Параметризация запросов, переменные окружения
У нас есть коллекция запросов, и мы хотим использовать их на разных окружениях. Допустим, выполнять их локально, на тестовом стенде и на проде. Посмотрим, что предлагает Postman, и как это работает.
В меню создания выбираем Environment
В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Назовём наше окружение Test Environment. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности.
Сохраняем созданное окружение кнопкой Add. Мы всегда сможем вернуться и отредактировать окружение с помощью кнопки Manage Environments (шестерёнка в правом верхнем углу основного экрана).
Устанавливаем Test Environment в качестве текущего окружения: выбираем из выпадающего списка и вносим параметры в запрос. Переменные указываются в двух фигурных скобках. Postman подсказывает названия переменных окружения при вводе.
После того как мы использовали параметры из переменных окружения, повторим запрос, чтобы проверить, что нигде не ошиблись.
Запрос вновь прошёл успешно, значит, всё сделали правильно.
Теперь создадим другое окружение, с другими URL и token, и поменяем их с помощью переключения в выпадающем списке. Протестируем продукт на двух разных окружениях, используя одну коллекцию запросов.
Создание тестов в Postman
Мы познакомились с отправкой и параметризацией запросов, а когда же приступим к тестированию? Мы на пороге написания первого теста в Postman.
Уже в знакомом нам запросе находим вкладку Tests и переходим в неё.
Открывается окошко для написания кода на JavaScript. Postman предлагает множество готовых сниппетов, которые можно применить для тестирования API. Здесь можно валидировать коды и содержание ответов, парсить и сохранять значения в переменные окружения или глобальные переменные, проверять их соответствие заданным значениям и т.д. Подробнее о написании тестовых скриптов в Postman можно прочитать в документации или статье на Хабре.
Остановимся на создании простого тестового скрипта: проверим, что код ответа 200. Для этого используем готовый сниппет.
Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.
Помимо этого, напишем проверку. В списке, который мы получили в данном запросе, отсутствуют проекты с параметром isDeleted = false. Надо парсить ответ, в цикле проходить все объекты полученного массива и проверять, что isDeleted = true.
Вот какой код теста получился:
Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет. Если оставить true, тест будет провален. Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results.
В тренировочном запросе два теста. Чтобы создать ещё один GET-запрос, данные для авторизации и проверку на код ответа 200 нужно продублировать. Чтобы сэкономить время, внесём эти данные на уровень всей коллекции.
Переходим в редактирование коллекции.
Видим уже знакомый интерфейс для настройки авторизации, переносим сюда данные из теста.
А на вкладку Tests перемещаем проверку, что код ответа равен 200.
В запросе убираем продублированную проверку, а на вкладке авторизации укажем «Inherit auth from parent». Сохраняем запрос и отправляем.
Запрос прошёл: с авторизацией всё в порядке, и у нас отображаются 2 теста, хотя один из них мы удалили. Мы вынесли авторизацию и один тест на уровень всей коллекции, и теперь авторизация и тест на код ответа 200 будут применяться ко всем тестам внутри этой коллекции.
Коллекции можно экспортировать, чтобы делиться ими с командой. Если вы авторизуетесь в Postman, то сможете хранить коллекцию в облаке и иметь доступ с разных устройств.
Запуск коллекций тестов в Postman
В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию.
Нажимаем пиктограмму треугольника на коллекции. Открывается дополнительное окно, в котором выбираем Run. В открывшемся окне выбираем окружение, количество итераций в запуске и задержку между отправкой запросов. Также здесь стоит настроить логирование запросов, хранение переменных и cookies.
Укажем значение Iterations равным 10 и пройдём наши тесты.
Далее можно посмотреть на результаты тестов по каждому запросу, экспортировать результаты по кнопке Export Results либо пролистать их в кратком виде по кнопке Run Summary.
Заключение
Итак, мы познакомились с базовыми возможностями инструмента Postman:
Это только малая часть полезных и интересных функций Postman, при помощи которых можно тестировать API. Понравилась статья — поделитесь с коллегами 😉
Если вы хотите освоить не только Postman, но также и другие инструменты ручного и автоматизированного тестирования ПО — приглашаем вас на факультет тестирования ПО GeekUniversity!
Привет! Меня зовут Игорь Гросс, я руководитель проектов в Test IT — это такая система управления тестированием. В этом посте я расскажу об одном интересном инструменте тестировщика — Postman — а также о том, как с его помощью решать распространённый тип задач — тестирование API.
Что это вообще такое?
API — это Application Programming Interface, или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой. API позволяет слать информацию напрямую из одной программы в другую, минуя интерфейс взаимодействия с пользователем.
Как это работает? Представьте, что вы сидите в ресторане, выбираете блюдо в меню. Подходит официант, и вы делаете заказ. Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ.
Какие бывают? API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения.
Чтобы программам общаться между собой, их API нужно построить по единому стандарту. Одним из них является REST — стандарт архитектуры взаимодействия приложений и сайтов, использующий протокол HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие.
Как тестировать API?
Тестирование API проводят, основываясь на бизнес-логике программного продукта. Тестирование API относится к интеграционному тестированию, а значит в ходе него можно отловить ошибки взаимодействия между модулями системы или между системами. Для тестирования используют специальные инструменты, где можно отправить входные данные в запросе и проверить точность выходных данных. Одним из таких инструментов как раз и является Postman. Вот что он умеет:
Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT.
Работа с запросами и отправка запросов в Postman
У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request.
Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться.
Создадим запрос на получение проектов. Назовём его соответственно: /api/v2/projects
По умолчанию открывается форма создания GET-запроса:
Для удобства мы указали на иллюстрации выше пункты, соответствующие порядку действий:
1. Выбираем тип запроса. Postman предлагает внушительный список, нам нужен GET.
2. Указываем URL запроса. Первая часть ссылки должна содержать адрес сервера, где развёрнута наша TMC. Мы используем публичное API Test IT, а при составлении запросов опираемся на Swagger-документацию. В нашем случае полная ссылка будет выглядеть так: https://testit.geekbrains.ru/api/v2/projects.
3. На вкладке параметров указываем ключи и значения запроса. Мы хотим получить только удалённые проекты, и API Test IT предоставляет нам такую возможность. Укажем в параметрах isDeleted=true.
4. Переходим на вкладку Authorization, указываем данные для идентификации пользователя. Postman поддерживает множество типов авторизации, параметры для каждого из них отличаются. Используем авторизацию по API Key, полученному из личного кабинета в Test IT.
Мы заполнили все необходимые данные. Теперь выполним запрос, нажав кнопку Send.
Видим, что запрос прошёл успешно: код 200, тело ответа, время ответа и сколько занимают полученные данные. Правда, в нашем случае тело ответа будет пустое, поскольку удалённых проектов у нас нет. Советуем в ключ isDeleted ставить значение true.
Отправляемый запрос или ответ мы можем сохранить с помощью меню справа:
Параметризация запросов, переменные окружения
У нас есть коллекция запросов, и мы хотим использовать их на разных окружениях. Допустим, выполнять их локально, на тестовом стенде и на проде. Посмотрим, что предлагает Postman, и как это работает.
В меню создания выбираем Environment
В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Назовём наше окружение Test Environment. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности.
Сохраняем созданное окружение кнопкой Add. Мы всегда сможем вернуться и отредактировать окружение с помощью кнопки Manage Environments (шестерёнка в правом верхнем углу основного экрана).
Устанавливаем Test Environment в качестве текущего окружения: выбираем из выпадающего списка и вносим параметры в запрос. Переменные указываются в двух фигурных скобках. Postman подсказывает названия переменных окружения при вводе.
После того как мы использовали параметры из переменных окружения, повторим запрос, чтобы проверить, что нигде не ошиблись.
Запрос вновь прошёл успешно, значит, всё сделали правильно.
Теперь создадим другое окружение, с другими URL и token, и поменяем их с помощью переключения в выпадающем списке. Протестируем продукт на двух разных окружениях, используя одну коллекцию запросов.
Создание тестов в Postman
Мы познакомились с отправкой и параметризацией запросов, а когда же приступим к тестированию? Мы на пороге написания первого теста в Postman.
Уже в знакомом нам запросе находим вкладку Tests и переходим в неё.
Открывается окошко для написания кода на JavaScript. Postman предлагает множество готовых сниппетов, которые можно применить для тестирования API. Здесь можно валидировать коды и содержание ответов, парсить и сохранять значения в переменные окружения или глобальные переменные, проверять их соответствие заданным значениям и т.д. Подробнее о написании тестовых скриптов в Postman можно прочитать в документации или статье на Хабре.
Остановимся на создании простого тестового скрипта: проверим, что код ответа 200. Для этого используем готовый сниппет.
Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.
Помимо этого, напишем проверку. В списке, который мы получили в данном запросе, отсутствуют проекты с параметром isDeleted = false. Надо парсить ответ, в цикле проходить все объекты полученного массива и проверять, что isDeleted = true.
Вот какой код теста получился:
Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет. Если оставить true, тест будет провален. Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results.
В тренировочном запросе два теста. Чтобы создать ещё один GET-запрос, данные для авторизации и проверку на код ответа 200 нужно продублировать. Чтобы сэкономить время, внесём эти данные на уровень всей коллекции.
Переходим в редактирование коллекции.
Видим уже знакомый интерфейс для настройки авторизации, переносим сюда данные из теста.
А на вкладку Tests перемещаем проверку, что код ответа равен 200.
В запросе убираем продублированную проверку, а на вкладке авторизации укажем «Inherit auth from parent». Сохраняем запрос и отправляем.
Запрос прошёл: с авторизацией всё в порядке, и у нас отображаются 2 теста, хотя один из них мы удалили. Мы вынесли авторизацию и один тест на уровень всей коллекции, и теперь авторизация и тест на код ответа 200 будут применяться ко всем тестам внутри этой коллекции.
Коллекции можно экспортировать, чтобы делиться ими с командой. Если вы авторизуетесь в Postman, то сможете хранить коллекцию в облаке и иметь доступ с разных устройств.
Запуск коллекций тестов в Postman
В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию.
Нажимаем пиктограмму треугольника на коллекции. Открывается дополнительное окно, в котором выбираем Run. В открывшемся окне выбираем окружение, количество итераций в запуске и задержку между отправкой запросов. Также здесь стоит настроить логирование запросов, хранение переменных и cookies.
Укажем значение Iterations равным 10 и пройдём наши тесты.
Далее можно посмотреть на результаты тестов по каждому запросу, экспортировать результаты по кнопке Export Results либо пролистать их в кратком виде по кнопке Run Summary.
Заключение
Итак, мы познакомились с базовыми возможностями инструмента Postman:
Это только малая часть полезных и интересных функций Postman, при помощи которых можно тестировать API. Понравилась статья — поделитесь с коллегами 😉
Если вы хотите освоить не только Postman, но также и другие инструменты ручного и автоматизированного тестирования ПО — приглашаем вас на факультет тестирования ПО GeekUniversity!