SoapUI - Краткое руководство

SOAP - это аббревиатура от Simple Object Access Protocol. Он определен Консорциумом World Wide Web (W3C) по адресуhttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 следующим образом -

SOAP - это легкий протокол для обмена информацией в децентрализованной распределенной среде. Это протокол на основе XML, который состоит из трех частей: конверта, который определяет структуру для описания того, что содержится в сообщении и как его обрабатывать; набор правил кодирования для выражения экземпляров определяемых приложением типов данных; и соглашение для представления вызовов и ответов удаленных процедур.

SOAP - важные функции

Ниже приведены некоторые важные особенности SOAP.

Это протокол связи, предназначенный для связи через Интернет.
Он может расширить HTTP для обмена сообщениями XML.
Он обеспечивает передачу данных для веб-служб.
Он может обмениваться полными документами или вызывать удаленную процедуру.
Его можно использовать для трансляции сообщения.
Он не зависит от платформы и языка.
Это способ XML для определения того, какая информация отправляется и как.
Он позволяет клиентским приложениям легко подключаться к удаленным службам и вызывать удаленные методы.

Хотя SOAP может использоваться в различных системах обмена сообщениями и может быть доставлен через множество транспортных протоколов, первоначальное внимание SOAP уделяется удаленным вызовам процедур, передаваемым через HTTP. Другие структуры, такие как CORBA, DCOM и Java RMI, предоставляют функциональные возможности, аналогичные SOAP, но сообщения SOAP полностью написаны на XML и поэтому не зависят от платформы и языка.

Сообщение SOAP - это обычный XML-документ, содержащий следующие элементы:

Envelope- Определяет начало и конец сообщения. Это обязательный элемент.
Header- Содержит любые дополнительные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.
Body- Содержит данные XML, составляющие отправляемое сообщение. Это обязательный элемент.
Fault - Необязательный элемент Fault, который предоставляет информацию об ошибках, возникающих при обработке сообщения.

Все эти элементы объявлены в пространстве имен по умолчанию для конверта SOAP -

https://www.w3.org/2001/12/soap-envelope

Пространство имен по умолчанию для кодировки SOAP и типов данных -

https://www.w3.org/2001/12/soap-encoding

Note- Все эти характеристики могут быть изменены. Таким образом, продолжайте обновлять себя последними спецификациями, доступными на веб-сайте W3.

SOAP - Структура сообщения

В следующем блоке показана общая структура сообщения SOAP -

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST - это аббревиатура от «Репрезентативная передача состояния». Его можно определить как архитектурный стиль разработки программного обеспечения. REST не является спецификацией или стандартом W3C. Следовательно, с RESTful Services легче работать. Он не требует какой-либо структуры спецификации промежуточного программного обеспечения.

ОТДЫХ - Важные особенности

Ниже приведены некоторые важные особенности REST.

Он полагается на протокол связи клиент-сервер без сохранения состояния, кэшируемый - практически во всех случаях используется HTTP.
Это облегченная альтернатива WebService и RPC (удаленный вызов процедур), такая как SOAP-WSDL.
Он представляет все в виде уникального идентификатора или URI.
Он использует стандартные методы HTTP, такие как GET, POST, PUT, DELETE.
Он связывает источники вместе.
Ресурсы REST могут иметь несколько представлений.
Любая названная информация рассматривается как Ресурс. Например: изображение, человек, документ - все это можно рассматривать как пример ресурса и представлять как уникальный идентификатор или URI.
Сама всемирная паутина, основанная на HTTP, может рассматриваться как архитектура на основе REST.

Сервисы REST не зависят от платформы и языка. Поскольку он основан на стандартах HTTP, он может легко работать в присутствии межсетевых экранов. Как и WebServices, REST не предлагает никаких встроенных средств безопасности, управления сеансами и гарантии QoS, но их можно добавить, построив поверх HTTP. Для шифрования можно использовать REST поверх HTTPS.

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

SoapUI - важные функции

Ниже приведены некоторые важные особенности SoapUI.

Он способен выполнять роль как клиента, так и сервиса.
Это позволяет пользователям быстро и эффективно создавать функциональные и нефункциональные тесты, используя единую среду.
Он находится под лицензией GNU Leaser General Public License (LGPL).
Он полностью реализован на платформе JAVA.
Он поддерживает Windows, Mac, несколько диалектов Linux.
Он позволяет тестировщикам выполнять автоматические функциональные, регрессионные, нормативные и нагрузочные тесты для различных веб-API.
Он поддерживает все стандартные протоколы и технологии для тестирования всех видов API.

SoapUI можно использовать для полного тестирования RESTful API и тестирования веб-службы SOAP. Он поддерживает функциональное тестирование, тестирование производительности, тестирование совместимости, регрессионное тестирование, нагрузочное тестирование и многое другое.

Он удобен для пользователя, а также легко преобразовать функциональный тест в нефункциональные тесты, такие как нагрузочное, стресс-тестирование.

SoapUI богат следующими пятью аспектами:

Функциональное тестирование
Тестирование безопасности
Нагрузочное тестирование
Протоколы и технологии
Интеграция с другими инструментами

