Автоматизация тестирования с использованием SoapUI — Практическое руководство

Привет! Меня зовут Александр Крылов, я разработчик Siebel CRM в Московском кредитном банке.

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

На всякий подчеркну, что автоматизация тестирования играет ключевую роль в современных ИТ-проектах (если кто не догадывался). Это позволяет командам ускорить процесс тестирования и повысить качество продукта за счет увеличения количества пройденных тест-кейсов.

И как раз одним из мощных инструментов для тестирования веб-сервисов является SoapUI, который предлагает широкие возможности для работы с SOAP и REST- сервисами. В этой статье мы рассмотрим, как эффективно автоматизировать тестирование с помощью SoapUI и интегрировать его в процесс CI/CD.

Итак, начнем!

Для примера соберем простой сервис, проверяющий число — если число состоит из 3 знаков, то сервис вернет Status — OK, иначе NOT OK, и ERROR при получении внутренних ошибок.

Собираем автотест

Для начала необходимо добавить в свой проект новый TestSuite (нажать ПКМ на свой проект в дереве с проектами):

Далее на созданном TestSuite необходимо создать TestCase. Добавляется из списка, при нажатии ПКМ на TestSuite.

Тут и будет происходить основная логика взаимодействия шагов кейса. Можно создать не один TestCase, и описать разные кейсы. Название говорит само за себя.

После создания кейса должен получиться такой результат:

В сам кейс необходимо добавить шаги. Добавим XML-запрос, его заполнение на Groovy-скриптах, условие на параметр из ответа и выполнение запроса в БД через 1 секунду при получении статуса OK.

Дополнительно добавим валидацию ответа и параметризацию автотеста, но обо все по порядку.

Добавляем шаги

В окне кейса мы можем добавлять шаги, которые будут выполняться по порядку:

Нам потребуется Properties, Groovy Script, SOAP-запрос, Conditional GoTo, Delay и JDBC-запрос:

После успешного создания шагов, каждый необходимо настроить. Доступ к настройке открывается после двойного клика по требуемому шагу.

Properties

Шаг Properties ничего не выполняет, он нужен чтобы хранить в себе некоторые данные, пока выполняется кейс. Например, данные УЗ или адрес сервиса. Добавим их в наш кейс:

У SoapUI есть интересная фича: если назвать параметр «Password», то его значение маскируется.

Также сами параметры мы можем хранить не только на уровне кейса, но и выше по иерархии. Например, на уровне проекта или создать глобальные для приложения.

Для наших целей ограничимся параметрами на уровне кейса.

Groovy Script

Groovy — это java-подобный язык, который кратно расширяет возможности SoapUI. В нашем примере мы реализуем генерацию числа Number.

Для того чтобы сервис возвращал разные статусы, будем генерировать значения от 900 до 1100 и подставлять в новый параметр шага Properties:

Если используемые в скриптах параметры не созданы или удалены, то скрипт их создаст.

SOAP Request

Переходим к самому интересному — заполнению XML и настройке всего окна с запросом.

Ранее мы создавали параметры, теперь предстоит их использовать. Их можно указывать где угодно и SoapUI вас поймет.

Заполним то, что уже создано и произведем тестовое обращение к сервису.

Сервис успешно ответил, теперь заполним MessageId, также с помощью генерации, но другим способом.

Помимо указания параметров в запросе мы можем писать исполняемый код. Вот некоторые полезные функции:

Функция	Описание
${=java.util.UUID.randomUUID()}	Генерация UUID
${=(int)(Math.round((Math.random()*(b-a))+a))}	Генерация целого числа в промежутке [a; b]
${=new Date().format(‘yyyy-MM-dd’)}	Получение текущей даты

Первую используем для MessageId:

Чтобы посмотреть, что было подставлено в запрос воспользуемся вкладкой Raw:

Для текущего шага осталось настроить валидацию, чтобы при получении статуса ERROR, автотест останавливался.

Выберем XPath Match:

Теперь автотест будет останавливаться, если сервис ответил статусом ERROR, в остальных случаях будет продолжать свою работу.

Conditional GoTo

Далее по условию нам необходимо повторить генерацию и отправить повторный запрос после получения статуса NOT OK, с этим нам поможет справиться шаг Conditional GoTo:

Мы добавили условие: Если статус из ответа равен NOT OK, то перейти к шагу Groovy Script, то есть вернуться на 2 шага назад.

На статус OK не будем добавлять условие, автотест и без него пойдет к следующему шагу, так как не найдет ни одного подходящего условия.

Delay

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

Шаг Delay — это обычный таймер, который останавливает выполнение кейса на время указанное в настройках. Указывается в миллисекундах:

Выполнение запроса рассмотрим далее.

JDBC Request

Для выполнения запроса в БД, нам необходимо разместить в папке к приложению SoapUI, JDBC-драйвер от необходимой БД.

Далее открыть окно настройки и указать драйвер, строку для подключения и сам запрос.

Как и адрес сервиса выше, строку для подключения и драйвер, я вынес в параметры:

Так как это тоже запрос, из ответа можно доставать параметры и обрабатывать их в кейсе, но в примере мы этого делать не будем.

Валидация тут также присутствует. Помимо настройки подключения к БД, все настройки аналогичны настройкам SOAP запроса.

Дополнительно

Также в примере выше мы не рассмотрели транспортировку.

SoapUI позволяет это сделать, с помощью шага Property Transfer:

На изображении показана настройка для записи параметра MessageId из ответа на SOAP запрос в параметр MessageId шага Properties.

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

Запуск и итоги

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

FINISHED — означает успешное прохождение всех шагов. В логах кейса описано какие шаги выполнялись и в каком порядке. В случае ошибок будет отображаться статус FAILED.

После полной настройки у нас получился полноценный автоматизированный кейс, который:

Генерирует инфо для SOAP-запроса;
Выполняет SOAP-запрос;
При получении статуса ERROR — останавливается;
При получении статуса NOT OK — начинается с начала;
При получении статуса OK — ожидает 1 секунду и выполняет запрос в БД;

Советы из рубрики «спасибо, подумаю» или «лучшая практика автоматизации тестирования в SoapUI»:

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

Автоматизация тестирования с помощью SoapUI — это эффективный способ повысить качество разработки и ускорить выпуск новых версий программного обеспечения. Используя возможности Groovy для сложных сценариев, вы сможете создать мощный процесс автоматизированного тестирования, который будет работать без вашего постоянного участия.

Если у вас есть опыт автоматизации тестирования в SoapUI, делитесь им в комментариях. Какие инструменты и практики вы считаете наиболее эффективными?

P.S. Автоматизация тестирования — это не просто тренд, а реальная необходимость в условиях ускоряющихся темпов разработки. Используя SoapUI, вы сможете значительно оптимизировать свои процессы и повысить качество продукта.

ссылка на оригинал статьи https://habr.com/ru/articles/852280/