[Перевод] Postman для эффективного тестирования API
Тестирование API является важной частью разработки программного обеспечения, но при выполнении вручную оно может отнимать много времени и включать в себя много повторяющихся задач. Postman является одним из наиболее широко используемых инструментов для тестирования API. Однако многие пользователи зачастую не используют его возможности автоматизации в полной мере, что приводит к снижению эффективности процесса тестирования API.
В компании JULO мы изначально не использовали возможности автоматизации Postman. Вместо этого мы вручную тестировали каждый API, включая те, которые уже были стабильны и находились в продакшене. Например, мы вручную жали кнопку «Отправить» 20 раз для выполнения 20 тест-кейсов для одного API. В случае интеграционных тестов, когда один тест-кейс требовал задействования нескольких API, например десяти, мы вручную нажимали кнопку «Отправить» 200 раз. Такой подход отнимал много времени и был чреват ошибками, что снижало нашу производительность.
Сегодня мы проводим ручное тестирование только для API, которые все еще находятся в разработке, или в определенных ситуациях, когда автоматизация может быть не лучшим вариантом, например, при исследовательском, ad-hoc, юзабилити и тестировании пограничных случаев. Для стабильных API, уже находящихся в продакшене, мы полагаемся на автоматизированное тестирование с использованием заранее написанных тестовых сценариев для получения эффективных и точных результатов.
Эта статья для тех, кто хочет повысить эффективность QA за счет автоматизации тестирования API или просто хочет изучить новые методы. Я проведу вас через процесс пошагового создания автоматизированных тестов в Postman, охватывая автоматизацию интеграционных тестов и тестов, основанных на данных.
Чувство безысходности от утомительных ручных шагов
В этом посте мы будем использовать коллекцию Postman Collection, представленную ниже. API, используемые в этой демонстрации, взяты с сайта gorest.co.in, который предоставляет бесплатный фиктивный сервис REST API, предназначенный для тестирования.
Названия запросов понятны и не требуют пояснений. Однако для контекста предположим, что эти API относятся к типичной системе онлайн-форума, которая включает функциональность для создания пользователей, сообщений, комментариев и удаления пользователей.
Интеграционное тестирование часто предполагает использование данных из ответа одного API в качестве параметра другого API. Например, чтобы протестировать API 'Create Post' и 'Delete User', необходимо добавить в URL ID пользователя, полученный из ответа API 'Create User'.
Получение user ID из успешного ответа API 'Create User'
Размещение user ID в URL API 'Create Post'
Ввод user ID в URL-адрес API 'Delete User'
Аналогично, URL API 'Post Comment' требует Post ID, полученный из ответа API 'Create Post'. Эти шаги могут быть утомительными и отнимать много времени, особенно при тестировании реальной системы, которая обычно включает в себя больше четырех API.
Как опытные тестировщики, мы также хотим проводить негативные тесты на каждом API в дополнение к интеграционному тестированию. Давайте рассмотрим несколько примеров негативных тест-кейсов для API 'Create User'.
Тело запроса API 'Create User' (JSON)
Примеры негативных тест-кейсов для API 'Create User'
Восемь — именно столько раз нам пришлось вручную нажимать кнопку «Отправить», не говоря уже о том, что нам пришлось вручную изменять тело запроса между нажатиями.
Давайте не будем больше медлить и начнем автоматизировать API. Я разделю процесс на две части: интеграция и управление данными.
Автоматизация — интеграционный тест
Шаг 1: Использование переменных
Мы можем упростить процесс, сохранив идентификатор пользователя из ответа API 'Create User' в переменной и затем используя его в URL API 'Create Post' и 'Delete User', вместо того, чтобы вручную копировать и вставлять его несколько раз.
Эту задачу можно решить, просто включив небольшой фрагмент кода на JavaScript в раздел Tests запроса. После отправки запроса Postman автоматически выполнит код в разделе Tests.
Сохраните User ID в переменной коллекции «user_id»
Теперь, когда ID пользователя сохранен в переменной коллекции с именем «user_id», давайте рассмотрим переменные коллекции. Переменная «user_id» теперь должна содержать значение User ID, полученное из ответа.
Переменные коллекции
Наконец, включите переменную в URL-адреса API 'Create Post' и 'Delete User'.
«Create Post» API URL
«Delete User» API URL
Поскольку URL API 'Post Comment' требует Post ID, полученный из ответа API 'Create Post', давайте сделаем то же самое.
Сохраните Post ID в переменной коллекции «post_id»
URL API 'Post Comment'
По завершении этого шага необходимость в ручном копировании и вставке данных между ответами API и URL будет устранена.
Шаг 2: Создание утверждений (Assertions)
Утверждения являются важным компонентом автоматизации, поскольку они позволяют определить успех или неудачу теста.
Аналогичным образом, утверждения могут быть включены в раздел Tests запроса. Поскольку в одной статье невозможно охватить все возможные типы утверждений, мы сосредоточимся на процессе добавления утверждений для код-статуса ответа и тела ответа.
Утверждение кода ответа состояния
Утверждение тела ответа
Давайте сделаем проверку: отправим запрос и посмотрим на раздел «Результаты тестирования» / Test Results.
Отлично! Теперь, когда мы применили тот же процесс к остальным API (которые не будут рассматриваться в этой статье), давайте перейдем к последнему шагу.
Шаг 3: Использование Postman Collection Runner
Хотя мы выполнили шаги 1 и 2, нам все еще нужно вручную нажать кнопку «Отправить» для каждого API. Postman Collection Runner автоматизирует этот процесс, запуская все API в коллекции. Помните, что он запускает их последовательно, поэтому перед запуском runner-а убедитесь, что порядок API в коллекции правильный.
Нажмите на три точки рядом с названием коллекции и выберите Run collection.
2. Нажмите кнопку «Run <имя коллекции>».
3. Вуаля!
Теперь интеграционный тест автоматизирован, что позволяет просто и без особых усилий выполнять его в любое время.
Автоматизация — тест, основанный на данных
Шаг 1: Настройка запросов
Цель этого процесса — создать наборы тестовых данных в CSV-файле, сохранить их в переменной коллекции, а затем отправить запрос определенное количество раз, исходя из количества строк (как тест-кейсов) в файле.
Создайте CSV-файл и введите необходимые тестовые данные
2. Назначьте отдельную переменную для значения каждого атрибута
3. В разделе Pre-request Script добавьте код, чтобы загрузить данные теста из CSV-файла и сохранить их в переменных коллекции. Обратите внимание, что Postman автоматически выполнит этот код перед отправкой запроса, в отличие от раздела «Тесты».
Шаг 2: Создание утверждения
На рисунке показан результат тест-кейса «проверить, пусто ли имя».
Поскольку все тест-кейсы будут возвращать ответ со статус-кодом 422, будет целесообразным определить это значение в качестве ожидаемого ответа. Кроме того, нам понадобится еще один «тест» для отображения описания каждого тест-кейса. Для этой информационной цели утверждение не требуется.
Шаг 3: Загрузите CSV-файл и запустите коллекцию
Перед запуском коллекции загрузите CSV-файл, содержащий тестовые данные. Postman автоматически определит количество итераций.
Нажмите кнопку «Запустить/Run <имя коллекции>».
Результаты выполнения тест-кейсов с 1 по 4
Результаты выполнения тест-кейсов с 5 по 8
Из результатов видно, что все утверждения прошли. Мы можем для проверки углубиться в детали каждого утверждения, как в приведенном ниже примере проверки, когда параметр name пуст.
Тест-кейс 1
Отлично! Мы видим, что все отправленные запросы соответствуют тестовым данным из CSV-файла. Автоматизированный Data Driven тест завершен!
Автоматизация облегчает жизнь
Когда я пришел в JULO, я стал частью команды, основной задачей которой было тестирование API. В мои повседневные задачи входило ручное тестирование этих API. Сначала работа была несложной, поскольку я тестировал всего несколько API для существующего продукта, и у меня было несколько коллег-тестировщиков, работавших над тем же продуктом.
Со временем ситуация изменилась — я оказался единственным QA, которому поручили тестировать новый продукт, состоящий из более чем 10 API. Времени на выполнение ручных интеграционных тестов и тщательных негативных тестов для каждого API уходило слишком много. Дополнительная трудность заключалась в том, что поскольку это был новый продукт, эти API все еще находились в стадии разработки и были нестабильны. Это означало, что если разработчик вносил изменения в код в связи с дополнительными требованиями или багфиксингом, мне приходилось заново все тестировать, чтобы избежать проблем с регрессивом. Неожиданно оказалось, что работа не так проста, как казалось.
К собеседованию в JULO я готовился, просматривая курс по Postman от Udemy, и изначально пропустил раздел автоматизации, поскольку в описании вакансии не было ничего сказано про автоматизацию. Однако вскоре я обратился к этому разделу и узнал об автоматизации Postman. Я внедрил ее в свою работу и обнаружил, что она весьма полезна. Несмотря на некоторые первоначальные дополнительные усилия, автоматизация значительно упростила процесс тестирования, сократив необходимость ручного выполнения. Даже когда требовалось внести изменения в сценарий автоматизации из-за изменения требований, усилия были минимальными по сравнению с ручным тестированием.
Я предложил этот подход QA Lead-у, который признал его ценность и предложил мне поделиться им с командой. Теперь Postman Automation является стандартной практикой в JULO.
В статье мы прошли через процесс создания интеграционного теста и автоматизированного теста на основе данных с помощью Postman. Теперь у вас должно сформироваться понимание, как автоматизировать тестирование API с помощью Postman.
Всех начинающих автоматизаторов приглашаем на бесплатное открытое занятие по основам одного из самых популярных тестовых фреймворков для Java — junit. На занятии научимся делать предусловия и постусловия для тестов, узнаем, что такое Assertions. В результате вы научитесь конфигурировать простые тестовые классы и будете понимать, когда и какие аннотации использовать. Занятие пройдет в рамках онлайн-курса «QA Automation Engineer».
