Тестирование 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'.
Аналогично, URL API 'Post Comment' требует Post ID, полученный из ответа API 'Create Post'. Эти шаги могут быть утомительными и отнимать много времени, особенно при тестировании реальной системы, которая обычно включает в себя больше четырех API.
Как опытные тестировщики, мы также хотим проводить негативные тесты на каждом API в дополнение к интеграционному тестированию. Давайте рассмотрим несколько примеров негативных тест-кейсов для API 'Create User'.
Восемь — именно столько раз нам пришлось вручную нажимать кнопку "Отправить", не говоря уже о том, что нам пришлось вручную изменять тело запроса между нажатиями.
Давайте не будем больше медлить и начнем автоматизировать API. Я разделю процесс на две части: интеграция и управление данными.
Автоматизация — интеграционный тест
Шаг 1: Использование переменных
Мы можем упростить процесс, сохранив идентификатор пользователя из ответа API 'Create User' в переменной и затем используя его в URL API 'Create Post' и 'Delete User', вместо того, чтобы вручную копировать и вставлять его несколько раз.
Эту задачу можно решить, просто включив небольшой фрагмент кода на JavaScript в раздел Tests запроса. После отправки запроса Postman автоматически выполнит код в разделе Tests.
Теперь, когда ID пользователя сохранен в переменной коллекции с именем "user_id", давайте рассмотрим переменные коллекции. Переменная "user_id" теперь должна содержать значение User ID, полученное из ответа.
Наконец, включите переменную в URL-адреса API 'Create Post' и 'Delete User'.
Поскольку URL API 'Post Comment' требует Post ID, полученный из ответа API 'Create Post', давайте сделаем то же самое.
По завершении этого шага необходимость в ручном копировании и вставке данных между ответами 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 <имя коллекции>".
Из результатов видно, что все утверждения прошли. Мы можем для проверки углубиться в детали каждого утверждения, как в приведенном ниже примере проверки, когда параметр name пуст.
Отлично! Мы видим, что все отправленные запросы соответствуют тестовым данным из 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".
Записаться на открытый урок
