Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Краткая инструкция по тестированию в SOAPUI для начинающих

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Всем привет, когда-то давно я опубликовал небольшую заметку о тестировании в SOAP UI. Многие посчитали ее полезной, поэтому вопрос публикации более развернутой статьи был чисто вопросом времени. К сожалению, руки постоянно не доходили заняться этим. Я провел очень поверхностный анализ того, что есть на русском на эту тему, и решил, что статья о тестировании SOAP сервисов остается актуальной.

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

Несколько важных уточнений:

  • Эту статью я пишу для людей, которые никогда до этого тестированием SOAP сервисов не занимались, поэтому возможно она может быть слишком детализированной или элементарной для тех, кто уже знаком с этой темой.
  • В процессе подготовки статьи заметил, что документацию для SoapUI очень хорошо доработали , плюс появилось много хороших ресурсов, поэтому эта статья возможно будет полезна только тем у кого есть сложности с английским.
  • Часть описанных возможностей есть только в Pro версии, которую можно получить в триал-пользование на 14 дней бесплатно.
  • SOAP это немного архаичная технология, но она еще будет оставаться актуальной скорее всего, потому что ее используют в основном очень консервативные клиенты (банки, финансовые организации, государственные учреждения, авиакомпании и т.д.)

Кратко о SOAP

SOAP (Simple Object Access Protocol) — это протокол обмена данными в виде XML. В основном применяется для передачи данных между разными системами в удобочитаемом для них формате. Такая связь разных систем называется интеграцией.

SOAP часто сравнивают с REST и это правильно, но так как статья ориентирована на начинающих, то, чтобы было легче представить что это такое, давайте воспользуемся аналогией с веб-сайтом и объясним на этом примере что такое веб-сервис и WSDL.

Веб-сервис — точка доступа к веб-серверу через которую происходит взаимодействие. По сути — это просто URL или говоря совсем по-простому ссылка. Ее даже можно открыть в браузере. Но в отличие от удобного человеко-читаемого сайта с картинками и меню, вы увидите XML документ, который является машиночитаемым. Этот документ называется WSDL (Web Services Description Language). По сути, он является заменой меню сайта. И полностью описывает что этот веб-сервис может делать, какие данные принимает на вход, формат запросов и ответов и еще много чего.

SoapUI — это удобный и популярный инструмент для тестирования веб-сервисов. С помощью Soapui можно выполнять запросы к сервису и получать ответы от него. Давайте попробуем протестировать работу веб-сервиса.

Пример 1. Вызов веб-сервиса

1. Для начала нужно установить Soap UI
2. Потом его надо запустить
3. Выбрать Create Functional Test

4. Выбрать API Definition

5. Вставить ссылку на WSDL. Для примера возьмем сервис, умеющий конвертировать цифровую запись числа в текстовую и нажать Next.

6. Выбрать Add Data

7. В левой части экрана появился список методов этого веб-сервиса

8. Выберем NumberToWords, в блоке Request введем цифру 55 и нажмем Send. Через некоторое время мы получили Response с текстом fifty five

Пример 2. Data Driven тесты

Очень неудобно, когда данные прописаны непосредственно в тест кейсах (hard-coded). Такие тесты неудобно поддерживать. Подход к тестированию, при котором тестовые данные хранятся отдельно от тест-кейсов называется Data-driven testing. SoapUI позволяет использовать различные источники данных: *.xls, *.csv, *.txt, XML properties, базы данных. После этого полученные данные мы можем использовать в наших TestSteps (реквесты, скрипты, property и т.д).

Будем предполагать, что для целей тестирования нам необходимо брать логин и пароль пользователя из документа и подставлять его в запрос для проверки баланса по счету (метод getBalance общедоступного сервиса shopInterkassa).

Перечень логинов и паролей выглядит так:

[email protected] — qwerty
[email protected] — password
[email protected] — qwerty
[email protected] — password
[email protected] — qwerty
[email protected] — password
[email protected] — qwerty

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

1. Подготовить проект (подключить WSDL)
2. Создать TestSuite и тест-кейс в проекте
3. Добавить тестовый шаг «DataSource»

3.1. Настраиваем наш источник данных. Для этого указываем:

  • Тип файла (Excel)
  • Директорию в которой находится файл
  • Ячейку, с которой необходимо начинать считывание данных

3.2. Задаем переменные Properties. В нашей таблице только 2 столбца: Логин и пароль.

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