Давайте узнаем больше о каждой из этих возможностей.

Функциональное тестирование

SoapUI позволяет тестировщикам писать функциональные тесты API в SoapUI.
SoapUI поддерживает функцию Drag-Drop, которая ускоряет разработку скрипта.
SoapUI поддерживает отладку тестов и позволяет тестировщикам разрабатывать тесты на основе данных.
SoapUI поддерживает несколько сред, что позволяет легко переключаться между средами QA, Dev и Prod.
SoapUI позволяет создавать расширенные сценарии (тестировщик может разработать свой собственный код в зависимости от сценария).

Тестирование безопасности

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

Нагрузочное тестирование

SoapUI распределяет нагрузочные тесты между n агентами LoadUI.
SoapUI с легкостью имитирует массовое и реальное нагрузочное тестирование.
SoapUI позволяет создавать расширенные настраиваемые отчеты для сбора параметров производительности.
SoapUI позволяет осуществлять непрерывный мониторинг производительности системы.

Протоколы и технологии

SoapUI поддерживает широкий спектр протоколов -

SOAP - простой протокол доступа к объектам
WSDL - язык определения веб-сервисов
REST - передача репрезентативного состояния
HTTP - протокол передачи гипертекста
HTTPS - защищенный протокол передачи гипертекста
AMF - формат сообщения действия
JDBC - подключение к базе данных Java
JMS - служба обмена сообщениями Java

Интеграция с другими инструментами

Проект Apache Maven
HUDSON
JUnit
Apache - Муравей и многое другое….

SoapUI - это инструмент с бесплатной версией с открытым исходным кодом и основными функциями тестирования, а SoapUI NG Pro - это коммерческий инструмент, имеющий расширенные функции отчетности, функции управления данными и многое другое.

Сравнение

В следующей таблице сравниваются и сравниваются различные функции SoapUI и SoapUI NG Pro.

Особенности	SoapUI	SoapUI NG Pro
Supported Technologies
МЫЛО	да	да
WSDL / WADL	да	да
ОСТАТОК	да	да
JMS	да	да
AMF	да	да
JDBC	да	да
HTTP	да	да
General Features
Автономное приложение	да	да
Поддержка нескольких сред	Нет	да
Плавающая лицензия	Нет	да
Покрытие WSDL	Нет	да
Покрытие запросов / ответов	Нет	да
Утверждение сообщения	да	да
Тестовый рефакторинг	Нет	да
Запуск нескольких тестов	да	да
Тест, управляемый источником данных	Нет	да
Библиотеки сценариев	Нет	да
Отчетность по объектам	Нет	да
Шаги ручного тестирования	да	да
Reporting
Отчеты Junit	Нет	да
Экспорт данных отчета	Нет	да
Отчет WSDL HTML	да	да
Покрытие Test Suite	Нет	да
Покрытие тестовых случаев	Нет	да
Покрытие утверждений	Нет	да
Покрытие записи сообщений	Нет	да

SoapUI - это кроссплатформенный инструмент. Он поддерживает операционные системы Windows, Linux и Mac.

Предпосылки

Processor - 32-разрядный или 64-разрядный процессор с тактовой частотой 1 ГГц или выше.
RAM - 512 МБ оперативной памяти.
Hard Disk Space - Минимум 200 МБ на жестком диске для установки.
Operating System Version - Windows XP или новее, MAC OS 10.4 или новее.
JAVA - JAVA 6 или новее.

Процесс загрузки

Step 1- Перейдите на сайт www.soapui.org и щелкните Загрузить SoapUI.

Step 2- Нажмите «Получить», чтобы загрузить SoapUI с открытым исходным кодом. Он начнет загрузку файла .exe размером 112 МБ в систему. Дождитесь завершения процесса загрузки.

Процесс установки

Step 1 - После загрузки запустите файл .exe как «Запуск от имени администратора».

Windows начнет процесс настройки, как показано на следующем снимке экрана.

Step 2 - После настройки в окне процесса отображается следующий экран, нажмите «Далее».

Step 3 - Примите лицензионное соглашение и нажмите Далее.

Step 4- Выберите каталог для установки или оставьте его как путь по умолчанию, выбранный системой. Нажмите "Далее.

Step 5- Выберите компоненты, которые хотите установить. Нажмите "Далее.

Step 6 - Примите лицензионное соглашение для HermesJMS и нажмите Далее.

Step 7 - Выберите целевой каталог для сохранения руководств и нажмите Далее.

Step 8 - Выберите расположение папки в меню «Пуск» или оставьте расположение по умолчанию как есть и нажмите «Далее».

Step 9 - Установите флажок «Создать значок на рабочем столе» и нажмите «Далее».

Теперь начинается установка. Это займет несколько минут.

Step 10 - После завершения установки нажмите Готово в следующем мастере.

После нажатия на Finish запускается SoapUI.

Строка меню
Панель инструментов
Панель навигации проекта
Свойства рабочего пространства
Панель журнала

Процесс настройки

Первый шаг - создать рабочее пространство, которое может содержать несколько проектов.

Step 1 - Перейдите в Файл → Новая рабочая область.

Step 2 - Добавьте название рабочей области и нажмите ОК.

