Soapui как пользоваться: RTM: SoapUI для чайников | Лаборатория качества — Независимое театральное объединение "Зрительские симпатии"

Содержание

RTM: SoapUI для чайников | Лаборатория качества

Эта статья написана в помощь студентам ПОИНТ, которые проходят вебинар “Тестирование веб-сервисов”, и является, в первую очередь, практическим руководством по основам работы с программой SoapUI.

Хотите получить чек-лист «Что должен знать и уметь начинающий тестировщик»? В конце статьи вас ждет ссылка на анкету, после заполнения которой вы получите чек-лист!

Вступление и пара слов о теории

Сегодня нужно хорошо постараться, чтобы найти софт, который никак не взаимодействует с другими программами. Обычно либо происходит равноценный обмен данными, либо стороннее ПО выполняет какие-либо вспомогательные функции, например, вычисления. И это совершенно нормально, при наличии тысяч готовых решений невыгодно или невозможно создавать все с нуля. Поэтому, то, что для конечного пользователя может выглядеть как единая программа или система, на самом деле чаще всего является набором самостоятельных сервисов. Этим сервисам нужно как-то между собой взаимодействовать (интегрироваться). И, как для общения программ с человеком существует пользовательский интерфейс UI, так и для взаимодействия программ между собой существует специальный интерфейс API (Application Programming Interface – интерфейс программирования приложений).

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

В данной статье речь пойдет об инструменте для функционального тестирования веб-сервисов — или, простыми словами, о специальных программах-помощниках. Они помогают сайтам и веб-приложениям общаться между собой в сети Интернет и передавать данные через специальный протокол HTTP(S). Веб-сервисы основываются на открытых протоколах и следуют общепринятым стандартам. Именно поэтому у приложений есть возможность общаться между собой вне зависимости от использованных при их создании технологий или пользовательского окружения. Для взаимодействия веб-приложений в основном используется два типа интерфейсов: REST API и SOAP API. Их различия и области типичного применения являются темой для отдельных статей.

Для тестирования API веб-приложений существует множество возможностей: начиная от написания своих собственных скриптов, работы в консоли и заканчивая специальными фреймворками, у которых доступен UI через обычный браузер (Swagger, Django REST framework и т.п.). SoapUI — это один из многих инструментов для такого тестирования. Он поддерживает множество дополнительных возможностей, которые в самом начале могут не понадобиться, но именно поэтому может показаться новичкам излишне сложным. Однако, очевидным плюсом для новичков является то, что SoapUI предлагает поддержку REST и SOAP API, поэтому можно не осваивать отдельную программу для каждого типа веб-API.

Первый REST проект

Если веб-приложение использует REST API, то форматы документации могут сильно отличаться, а схема (WADL) опциональна. Единственное, без чего при тестировании REST не обойтись, так это без информации об endpoint, т.е. конечного адреса, куда отправляются запросы сервиса, инициирующего взаимодействие. Или, с другой стороны, точки входа для программы, с которой это взаимодействие осуществляется. Конечная точка сама по себе является просто ссылкой на URL, который принимает веб-запросы, которые в свою очередь могут быть или не быть REST. В зависимости от конкретной проверки этот адрес уточняется или к нему добавляются дополнительные параметры. Уточнения адреса являются уже детализированными ссылками на ресурсы, т.е. кусочки программы, которые непосредственно содержат данные, информацию о связях с другими кусочками программы, реализованные методы для взаимодействия и т. п. Иногда понятия ресурс и эндпоинт употребляются как синонимы.

Итак, приступим. В качестве подопытного будет выступать API спеллчекера от Яндекс https://tech.yandex.ru/speller/doc/dg/concepts/api-overview-docpage/ документация.

1. Создаем через меню File новый REST проект. Или в Navigator через меню, которое открывается по клику правой кнопкой мыши по Projects.

