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

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

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

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

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

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

image-2024-9-2_12-55-45

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

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

image2022-2-15_13-6-49

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

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

image2022-2-15_13-26-36

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

ad956c3ac8f984c76c1a7916962c65bf

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

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

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

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

d3dbbd4726b6a745735461ee75232a96

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

4f2f3a794c1c2b7d6ce0c63bb1359614

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

Properties

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

ad05a5698a601e2cf71f0023efc0f7ff

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

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

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

Groovy Script

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

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

f682eba5a8e048389572b4ea7bf8533c

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

SOAP Request

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

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

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

d47e0c5893b745822b50a68821f65cad

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

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

Функция

Описание

${=java.util.UUID.randomUUID()}

Генерация UUID

${=(int)(Math.round((Math.random()*(b-a))+a))}

Генерация целого числа в промежутке [a; b]

${=new Date().format(‘yyyy-MM-dd’)}

Получение текущей даты

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

2e695e6f50de80ee6c2160ab6ecc4a99

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

58d116d24e96fa2f6d7abb8ad37a4994

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

d77497d2b2726acff4e4d8a79db7f907

Выберем XPath Match:

bd30ce072ba553b2dcb855a7498b708d
37802d9472fd46ce2affff2100822f9f

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

147a0d2f02e2e01390f38bb982651e9b
d6358b69b77c3a8ff51e135c1765fc0b

Conditional GoTo

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

12ef32790e010caf0aa15b92b0e2429a

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

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

Delay

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

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

1fb0d9c6ef10e7a4a4bb109ae3a17410

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

JDBC Request

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

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

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

cc7e36449672375b085d80208181c747

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

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

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

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

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

2d0aa369327a7ea6a02b94b9e547ac29

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

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

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

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

5d5b8b105c7b4fe6b683a5a5c245bf5a
019c73bc36dc6baf1159fb62b6dd0410

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

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

  • Генерирует инфо для SOAP-запроса;

  • Выполняет SOAP-запрос;

  • При получении статуса ERROR - останавливается;

  • При получении статуса NOT OK - начинается с начала;

  • При получении статуса OK - ожидает 1 секунду и выполняет запрос в БД;

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

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

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

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

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

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

Комментарии (4)


  1. mckir
    22.10.2024 14:05

    Не планируете переходить на что-то другое? импортозамещение и всё такое? Российских же пользователей на сайт даже не пускают.


    1. FreezePix Автор
      22.10.2024 14:05

      Спасибо за ваш вопрос! Действительно, доступ к официальному сайту Soup UI для пользователей из России ограничен. Однако, это не означает, что продукт перестал быть актуальным или востребованным. В то же время я понимаю, что вопрос импортозамещения актуален для российских разработчиков.

      Вот несколько ключевых моментов, которые я выделил:

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

      Альтернативы: да есть ряд неплохих вариантов на рынке со своими плюсами и минусами. Например самые, наверное известные альтернативы

      1. Apache JMeter - Не подходит для тестирования API, он про нагрузочное тестировпние

      2. Postman - простой в использовании, и является самой хорошей альтернативой SoupUI, но может гораздо меньше в бесплатной версии

      3. RestSharp - более требователен, так каа без знания программирования на C#, но более гибкий

      4. REST Assured - Не имеет GUI-интерфейса, только командная строка.

      5. Insomnia - Менее развитая экосистема и интеграции, чем у Postman.

      6. Httpie - Ограниченный функционал по сравнению с другими инструментами.

      7. Swagger - В основном фокусируется на документации и валидации API, менее мощный для нагрузочного тестирования.

      Универсальность: SoupUI может быть использован для тестирования различных видов API, включая SOAP, REST, GraphQL, JMS, AMQP и другие.
      К тому же, он предлагает широкий набор функций от автоматизации тестов, создания тестовых наборов, проверки ответов до интеграции с различными инструментами.

      Необходимость импортозамещения: В данный момент импортозамещение, да и замещение Soup UI не рассматривается. Не слышал про российские аналоги, но предполагаю если они есть, у них могут быть существенные ограничения по функциональности, отсутствовать необходимые функции, или быть менее стабильными. Ну и скорее всего они стоят дороже уже привычных продуктов, есть примеры уже импортозммещенного)
      Да и переход на новые продукты, протоколы и форматы взаимодействия - это длительный и сложный процесс. Плюс все должно быть согласовано с ИБ.

      Важным считаю отметить, что SoupUI не всегда удобен для простых сценариев тестирования, т.к. может оказаться избыточным.
      Надеюсь получилось максимально структурированно и подробно ответить на вопрос. Но если у вас есть знания об отечественных альтернативах, буду рад познакомиться с этими инструментами.


  1. Iknwpwd
    22.10.2024 14:05

    Мне вот уже лет 10 не понять, чем такой подход лучше просто написания того же самого на Java? Особенно когда включается Groovy и прочая скриптотня логика выходит из чата вроде как....


    1. FreezePix Автор
      22.10.2024 14:05

      Использование SoapUI имеет несколько преимуществ: он предоставляет удобный графический интерфейс для тестирования API, что упрощает процесс и делает его более доступным для команды. Также инструмент имеет встроенные функции для тестирования и его автоматизации, которые требуют больше времени и усилий при разработке на Java. Это позволяет быстрее создавать и запускать тесты, а также легко интегрировать их в CI/CD процессы. Таким образом, SoapUI может существенно ускорить процесс тестирования и повысить его эффективность.