Step 3 - Теперь выберите путь, по которому будет сохранен XML-файл рабочей области.

Step 4 - Выберите путь и нажмите Сохранить.

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

WSDL означает язык описания веб-служб. Это стандартный формат для описания веб-службы. WSDL был разработан совместно Microsoft и IBM. WSDL произносится как «глупый» и пишется как «WSD-L».

WSDL ─ Краткая история

WSDL 1.1 был представлен Ariba, IBM и Microsoft в качестве примечания W3C для описания сервисов W3C XML Activity по протоколам XML в марте 2001 года.

WSDL 1.1 не был одобрен консорциумом World Wide Web Consortium (W3C), однако он только что выпустил черновик версии 2.0, который будет рекомендован (официальный стандарт) и, таким образом, одобрен W3C.

WSDL ─ на заметку

WSDL - это протокол на основе XML для обмена информацией в децентрализованной и распределенной среде. Некоторые из других функций WSDL следующие:

Определения WSDL описывают, как получить доступ к веб-сервису и какие операции он будет выполнять.
Это язык для описания взаимодействия со службами на основе XML.
Он является неотъемлемой частью Универсального описания, обнаружения и интеграции (UDDI), всемирного бизнес-реестра на основе XML.
WSDL - это язык, который использует UDDI.

Использование WSDL

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

Понимание WSDL

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

Три основных элемента WSDL, которые можно определить отдельно:

Types
Operations
Binding

Документ WSDL имеет различные элементы, но они содержатся в этих трех основных элементах, которые могут быть разработаны как отдельные документы, а затем их можно объединить или повторно использовать для формирования полных файлов WSDL.

В этом руководстве мы используем CurrencyConverter WSDL: http://www.webservicex.net

Формат и элементы

CurrencyConverter WSDL будет выглядеть следующим образом:

WSDL ─ Тип порта

Элемент <portType> объединяет несколько элементов сообщения для формирования полной односторонней или двусторонней операции. Например, <portType> может объединить один запрос и одно сообщение ответа в одну операцию запроса / ответа. Это наиболее часто используется в службах SOAP. PortType может определять несколько операций.

пример

Элемент portType определяет одну операцию, называемую ConversionRate.
Операция состоит из одного входного сообщения ConversionRateHttpPostIn.
Операция для выходного сообщения - ConversionRateHttpPostOut.

Образцы работы

WSDL поддерживает четыре основных шаблона работы:

Одностороннее движение

Сервис получает сообщение. Таким образом, операция имеет единственный входной элемент. Грамматика для односторонней операции -

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Запрос ─ Ответ

Сервис получает сообщение и отправляет ответ. Таким образом, операция имеет один входной элемент, за которым следует один выходной элемент. Чтобы инкапсулировать ошибки, можно также указать необязательный элемент отказа. Грамматика для операции запрос-ответ -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Запрос ─ Ответ

Сервис отправляет сообщение и получает ответ. Таким образом, операция имеет один выходной элемент, за которым следует один входной элемент. Чтобы инкапсулировать ошибки, можно также указать необязательный элемент отказа. Грамматика для операции запроса-ответа -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Уведомления

Сервис отправляет сообщение. Таким образом, операция имеет единственный выходной элемент. Ниже приводится грамматика операции уведомления -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Привязка и обслуживание

В <binding>Элемент предоставляет конкретные подробности о том, как операция portType будет фактически передаваться по сети.

Привязки могут быть доступны через несколько транспортов, включая HTTP GET, HTTP POST или SOAP.
Привязки предоставляют конкретную информацию о том, какой протокол используется для передачи операций portType.
Привязки предоставляют информацию о расположении службы.
Для протокола SOAP привязка - это <soap: binding>, а транспорт - это сообщения SOAP поверх протокола HTTP.
Вы можете указать несколько привязок для одного portType.

обслуживание

В <service>определяет порты, поддерживаемые веб-службой. Для каждого из поддерживаемых протоколов существует один элемент порта. Сервисный элемент - это набор портов.

Клиенты веб-службы могут узнать следующее из элемента службы:

Где получить доступ к услуге,
Через какой порт получить доступ к веб-службе, и
Как определяются коммуникационные сообщения.

Сервисный элемент включает элемент документации, обеспечивающий удобочитаемую документацию.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

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

В этой главе мы обсудим две вещи - Как -

Создать проект SOAP
Добавить WSDL

Создать проект SOAP

Step 1 - В навигаторе в левой части экрана щелкните правой кнопкой мыши «Проект» и выберите «Новый проект SOAP».

Или перейдите в File и выберите New Soap Project.

При выборе открывается новое всплывающее окно - Новый проект мыла.

Step 2 - Project Name: Введите имя проекта - это поле ввода пользователя. Initial WSDL: Это не обязательно. Это зависит от пользователя. Пользователь может предоставить WSDL или добавить после создания Project.

В этом случае мы создаем проект и добавляем WSDL позже.

Step 3- Щелкните ОК. Будет создан новый проект, который будет виден на левой панели навигации.

Добавить WSDL

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

Step 1 - Чтобы добавить WSDL, щелкните правой кнопкой мыши имя проекта (SOAP - Пример) и выберите «Добавить WSDL».