2. В открывшемся диалоговом окне вводим наш базовый URL, куда будут уходить все запросы: https://speller.yandex.net и нажимаем OK. Можно ввести и всю ссылку целиком, умный SoapUI сам разделит эндпоинт и ресурс.

3. После того, как проект создался, в рабочей области откроется окно с самим запросом. Здесь выбираем метод (в нашем случае по документации GET) и уточняем URL, дописываем ресурс, к которому обращаемся. У спеллчекера реализовано два ресурса checkText и checkTexts. Пока добавим первый.

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

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

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

7. Добавляем в новый тест-кейс сам запрос. На данном этапе можно переименовать запрос. Но это переименование будет касаться только тест-кейса.

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

9. Самое время проверить, что сервис работает и ответ на запрос приходит. Заполняем параметр text словом с ошибкой и нажимаем на кнопку Play (зеленый треугольник). Видно, что параметр автоматически добавился в URL.

10. А теперь можно добавить второй ресурс /services/spellservice/checkTexts к уже существующему эндпоинту. Кликаем правой кнопкой мыши по нему и выбираем в контекстном меню New Resource. Так как эти ресурсы равноценны, то нужно его добавлять имено к эндпоинту, а не как дочерний ресурс к добавленному выше checkText.

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

12. Чтобы поделиться REST проектом, его можно экспортировать как xml и тогда любой другой тестировщик сможет добавить этот файл в свой SoapUI и воспользоваться готовыми тест-кейсами. Для этого нажимаем правой кнопкой мыши на саму папку проекта и выбираем Save Project или Save Project as. Если выбрать пункт Export Project, то xml файл проекта будет добавлен в zip-архив. Тоже самое можно сделать через главное меню в разделе Project.

Выше приведены самые базовые действия для создания тест-кейсов по REST сервису в SoapUI. На самом деле возможности инструмента, конечно, гораздо шире. Обо всем этом можно узнать на официальном сайте https://www.soapui.org/

Тестирование параметров происходит также, как на UI тестирование полей в форме, все базовые техники применимы и тут. Особенностью тестирования REST является возможность смотреть не только значения параметров, но и проверить, как тестируемая система реагирует на запросы к несуществующим ресурсам, с несуществующими параметрами, неверным методом. Если углубляться в данный вид тестирования, то можно проверять также заголовки запроса и форматы запросов/ответов.

Первый Soap проект

Если используется Soap API, то можно быть спокойным, у вас будет файл схемы. Тут уже все происходит автоматически, SoapUI создает проект на основе схемы и можно сразу увидеть все доступные запросы.

Продолжим с Яндексом. По данной ссылке https://speller.yandex.net/services/spellservice?WSDL доступен WSDL файл, который нужно сохранить в формате xml.

1. Снова открываем меню File и создаем уже новый Soap проект.

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

3. Готово, проект создан, есть примеры запросов.

4. Теперь вместо “?” можно добавить значения в xml и отправить первый запрос.

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

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

На этом у меня все!

Вы в поисках курсов для тестировщиков с нуля? Присоединяйтесь к ПОИНТ — Первому Онлайн ИНституту Тестировщиков!

Обучение стартует ежемесячно. Следить за актуальным расписанием можно в нашей группе VK.

Заполните эту небольшую анкету, чтобы получить чек-лист «Что должен знать и уметь начинающий тестировщик» 🙂

Отзывы выпускников курса ПОИНТ:

тестирование SOAP и REST API — testengineer.ru

Кратко об 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 работает на уровне бизнес-логики приложения.

Тестирование 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

Архитектура 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 Мб]:

Скачать последний стабильный релиз SoapUI с официального сайта, сейчас 5.7.0

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

Процессор — хотя бы 1 ГГц
Места на диске — минимум 300 Мб
Память — минимум 1 Гб

Java — Java 6+
ОС — MacOS 10. 4+, Windows XP+

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

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

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

Главный экран SoapUI

Тестирование 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-проект.

Создаем новый проект SOAP

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

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

Заполняем

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

Поле “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-файла:

Формат WSDL

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

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

Настройка нового SOAP-проектаИерархия Soap-проекта после добавления WSDL

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

Тест-свит > тест-кейсы > тестовые этапы в SoapIU

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

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

Добавление тест-сьюта в проект

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

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

Добавляем тест-кейс в сьют

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

Структура после добавления тест-кейса

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

Добавление этапов в тест-кейс SoapUI

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

Добавляем эндпойнт

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

Выполнение тестового действия

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

Форматы

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

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

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

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

Создание REST-проекта

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

Путь к WADL-файлу

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

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

Что такое WADL

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

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

Прописываем WADL-файл

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

Иерархия REST-проекта

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

Сервисы, ресурсы и запросы в REST-проекте SoapUI

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

Добавляем ресурс в SoapUI

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

Добавлен ресурс в REST-проект

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

Генерируем тест-сьют

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

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

Добавляем действия в тест-кейс

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

Добавление тестовых действий

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

Запускаем тестовый запрос

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

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

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

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

Добавление эндпойнта в REST-запрос

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

Сохраняем REST-запрос

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

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

Кастомный HTTP-заголовок

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

Заполняем

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

Заполненные поля кастомного HTTP-заголовкаДо добавления заголовкаПосле добавления заголовка

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

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

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

Кастомное свойство на уровне сьютаСвойство добавленоЗапрос после параметризации заголовка

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

Assertions

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

Добавление assertion в запрос

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

Assertions в SoapUI

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

HTTP 200

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

Тип Assertion в запросе

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

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

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

Сценарий 200 ОК

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

Сценарий 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.

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

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

Теперь:

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

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

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

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

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

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

NOT CONTAINS

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

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

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

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

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

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

XPATH MATCH

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

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

Откроется окно 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/’;

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

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

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

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

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

SCRIPTING ASSERTIONS

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

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

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

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

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

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

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

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

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

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

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

Теперь копируем 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-ам.)

Нажимаем ОК.

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

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

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

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

***

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

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

Как протестировать свой первый SOAP API | Приступая к работе

В этом руководстве описывается, как создавать свои первые проекты SOAP и REST в SoapUI.

Указатель статей
1. Ваш первый проект SOAP
1.1. Создать проект SOAP
1.2. Добавьте файл WSDL
2. Ваш первый проект REST
2.1. Создать проект REST из URI
2.2. Создание проекта REST из определения WADL

1. Ваш первый проект SOAP

Совет . Образец службы WSDL, показанный в этом видео, был удален. Вместо этого используйте один из следующих URL-адресов WSDL:

http://www.dataaccess.com/webservicesserver/numberconversion.wso?WSDL
http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?WSDL

ReadyAPIjects — центральная точка всего тестирования SoapUI. Создав проект, вы можете расширить его функциональными тестами, нагрузочными тестами, фиктивными сервисами и многим другим. В этом руководстве описываются два основных этапа создания проекта SOAP:

Создание проекта
Добавить файл WSDL

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

В Navigator , который находится в левой части окна SoapUI, щелкните правой кнопкой мыши Projects и выберите New SOAP Project .
Появится диалоговое окно Новый проект SOAP .
Примечание : Чтобы создать новый проект SOAP, вы также можете нажать CTRL+N (в Windows) или CMD+N (в OS X).
В диалоговом окне Новый проект SOAP укажите имя нового проекта в поле редактирования Имя проекта .
Нажмите OK .

Новый проект появится в Навигаторе .

Поздравляем, вы только что создали свой первый проект SOAP!

Совет : Вы также можете попробовать импортировать существующий проект. Дополнительные сведения см. в примере проекта веб-службы.

1.2. Добавить файл WSDL

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

Давайте добавим WSDL во вновь созданный проект:

Щелкните правой кнопкой мыши имя нового проекта в Navigator и выберите Добавить WSDL .
Появится диалоговое окно Добавить WSDL .
В поле редактирования WSDL Location диалогового окна укажите путь к файлу или службе WSDL:
Нажмите OK .
Операции веб-службы, связанные с проектом, должны появиться в Navigator . Это означает, что вы успешно добавили WSDL в свой проект.
Дважды щелкните имя проекта в Navigator . Появится редактор проекта с обзором вашего проекта, включая конфигурации безопасности и основные требования.
Совет : В ReadyAPI обзор проекта содержит еще больше полезной информации, например, список доступных подключений JDBC, историю и статистику выполнения тестов и т. д. Вы можете проверить эти инструменты, загрузив пробную версию ReadyAPI.
Дважды щелкните имя интерфейса, чтобы получить обзор интерфейса. В появившемся окне окна вы увидите информацию о файле WSDL.

2. Ваш первый проект REST

Как тестировать RESTful API и веб-сервисы | Начало работы | SoapUI

Тестирование REST основано на отправке различных запросов к RESTful API и проверке ответов от него. В этом руководстве описаны основные способы создания проектов REST в SoapUI:

Создать проект REST из URI
Создать проект REST из определения WADL

2.1. Создать проект REST из URI

В Navigator щелкните правой кнопкой мыши Projects и выберите New REST Project .
Появится диалоговое окно Новый проект REST .
Примечание . Чтобы создать новый проект REST, вы также можете нажать CTRL+ALT+N (в Windows) или CMD+ALT+N (в OS X).
В диалоговом окне укажите путь URI к вашему REST API в поле Поле редактирования URI .
Совет . Чтобы увидеть, как это работает, вы можете использовать образец веб-службы Petstore: http://petstore.swagger.io/v2/swagger.json.
Нажмите OK .

Новый проект появится в Navigator вместе с операциями веб-службы, доступными для рассматриваемого REST API. Затем вы можете дважды щелкнуть имя проекта, чтобы получить обзор проекта:

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

Примечание . Чтобы получить доступ к более удобным инструментам для тестирования REST API, ознакомьтесь с ReadyAPI — нашим передовым решением для REST и SOAP API. тестирование. Чтобы попробовать, загрузите бесплатную пробную версию ReadyAPI.

Поздравляем с созданием вашего первого проекта REST!

2.2. Создать проект REST из определения WADL

В Навигаторе , щелкните правой кнопкой мыши Projects и выберите New REST Project .
После этого появится диалоговое окно New REST Project .
Примечание . Чтобы создать новый проект REST, вы также можете нажать CTRL+ALT+N (в Windows) или CMD+ALT+N (в OS X).
В диалоговом окне нажмите Import WADL .
Появится диалоговое окно New WADL Project .
В диалоговом окне укажите путь к исходному файлу WADL с описанием доступных ресурсов и операций.
Совет . Вы можете использовать образец файла WADL ( sample-service.wadl ), расположенный в пользовательском каталоге вашей системы, в папке SoapUI-Tutorials\WSDL-WADL .
Нажмите ОК .

Новый проект появится в Navigator вместе с операциями веб-службы, доступными для рассматриваемого REST API. Как и в приведенном выше примере, вы можете дважды щелкнуть имя проекта, чтобы получить обзор проекта:

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

Следующие шаги

Проверить Вышло SoapUI 101, наше подробное руководство для начинающих по тестированию API! Он содержит пошаговые руководства по работе с SoapUI и ReadyAPI: Прочитайте руководство 9. 0003

Отслеживание производительности тестирования по мере масштабирования тестирования API

Сравните: все функции SoapUI Pro

SoapUI с открытым исходным кодом

Поддержка тестирования SOAP и REST API.
Простое переключение между несколькими средами.
Подробная история тестов и отчет о сравнении тестов.

SoapUI Pro

Поддержка тестирования API SOAP, REST и GraphQL.
Простое переключение между несколькими средами.
Подробная история тестов и отчет о сравнении тестов.

Попробуйте SoapUI Pro