SOAP UI

О чём эта статья

В этой статье Вы узнаете о том что такое SOAP UI и увидите некоторые примеры использования.

Если Вам проще изучать материал от самого простого к более сложному - рекомендую сперва прочитать первые несколько страниц моего учебника здесь

Содержание статьи

	Введение
	Создание Test Suit в SOAP UI
	Assertions в SOAP UI
	XPath Match Assertion
	Mock Service с помощью SOAP UI
	Установка SOAP UI в Linux

Введение

SoapUI - это приложение для тестирования веб-сервисов с открытым исходным кодом для сервисно-ориентированных архитектур (SOA) и передач состояния представления (REST).

Разработчик - Eviware Software

Язык программирования, на котором пишут скрипты в SOAP UI, называется Groovy.

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

Коммерческая версия SoapUI Pro, которая в основном фокусируется на функциях, предназначенных для повышения производительности, также была разработана Eviware Software. В 2011 году SmartBear Software приобрела Eviware.

SoapUI был первоначально выпущен в SourceForge в сентябре 2005 года. Это бесплатное программное обеспечение, лицензированное в соответствии с публичной лицензией Европейского Союза.

Начиная с первого релиза, SoapUI был загружен более 2 000 000 раз. Он полностью построен на платформе Java и использует Swing для пользовательского интерфейса. Это означает, что SoapUI является кросс-платформенным. Сегодня SoapUI также поддерживает IDEA, Eclipse и NetBeans.

SoapUI может тестировать веб-службы SOAP и REST, JMS, AMF, а также совершать любые вызовы HTTP(S) и JDBC.

Ссылку на скачивание SOAP UI можно найти здесь

Как отправлять запросы

New REST Project → Пишем URI → Запрос создаётся, можно добавлять новые.

Method можно выбирать из выпадающего списка.

Проект имеет иерархическую структуру.

Project → Service → Resource → Method → Request

Названия отражают суть:

Request (запрос) это то место, где можно поменять тело запроса и просмотреть ответ сервера. Чтобы отправлять запросы нужно нажимать зелёный треугольник.

Method (метод) указывает GET, POST, PUT или другой метод, который Вы будете использовать. Все дочерние запросы будут иметь один и тот же Method.

Resourse (ресурс) отвечает за ту часть URL, которая добавляется к базовой.

Service (сервис) отвечает за базовую часть URL

Как сохранять проекты

Советую помимо использования «Save all projects» закрывать все новые окна вручную. Тогда SOAP UI предложит Вам сохранить каждый проект по отдельности.

После того, как все новые проекты сохранены, Вы можете закрыть SOAP UI. Я стараюсь закрывать SOAP UI только когда все окна закрыты.

Создание Test Suit in SOAP UI

Коротко:

→Правый клик Project → Create New TestSuit (CTRL + T) → Укажите имя для TestSuit → Правый клик на TestSuit → New TestCase (CTRL + N) → Укажите имя для TestCase → Expand Test Case → Кликните на Test Steps → Add Step → Выберите request (e.g. SOAP Request) → Укажите имя для new step → Выберите операцию, которая запускает request → Добавьте Request в TestCase (OK)
Зелёная «+» иконка плюса появится наверху. Кликнув на неё Вы можете добавить Assertions.

Подробно:

Create New TestSuit (CTRL + T)

→ Правый клик на TestSuit

→ Expand Test Case

→ Кликните на Test Steps

→ Add Step

→ Выберите request (e.g. SOAP Request)

→ Укажите имя для new step

→ Выберите операцию, которая запускает request

→ Добавьте Request в TestCase (OK)


Зелёная «+» иконка плюса появится наверху. Кликнув на неё Вы можете добавить Assertions.

Assertions в SOAP UI

Assertions добавляются в TestSuits поэтому, чтобы добавлять Assertions нужно создать хотя бы один TestSuit и затем кликнуть на зелёную+ иконку.

Затем Вы можете выбрать однин из многих доступных в SOAP UI типов assertion.

Property Content → Contains

Выберите Contains. С помощью этого подтверждения (assertion) можно искать присутствует ли в ответе заранее определённое ключевое слово. Оно поддерживает регулярные выражения и применимо ко всем ответам.

Specify unique name of Assertion

Type in content that you expect to receive in case of successfull request

Property Content → Not Contains

Выберите Not Contains. С помощью этого подтверждения (assertion) можно проверить отсутствие в ответе заранее определённого ключевого слова. Оно поддерживает регулярные выражения и применимо ко всем ответам.

Введите уникальное имя для Assertion

Введите сюда то, что Вы точно не хотите видеть в теле ответа

Compliance, Status и Standards

SOAP Response

Выберите SOAP Response. В этим assertion Вы можете проверить что последний полученные ответ является валидным SOAP ответом. Это можно применять только к SOAP TestRequest Steps. Не пытайтесь применять этот assertion к REST запросам.

Двойной клик на Assertion. Никакие дополнительные параметры не нужны этот шаг можно добавить только один раз.

Compliance, Status и Standards

Valid HTTP Status Code

Выберите Valid HTTP Status Code. С помощью этого assertion Вы можете проверить является ли последний полученный ответ (Response) валидным SOAP ответом (Response).

Как Вы уже, наверное, догадались, этот assertion применим только к SOAP TestRequest Steps. Не пытайтесь использовать его для REST запросов.

Type in the HTTP Status Codes that are appropriate for your request.

Обычно это 200, но всё же стоит прочитать спецификацию системы, которую Вы тестируете..

SLA → Response SLA

Выберите Response SLA. С помощью этого assertion Вы можете подтвердить, что последний полученный ответ (Response) был получен в течении определенного времени.

Можно применять к Script TestSteps и TestSteps которые посылают запросы и получают ответы.

Укажите максимальное время ответа (мс)

Если время в которое нужно уложиться не указано в спецификации - поставьте какое-то разумное время.

Property Content → XPath Match

Выберите XPath Match. Этот Assertion использует выражение типа XPath чтобы выбрать содержимое указанного объекта и сравнить результат с ожидаемым значением.

Может быть применён к любому объекту, который содержит XML.

Нажмите Declare

Чтобы подтвердить что нужные данные присутствуют в ответе напишите exists (//данные_которые_должны_придти)

В поле Expected Result напишите true.

Чтобы проверить не наличие как таковое, а значение какой-то величины введите в XPath Expression либо полный путь до величины либо её имя.

А само значение, которое Вы ожидаете получить введите в поле Expected Result.

В случае, если, например, мы не можем соединиться с сервером и все наши assertions зафейлились у них появятся красные индикаторы.

Сервис-имитация

Сделаем сервис, который будет посылать нам сообщения в ответ на определённый тип запроса на определённый EndPoint

Для примера я выбрал сервис для сайта о велосипедах TopBicycle.ru заходите на этот сайт если любите велосипеды.

Аналогичный функционал можно реализовать с помощью любого веб-сервера.

Если не хотите связываться с SOAP UI - советую прочитать статью Flask

File → Create Empty Project

Введите имя проекта

New Rest Mock Service

Укажите имя MockService

Add new mock action

Введите путь и выберите метод GET

New MockResponse

Введите имя нового ответа

Скопируйте json и вставьте в тело ответа

{ "bicycles":{ "bicycle": [{ "id":1, "name": " Helkama ", "country": " Finland" }, { "id":2, "name": " Stels ", "country": "Russia" },{ "id":3, "name": " Tunturi ", "country": " Finland " }] } }

Замените Content | Media type на application/json. Http Status Code должен быть 200 – OK. Headers введите по желанию. Их можно добавить нажав на зелёный плюс +

Правой кнопкой мыши кликните на BicycleService и

Add new mock action

Назовите его «bicycle/1»

Правой кнопкой мыши кликните на «bicycle/1» (или кликните Ctrl + N) и

create New MockResponse

назовите его «singleBicycle»

Скопируйте json и вставьте в тело ответа

{ "bicycle": { "id":1, "name":"Helkama", "country":"Finland" } }

Создайте новый mock action, имя оставьте старое «/bicycle» а тип измените на POST вместо GET.

Создайте новый MockResponse и назовите его «addBicycle»

Скопируйте json и вставьте в тело ответа

{"key":12041961}

Создайте новый mock action типа GET и назовите его «/incorrectep» а новый MockResponse «400» Измените Http Status Code на 400 – Bad Request

Обратите внимание, что сервис BicycleService использует порт 8080

Запустите BicycleService нажав на зелёный треугольник

У нас есть четыре сценария

Используем Postman чтобы протестировать их

POST на http://localhost:8080/bicycle

Должен вернуть key 12041961

GET на http://localhost:8080/bicycle

Должен вернуть список велосипедов

GET на http://localhost:8080/bicycle/1

Должен вернуть первый велосипед

GET на http://localhost:8080/incorrectep

Должен вернуть пустой ответ и Http Status 400 Bad Request

Dynamic Response

Чтобы заменить статичный ответ 12041961 на динамический в запросе POST на /bicycle заменим 12041996 на ${variable} и в script добавим следующий код:

context.setProperty("variable" ,Math.random()*100000000000000000)

Чтобы протестировать отправим несколько запросов из Postman и проверим изменяется ли ответ

Нужен ли SOAP UI?

Ответ на этот вопрос зависит от уровня Вашей подготовки, предпочтений и, в каком-то смысле, идеологии.

Начинающему тестировщику SOAP UI пригодится хотя бы потому, что хранить и создавать запросы в нём прощё и быстрее чем другими способами.

Тестировщик с опытом программирования, например, на Python может написать все необходимые скрипты самостоятельно.

Идеологическим приверженцам работы из консоли или только из Linux тоже может показаться что в SOAP UI слишком много UI.

Установка SOAP UI в Linux

Обратите внимание на необходимость предварительной установки Java (JRE).

Как установить Java читайте здесь

Существует официальная инструкция, но если хотите сэкономить время и нервы…

Переходим на страницу загрузки.

Скачиваем установщик. Копируем в нужную директорию, например, в /opt. Распаковываем.

tar -zxvf SoapUI-5.4.0-linux-bin.tar.gz

Переходим в директорию SoapUI-5.4.0/bin

sh soapui.sh

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