Soapui как пользоваться пример 1с

Обновлено: 03.07.2024

Описанный метод позволяет обратиться к веб-сервисам 1С из html-страницы через JavaScript. В качестве примера выводится список справочников. При нажатии на любой справочник выводятся первые буквы наименований. При нажатии на букву выводятся данные с наименованиями, начинающимися на эту букву.

Способ применим для случаев, когда веб-сервис и html-страница опубликованы на одном сервере. В этом случае не возникает кросс-доменных проблем. Например, если домены будут отличаться, то Chrome выдаст ошибку:

Failed to load resource: Origin localhost:3299 is not allowed by Access-Control-Allow-Origin

Не вдаваясь в подробности публикации веб-сервисов, предположим, что на стороне 1С создан и опубликован веб-сервис catalogs с операцией Execute. На входе — параметр script типа string, на выходе тип string. Операция запускает на стороне произвольный код script из параметра и возвращает JSON-сериализацию от переменной result.

С JSON-сериализацией удобно работать средствами JavaScript и преобразовать строку в объект/массив одной командой eval(resultText). В Интернете можно найти несколько JSON-сериализаторов для 1С.

Удостоверимся, что веб-сервис отвечает, введя его адрес:

На форме сверху разместим элементы настройки веб-сервера: wsUrl — адрес веб-сервиса, wsUser — логин, wsPassword — пароль. На стороне веб-сервиса 1С включена basic autherization. Логин и пароль соответствуют пользователю, прописанному в 1С.

Левая панель отвечает за отображение доступных справочников catalogsList, правая — за отображение букв (letters) и данных (catalogRecords).

JavaScript

Функция обращения к SOAP веб-сервису определена следующим образом:

Получение списка наименований каталогов.

Получение первых букв наименований справочника

Получение данных для каталога , где первая буква входит в условие .

При нажатии на кнопку Обновить происходит вызов функции

и при успешном выполнении вызывается обработчик processSuccess

Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга — JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.

Аналогично обрабатываются нажатия на все управляющие элементы. Нажатие на справочник очищает буквы и данные, перезаполняет буквы. Нажатие на букву перезаполняет данные из справочника. За обработку кода на 1С отвечают куски кода в script-блоках с типом «text/1c».
Приложение выглядит так:

Нерешенная проблема авторизации на браузере IE

Существует проблема авторизации на IE. На IE 8/9 не удалось решить проблему basic authorization аналогичным для остальных браузеров методом.

На IE Ajax не работает с использованием user/password — свойств $.ajax. На FF и Chrome все работает нормально. По какой-то причине на сервер в случае с IE не передается заголовок

Authorization: Basic 0JHQsNGF0YjQuNC10LLQn9CYICjRgNGD0LrQvtCy0L7QtNC40YLQtdC70YwpOg==
Если кто-нибудь знает причину и как обойти, пожалуйста, напишите в комментариях.

Выводы

Предложенный подход на основе SOAP имеет право на существование для несложных задач, так как сопровождается достаточно большим числом JavaScript кода. Возможно, в будущем удастся создать JavaScript фреймворк для упрощения процесса создания приложений.

Разработчики в этом способе самостоятельно отвечают за безопасность. Необходимо проверять входные параметры при записи, не позволять запуск произвольных скриптов, переданных с клиента. В статье выполнение произвольного кода показано только для примера. Унифицировать можно выполнение произвольного запроса, но это связано с опасностью SQL-инъекций.

Внешние компоненты Native API от 1С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.

Допустим, вы интегрируете системы, используя веб-сервисы, или ваши клиентские приложения взаимодействуют с сервером посредством веб-сервисов, в этом случае вам просто необходимо использовать инструмент 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», в котором вы увидите сформированный запрос.

Теперь вычислим сумму с отрицательным числом. Как видно на картинки, функция GetSum1 с отрицательными числами работает дольше. Это ожидаемый результат, т.к. в функции GetSum1 специально стоит задержка 100мс, если хотя бы одно из полученных чисел отрицательное.

Если вместо числа передать строку, то вы увидите ошибку.

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

Как видите, проверить работу веб-сервиса можно очень просто и быстро.