При выборе отображается мастер WSDL.

Step 2 - WSDL Location: Введите WSDL как http://www.webservicex.com или просмотрите его с компьютера.

Step 3- Как только будет введен WSDL, будут включены 3 флажка - «Создать запросы», «Создать TestSuite», «Создать MockServices». В зависимости от требований пользователь может установить один или несколько флажков.

По умолчанию установлен флажок Создавать запросы.

Step 4- Щелкните ОК. WSDL успешно добавлен в проект. Это можно проверить, наблюдая за левой навигационной панелью. Внутри проекта есть несколько операций, и запросы добавляются в соответствии с WSDL.

Подробный просмотр

Чтобы получить более подробную информацию о проекте, дважды щелкните имя проекта, откроется новое окно с различными деталями.

На вкладке «Обзор» представлена различная информация, например:

File Path - Отображает расположение сохраненного проекта xml.
Interface Summary - Имя интерфейса и связанный с ним WSDL.
Test Summary - Он отображает наборы тестов, тестовые примеры, шаги тестирования, утверждения, добавленные в проект.

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

На вкладке «Обзор» перечислены определения WSDL, части определения и сведения об операции.

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

На вкладке «Содержимое WSDL» представлены все сведения о WSDL в формате XML / схемы, как показано на следующем снимке экрана.

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

Создание TestSuite

Step 1 - В проекте щелкните правой кнопкой мыши интерфейс (рядом с именем проекта) и выберите «Создать TestSuite».

Здесь SOAP - пример - это имя проекта, а CurrencyConvertorSoap и CurrencyConvertorSoap12 - интерфейсы.

Step 2- Откроется новый мастер. Выберите варианты в зависимости от требований.

Step 3 - После того, как выбор сделан, нажмите ОК.

Step 4- Установите флажок Generate LoadTest. Это будет генерировать LoadTest для каждого TestCase, созданного в этом TestSuite.

Step 5 - Введите имя TestSuite в новом мастере и нажмите OK.

Созданный TestSuite отобразится на панели навигации, как показано на следующем снимке экрана.

Step 6- Дважды щелкните имя TestSuite, и на правой панели откроется окно TestSuite. Поскольку тестовые наборы не добавляются, поле остается пустым.

Свойства TestSuite можно увидеть в нижней части панели навигации. Новые настраиваемые свойства могут быть добавлены на уровне TestSuite.

TestCase - это набор TestSteps, собранный для тестирования некоторых конкретных аспектов веб-сервисов. Пользователь может добавить n наборов TestCases в TestSuite и даже разбить их на модули, чтобы вызывать друг друга для сложных сценариев тестирования.

Создание TestCase

Step 1- В TestSuite пользователь может добавить несколько тестовых случаев. Щелкните правой кнопкой мыши Test Suite и выберите «New Test Case».

Step 2 - Введите имя TestCase и нажмите OK.

Созданный TestCase на данный момент не имеет шагов тестирования. TestCase добавлен без TestSteps для всех видов доступных тестов. После добавления TestSteps числа в скобках автоматически изменятся. Функциональный TestStep должен перейти в «Шаги тестирования», в то время как TestStep производительности должен перейти в «Load Test», а TestStep безопасности должен войти в «Security Tests».

Step 3- Дважды щелкните имя TestCase, и на правой боковой панели откроется окно TestCase. Поскольку TestSteps не добавлен, он пуст, как показано на следующем снимке экрана.

TestSteps - это «строительные блоки» функциональных тестов в SoapUI. Они добавляются в TestCase и используются для управления потоком выполнения и проверки функциональности тестируемых веб-сервисов.

Вставка TestStep

Step 1- Щелкните правой кнопкой мыши TestSteps. Добавьте Step и выберите подходящий TestStep из списка. Например, если пользователю нужно протестировать REST WebService, он выберет тестовый запрос REST.

Step 2 - Добавьте TestStep для проверки импортированного запроса SOAP, выбрав TestSteps → Добавить шаг → Запрос SOAP.

Step 3 - Введите имя TestStep и нажмите ОК в мастере.

После нажатия кнопки «ОК» появляется диалоговое окно, в котором можно выбрать операцию, которую необходимо вызвать. Перечислены все операции, и пользователи могут выбрать операцию, которую они хотели бы вызвать.

Будут перечислены две операции. Обе операции одинаковы, за исключением используемой версии SOAP.CurrencyConvertorSoap использует SOAP версии 1.1, тогда как CurrencyConvertorSoap12 использует протокол SOAP версии 1.2.

Step 4 - Выберите первый - CurrencyConvertorSoap и нажмите ОК.

При добавлении TestCase можно добавлять различные стандартные утверждения. Утверждения также называются контрольными точками / точками проверки запроса / ответа SOAP.

Step 5 - Давайте создадим TestCase с опцией по умолчанию, что означает создание TestStep БЕЗ любой из следующих точек проверки -

Проверяет, является ли ответное сообщение SOAP при выполнении теста.
Проверяет правильность схемы ответа.
Проверяет, содержит ли ответ SOAP ОТКАЗ.

