Что такое 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 является наиболее часто используемым инструментом благодаря простому в использовании интерфейсу. Подводя итог, можно сказать, что если вы хотите пройти обучение и стать тестером программного обеспечения, это лучший инструмент для тестирования и достижения успеха.
Рекомендуемые статьи
Что такое soapui понятным языком
SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).
Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению.
Теоретическая база
Тот факт, что SOAP является протоколом, имеет большое значение для тестирования: нужно изучить сам протокол, «первичные» стандарты и протоколы, на которых он базируется, а также (по мере необходимости) существующие расширения.
XML
XML – язык разметки, схожий с HTML. Любое сообщение, отправляемое/получаемое через SOAP, – это XML-документ, в котором данные удобно структурированы и легко читаемы, например:
Юля
Наташа
Напоминалка
Не забудь написать статью!
Что такое 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 файл на полноту и валидность (соответствие схеме) и реакции системы на такие ошибки.
Тестирование веб сервисов или как пользоваться 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 – это мощный инструмент, который постоянно развивается, и при разработке веб-сервисов – это незаменимый инструмент для тестирования. Полное описание программы сделать в одной статье невозможно, да и не имеет смысла, ведь у каждого разные задачи. Но на сайте разработчика есть хорошее описание программы с примерами и справка по всем классам, которые можно использовать в скриптах.