Тесты

Теперь попробуем создать тесты для сервиса. Сначала добавьте в проект набор тестов (TestSuite).

Затем в набор тестов добавьте тестовый случай (TestCase).

Теперь в новый тестовый случай можно добавить шаги для теста. Добавим тестовый запрос «Test Request».

В диалоге «New TestRequest» выбираем тестируемую функцию «GetSum1».

После добавления шага теста можно задать параметры и выполнить тест. Для выполнения теста также нажимаем зелёный треугольник.

Как видите после тестирования слева от названия шага «Test Request» отобразилась зелёная картинка-статус, сигнализирующая, что тест выполнен успешно. Теперь в первом параметре передайте строку и запустите тест. После тестирования вы можете увидеть, что картинка-статус поменяла цвет на красный, а на нижней левой панели отображается, что пошло не так. В нашем примере – это SOAP-ошибка «Not SOAP Fault - FAILED». Там же на закладке «Request Log» вы можете посмотреть, когда выполнялся тест, сколько по времени и сколько байт было возвращено.

Теперь сделаем тестирование диапазона значений. Будем подставлять в параметр «a» значения от 1 до 5 и проверять сумму. Для этого сначала нужно добавить свойство, которое будет хранить текущее значение параметра «a», например, в тестовый случай «TestCase 1». Для этого дважды щёлкните по нему на панели «Navigator». Затем в открывшемся дочернем окне «TestCase 1» откройте вкладку «Properties», щёлкните на кнопку с плюсом и задайте новому свойству имя «aValue» и значение 1.

Теперь переключитесь в тестовый запрос «Test Request» (дважды щёлкнув по нему на панели «Navigator») сотрите значение в параметре «a» и щёлкните по тому месту, где нужно будет вставить значение свойства, правой клавишей мышки и в меню выберите только что добавленный параметр «Get Data. -> TestCase: [TestCase 1] -> Property [aValue]».

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

Кстати, для более удобного доступа к свойствам вы можете включить режим отображения свойств на панели навигатора (маленькая кнопка слева сверху на панели). Тогда свойства можно просматривать прямо на панели «Navigator». После этого дважды щёлкнув на свойство в навигаторе, вы можете поменять его значение.

Как видите из картинки, свойства могут быть заданы для проекта в целом, для отдельного набора тестов (TestSuite) или для отдельной тестовой ситуации (TestCase).

Теперь сделаем установку свойству «aValue» значения 1 в начале тестирования. Для этого откройте тестовый случай «TestCase 1», откройте вкладку «Setup Script» (скрипт инициализации вызывается перед выполнением тестового случая) и добавьте сюда следующий код:

Здесь нужно сразу заметить, что все скрипты в SoapUI по умолчанию пишутся на языке Groovy, и в статье я буду использовать этот скрипт. Справку по языку можно получить здесь. По желанию вы можете использовать JavaScript для написания скриптов, тогда для правильной интерпретации ваших скриптов нужно установить в свойстве проекта «Script Language» значение «Javascript». В этом случае для интерпретации скриптов будет использоваться движок Rhino.

Также обратите внимание, что над каждым окошком для написания скрипта перечислены доступные глобальные переменные. На картинке сверху – это переменные log, testCase, context и testRunner.

Теперь после каждого шага «Test Request» нам нужно увеличивать значение свойства «aValue» на единицу. Чтобы это сделать, добавьте в тестовую ситуацию (TestCase) шаг «Groovy Script» - пункт контекстного меню «Add Step -> Groovy Script».

После добавления шага напишите следующий скрипт для изменения значения свойства:

Здесь вы сразу можете выполнить скрипт и увидеть на панели навигатора изменённое значение свойства «aValue», а на вкладке «Log Output» увидите наш лог.

Теперь попробуем циклично выполнять шаги «Test Requset» и «Groovy Script». Для того чтобы это сделать добавьте к скрипту следующие строчки:

Как видите, цикл будет выполняться пока значение свойства «aValue» меньше 10. Теперь откройте тестовый случай «TestCase 1» и выполните его. Как видите на вкладке «TestCase Log», всего выполнилось 18 шагов (9 «Test Request» и 9 «Groovy Script»).

