SoapUI: тестирование SOAP и REST API

• Кратко об API
• Тестирование API: сферы и инструменты
• Знакомство с Soap UI
  • Доступен ли в России
  • Области применения
  • Архитектура
  • Поддерживаемые протоколы
  • Интеграция с другими инструментами
  • Сравнение с Selenium
• SoapUI vs Postman
  • Импорт коллекций из Postman
• Установка
• SOAP и REST
• Тестирование SOAP в Soap UI
  • Что такое WSDL
• Тестирование REST
  • Что такое WADL
• Добавление эндпойнтов
• Кастомные свойства
• Параметризация
• Assertions
• Гайд по Assertions

Что такое API

По стандартному определению, «программный интерфейс приложения», программный «посредник» между приложениями. API состоит из набора правил взаимодействия, описывающих как приложение работает с другими приложениями. Иначе говоря, API — это механизм обмена данными (функциями) между приложениями.

Когда приложению нужны данные из другого приложения (или нужно отправить свои данные в другое приложение), происходит взаимодействие через API. Чаще всего приложению нужно запросить срабатывание сервиса (то есть какой-то «внешней функции») другого приложения. Суть API — не в взаимодействии с пользователем через пользовательский интерфейс, а в взаимодействии на уровне программа-программа.

Тестирование API

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

Тестирование API не затрагивает пользовательский интерфейс, не касается «вида и ощущений» от продукта. Тестировщик программно эмулирует данные и сценарии взаимодействий. Фокус — на функциональности, а не на user experience, как в других видах тестирования, «обращенных к пользователю».

Почему тестирование API сейчас востребовано в QA

• Растущая взаимосвязанность ИТ-сервисов, зависимость множества приложений от API-сервисов крупных компаний
• При тестировании API возможно автоматизированное тестирование, что экономит усилия
• А также параллелизация тестов

• Независимость от языка программирования (данными обмениваются в формате JSON или XML, следовательно тестировать API-ответы можно на любом общеупотребительном в QA языке)
• Простая интеграция с GUI-инструментами тестирования, и наличие удобных инструментов, и в частности SoapUI

Инструменты

Кроме Soap UI (его официальный сайт здесь):

• Katalon Studio
• Postman (у нас есть большой гайд для начинающих и вопросы на собеседовании по Postman)
• JMeter — производительность API
• Rest-Assured

Что такое Soap UI

Заявляется владельцем как «самый часто применяемый инструмент для тестирования API в мире». С открытыми исходниками, годится в принципе для всех видов тестирования API: функциональное, регрессионное, нагрузочное и тестирование совместимости.

• Функциональное тестирование API. Проверка общей функциональности приложения (работает ли в соответствии с функциональными требованиями). 
• Регрессионное тестирование API — проверка того, что изменения/багфиксы не повредили существовавшую функциональность системы.
• Совместимости API — что система отвечает требованиям по совместимости API с другими системами и стандартами, возможности работы на других платформах и т.п.
• Нагрузочное тестирование API — проверка работы API в условиях стандартной рабочей и повышенной нагрузки.

Доступен ли в России

Формально — нет, для пользователей с российским IP доступ к сайту закрыт (по крайней мере об этом пишут). С другой стороны, есть VPN, или можно просто попросить кого-то переслать установочный файл.

Применение Soap UI

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

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

• Очень мощный инструмент функционального тестирования API
• Перетаскивание мышкой, ускоряющее создание скриптов
• Поддерживает дебаг автотестов
• Поддержка Data-Driven-тестирования
• Поддержка нескольких тестовых окружений: переключение между QA-, Dev- и Prod-окружениями
• Продвинутые тестовые сценарии с кастомным кодом

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

• Есть возможности делать полный набор тестов проверки уязвимостей
• Предотвращает SQL-инъекции
• Проверка на переполнение буфера большими документами
• Проверка на XSS-уязвимости при передаче параметров
• Поддержка fuzzy-сканирования и сканирования граничных значений

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

• Нагрузочное тестирование при помощи LoadUI-Агентов
• Режимы объемного и нагрузочного тестирования
• Продвинутые функции репортов и записи параметров нагрузки
• Сквозное нагрузочное тестирование

Тестирование совместимости

Тестирование аутентификации (сертификатов) и совместимости в различных системах.

Регрессионное 

Анализ багов и проблем в веб-сервисах (повторная верификация после модификаций сервисов).

Архитектура SoapUI

Архитектура SoapUI сравнительно проще, чем у других подобных инструментов тестирования.

