соап юай что это
Соап юай что это
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 файл на полноту и валидность (соответствие схеме) и реакции системы на такие ошибки.
SoapUI, Postman и Katalon Studio: Обзор 3 лучших инструментов для тестирования API
За последние пять лет, по данным Google Trends, значительно вырос интерес к тестированию API. Такая тенденция отражает сдвиг парадигмы в сторону web и мобильных приложений, а также разделение серверных служб и пользовательских интерфейсов.
Чтобы помочь вам разобраться, какие же все-таки инструменты лучше всего подходят для автоматизации тестирования API, в этой статье для вас будет представлены обзор и сравнение трех популярных инструментов для тестирования API: SoapUI, Postman и Katalon Studio. SoapUI и Postman специализируются исключительно на тестировании API, в то время как, Katalon Studio предоставляет полный набор инструментов для тестирования API, Web и мобильных приложений.
Katalon Studio
Katalon Studio — это интегрированная среда для создания и выполнения тестирования при работе с API, Web и мобильных приложениями. Имеет богатый набор инструментов для тестирования и поддерживает множество платформ, включая Windows, Mac OS и Linux. Интегрируя движки от Selenium и Appium со всеми необходимыми компонентами, встроенными ключевыми словами и шаблонами, Katalon Studio предоставляет уникальную среду разработки как для тестировщиков, так и для разработчиков, занимающихся тестированием API и веб-автоматизации. Вот некоторые примечательные особенности инструмента:
SoapUI
SoapUI чаще всего рекомендуют использовать, когда дело доходит до выбора инструмента тестирования API. Этот инструмент был специально разработан для тестирования API. SoapUI поддерживает сервисы REST и SOAP. Специалистам для автоматизации тестирования API на выбор доступны в версиях open-source и pro. Pro версия имеет удобный интерфейс и несколько дополнительных возможностей, такие как мастер создание проверок, редактор форм и конструктор SQL запросов. SoapUI – входит в готовый набор инструментов Ready API suite, предлагаемый компанией SmartBear.
SoapUI распространяется в версиях open-source и Pro ($659/год для средних и больших команд).
Postman
Postman стал популярен в качестве инструмента для автоматизации тестирования API, благодаря своему расширению для браузера, которое предназначено для проверки API. Postman можно установить, как в виде расширения для браузера, так и в качестве desktop-приложения для операционных систем Mac, Linux и Windows. Его используют не только тестировщики, которые занимаются автоматизацией тестирования API, но он так же полезен разработчикам для создания и проверки API. По факту, его можно рассматривать, как среду для разработки и тестирования API.
Postman доступен в трех версиях: Postman (бесплатно), Postman Pro ($8/месяц) и Postman Enterprise ($21/месяц).
Сравнение SoapUI, Postman и Katalon Studio
REST и SOAP являются доминирующими типами API, на которые приходится более 95% всех разрабатываемых API / веб-сервисов в соответствии c отчетом о состоянии интеграции API. Katalon Studio и SoapUI поддерживают оба типа REST и SOAP API, в то время как Postman может обрабатывать только REST. Следует отметить, что подавляющее большинство реализаций API (83%) основаны на REST протоколе.
В этой мы рассмотрели три самых популярных и перспективных инструмента для автоматизации тестирования API. Если сравнивать SoapUI с Postman и Katalon Studio, то у каждого инструмента есть свои плюсы и минусы, но несмотря на это они широко используются разработчиками и тестировщиками. (Подробнее о топ-10 инструментов тестирования API)
На сегодняшний день, для успешной реализации методов DevOps требуется использование многих инструментов, которые выполняют функцию управления конфигурацией, интеграции, тестирования и развертывания. Крайне важно, чтобы инструменты были легко и плавно интегрированы в целую инструментальную цепочку DevOps, для того чтобы разработчики, тестировщики и другие заинтересованные стороны могли взаимодействовать. В итоге интегрированные средства автоматизации тестирования, которые могут поддерживать API, Web UI и тестирование мобильных приложений, определенно имеют преимущество перед узконаправленными, специализированными инструментами, такими как Postman и Apache JMeter.
Автоматизация тестирования Java EE веб-сервисов с помощью SoapUI и Arquillian
Возможные альтернативы
Ближе к делу
Мы будем использовать Maven как систему сборки и управления проектом и JUnit в качестве фреймворка для тестирования, а наше приложение будет работать на сервере WildFly. Хотя, это не столь принципиально: тоже самое можно было бы сделать, используя TestNG и какой-нибудь другой более или менее распространенный сервер приложений.
Подопытный
Итак, для начала напишем простенький сервис, который, собственно, и будем тестировать:
SoapUI
Далее, создадим в SoapUI проект и добавим туда тест, который будет проверять, что если операции hello нашего веб-сервиса передать «world», то она нам вернет «Hello, world». Не будем вдаваться в подробности этого процесса, поскольку информацию на эту тему легко найти в сети, например, на официальном сайте SoapUI (тут и тут).
Не забудем после этого сохранить SoapUI-проект с именем Greeter-soapui-project.xml в папку с тестовыми ресурсами нашего основного проекта.
Arquillian и JUnit
Теперь самое интересное: нужно сделать так, чтобы при сборке, на этапе тестирования, наш сервис деплоился на сервер приложений, и после этого запускались SoapUI-тесты, созданные нами ранее. С этим нам поможет Arquillian – замечательный фреймворк, призванный сделать тестирование Java EE приложений чуть приятнее (знакомство можно начать с Getting Started Guide на официальном сайте).
Добавим зависимости для всего этого зоопарка в наш pom-файл:
Для запуска сервера Arquillian должен знать путь до инсталляции WildFly. По умолчанию он берется из переменной окружения JBOSS_HOME (но его можно переопределить в arquillian.xml), поэтому не забудем задать ей нужное значение.
Теперь, когда мы указали все зависимости и сконфигурировали Arquillian, можно наконец переходить к написанию тестового класса, который и будет выполнять всю работу:
Нужно отметить, что в SoapUI-проекте в качестве хоста у нас указан localhost, и веб-сервис во время тестов деплоится на локальный managed сервер, поэтому все будет работать корректно. Но если бы мы деплоили на удаленный сервер, то нам нужно было бы переопределить адрес, по которому SoapUI должен слать запросы. В таком случае метод testGreeter стал бы выглядеть так:
Failsafe
Теперь осталось только настроить Maven так, чтобы он мог запускать тесты в процессе сборки. С этим нам поможет плагин Failsafe. Наименование нашего тестового класса оканчивается на «IT», что соответствует конвенции именования интеграционных тестов, запускаемых Failsafe, поэтому остается только сконфигурировать плагин в нашем pom-файле:
Вот и все!
Теперь Maven будет автоматически запускать выполнение тестов в CI-окружении при сборке с профилем it, а разработчики могут наслаждаться видом green bar в любимой IDE.
Все исходники из статьи можно найти на github.
Погружение qa junior в пучину API с использованием SoapUI(Open Source)
Коротко про API
Начнем знакомство с расшифровки аббревиатуры API (англ. application programming interface, либо программный интерфейс приложения, интерфейс прикладного программирования) набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах (Wikipedia). То есть API даёт возможность использовать чужие наработки в своих интересах. Есть два подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API. Но не будем углубляться в нюансы, ибо литературы в свободном доступе на эту тему большое множество.
Осознание и принятие ситуации
Если жизненная ситуация сложилась таким образом, что Вы оказалась без малейшего опыта на проекте по API, то не отчаивайтесь, потому что всему можно научиться. Первым делом узнайте какая есть документация на проекте, есть ли пример запросов, может кто-то из коллег уже создавал проекты и сохранил их. А вторым пунктом установите SoapUI и приступайте к работе!
Сначала необходимо импортировать проект, если есть в наличии, либо создать его на основе WSDL:
1. создаем новый проект file→ New soapUI Project. Указываем Project Name и Initial WSDL/WADL.
2. Импортировать проект file→Import Project. Выбираем необходимый файл в формате xml. Обратите внимание: проставили галочку на создание TestSuite!
3. Теперь вы можете использовать в работе созданные TestSuite, либо создать свой и скомпоновать методы. На указанном примере получился один TestSuite и три TestCase.
Обратите внимание, что у каждого TestCase присутствует TestStep.
5. Обратите внимание, что TestCase: «Step2» и «Step3» я перевела в disabled, в дальнейшей работе они нам не понадобятся, поэтому их можно будет удалить.
6. Довольно часто встречаются ситуации, когда одни и те же параметры используются в нескольких методах, если возникнет необходимость в их редактировании, то придется заходить в каждый метод и править. Для удобства работы выведем все переменные в Properties в TesCase «All_steps«. Советую, чтоб названия переменных совпадали с параметрами в методах. Например, в «Step 1» используется «MessageId«, добавляю его в Properties.
7. Не забываем указывать значения по переменным. Далее устанавливаем связь, например, «Step 1» нажимаем правой клавишей мыши на «MessageId«, отобразится меню, выбираем Get Data, затем выбираем на какую переменную в Properties ссылаться.
В итоге получилось:
8. Если возникнет необходимость передавать значения между методами, то вы так же можете сохранить его в Properties, а затем ссылаться на него, либо использовать Transfer. Например, возникла необходимость передать параметр PolicyNumber из «Step1″ в «Step2″.
Добавляем Transfer в TestCase. Настроить transfer легко, но советую ознакомиться с инструкцией с официального сайта.
9. Если в методах используются даты, то вам не обойтись никак без скриптов. В SOAP UI используется groovy, популярные скрипты всегда можно подсмотреть на официальном сайте, либо на любительских. Например, в моем примере в методах присутствуют параметры ClaimDate и PaymentDate, чтобы вручную постоянно не править даты, использую скрипт:
Date ClaimDate = new Date()
testCase.setPropertyValue(«ClaimDate», ClaimDate.format(«yyyy-MM-dd’T’hh:mm:ss»))
Date PaymentDate= new Date();
testCase.setPropertyValue(«PaymentDate», PaymentDate.format(«yyyy-MM-dd’T’hh:mm:ss»))
Скрипт указываем в TestCase в SetupScript, затем нажимаем на Runs this script, скрипт отрабатывает и значения по ClaimDate и PaymentDate, прописываются в Properties.
10. В TestSuite можете создать любое количество TestCase разными входными значениями. Таким образом, у вас будет небольшой проект с различными проверками. Так же вы можете на ответы сервиса настроить Assertion в TestStep, например, что сервис всегда возвращает статус true/false.
11. Если у вас развернут Jenkins и на ноде установлен Soap UI, то можно запускать ваш проект удаленно по расписанию. Расскажу, как выстроен этот процесс в нашей компании. Для начала загружаю проект, созданный в Soap UI и сохраненный в формате .xml, в систему контроля версий, а именно в Gitlab. Затем в Jenkins создаю мультиконфигурационный проект, в его настройках «Управление исходным кодом » указываем путь к проекту в Gilab.
В «Послесборочных операций» можете добавить шаги «Publish JUnit test result report», «Заархивировать артефакты», «Уведомление по почте».
Далее сохраняем и можем пользоваться! Результат прогона должен прийти на указанною почту.
Всё хорошее когда-нибудь заканчивается
Тестирование веб сервисов или как пользоваться SoapUI
Допустим, вы интегрируете системы, используя веб-сервисы, или ваши клиентские приложения взаимодействуют с сервером посредством веб-сервисов, в этом случае вам просто необходимо использовать инструмент SoapUI для тестирования веб-сервисов и клиентов. Работа с программой SoapUI очень проста и позволяет воочию увидеть передаваемые и получаемые данные. Кроме того вы сможете провести нагрузочное тестирование вашего веб-сервиса и симулировать работу веб-сервиса.
О SoapUI
Итак, что же такое SoapUI? Это кроссплатформенное клиентское оконное приложение, написанное на языке Java. Использовать основной функционал приложения можно бесплатно. В платной версии программы, которая называется SoapUI Pro, вы сможете делать чуть больше, например, устанавливать плагины с помощью менеджера плагинов, проводить тесты драйверов данных, перехватывать трафик, оценивать покрытие ваших веб-сервисов тестами и создавать отчёты. Официальная страничка проекта находится здесь, скачать дистрибутив бесплатной версии программы можно здесь. Если бесплатной версии вам не хватает, вы можете скачать пробную версию SoapUI Pro здесь.
Если для разработки вы используете IDE IntelliJ, NetBeans или Eclipse, то вы можете интегрировать SoapUI прямо в IDE используя плагины. Как это сделать написано здесь. Я не буду останавливаться на этом варианте. Здесь я опишу лишь вариант использования SoapUI, как самостоятельного приложения. Установка на компьютер под управлением Windows проходит быстро и не вызывает вопросов, поэтому на этом этапе я тоже не буду заострять внимание.
Тестирование веб-сервиса
Прежде чем продолжить изучать программу SoapUI сделаем тестовый веб-сервис. Я сделаю это в Visual Studio, у моего сервиса будет только две функции GetSum1 и GetSum2, которые работают одинаково, но принимают и отдают результат по-разному.
После этого мы увидим, что для нашего тестового веб-сервиса создались запросы, причём для версий протокола SOAP 1.1 и 1.2. Дважды щёлкните на запрос «Request 1» и справа откроется дочернее окошко «Request 1», в котором вы увидите сформированный запрос.
Чтобы теперь проверить, как работает наш тестовый веб-сервис, замените вопросительные знаки значениями и нажмите на зелёный треугольник (сверху слева в этом же дочернем окне), чтобы отправить запрос. Когда запрос выполнится, в правой части отобразится ответ сервера (на картинке веб-служба вернула число 7), а снизу слева время выполнения (на картинке 3 миллисекунды) и количество полученных байт (на картинке 358 байт).
Теперь вычислим сумму с отрицательным числом. Как видно на картинки, функция GetSum1 с отрицательными числами работает дольше. Это ожидаемый результат, т.к. в функции GetSum1 специально стоит задержка 100мс, если хотя бы одно из полученных чисел отрицательное.
Если вместо числа передать строку, то вы увидите ошибку.
Третий параметр у нас необязательный. Проверим, что будет, если мы его уберём из запроса. После выполнения мы увидим, что сумма посчиталась, ошибок нет.
Как видите, проверить работу веб-сервиса можно очень просто и быстро.
Тесты
Теперь попробуем создать тесты для сервиса. Сначала добавьте в проект набор тестов (TestSuite).
Затем в набор тестов добавьте тестовый случай (TestCase).
Теперь в новый тестовый случай можно добавить шаги для теста. Добавим тестовый запрос «Test Request».
В диалоге «New TestRequest» выбираем тестируемую функцию «GetSum1».
На следующем диалоге можно выбрать дополнительные утверждения, которые будут проверяться при проведении тестов: Add SOAP Response Assertion (добавляет утверждение, что ответ является SOAP-сообщением), Add Schema Assertion (добавляет утверждение, что ответ соответствует схеме), Add NOT SOAP Fault Assertion (добавляет утверждение, что ответ не является SOAP-ошибкой). Также здесь можно указать, нужно ли создать шаблон для необязательных элементов в запросе. Поставьте первую и третью галочку.
После добавления шага теста можно задать параметры и выполнить тест. Для выполнения теста также нажимаем зелёный треугольник.
Теперь сделаем тестирование диапазона значений. Будем подставлять в параметр «a» значения от 1 до 5 и проверять сумму. Для этого сначала нужно добавить свойство, которое будет хранить текущее значение параметра «a», например, в тестовый случай «TestCase 1». Для этого дважды щёлкните по нему на панели «Navigator». Затем в открывшемся дочернем окне «TestCase 1» откройте вкладку «Properties», щёлкните на кнопку с плюсом и задайте новому свойству имя «aValue» и значение 1.
После выполнения запроса вы можно посмотреть, что было передано веб-сервису, в частности, какое значение параметра «a» было передано на сервер, на закладке «Raw» (сырые данные). Здесь вы увидите HTTP-запрос полностью вместе с заголовочной частью. Аналогично можно посмотреть HTTP-ответ от веб-сервиса.
Кстати, для более удобного доступа к свойствам вы можете включить режим отображения свойств на панели навигатора (маленькая кнопка слева сверху на панели). Тогда свойства можно просматривать прямо на панели «Navigator». После этого дважды щёлкнув на свойство в навигаторе, вы можете поменять его значение.
Как видите из картинки, свойства могут быть заданы для проекта в целом, для отдельного набора тестов (TestSuite) или для отдельной тестовой ситуации (TestCase).
Теперь сделаем установку свойству «aValue» значения 1 в начале тестирования. Для этого откройте тестовый случай «TestCase 1», откройте вкладку «Setup Script» (скрипт инициализации вызывается перед выполнением тестового случая) и добавьте сюда следующий код:
Здесь же сразу можно проверить, как выполняется скрипт. Для этого нажмите на зелёный треугольник. Если при выполнении возникнут ошибки, то появится диалоговое окно с их описанием. В нашем случае всё отработало нормально. Откройте вкладку «script log», чтобы увидеть наше сообщение.
Здесь нужно сразу заметить, что все скрипты в SoapUI по умолчанию пишутся на языке Groovy, и в статье я буду использовать этот скрипт. Справку по языку можно получить здесь. По желанию вы можете использовать JavaScript для написания скриптов, тогда для правильной интерпретации ваших скриптов нужно установить в свойстве проекта «Script Language» значение «Javascript». В этом случае для интерпретации скриптов будет использоваться движок Rhino.
Также обратите внимание, что над каждым окошком для написания скрипта перечислены доступные глобальные переменные. На картинке сверху – это переменные log, testCase, context и testRunner.
После добавления шага напишите следующий скрипт для изменения значения свойства:
Здесь вы сразу можете выполнить скрипт и увидеть на панели навигатора изменённое значение свойства «aValue», а на вкладке «Log Output» увидите наш лог.
Теперь попробуем циклично выполнять шаги «Test Requset» и «Groovy Script». Для того чтобы это сделать добавьте к скрипту следующие строчки:
Как видите, цикл будет выполняться пока значение свойства «aValue» меньше 10. Теперь откройте тестовый случай «TestCase 1» и выполните его. Как видите на вкладке «TestCase Log», всего выполнилось 18 шагов (9 «Test Request» и 9 «Groovy Script»).
И в диалоге «Script Assertion» пропишите скрипт проверки результата.
Здесь же сразу можно проверить результат, выполнив скрипт. На картинке видно, что скрипт выполнился успешно – утверждение истинно.
Теперь поменяем в качестве эксперимента параметр «aValue» – установим значение 5 и выполним тест «Test Request». После выполнения вы увидите, что тест провален (красная иконка в навигаторе) и увидите, какое утверждение не выполнено. В нашем случае – это утверждение «Script Assertion».
Теперь выполним всю ситуацию «TestCase 1». После выполнения на вкладке «TestCase Log» мы видим, что тестирование прошло с ошибкой. Выполнение было прервано на шаге 9. Предыдущие шаги были выполнены без ошибок. Дважды щёлкнув на шаг 9 в логе, мы можем узнать, какой запрос был передан веб-сервису и что было возвращено (в нашем случае сумма посчиталась неправильно).
Аналогичным образом вы можете добавлять любое количество тестов любой сложности. А затем при каждом обновлении вашего сервиса выполнять все тесты сразу, чтобы проверять его работоспособность.
Нагрузочное тестирование
Чтобы проверить, выдерживает ли сервер требуемую нагрузку, или понять, какие функции выполняются медленно, мы можем провести нагрузочное тестирование. В нашем примере умышленно сделана большая задержка в функции «GetSum2». Давайте обнаружим эту задержку с помощью нагрузочного тестирования.
для функции «GetSum1» и для функции «GetSum2»:
Теперь добавьте нагрузочный тест (пункт контекстного меню «New LoadTest»).
После добавления нагрузочного теста сразу всё готово к его запуску. Здесь вы можете задать количество потоков, стратегию выполнения и параметры для каждой стратегии (вы можете параллельно выполнять несколько тестов, используя разную стратегию). Выполните тест.
После выполнения в таблице вы увидите минимальное и максимальное время выполнения теста, среднее значение, количество ошибок и пр. На вкладке «LoadTest Log» будет указано время начала и окончания теста. Также вы можете посмотреть статистику и историю на графиках.
По таблице вы можете заметить, что тест «Test Request 2» выполняется дольше. В среднем 203,55 мс, а тест «Test Request 1» выполняется быстрее примерно в 2 раза. Вот мы и обнаружили, что в функции «GetSum2» есть задержка при выполнении.
Тестирование клиента
Теперь давайте попробуем создать имитацию веб-сервиса с помощью программы SoapUI. Это может пригодиться для тестирования клиента веб-сервиса. Ведь с помощью такого имитатора веб-сервиса вы сможете протестировать все возможные ситуации на клиенте.
Чтобы создать веб-сервис, щёлкните по SOAP-интерфейсу и в контекстном меню выберите пункт «Generate SOAP Mock Service».
В поднявшемся диалоге вы можете выбрать функции, для которых нужно создать операции сервиса, путь к сервису и порт. Нажмите «OK».
После того как сервис создан, дважды щёлкните по запросу, который хотите поправить, например, по «Response 1» и задайте параметр, который должна вернуть функция GetSum1. Вы можете здесь задать статическое значение, которое будет получать клиент или вычислять его в зависимости от входных параметров. Также здесь вы можете задать ответ-ошибку и протестировать, как клиент будет обрабатывать сообщение с ошибкой.
Мы здесь сделаем расчёт суммы и возврат результата с помощью скрипта. Откройте вкладку «Script» и напишите следующий код:
Вот так это выглядит в программе:
Теперь, можете запустить сервис. Для этого переключитесь в навигаторе на сервис, у меня это «Service1Soap MockService» и щёлкните по зелёному треугольнику. После запуска сверху будет двигаться бегунок показывающий, что сервис работает.
Теперь можно тестировать клиента. Я для примера сделал консольное приложение в Visual Studio, добавил в проект ссылку, указав ссылку на WSDL (WSDL можно получить, щёлкнув по кнопке с изображением зелёной фигуры, на картинке сверху она обведена зелёным кружком). Далее можно вызывать функцию сервиса «GetSum1». Вот код консольного приложения:
После выполнения приведённого кода программы в консоль будет выведен результат 7.
Также при создании сервиса вы можете тестировать его здесь же прямо из программы SoapUI.
Заключение
SoapUI – это мощный инструмент, который постоянно развивается, и при разработке веб-сервисов – это незаменимый инструмент для тестирования. Полное описание программы сделать в одной статье невозможно, да и не имеет смысла, ведь у каждого разные задачи. Но на сайте разработчика есть хорошее описание программы с примерами и справка по всем классам, которые можно использовать в скриптах.