Теперь нужно отловить ошибку в вычислениях, которую мы специально заложили в веб-сервисе. Сервис должен вернуть -1, если первый параметр функции «GetSum1» равен 5. Для этого будем проверять результат работы функции. Чтобы добавить утверждение, которое будет проверять SoapUI, щёлкните по кнопке «Add an assertion to this item» (см. картинку), и в диалоге выбора утверждения выберите «Script Assertion».

И в диалоге «Script Assertion» пропишите скрипт проверки результата.

Здесь же сразу можно проверить результат, выполнив скрипт. На картинке видно, что скрипт выполнился успешно – утверждение истинно.

Теперь поменяем в качестве эксперимента параметр «aValue» – установим значение 5 и выполним тест «Test Request». После выполнения вы увидите, что тест провален (красная иконка в навигаторе) и увидите, какое утверждение не выполнено. В нашем случае – это утверждение «Script Assertion».

Теперь выполним всю ситуацию «TestCase 1». После выполнения на вкладке «TestCase Log» мы видим, что тестирование прошло с ошибкой. Выполнение было прервано на шаге 9. Предыдущие шаги были выполнены без ошибок. Дважды щёлкнув на шаг 9 в логе, мы можем узнать, какой запрос был передан веб-сервису и что было возвращено (в нашем случае сумма посчиталась неправильно).

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

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

Чтобы проверить, выдерживает ли сервер требуемую нагрузку, или понять, какие функции выполняются медленно, мы можем провести нагрузочное тестирование. В нашем примере умышленно сделана большая задержка в функции «GetSum2». Давайте обнаружим эту задержку с помощью нагрузочного тестирования.

Сначала сделайте новую тестовую ситуацию «TestCase 2», добавьте в неё тестовый запрос «Test Request 1» для функции веб-сервиса «GetSum1» и тестовый запрос «Test Request 2» для функции «GetSum2». Вместо статических значений параметров поставьте следующий скрипт: $ . Так в качестве значений параметров будут устанавливаться отрицательные и положительные числа подобранные случайным образом. У вас должны получиться следующие SOAP-запросы:

для функции «GetSum1» и для функции «GetSum2»:

Теперь добавьте нагрузочный тест (пункт контекстного меню «New LoadTest»).

После добавления нагрузочного теста сразу всё готово к его запуску. Здесь вы можете задать количество потоков, стратегию выполнения и параметры для каждой стратегии (вы можете параллельно выполнять несколько тестов, используя разную стратегию). Выполните тест.

После выполнения в таблице вы увидите минимальное и максимальное время выполнения теста, среднее значение, количество ошибок и пр. На вкладке «LoadTest Log» будет указано время начала и окончания теста. Также вы можете посмотреть статистику и историю на графиках.

По таблице вы можете заметить, что тест «Test Request 2» выполняется дольше. В среднем 203,55 мс, а тест «Test Request 1» выполняется быстрее примерно в 2 раза. Вот мы и обнаружили, что в функции «GetSum2» есть задержка при выполнении.

Тестирование клиента

Теперь давайте попробуем создать имитацию веб-сервиса с помощью программы SoapUI. Это может пригодиться для тестирования клиента веб-сервиса. Ведь с помощью такого имитатора веб-сервиса вы сможете протестировать все возможные ситуации на клиенте.

Чтобы создать веб-сервис, щёлкните по SOAP-интерфейсу и в контекстном меню выберите пункт «Generate SOAP Mock Service».

В поднявшемся диалоге вы можете выбрать функции, для которых нужно создать операции сервиса, путь к сервису и порт. Нажмите «OK».

Мы здесь сделаем расчёт суммы и возврат результата с помощью скрипта. Откройте вкладку «Script» и напишите следующий код:

После этого в SOAP-ответе вместо вопроса можно подставить следующую строку: $ . У вас должен получиться такой ответ:

Вот так это выглядит в программе:

Теперь, можете запустить сервис. Для этого переключитесь в навигаторе на сервис, у меня это «Service1Soap MockService» и щёлкните по зелёному треугольнику. После запуска сверху будет двигаться бегунок показывающий, что сервис работает.

