Привет! Меня зовут Александр Крылов, я разработчик 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, вы сможете значительно оптимизировать свои процессы и повысить качество продукта.