• Файлы конфигурации тестов. Тестовые данные, ожидаемые результаты, переменные для подключения к базам данных, и другие переменные и данные для тестирования.
• Third-party API. Сторонние API для оптимизации тестового фреймворка. В частности JExcel API для интеграции с Microsoft Excel, для создания DDT-фреймворка.
• Selenium. JAR-файл Selenium для автоматизации
• SoapUI Runner для запуска автотестов из командной строки.
• Groovy-библиотека для написания сценариев на Groovy.
• Свойства (Properties). В Свойствах хранятся динамически генерируемые данные. Например, для конфигурирования SSL и других параметров безопасности.
• Репорты (отчеты), в стиле JUnit, плюс JasperReports для оформления.

Какие протоколы поддерживает SoapUI

• SOAP
• WSDL
• REST
• HTTP(S)
• AMF
• JDBC
• JMS

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

• Maven, инструментом управления билдами, репортами и документацией из центрального репозитория. Также Maven может выполнять SoapUI-тесты при помощи простых команд Maven Build.
• Hudson, Java-инструмент для Continuous Integration, подключающийся к CVS, Subversion, Git, Perforce, Clearcase, RTC. И SoapUI, что помогает быстро находить баги в каждом коммите.
• JUnit, Java-фреймворк для юнит-тестирования, управляющий выполнением из SoapUI.
• Apache Ant, Java-библиотека, позволяющая запускать API-тесты при помощи Ant Automated Build.

SoapUI и Selenium — сравнение

SoapUI	Selenium
Не предназначен для тестирования UI приложений и сайтов.	Широко применяют для тестирования интерфейса
Тестирует отправляемые и принимаемые данные между браузером и сервером, через протоколы REST и SOAP	Не тестирует как работают протоколы, а как работает интерфейс
Для функционального, нагрузочного и безопасного тестирования	В целом только функциональное тестирование. Может и для нагрузочного, оценивая время отклика, но не поддерживает множественных пользователей. Не годится для тестирования безопасности.
Построен «вокруг протоколов» и не зависит от браузеров	Построен «вокруг браузеров»

SoapUI и Postman — сравнение

SoapUI	Postman
Для SOAP, REST, Graph QL	Для REST API
Data-driven-тестирование	Не поддерживает DDT
Кастомизация репортов в разные форматы	Репорты только в JSON и HTML
Для тестирования API	Для ручного и исследовательского тестирования REST API
Сценарии легко использовать повторно	REST-вызовы сохраняются для повторного использования
Поддерживает асинхронное тестирование	Поддерживает форматы Swagger (OpenAPI) и RAML API
JavaScript и Groovy	JavaScript
Есть платная (с расширенной функциональностью) и бесплатная кроссплатформенная версия с открытым кодом	Нативное приложение кроссплатформенное приложение. Postman-плагин для Chrome не обновляется с 2017
Более широкая функциональность, сравнивая с Postman	Ограниченный набор функций (впрочем достаточный для распространенных задач)
Продукт рассчитан на тестирование SOAP	Создание SOAP-запросов возможно, но довольно сложное

Импорт коллекций из Postman

В Postman можно создавать описания API, и группировать их в коллекции. Эти коллекции легко импортируются в Soap UI. Postman — отличное средство тестирования API, однако SoapUI (и тем более платный ReadyAPI) — лучше.

Сначала экспортируем коллекцию, сохранив ее в файле:

Указываем Collection v1.

И сохраняем.

Теперь в SoapUI находим в главном меню File > Import Postman Collection.

В диалоговом окне нажимаем Browse и находим сохраненную коллекцию.

Soap UI создаст новый проект и импортирует все описания API из коллекции. Если в коллекции есть тесты, автоматически создаются тестовые этапы (действия) SOAP или REST-запросов. Нужно будет уточнить тест-кейсы и действия по каждому запросу.

Правила преобразования из Postman в SoapUI

Структура проекта в SoapUI отличается от Postman. 

•  API-запросы преобразуются в API-описания в Проектах.
• Глобальные переменные, заданные в элементах preRequestScript и tests, преобразуются в кастомные свойства проекта.
• Все property-элементы в URL запросов и globals[«property»] в скриптах заменяются на расширенные свойства.
• Базовая авторизация преобразуется в заголовок запроса, содержащий данные по авторизации.
• Заголовки преобразуются в параметры запроса HEADER.
• Если в коллекции есть тесты, SoapUI создаст тест-кейс для них (см. выше).
• SoapUI создает assertions для соответствующих элементов в тестах Postman. Например:
• tests[«Status code is 200»] = responseCode.code === 200 конвертируется в assertion “Valid HTTP Status Codes”.
• tests[«Status code is not 401»] = responseCode.code !== 401 будет преобразован в assertion “Invalid HTTP Status Codes”.
• tests[«Response time is less than 300ms»] = responseTime < 300 преобразуется в assertion “Response SLA”.
• tests[«Body matches string»] = responseBody.has(«abc») преобразуется в assertion “Contains”.
• tests[«Content Type is present»] = postman.getResponseHeader(«Content-Type») преобразуется в assertion “Script”.

Установка SoapUI в Windows

Есть два варианта — бесплатная и платная версии SoapUI (платная версия c расширенной функциональностью называется ReadyAPI). Работаем с бесплатной версией [скачать отсюда, около 200 Мб]:

Системные требования для установки

• Процессор — хотя бы 1 ГГц
• Места на диске — минимум 300 Мб
• Память — минимум 1 Гб
• Java — Java 6+
• ОС — MacOS 10.4+, Windows XP+

Устанавливаем.

1. Нажимаем “Run”.
2. Проходим все этапы установки (“Next”).
3. Жмем “Finish”.

После установки запускаем SoapUI. Скипаем диалог регистрации (сейчас не нужна) и выбора REST-эндпойнта:

Тестирование SOAP и REST в Soap UI

Есть два типа архитектуры веб-сервисов, которые тестирует SoapUI: SOAP и REST.

SOAP

То есть SOAP-протокол поверх HTTP. Эти сервисы типа HTTP POST, передающие данные в XML-формате в запросе и ответе. Все запросы идут на один и тот же URL, и могут быть добавлены специальные заголовки или XML-элементы в тело запроса, выполняющие нужные операции. SOAP-сервисы используют WDSL-описания (о них далее).

REST

Использует HTTP. Операции выполняются с использованием комбинаций HTTP-методов и имени запрошенного ресурса.

POST/GET-запросы могут добавлять информацию или доставлять данные из/в базу данных.

SOAP-сервисы используют WADL-описания (о них далее), Swagger (Open API) и другие.

Тестирование SOAP-запросов в SoapUI

Создаем SOAP-проект.

(Нажимаем “New SOAP Project” в меню)

2. В диалоге настройки заполняем необходимые поля:

Заполняем “Название проекта”.

Поле “Initial WSDL”. Способ первый: взять готовый WSDL-файл в интернете. (Можно здесь, просто для ознакомления как это работает). Копируем этот URL и вставляем в поле ‘Initial WDSL’ (комбинацией Ctrl-V).

Способ 2. Файл уже есть где-то на рабочем компьютере, тогда просто указать путь к нему (‘Browse’).

Что такое WSDL

Web Services Description Language — язык описания веб-сервисов, указывающий путь к сервису и его методы, используя XML-элементы <types>, <message>, <portType> и <binding>.

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

Структура WSDL-файла:

Если при создании SOAP-проекта применяется способ с добавлением внешнего WSDL-файла в проект, нужно заполнить поля.

Этап 3. Жмем ‘ОК’, завершая создание проекта.

SoapUI: иерархия тест-свит > тест-кейсы > тестовые действия (этапы):

4. Создаем тестовый набор (тест-сьют).

Кликаем правой кнопкой на имени проекта и в выпавшем меню нажимаем ‘New Test Suite’:

Этап 5. Добавление тест-кейса в сьют

Кликаем правой кнопкой на созданном только что тест-сьюте и выбираем ‘Новый тест-кейс’: 

Теперь проект выглядит так:

Этап 6. Добавляем тестовые действия в тест-кейсе.

Этап 7. Теперь добавляем релевантный эндпойнт в запрос. Эндпойнты у нас есть, потому что мы их добавили в WSDL-файле (выше).

Этап 8. Выполняем тестовые действия (запуск — зеленая кнопка со стрелкой):

Выполнение действия, запрос и ответ в XML и raw-форматах:

Иконка будет зеленой, если все прошло без проблем.

SoapUI отображает как XML- так и raw-формат (переключение слева вверху).

Тестирование REST-запросов в SoapUI

Этап 1. Создаем REST-проект:

Этап 2. В появившемся окне нужно ввести URL к WADL-файлу:

1. Способ 1. Указываем WADL-файл в поле. Копируем где-то URL и вставляем в поле (через Ctrl-V). (URL например здесь: http://petstore.swagger.io/v2/swagger.json )

2. Способ 2. Если WADL-файл уже есть на машине, нажимаем ‘Import WADL… > Browse’ и указываем путь к нему.

Что такое WADL

Язык Web Application Description Language. Аналог WSDL-файла из примера выше. Применяется для REST-сервисов. 

Нажимаем ‘ОК’ и создаем новый REST-проект:

Структура REST-проекта:

Сервисы, ресурсы, и запросы:

Этап 4. Добавляем ресурс (для примера http://petstore.swagger.io/#/ ):

Ресурс добавлен:

Этап 5. Генерируем тест-сьют:

Структура тест-сьюта:

Этап 6. Добавляем действия в тест-кейс:

Этап 7. Добавляем эндпойнт в запрос:

Этап 8. Запускаем: 

9. Добавление эндпойнтов

Что такое эндпойнт?

Это «один из концов канала коммуникации» в API, проще говоря конечная точка API.

Добавление эндпойнта:

1. Нажимаем ‘Endpoint Explorer’.
2. Указываем метод (например GET).
3. Добавляем эндпойнт (например http://petstore.swagger.io )
4. Нажимаем ‘Отправить’ и смотрим raw-ответ.
5. Нажимаем ‘Сохранить запрос’.

Кастомные свойства

1. Кастомные HTTP-заголовки. При нажатии зеленой кнопки ‘+’ откроется диалог ‘Добавить HTTP-заголовок’, вводим имя.

До ввода заголовка тело запроса не имеет поля ‘key’.

После получения заголовка тело запроса — поле ‘key’ и значение.

Параметризация

Добавляются свойства на любом уровне проекта (уровне тест-сьюта или тест-кейса).

Добавляем свойство на уровне сьюта:

Также можно добавить на уровне проекта. 

Assertions

Нажимаем зеленый ‘+’ в окне запроса ‘Request 1’:

Окно с вариантами assertions.

Далее сценарий с assertions. Должен быть http-статус 200, тогда считается валидным.

Выбираем ‘Valid HTTP Status Code’:

Указываем валидный http-статус

Если в ответе будет статус 200, он подходит для этого assertion, тест-кейс пройдет:

А если не 200, а допустим 400:

Об Assertions подробнее

Assertion (или assert, или утверждение) — утверждение/предположение о правильности какого-либо условия. В QA эта концепция применяется в качестве «точки проверки» условия (точка валидации). 

Например, на сервер отправлен запрос и получен ответ. Нужно проверить (валидировать), что в запросе содержатся нужные данные. Это удобно делать с помощью assertions.

Типы Assertions в SoapUI

• Property Content
• Compliance Status Standard
• Script
• SLA
• JMS
• Security

В Pro-версии продукта (readyAPI) есть еще встроенный JDBC-assertion, проверяющий правильность обновления базы данных; в SoapUI недоступен.

Сейчас сосредоточимся на следующих Assertions:

• Contains Assertion
• Not contains Assertion
• XPath Match Assertion
• Scripting Assertion

Contains

Производит поиск указанной строки. Также поддерживает регулярные выражения.

Для примера поработаем с WSDL-запросом на сайт http://www.dneonline.com/calculator.asmx.

1. По умолчанию нет assertions.

• Количество Assertions отображается в соответствующей вкладке.
• Добавить assertion: кнопка ‘+’.

2. Теперь: 

Выбираем категорию ‘Property Content’, тип ‘Contains’, и нажимаем ‘Add’:

3. Теперь валидируем, что в ответе есть например строка ‘46’. Нажимаем ОК.

(Можно игнорить регистр и добавлять регулярные выражения)

4. Assertion выполняется и показывает, VALID или INVALID.

5. Теперь изменим в поле ‘Contains Assertion’ на ‘47’ и посмотрим результат.

6. Assertion выполнен, результат передан. В ответе нет строки ‘47’, поэтому assertion FAILED.

NOT CONTAINS

Проверяет отсутствие указанной строки в ответе. И также с регулярными выражениями.

1. Нажимаем ‘Добавить Assertion’, выбираем категорию ‘Property Content’, ‘Добавить’.

2. Проверяем, что в ответе нет строки ‘intA’. Вводим строку ‘FromCurrency’ и жмем ОК.

3. После добавления и выполнения assertion-а, он выполнится и выведет результат. В примере ниже добавлены два assertion-а, оба выполнятся и покажут VALID.

4. Теперь изменим содержимое (поле Content) и посмотрим результат. Проверим отсутствие строки ‘AddResult’:

5. Строка ‘AddResult’ есть в ответе, поэтому утверждение ‘НЕ содержит’ FAILED:

XPATH MATCH

Xpath-выражение, выбирающее нужный узел и его значения. 

1. Нажимаем ‘Add new assertion’, выбираем категорию ‘Property Content’ и тип ‘XPath Match’, ‘Add’

2. Откроется окно XPath Window.

Сначала нужно объявить XML NameSpace — коллекцию имен, идентифицируемых по URI, которые используются в XML-документах как имена элементов и атрибутов. Нажимаем ‘Declare’ (можно также вручную объявить ). Далее появятся два пространства имен (потому что у нас два URI). Одно из них schema-URL, второе реальный URL ресурса. При обращении к XPath нам нужен реальное пространство (не schema-namespace).

declare namespace soap=’http://schemas.xmlsoap.org/soap/envelope/’;

declare namespace ns1=’http://tempuri.org/’;

3. Теперь вводим XPath XML-узла, который нужно валидировать.

//ns1:AddResult дает значение узла между <AddResult> & </AddResult>, ns1 соответствует объявленному пространству имен, указывающему на ‘http://tempuri.org/’.

После введения XML нажимаем ‘Select from current’, чтобы для assertion-а было выбрано значение из текущего ответа.

4. Итак, после объявления namespace-ов мы ввели XPath нужного XML-узла. Далее нажали ‘Select from Current’, задав текущее значение как ожидаемое. Текущее значение выводится и его можно изменять, если понадобится. Нажимаем ‘Сохранить’.

5. Добавленные assertion-ы показаны на рисунке.

SCRIPTING ASSERTIONS

Этот тип не применяется так широко как предыдущие, так как очень сложный в создании и обслуживании (десятки и сотни assertions). 

Как мы уже знаем, в SoapUI поддерживаются языки Groovy (предпочтительный) и JavaScript. Методика рассчитана на создание фреймворка тестирования SOAP. 

Сценарии дают возможность выполнять некие операции до и после тест-кейса, применяя методы set-up и tear-down. Set-up — процедура, выполняемая перед выполнением какого-то метода (пример: создание и инициализация объекта), соответственно tear-down — после метода (пример: уничтожение объекта и очистка). Таких функций нет в других типах assertions, доступны только через написание кода сценария.

Частые функции: открытие/закрытие проекта, инициализация/очистка настроек проекта, переменные окружения.

Применяется для валидации контента с динамическим ответом, а также для создания кастомных assertions, которых нет в SoapUI. 

Для примера возьмем тот же сайт что в начале (‘Contains’) и тест-кейс созданный выше.

1. Этапы по добавлению Groovy-скриптов те же, только assertion-а нет в списке предустановленных, он user-defined. Это дает бОльшую гибкость.

Выбираем в дереве проекта Test Step, в котором создадим кастомный assertion:

Нажимаем добавление assertion:

2. Выбираем категорию (Script), далее ‘Script Assertion’, жмем ‘Add’.

3. Откроется диалоговое окно для ввода сценария (валидации XML-ответа).

4. Теперь копируем groovy-скрипт (валидации курса валют). Код ниже, с комментариями. 

//Define Groovy Utils and holder for validating the XML reponse content
def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context)
def holder = groovyUtils.getXmlHolder(messageExchange.responseContent)

//Define the NameSpace
holder.namespaces["ns1"] = "http://tempuri.org/"

//Get the Value of the Node 'AddResult' and assign to a variable
def addResult = holder.getNodeValue("//ns1:AddResult")

//print the value of the result in the Output panel
log.info "The result value for integers is " + addResult

//Comparing the value to print 'Pass' or 'Fail'
if(addResult=="46")
{ log.info "Pass" }
else
{ log.info "fail"}

Нажимаем кнопку ‘Execute’. В окне вывода появится результат (конвертированное число и pass/fail). Нажимаем ОК.

(Примечание: последнее сообщение всегда будет ‘Script Assertion Passed’, поскольку скрипт синтаксически корректный. Это не имеет отношения к нашим assertion-ам.)

Нажимаем ОК.

5. Теперь во вкладке отображены все наши assertion-ы, добавленные в тестовый набор (в примерах выше).

6. В дереве проектов выбираем Test Suite, нажимаем ‘Run’, видим результаты запуска всего набора:

На этом пока всё. Если нужно что-то дополнить, исправить, уточнить — пишите в комментариях, или в ТГ-канале «Тестировщик от бога».

Источники: 1,2,3,4,5

***

Исследовательское тестирование

Сквозное тестирование