4.1. Удаляем знаки вопроса в запросе и кликаем правой кнопкой мыши

4.2. В появившемся меню выбираем какие данные нужно брать и откуда

5. Теперь для того, чтобы циклично выбрать по строкам данные из DataSource добавляем DataSource Loop.

5.1. Настраиваем DataSource Loop:

  • Выбираем DataSource step
  • Выбираем Target Step — шаг, в который будут циклично передаваться данные из DataSource

После этого можно запускать тест-кейс. В такой конфигурации тест-кейс будет выполняться пока не переберет все значения из DataSource.

Пример 3. Извлечение данных из Response и их вставка в Request (Property transfer)

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

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

В подготовленном примере моделируется ситуация, когда у нас есть сервис, способный преобразовывать вес из килограммов в граммы. Также есть сервис, способный преобразовывать вес из граммов в милиграммы. Предположим, что напрямую превратить килограммы в милиграммы мы не можем. В таком случае пригодится Property transfer. Мы выполним следующую последовательность действий:

  • преобразуем вес из килограммов в граммы
  • перенесем полученное значение из ответа первого метода в запрос второго метода
  • преобразуем вес из граммов в милиграммы

Для того чтобы это выполнить, необходимо:
1. Подготовить проект (WSDL)
2. Создать TestSuite и тест-кейс в проекте
3. Сформировать запрос, преобразующий вес из килограммов в граммы

4. Добавить шаг Property transfer


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

6. Сформировать запрос, преобразующий вес из граммов в милиграммы. При этом MetricWeightValue оставить пустым. Это поле заполнится автоматически благодаря Property transfer

Примеры посложнее

Пример 4. Настройка JDBC соединения с БД

Выше я упомянул, что Soap UI позволяет брать данные из базы данных. Это возможно будет немного сложно для начинающих, но может оказаться полезным тем, кто немного знаком с SoapUI.

Для подключения к БД необходимо:

1. Скопировать соответствующий JDBC драйвер в папку с SoapUI (SmartBear\SoapUI-5.1.3\bin\ext)

2. Вставить JDBC Request

3. Добавить параметры подключения к базе

4. Проверить соединение нажатием на кнопку Test Connection

5. Ввести запрос к БД в окошке SQL Query

Для JDBC Request предусмотрено 2 типа проверок;

  • JDBC Status проверяет что ответ от базы получен
  • JDBC Timeout проверяет что ответ от базы получен в течении Краткая инструкция по тестированию в SOAPUI для начинающих

Нюансы подключения к БД Oracle

В документации ( список Driver и Connection string для разных БД наперед заданного времени, может использоваться для проверки SLA) к soapUI написано, что при подключении к Oracle для записи Connection String необходимо использовать следующий формат jdbc:oracle:thin:/@::

Но в данном формате не ясно куда и как вводить логин/пароль. В случае шаблона подключения к MySql явно прописано где и как должны быть указаны логин/пароль jdbc:mysql://:/?user=&password=

Экспериментально было установлено, что для подключения к Oracle необходимо использовать следующий формат jdbc:oracle:thin:login/password@//host:port/sid

Groovy скрипт для установки JDBC соединения с БД

import groovy.sql.Sql;
def  con = Sql.newInstance("jdbc:oracle:thin:@192.168.77.71:1521:ORA11", "IBPE", "IBPE", "oracle.jdbc.driver.OracleDriver");
def res = con.rows("select id  from CURRENCY where A3='UAH'")
log.info(res[0].sysdate.toString())
con.close()

Пример 5. Создание заглушек в SoapUI

Заглушки важная составляющая тестирования и разработки. SOAP в основном используется для интеграций, и часто доступа к реальным системам нет, но есть информация о том как они работают (например в виде спецификаций). В таких случаях создаются заглушки, которые являются очень упрощенной эмуляцией реальных систем, с которыми нужно интегрироваться.

В SoapUI MockService включает 3 основных компонента:

  • MockService
  • MockOperations
  • MockResponses

MockService может включать в себя любое количество MockOperations, которые в свою очередь содержат несколько MockResponses. MockOperations это операции WSDL, который импортируется в проект SoapUI. MockResponses являются реакциями на эти операции. MockService моделирует работу реального веб-сервиса.

1. Выберите проект, который мы создали ранее, и щелкните на нем правой кнопкой мыши. Выберите пункт Generate MockService.