Теперь можно тестировать клиента. Я для примера сделал консольное приложение в Visual Studio, добавил в проект ссылку, указав ссылку на WSDL (WSDL можно получить, щёлкнув по кнопке с изображением зелёной фигуры, на картинке сверху она обведена зелёным кружком). Далее можно вызывать функцию сервиса «GetSum1». Вот код консольного приложения:

После выполнения приведённого кода программы в консоль будет выведен результат 7.

Также при создании сервиса вы можете тестировать его здесь же прямо из программы SoapUI.

Заключение

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

Всем привет! Меня зовут Александра Кабехова, я - QA Team Lead в компании «Ренессанс страхование». В этой статье хочу поделиться опытом тестирование SOAP- запросов через SOAP UI Open Source. Когда я погружалась в тестирование API, то у меня практически не было никакого опыта, пришлось самостоятельно нарабатывать базу знаний и лайфхаков, собственно про некоторые из них и хочу рассказать.

Коротко про 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.

4. И так, предположим, что "Step1" - метод для получения номера телефона Страхователя(клиента), "Step2"- метод для передачи данных по заявлениям выплаты, "Step3" - метод для передачи данных по совершенным выплатам. Все три метода взаимосвязаны, данные ответа одного метода влияют на другие. Следующем шагом я объединю все TestStep в один TestCase.

5. Обратите внимание, что TestCase: "Step2" и "Step3" я перевела в disabled, в дальнейшей работе они нам не понадобятся, поэтому их можно будет удалить.

7. Не забываем указывать значения по переменным. Далее устанавливаем связь, например, "Step 1" нажимаем правой клавишей мыши на "MessageId", отобразится меню, выбираем Get Data, затем выбираем на какую переменную в Properties ссылаться.

В итоге получилось:

8. Если возникнет необходимость передавать значения между методами, то вы так же можете сохранить его в Properties, а затем ссылаться на него, либо использовать Transfer. Например, возникла необходимость передать параметр PolicyNumber из "Step1" в "Step2".
Добавляем Transfer в TestCase. Настроить transfer легко, но советую ознакомиться с инструкцией с официального сайта.

Скрипт указываем в 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.

В "Триггерах сборки" в пункте "Запуск периодически" вводим расписание, например, H 20 * * 1-7 , то есть запускаем после 20:00 каждый день. В "Сборке" добавляем шаг "Выполнить команду Windows" указываем:
C:\Tools\SoapUI-5.4.0\bin\testrunner.bat -j -f C:\Jenkins\workspace\TestHabr\Project_for_soap\Report\ -I Project_for_soap_TestHabr.xml
SoapUI-5.4.0 - наименование программы;
C:\Jenkins\workspace\TestHabr\Project_for_soap\Report - путь к мультиконфигурационному проекту в Jenkins;
Project_for_soap_TestHabr.xml - название проекте в Gitlab.

В "Послесборочных операций" можете добавить шаги "Publish JUnit test result report", "Заархивировать артефакты", "Уведомление по почте".

Далее сохраняем и можем пользоваться! Результат прогона должен прийти на указанною почту.

Всё хорошее когда-нибудь заканчивается

Я рассказала про самый минимум, с которого следует начать при освоении Soap UI. С приобретением опыта вы будете узнавать и другие возможности/функции программы.
Для расширения кругозора советую ознакомиться с кратким руководством и с книгой "Web Services Testing with soapUI" by Charitha Kankanamge, "SoapUI Cookbook" by Aly Saleh , Murat Karslioglu.

Failed to load resource: Origin localhost:3299 is not allowed by Access-Control-Allow-Origin

Удостоверимся, что веб-сервис отвечает, введя его адрес:

JavaScript

Функция обращения к SOAP веб-сервису определена следующим образом:

Получение списка наименований каталогов.

Получение первых букв наименований справочника

Получение данных для каталога , где первая буква входит в условие .

При нажатии на кнопку Обновить происходит вызов функции

и при успешном выполнении вызывается обработчик processSuccess

Нерешенная проблема авторизации на браузере IE

Выводы

RTM: SoapUI для чайников

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

Читайте также: