Soapui что это простыми словами
Что такое SoapUI?
Что такое SoapUI
В этом руководстве мы узнаем о SoapUI и о SoapUI, который широко используется во всем мире. Но прежде чем перейти к этой теме, у меня к вам вопрос. У вас есть знания по этой теме? Прежде чем перейти к теме, сначала мы должны прочитать о тестировании, где это будет полезно. Знаете ли вы, что такое тестирование? ее мы узнаем много вещей и особенно то, что тестирование и его несколько аспектов /
тестирование
Теперь, возвращаясь к нашей теме:
Мы знаем, что это кроссплатформенный инструмент и поддерживает операционные системы Windows, Linux и Mac.
Минимум 512 МБ ОЗУ
Место на жестком диске минимум 200 МБ для установки. Требуется версия операционной системы Windows XP, MAC и, наконец, требуется JAVA
Тогда это покажет так
Установка начнется и будет завершена через некоторое время. Это покажет вам, как это.
Почему мы должны использовать SoapUI?
SOAPUI позволяет тестировщикам автоматически выполнять функционал, компилировать и загружать тесты в различных веб-API. Он также поддерживает все стандартные протоколы и технологии для тестирования различных видов API. Его интерфейс прост, что позволяет легко использовать как техническим, так и нетехническим пользователям.
Функциональное тестирование
Это дает нам много функций и возможностей, которые мы можем применить через него.
Агенты LoadUI: SoapUI имеет количество агентов LoadUI, распределенных по этой нагрузке, и может анализировать различные параметры производительности.
Простота использования: инвестируя простую программу и обрабатывая агенты LoadUI инструмента SoapUI, нагрузочное тестирование становится ужасно простым и простым в работе.
Мониторинг производительности: SoapUI имеет усовершенствованную систему покрытия для сбора различных параметров производительности для нагрузочного тестирования Кроме того, он позволяет отслеживать производительность для сквозного тестирования нагрузки системы.
Как эта технология SoapUI поможет вам в карьерном росте?
На самом деле не существует единого «пути карьеры тестировщика программного обеспечения», так как можно пойти разными путями, специализируясь и развиваясь в определенной отрасли тестирования или переходя в другие области бизнеса. Хорошо помнить заранее, по какому пути вы хотите идти, чтобы знать, какие навыки оттачивать, какие проекты выбирать и т. Д.
Это некоторые наросты
Вывод
Есть несколько инструментов тестирования, которые могут быть использованы в соответствии с нашими требованиями. SoapUI является наиболее часто используемым инструментом благодаря простому в использовании интерфейсу. Подводя итог, можно сказать, что если вы хотите пройти обучение и стать тестером программного обеспечения, это лучший инструмент для тестирования и достижения успеха.
Рекомендуемые статьи
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО. Одни системы «из коробки» умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.
Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, в SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.
Самые известные способы реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.
SOAP (Simple Object Access Protocol) — данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns. Паттерны связывают HTTP методы с тем, что они делают.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос «Какой способ реализации использовать?» необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром. Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков «заготовок» — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.
Тестирование веб сервисов или как пользоваться 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 – это мощный инструмент, который постоянно развивается, и при разработке веб-сервисов – это незаменимый инструмент для тестирования. Полное описание программы сделать в одной статье невозможно, да и не имеет смысла, ведь у каждого разные задачи. Но на сайте разработчика есть хорошее описание программы с примерами и справка по всем классам, которые можно использовать в скриптах.