Step 6 - После нажатия кнопки ОК появляется следующий снимок экрана XML с запросом.

Счетчик тестовых шагов теперь увеличивается до единицы по мере добавления функционального TestStep. Точно так же при добавлении TestSteps нагрузки и безопасности соответствующее число автоматически увеличивается в зависимости от количества добавленных шагов.

Запросить настройку

Здесь мы выполним конвертацию валюты из INR в USD.

FromCurrency - INR
ToCurrency - доллары США

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

отклик

После отправки запроса запрос веб-службы обрабатывается веб-сервером и отправляет ответ, как показано на следующем снимке экрана.

Прочитав ответ, можно сделать вывод, что 1 единица INR = 0,0147 единицы USD.

HTTP-запрос

Сообщения SOAP передаются по протоколу HTTP. Чтобы просмотреть HTTP-запрос, щелкните RAW в окне запроса SoapUI (слева).

Запрос отправляется на веб-сервер. Следовательно, используется метод POST протокола Http.

Запрос SOAP транспортируется в теле сообщения http, которое показано ниже.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

HTTP-ответ

Щелкните вкладку «RAW» в окне ответа SOAP-UI, чтобы понять, как ответ отправляется через HTTP.

После обработки запроса отображается код ответа http (200), что означает успешное выполнение. Веб-сервер успешно его обработал.

Ответ SOAP отправляется обратно клиенту как часть тела HTTP-сообщения.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

Следующие коды HTTP используются для отправки ответов веб-сервером и очень полезны для отладки.

HTTP-код	Описание
1xx:	Informational - Это означает, что запрос был получен и процесс продолжается.
2xx:	Success - Действие было успешно принято, понято и принято.
3xx:	Redirection - Это означает, что для выполнения запроса необходимо предпринять дальнейшие действия.
4xx:	Client Error - Это означает, что запрос содержит неверный синтаксис или не может быть выполнен.
5xx:	Server Error - Серверу не удалось выполнить явно действительный запрос.

Свойства - центральный аспект более продвинутого тестирования с SoapUI. Свойства функционального тестирования используются для параметризации выполнения и функциональности тестов.

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

Определение свойств

Свойства можно определять на многих уровнях проекта.

Свойства, общие на уровне проекта, можно определить на уровне проекта.
Точно так же конкретные свойства TestSuite и TestCase могут быть определены на соответствующих уровнях.
Специфические свойства проекта определены на вкладке «Пользовательские свойства».

Например, свойство ToCurrency можно определить на уровне проекта, щелкнув символ «+» и введя Имя свойства и Значение.

Доступ к собственности

Доступ к свойству можно получить в любом месте проекта с помощью расширения свойств.

Структура будет такой -