2. В появившейся форме выберите операции, работу которых необходимо имитировать.

3. При создании MockService, мы можем изменить URL, на котором хостится Mock. По умолчанию SoapUI запускает сгенерированный MockService на встроенном сервере Jetty, который работает через порт 8088.

4. После нажатия кнопки ОК, необходимо ввести имя MockService. Затем будет создан MockService с соответствующими ему MockOperations.

5. Двойной клик на MockOperations открывает форму с настраиваемыми опциями

Адресация (Dispatching) при выполнении MockOperation

MockOperation может включать в себя несколько MockResponses. Поэтому, когда мы отправляем запрос на MockService, необходимо иметь возможность управлять тем, какой из MockResponse будет отвечать на определенный Request. Dispatching styles используется для выбора механизма управления mock responses. SoapUI поддерживает следующие Dispatching styles:

  • SEQUENCE: Это стиль диспетчеризации по умолчанию. Когда отправляется запрос к MockOperation, MockResponses будут выполняться последовательно один за другим, в том порядке в котором они находятся в списке MockResponses. Например, когда у нас есть два MockResponses, response1 и response2 и вы отправляете два запроса к MockService, то первый запрос будет направлен к response1, а второй будет направлены к response2.
  • SCRIPT: Этот стиль дает возможность контролировать ответы на основе Groovy сценариев и определяется непосредственно скриптами.
  • RANDOM: Этот стиль выбирает MockResponses случайно без определенной логики.
  • QUERY_MATCH: Этот стиль возвращает MockResponse по оценке нескольких выражений XPath. Например, вы можете указать несколько пар запросов, с разными ожидаемыми значениями и указать MockResponse, к которому запрос должен быть направлен.
  • XPATH: Этот метод диспетчеризации используется для отправки запроса в ответ, на основании результата выражений XPath запроса.

Статические заглушки

1. Двойным кликом на операции откройте редактор MockResponse.

2. Замените знаки вопроса данными, которые должны выводиться в MockResponse

3. Теперь для любого запроса, в ответ будет возвращаться MockResponse с введенными данными

Динамические заглушки

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

В нашем примере мы можем создать три разных ответа в зависимости от того, как заполнен логин

  • Поле пустое
  • Поле заполнено правильно
  • Поле заполнено неправильно

Создадим три MockResponse для трех этих случаев

  • ValidResponse
  • FaultResponse
  • EmptyResponse

Для FaultResponse ответ должен выглядеть следующим образом:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
  	<SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>Authorisation failed</faultstring>
  	</SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Для EmptyResponse ответ должен выглядеть следующим образом:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
	     <faultcode>SOAP-ENV:Server</faultcode>
         <faultstring>Call to a member function checkPass() on a non-object</faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Для ValidResponse ответ должен выглядеть следующим образом:

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://shop.interkassa.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns2="http://xml.apache.org/xml-soap" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
      <ns1:getBalanceResponse>
     	<return xsi:type="ns2:Map">
        	<item>
          	 <key xsi:type="xsd:string">EUR</key>
           	<value xsi:type="xsd:float">0</value>
        	</item>
        	<item>
           	<key xsi:type="xsd:string">USD</key>
           	<value xsi:type="xsd:float">0</value>
        	</item>
        	<item>
  	         <key xsi:type="xsd:string">UAH</key>
           	<value xsi:type="xsd:float">0</value>
        	</item>
        	<item>
           	<key xsi:type="xsd:string">RUR</key>
           	<value xsi:type="xsd:float">0</value>
        	</item>
     	</return>
      </ns1:getBalanceResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

В ответ на запрос, в зависимости от данных запроса, должен быть показан один из трех MockResponses. Чтобы добиться этого, мы не можем использовать стиль SEQUENCE, который будет просто последовательно выводить три разных респонса. Ответ должен зависеть от запроса. Поэтому нам нужно иметь какой-то сценарий, чтобы прочитать запрос и выбрать соответствующий MockResponse. Для этого нужно использовать SCRIPT style.

Добавим следующий скрипт

def payload = new com.eviware.soapui.support.XmlHolder(mockRequest.requestContent)
def getBalance = payload["//soapenv:Envelope/soapenv:Body/soap:getBalance/email"]
def responseToUse = "";
 