$ {# Project # PropertyName} - для уровня проекта
$ {# TestSuite # PropertyName} - для уровня Test Suite
$ {# TestCase # PropertyName} - для уровня тестового набора
$ {TestStepName # PropertyName} - для уровня тестового шага
$ {# MockService # PropertyName} - для свойства MockService
$ {# Global # PropertyName} - для глобальных свойств, находится в Файл → Настройки → вкладка Глобальные свойства. Это свойство можно использовать во всех проектах.
$ {# System # PropertyName} - для свойства системы, находится в Справке → Свойства системы.
$ {# Env # PropertyName} - для переменной среды.

Такую же структуру можно поместить в XML-запрос запроса, чтобы получить значение определенного атрибута во время выполнения.

Свойство также можно рассматривать как переменную в компьютерной программе. Если пользователь хочет определить что-то, что можно использовать где-то еще, свойства очень полезны. Свойства также можно определять динамически, но это зависит от сценария Groovy.

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

Добавление передачи собственности

Step 1 - Выберите TestCase или TestStep, щелкните правой кнопкой мыши → Добавить шаги → Передача свойств.

Step 2 - Введите имя TestStep и нажмите OK.

Step 3 - Добавлен шаг RateTransfer, и откроется новый мастер.

Step 4- Щелкните значок «Добавляет новый перенос собственности» + в верхнем левом углу окна передачи собственности. Будет предложено ввести имя для перевода. Введите «Оценить» и нажмите «ОК».

Передача собственности

Как только перевод будет создан, Source и Target panesнеобходимо указать соответствующие выражения XPath для извлечения и замены значений свойств. В раскрывающемся списке рядом с источником перечислены различные уровни проектов SoapUI, которые могут использоваться в качестве источника передачи собственности. По умолчанию будет показан ближайший TestStep.

В данном случае это Request – INR to USDTestStep. В раскрывающемся списке рядом со свойством отображается исходное свойство, которое используется при передаче, которое может быть запросом, ответом или конечной точкой службы.

Step 1- Выберите Response и перейдите к Path language. Пользователь может выбрать XPath, Xquery или Jason для определения свойства. В этом случае выберите XPath.

Step 2 - Чтобы получить объявление исходного xml, щелкните ns и укажите XPath.

Step 3- Укажите цель, куда должно быть передано значение, извлеченное из вышеуказанного выражения XPath. Для этого используется целевая панель в нижней части окна передачи свойств.

Step 4 - Перенести извлеченное значение ConversionRateResult из ответа шага RequestINRtoUSD.

Target - Свойства

Property - ConversionRate (добавлено новое свойство, изначально не имеет значения).

Step 5 - После успешного выполнения тестового примера свойство «ConversionRate» обновляется на основе ответа.

Ниже приведен скриншот изначально.

Ниже приведен снимок экрана после успешного запуска.

Точно так же Target может быть следующим XML-запросом. Если Target - это запрос SOAP, нам нужно предоставить XPath для идентификации целевого атрибута.

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

Журнал SoapUI

В журнале SoapUI отображается информация об ответе веб-сервера. Та же информация хранится в файле soapui.log установленной папки SOAP-UI в каталоге bin.

Журнал HTTP

Журнал HTTP отображает все передачи пакетов HTTP. Вся информация в формате RAW отображается в журнале HTTP.

Журнал ошибок

Журнал ошибок отображает все ошибки, возникшие в течение всего сеанса проекта. Та же информация доступна в журнале «soapui-errors.log» в каталоге «bin» места установки SoapUI.

Журнал памяти

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

Утверждение можно интерпретировать как контрольную точку или точку проверки. Как только запрос отправлен на веб-сервер, будет получен ответ. Требуется проверить ответ, который содержит ожидаемые данные или нет. Для проверки ответа в SoapUI есть функция утверждений.

Указывает на заметку

Утверждения используются для проверки сообщения, полученного TestStep во время выполнения.
Он сравнивает часть сообщения или все сообщение с некоторым ожидаемым значением.
В TestStep можно добавить любое количество утверждений, каждое из которых проверяет различные аспекты и содержание ответного сообщения.
После выполнения TestStep все его утверждения применяются к полученному ответу, и если какое-либо из них не выполняется, TestStep помечается как сбойный в представлении TestCase.
Неудачная запись отображается в журнале выполнения теста.

Тип утверждения

SoapUI поддерживает широкий спектр утверждений в ответ.

Ниже приведен список утверждений, поддерживаемых SoapUI.

Утверждение	Описание
Property Content
Содержит	Проверяет наличие указанной строки. Он также поддерживает регулярное выражение.
Не содержит	Проверяет отсутствие указанной строки. Он также поддерживает регулярное выражение.
XPath Match	Использует выражение XPath для выбора целевого узла и его значений. Сравнивает результат выражения XPath с ожидаемым значением.
XQuery Match	Использует выражение Xquery для выбора содержимого из целевого свойства. Сравнивает результат выражения XQuery с ожидаемым значением.
Compliance, Status, Standards
HTTP-загрузка всех ресурсов	Загружает все ресурсы, называемые HTML-документом (изображения, сценарии и т. Д.), И проверяет, что все они доступны. Применимо к любому свойству, содержащему HTML.
Недействительные коды состояния HTTP	Проверяет, что целевой TestStep получил результат HTTP с кодом состояния, отсутствующим в списке определенных кодов. Применимо к любому TestStep, который получает сообщения HTTP.
Не ошибка SOAP	Проверяет, что последнее полученное сообщение не является ошибкой SOAP. Применимо к SOAP TestSteps.
Соответствие схемы	Проверяет, соответствует ли последнее полученное сообщение соответствующему определению схемы WSDL или WADL. Применимо к этапам тестирования SOAP и REST. URL-адрес определения схемы поддерживает расширения свойств (например, $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Ошибка SOAP	Проверяет, что последнее полученное сообщение является ошибкой SOAP. Применимо к SOAP TestSteps SOAP Request - проверяет, является ли последний полученный запрос действительным запросом SOAP. Применимо только к шагам тестирования MockResponse.
Ответ SOAP	Проверяет, является ли последний полученный ответ действительным ответом SOAP. Применимо только к шагам SOAP TestRequest.
Действительные коды состояния HTTP	Проверяет, что целевой TestStep получил результат HTTP с кодом состояния в списке определенных кодов. Применимо к любому TestStep, который получает сообщения HTTP.
Запрос WS-адресации	Проверяет, что последний полученный запрос содержит допустимые заголовки WS-Addressing. Применимо только к шагам тестирования MockResponse.
Ответ WS-Addressing	Проверяет, что последний полученный ответ содержит допустимые заголовки WS-Addressing. Применимо только к шагам SOAP TestRequest.
Статус WS-Security	Проверяет, что последнее полученное сообщение содержало допустимые заголовки WS-Security. Применимо к этапам тестирования SOAP.
Script
Утверждение сценария	Позволяет пользователям выполнять настраиваемый сценарий для выполнения заданных пользователем проверок. Применимо только к TestSteps (т.е. не к свойствам)
SLA
Ответ SLA	Проверяет, было ли время ответа последнего полученного ответа в пределах определенного лимита. Применимо к сценариям TestSteps и TestSteps, которые отправляют запросы и получают ответы.
JMS
Статус JMS	Проверяет, что запрос JMS целевого TestStep выполнен успешно. Применимо для запроса TestSteps с конечной точкой JMS.
Тайм-аут JMS	Проверяет, что инструкция JMS целевого TestStep не заняла больше указанного времени. Применимо для запроса TestSteps с конечной точкой JMS.
Security
Раскрытие конфиденциальной информации	Проверяет, не раскрывает ли ответное сообщение конфиденциальную информацию о целевой системе. Мы можем использовать это утверждение для REST, SOAP и HTTP TestSteps.
JDBC
Статус JDBC	Проверяет, что запрос JDBC целевого TestStep выполнен успешно. Применимо только к JDBC TestSteps.
Тайм-аут JDBC	Проверяет, что инструкция JDBC целевого TestStep не заняла больше указанного времени. Применимо только к JDBC TestSteps.

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

Issue- Пространство имен определено неправильно. Используйте правильное пространство имен. Пространство имен должно быть URL-адресом, по которому находится веб-служба.

Solution - Если при разработке утверждения сценария возникает ошибка, используйте log.info для печати содержимого переменных.

Issue - Если в качестве ответа XML получен код ошибки, это может быть связано с неверным вводом.

Solution - Проверить ввод запроса XML.

Example - В конвертере валют, если вход «FromCurrency» - «123», который не существует, на выходе выдается код ошибки как «SOAP-Client», что означает, что проблема связана с параметром, который передается из сторона клиента.

Запрос

отклик

Issue - Нет совпадений в текущем ответе при использовании XPath или XQuery.

Solution -

Используйте правильный синтаксис при определении XPath или XQuery.
Убедитесь, что при объявлении пространства имен используется двоеточие, а не точка.
Убедитесь, что XPath и XQuery верны.

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

Это означает, что это не обязательно должно быть так, как система работает при высокой нагрузке, это также может быть как она работает при базовой или ожидаемой нагрузке. Его даже не нужно структурировать, автоматизировать или создавать в TestWare, например SoapUI; простое обновление веб-браузера снова и снова очень быстро - это тоже нагрузочный тест.

Типы тестирования производительности

Ниже приведены типы тестирования производительности -

Baseline Testing - Исследует, как система работает при ожидаемой или нормальной нагрузке, и создает базовый уровень, с которым можно сравнивать другие типы тестов.
Load Testing- Включает увеличение нагрузки и посмотрите, как система ведет себя при более высокой нагрузке. Во время нагрузочных тестов пользователь может отслеживать время отклика, пропускную способность, состояние сервера и многое другое. Цель нагрузочного тестирования - не нарушить целевую среду.
Soak Testing - Цель тестирования - убедиться, что нежелательное поведение не проявляется в течение длительного периода времени.
Scalability Testing- Тестирование масштабируемости очень похоже на нагрузочное тестирование, однако вместо увеличения количества запросов оно увеличивает размер или сложность отправляемых запросов. Например, отправка больших запросов, больших вложений или глубоко вложенных запросов.

Ключевые аспекты веб-службы

В уникальных характеристиках производительности веб-сервисов выделяются два аспекта.

Первый аспект

На стороне сервера происходит обработка XML / JSON, как синтаксический анализ XML / JSON, так и сериализация . То, что часто терпит неудачу, - это обработка полезных данных. Причины выхода из строя могут быть самыми разными; это может быть связано с платформой, слабыми сторонами сервера приложений или с проблемой реализации в форме излишне сложных WSDL. Это также может означать, что код делает запрос к базе данных, которая медленно отвечает.

Testing Aspect- Сложность синтаксического анализа полезной нагрузки XML / JSON означает, что необходимо уделять дополнительное внимание тестированию масштабируемости. Это также означает, что необходимо внимательно изучить WSDL. Если запросы и ответы сложны или крупнее, или если они включают в себя большие вложения, следует сосредоточиться на том, чтобы подчеркнуть сложность и посмотреть, как она ведет себя под нагрузкой.

Второй аспект

Еще один часто встречающийся фактор - безопасность. Защищенные сайты за HTTPS имеют значительно более низкую производительность, и при тестировании веб-сервисов мы можем добавить уровень WSSecurity к уровню безопасности HTTP, еще больше снизив производительность.

Testing Aspect- Проблема безопасности означает, что необходимо сосредоточиться на выполнении тестирования безопасных запросов. Если вся веб-служба защищена, это означает, что нагрузочное тестирование более важно, особенно если используется WS-Security и обработка токенов.

Load testingэто особая форма тестирования производительности, которая проводится для оценки поведения системы при определенной нагрузке. В SoapUI мы обычно используем термин «нагрузочное тестирование» для всех типов нефункционального тестирования, однако SoapUI поддерживает все типы оценки производительности веб-служб, такие как нагрузка, стресс и выносливость.

Указывает на заметку

Нагрузочное тестирование в SoapUI совершенно уникально; функциональный тестовый пример, который позволяет быстро создавать и изменять тесты производительности.
Основное отличие состоит в том, что тесты производительности в SoapUI обычно создаются на основе существующих функциональных тестов. Это позволяет быстро создавать расширенные тесты производительности.
Производительность веб-службы можно проверить при различных сценариях нагрузки. Выполняйте функциональные проверки, чтобы убедиться, что они не ломаются под нагрузкой, запускайте одновременно несколько нагрузочных тестов, чтобы увидеть, как они влияют друг на друга, и многое другое.

Создание нагрузочного теста

Step 1 - Щелкните правой кнопкой мыши Functional Test Case и выберите New Load Test.

Step 2 - Введите имя нагрузочного теста и нажмите ОК в мастере диалогового окна.

Откроется Load Test и будет создан Load Test, как показано на следующем снимке экрана.

Выполнение нагрузочного теста

Когда создается новый нагрузочный тест, он предварительно настроен на работу в течение 60 секунд (вверху справа) с 5 потоками с использованием стратегии простой загрузки.

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

Пользователь увидит статистическую таблицу посередине, начиная со сбора данных, и через 60 секунд у него должен быть завершенный LoadTest.

Добавление утверждения

Step 1 - В редакторе LoadTest выберите вкладку LoadTest Assertion в нижней части редактора.

Step 2 - Нажмите кнопку «Добавить утверждение» в строке меню «LoadTest Assertion», чтобы добавить утверждение.

Step 3- Откроется диалоговое окно «Добавить утверждение». Выберите Максимальный шаг. Выберите «Максимум», чтобы задать максимальное время в миллисекундах, которое разрешено принимать ответам, если время превышает установленное нами, тест завершится неудачно. Щелкните ОК.

Step 4- Откроется окно TestStep Max Assertion. Как видно на следующем снимке экрана, мы допускаем максимальный ответ в одну секунду, 1000 миллисекунд. Не будем ничего изменять. Щелкните ОК.

Утверждение Step Maximum теперь будет успешно добавлено.

Step 5- Теперь запустите тест еще раз. Если ответы занимают слишком много времени, вы должны увидеть, как числа в столбце ошибок быстро увеличиваются.

Веб-сервис - это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на различных языках программирования и работающие на различных платформах, могут использовать веб-службы для обмена данными через компьютерные сети, такие как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта функциональная совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.

Веб-службы, основанные на архитектуре REST, известны как веб-службы RESTful. Эти веб-службы используют методы HTTP для реализации концепции архитектуры REST. Веб-служба RESTful обычно определяет URI (унифицированный идентификатор ресурса), который представляет собой службу, которая предоставляет представление ресурсов, такое как JSON и набор методов HTTP.

Все возможности тестирования REST в SoapUI основаны на логическом представлении, известном как служба REST. Мы не должны путать это здесь с термином «служба», поскольку это не реализация службы, а отображение вызываемой службы RESTful. Мы можем добавить столько служб REST, сколько сможем, в проект SoapUI. Каждый представляет собой конкретную службу RESTful. Они следующие -

REST - Настройка проекта
ОТДЫХ - WADL
ОТДЫХ - Запрос
ОТДЫХ - Ответ
REST - HTTP-методы

SoapUI позволяет управлять работой базы данных с помощью TestStep, называемого JDBC Request.

Step 1 - Щелкните правой кнопкой мыши TestStep и выберите Добавить шаг → Запрос JDBC.

Step 2 - Введите имя шага и нажмите ОК.

Добавлен шаг JDBC. Дважды щелкните шаг, и откроется мастер JDBC.

Чтобы создать соединение JDBC, пользователь должен предоставить действительный драйвер и строку подключения. Эти параметры используются для определения типа базы данных и создания соединения для использования базы данных.

Для MySQL драйвер базы данных может быть com.mysql.jdbc.Driver. Точно так же для другой базы данных существует предопределенный драйвер, который можно найти в разделе документов базы данных.

Step 3 - Строка подключения должна быть в следующем формате -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

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

Например,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Щелкните Проверить соединение. При успешном подключении отобразится УСПЕШНО, в противном случае - подробные сведения об ошибке.

JDBC имеет свой собственный раздел свойств добавления, который можно использовать в качестве переменной в SQL-запросе.

Посмотрим, как себя ведет -

Предположим, что на шаге JDBC необходимо выполнить SQL-запрос Select * from Currency, где CurrencyCode = 'xxx'.

В этом сценарии CurrencyCode может быть изменен на основе ввода запроса. Если пользователь предоставляет жестко запрограммированное значение, шаг JDBC не будет выполняться для валюты, указанной в запросе.

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

SQL-запрос будет запускаться на основе текущего значения Property Code, а SQL-запрос параметризует CurrencyCode =: Code.

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

JDBC Request также может использовать большинство утверждений с помощью TestSteps SOAP-запроса. В SoapUI большинство этих утверждений не зависят от TestSteps. Следовательно, такие утверждения, как Contains и XPath Match, можно использовать с JDBC Request TestStep.

Щелкнув по Add an assertion Значок в верхнем меню JDBC Request TestStep, пользователь может узнать, какие утверждения поддерживаются TestStep.

В дополнение к общим утверждениям есть два конкретных утверждения JDBC Request TestStep:

JDBC Timeout - Это утверждение можно использовать для проверки того, выполняется ли текущий SQL-запрос в пределах указанного значения свойства Query Timeout.

JDBC Status - Чтобы проверить, успешно ли выполняется инструкция SQL, мы можем использовать утверждение JDBC Status.

Чтобы установить время ожидания запроса, укажите значение, соответствующее параметру «Время ожидания запроса свойства» в левой части экрана. Имейте в виду, он принимает значение в миллисекундах (мс).