if (getBalance.equals('[email protected]')) {
    responseToUse = "ValidResponce"
} else if (getBalance.equals("[email protected]")) {
    responseToUse = "FailureResponse"
} else if (getBalance.equals("_")) {
    responseToUse = "EmptyResponse"
} else {
 
    //default to success response
    responseToUse = "EmptyResponse"
}
 
return responseToUse

Данный скрипт работает следующим образом:

Строка def getBalance = payload["//soapenv:Envelope/soapenv:Body/soap:getBalance/email"] определяет поле, которое является неким «индикатором» для скрипта. Именно по значению email в запросе, скрипт определяет по какому пути выполняться.

Блок проверки условий

if (getBalance.equals('[email protected]')) {
	responseToUse = "ValidResponce"
} else if (getBalance.equals(`[email protected]`)) {
	responseToUse = "FailureResponse"
} else if (getBalance.equals("_")) {
	responseToUse = "EmptyResponse"
} else {

В этом блоке сравнивается значение email в запросе с ожидаемым значением. Если в запросе указано [email protected], то скрипт выведет ValidResponce. Если будет введено [email protected], то это считается не валидным значением и в ответ будет выведен FailureResponse. Если же в поле email, введено любое другое значение, будет EmptyResponse.

Пример 6. Использование Groovy скриптов в SoapUI

Скрипты в SoapUI могут использоваться для:

  • Генерации заглушек при моделировании веб-сервисов
  • Генерации запросов и условий прохождения тестов
  • Расширения базовой функциональности

Скрипты могут быть добавлены в такие объекты

  • Groovy Script step
  • Setup and TearDown Scripts
  • Load Script
  • Script assertion
  • MockService

Переменные типа Context

Используются для получения и сохранения информации

  • LoadTestRunContext — доступны в нагрузочных тестах
  • MockRunContext — доступны на протяжении работы заглушки
  • SubmitContext — доступны в момент отправки запроса
  • TestRunContext — доступны во время выполнения тест-кейса. Все скрипты в тест-кейсе имеют доступ к переменным TestRunContext

Например

  • получить имя тестового шага log.info(context.getCurrentStep().getLabel())
  • получить имя тест-кейса log.info(context.getTestCase().getLabel())
  • получить имя тест-сьюита log.info(context.getTestCase().getTestSuite().getLabel())

Переменные типа testRunner

Переменные в SoapUI бывают:

  • уровня проекта
  • уровня тест-сьюта
  • уровня тест-кейса

Если у нас объявлена переменная, то ее можно вставить в любое место запроса используя конструкции

  • ${# Project Name # Value }
  • ${# TestSuite # Value }
  • $ {# TestCase # Value }

Создание переменной проекта/ тест-сьюита / тест-кейса

testRunner.testCase.testSuite.project.addProperty(‘ProjectProperty1’)
testRunner.testCase.testSuite.addProperty(‘TestsuiteProperty1’)
testRunner.testCase.addProperty(‘TestcaseProperty1’)

Установка значения переменной проекта/ тест-сьюита / тест-кейса

Получение значения переменной проекта/ тест-сьюита / тест-кейса

def projectProp = testRunner.testCase.testSuite.project.getPropertyValue
( “Project_Level_Property” )
“Project_Level_Property” )

log.info (projectProp)
def testProp = testRunner.testCase.testSuite.getPropertyValue(‘Testsuite_Property’)
log.info (testProp)

def testcasePro = testRunner.testCase.getPropertyValue(‘Testcase_Property’)
log.info (testcasePro)

Удаление переменной проекта/ тест-сьюита / тест-кейса

testRunner.testCase.testSuite.project.removeProperty( “Testcase_Property” );
testRunner.testCase.testSuite.removeProperty( “Testcase_Property” );
testRunner.testCase.removeProperty( “Testcase_Property” );

P. S.

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

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Гарна стаття. Достатньо докладна. Після Н.Р. пораджу своїм QA її добре проштудувати (самому немає часу показувати нюанси — тут вони є!) .

По Оракл невеличке доповнення — зараз треба працювати вже через ojdbc.
А корректні налаштування треба брати з файлу names.ora — бажано мати хоча б sqlplus —тоді все дуже легко... :) —перевірка конфігурації tnsping

Гарно було б додати порівняння з Postman — плюси/мінуси

Підтримую про «порівняти з Postman». Так як для початківців — це було б корисно розуміти, з точки зору більш досвідчених спеціалістів.

після «@mail.ru» не читав ((((((((

Так это ж тестовые данные. Над кацапами опыты ставят))

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі