testomat.io управление авто тестамиПять или шесть лет назад я тестировал свой первый веб-сервис. Сервис был одной частью большoй системной перезаписи. В этой фазе мы интегрировали устаревшее приложение мэйнфрейма и новую веб-платформу, используя веб-сервисы. У нас было много инструментов для тестирования веб-сервисов: SoapScope, отечественный инструмент тестирования основанный на браузере, и несколько из нас писали прямые Java или Ruby коды для тестирования. Я отлично помню, что в то время думал о том, что должен существовать более простой путь.
Через приблизительно две недели работы в проекте, в то время, как я изо всех сил пытался заставить несколько библиотек Ruby работать и тестировать нашу службу, кто-то из команды проекта представил мне soapUI. В то время, проект soapUI был еще молод и включал только основной функционал и возможность эксплуатационного тестирования и вообще не содержал профессиональной версии. С тех пор, когда я в первый раз использовал soapUI, он стал моим выбором по умолчанию для тестирования сервисов.
Сегодня, у soapUI есть как коммерческая версия Pro, так и бесплатная версия. Они предлагают поддержку WS, REST, и HTTP сервисов, наряду с недавним объявлением о поддержке JMS, AMF, и JDBC. В этой статье мы рассмотрим на примере функциональных и эксплуатационных тестов, тестирование WSDL сервиса. В следующих статьях мы рассмотрим нагрузочное тестирование, симуляцию веб-сервиса, и интеграцию с JUnit. В качестве приложения-примера для каждой из этих статей мы будем рассматривать веб-сервис Atlassian JIRA. Это - хороший нетривиальный интерфейс, также являющийся публично доступным примером.
Создание первого проекта
При первом открытии soapUI, не будет загружаться ни один проект. Для создания нового проекта необходимо кликнуть правой кнопкой мыши на значке Projects и выбрать New soapUI Project, как показано на картинке 1 ниже:
Шаг 1: создание нового проекта в soapUI.
Это загружает новое диалоговое окно Проекта soapUI, как показано на рисунке 2. Введите имя проекта и начальный WSDL для проекта, который будет создан. Если ваш WSDL изменяется, вы можете импортировать обновления позднее - не думаю, что для того, чтобы начать, вам потребуется последняя версия. Для этого примера я буду использовать свою собственную реализацию веб-сервиса JIRA, таким образом, я смогу выполнить тесты. Если вы последуете за мной, вы можете направить свой проект на версию Atlassian, используемую в качестве примера, и которую можно найти тут.
Шаг 2: Присвоение названия проекту и импорт первоначального WSDL.
Вы увидите много флажков для задач, и таким образом soapUI сможет работать у вас автоматически, во время создания проекта. Вы можете попробовать их все, но обычно я только проверяю флажок "Create sample requests for all operations?" («Создать образцы запросов для всех операций?»). Когда вы закончите с вводом новой информации о проекте, нажмите OK
После завершения загрузки проекта, вы должны увидеть, что все различные запросы детализированы в определении WSDL, выведенном на экран в соответствии с проектом, как показано на рисунке 3. Чтобы просмотреть детали запроса, вы можете развернуть запрос с помощью двойного щелчок по значку "Request 1", показанному ниже. Это должно открыть запрос в окне основного рабочего пространства soapUI.
Step 3: Различные запросы JIRA показаны под проектом с окном запроса, открытым в основной рабочей среде soapUI.
Чтобы подать запрос сервису вручную, просто нажмите на зеленую стрелку в нужном окне, как показано на рисунке 4.
Шаг 4: используйте зеленую стрелку, чтобы подать запрос сервису.
Если вы сделаете это для этого конкретного запроса - запроса addVersion – без внесения каких-либо изменений, вы получите ответ, содержащий исключение, показанное в списке 1 ниже.
Это исключение возвращается по нескольким причинам. Во-первых, мы еще не вошли в систему. Если вы прокрутите вниз доступные запросы в нашем проекте, то увидите, что есть запрос входа в систему. Во-вторых, во всех значениях данных в нашем запросе были вопросительные знаки, как показано в списке 2 ниже. Прежде, чем представить любые запросы, вы захотите ввести тестовые значения в те поля, где видите вопросительные знаки.
…
<faultcode>soapenv:Server.userException</faultcode>
<faultstring>java.lang.NumberFormatException: Invalid boolean</faultstring>
…
Список 1: Исключения
В этой точке вы можете просмотреть любой из запросов; просмотреть различные параметры запроса; изменить запросы и выполнить их вручную, чтобы видеть ответы. Короче говоря, вы должны быть в состоянии просматривать и взаимодействовать с Вашим веб-сервисом.
…
<in0 xsi:type="xsd:string">?</in0>
<in1 xsi:type="xsd:string">?</in1>
<in2 xsi:type="bean:RemoteVersion" xmlns:bean="http://beans.soap.rpc.jira.atlassian.com">
<id xsi:type="xsd:string">?</id>
<name xsi:type="xsd:string">?</name>
<archived xsi:type="xsd:boolean">?</archived>
<releaseDate xsi:type="xsd:dateTime">?</releaseDate>
<released xsi:type="xsd:boolean">?</released>
<sequence xsi:type="xsd:long">?</sequence>
</in2>
…
Список 2: По умолчанию, значения не заполняется для запросов
Написание и выполнение тестовых случаев
Просмотр и взаимодействие - это хорошо, но я предполагаю, что вы хотите выполнить некоторые тесты. Чтобы сделать это, вы должны будете создать TestSuite. Для этого щелкните правой кнопкой по проекту и выберите Новый TestSuite, как показано на рисунке 5.
Шаг 5: Создание нового TestSuite в soapUI.
Это должно открыть новое диалоговое окно TestSuite, как показано на рисунке 6. Введите название своего комплекта тестов. Имейте в виду, что для большинства проектов у вас будет большое количество комплектов, таким образом, описательные названия могут быть полезны. После завершения, нажать OK.
Шаг 6: присвоение названия вашему TestSuite в soapUI.
Это добавит ваш TestSuite к дереву проекта в навигации с левой стороны. Это также откроет ваш TestSuite в основном рабочем пространстве soapUI.
В soapUI TestSuite (набор тестов) составляются из TestCases (тест кейсов). Для нашего примера мы создадим простой набор тестов, для входа в JIRA и выхода из него после. Этот пример хорош по нескольким причинам. Во-первых, это покажет вам, как передать значения между TestCases, это важно, потому что для большинства веб-сервисов, которые я тестировал, мне нужно было это делать самому. Во-вторых, мы получим шанс посмотреть на некоторые основные характеристики - как утверждения – без необходимости для вас хорошо знать JIRA. Вход в систему и выход из системы - довольно очевидные функции.
Чтобы добавить наш первый TestCase, щелкните по кнопке "Create a new TestCase in this test suite" (создать новый тестовый случай в этом наборе тестов). Вы найдете это в окне TestSuite, как показано на рисунке 7.
Шаг 7: Создание новой кнопки TestCase в окне TestSuite.
Так открывается новое диалоговое окно TestCase, где вы даете название тест кейсу, который создаете. Это выглядит точно так же, как и новое диалоговое окно TestSuite. Введите имя и нажмите OK. Так как этот тестовый случай тестирует вход в систему, я даю ему название "Вход в систему".
Когда Вы нажимаете OK, происходят две вещи. Во-первых, ваш TestCase показывается в окне TestSuite с пустой панелью результата, как показано на рисунке 8 ниже. Эта панель результата является белой, потому что вы еще не выполнили тест. При выполнении панель станет красной для отказа или зеленой для передачи
Шаг 8: ваш TestCase добавлен к вашему TestSuite.
Затем, вы также увидите окно, открытое для TestCase, который вы только что создали. На рисунке 9, окно тестового случая для входа, который создал я.
Шаг 9: окно TestCase для тестового случая входа.
В-третьих, как показано на рисунке 10, в дереве навигации проекта с левой стороны вы увидите новый TestCase, указанный в вашем TestSuite. Вы также увидите счетчики количества шагов теста или нагрузочных тестов, связанных с ним.
Шаг 10: TestCase добавлен в навигационном дереве проекта.
То же что и для TestSuite выполняется и для TestCases, тест кейс состоит из шагов теста. Для нашего теста Войти в систему, мы должны добавить шаги, чтобы это произошло
Первым делом, мы добавим запрос входа в систему для веб-сервиса. Чтобы выполнить это, нужно нажать кнопку "Create a new Test Request TestStep" в окне тестового случая. Эта кнопка показана на рис. 11.
Шаг 11: кнопка Create a new Test Request TestStep.
В диалоговом окне Add Step «Добавить шаг» введите название шага и нажмите OK. Это откроет Новое диалоговое окно TestRequest, показанное на рисунке 12. Прокрутите вниз список и выберите запрос входа в систему. Затем нажмите OK.
Шаг 12: диалог New TestRequest.
Это открывает диалоговое окно Add Request to TestCase (Добавить запрос для TestCase), показанное на рисунке 13. По желанию вы можете поменять название для запроса, и вы также можете выбрать серию подтверждения запаса. По умолчанию выбрано SOAP Response Assertion. На данный момент это отлично. Просто нажмите OK
Шаг 13: Добавление запроса в TestCase диалог.
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://soap.rpc.jira.atlassian.com">
<soapenv:Header/>
<soapenv:Body>
<soap:login soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<in0 xsi:type="xsd:string">mike.kelly</in0>
<in1 xsi:type="xsd:string">password</in1>
</soap:login>
</soapenv:Body>
</soapenv:Envelope>
Список 3
Когда вы нажимаете OK, запрос добавляется к TestCase, и окно запроса открывается для запроса, который вы только что добавили. Точно так же как ранее в статье, вы можете отредактировать значения и выполнить этот запрос вручную. Однако на сей раз, независимо от того, какие значения вы вводите, они будут значениями, сохраненными для этого тест кейса. Для этого примера я буду использовать свое имя пользователя и пароль, показанные в списке 3 ниже. Если я провожу этот запрос вручную, я получаю ответ, показанный в списке 4.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:loginResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://soap.rpc.jira.atlassian.com">
<loginReturn xsi:type="xsd:string">26lRGT7uX5</loginReturn>
</ns1:loginResponse>
</soapenv:Body>
</soapenv:Envelope>
Список 4
Вы увидите строку из 10 символов, которая возвращается с моим сеансом. Вы можете также заметить, что где бы ни появлялся значок TestStep, он меняет цвет от белого до зеленого. Это - хорошая визуальная подсказка, говорящая о том, что ваши утверждения с этим тестовым шагом прошли.
В настоящий момент единственное утверждение, которое мы имеем в нашем TestStep – то, которое было установлено при создании. Все, что делает утверждение , подтверждает, что наш ответ - допустимый ответ SOAP. Хотя это важно, этого недостаточно для нас. Таким образом, мы собираемся добавить другое утверждение, которое подтверждает, что мы получаем 10-символьную строку назад в нашем ответе.
В окне запроса вы увидите кнопку Assertions у основания окна. Если вы щелкните по нему, это покажет, какие текущие утверждения вы связали со своим TestStep. Если вы захотите добавить другое утверждение – что мы и делаем - вы захотите нажать кнопку Add Assertion, показанную на рисунке 14.
Шаг 14: кнопка для добавления утверждения к TestStep.
Когда вы добавляете утверждение, первое появившееся диалоговое окно, является диалоговым окном выбора утверждения. Есть много различных доступных утверждений, и в этой статье мы собираемся рассмотреть только одно из них. Для получения дополнительной информации по каждому типу утверждения, проверяйте soapUI реководство пользователя . Для нашего примера мы собираемся сделать Запрос XPath. Выберите эту опцию и нажмите OK
Шаг 15: выбор утверждения запроса XPath .
Это откроет диалоговое окно конфигурации соответствия XPath. В этом диалоговом окне Вы можете определить XPath Epression, чтобы получить значение (я), которое вы хотите протестировать. В этом диалоговом окне вы также определяете ожидаемый результат для своего выражения.
В то время как вы пишете свое выражение и результат, вы можете протестировать свое заявление, используя кнопки "Select from current" (выбор из текущих) и "Test" (Тест) под частью Expected Result (Ожидаемый раздел) этого диалогового окна. Это предоставляет вам некоторую обратную связь в реальном времени по Вашему выражению и определению результата.
Шаг 16: Обычное выражение для проверки XPath возврата входа в систему.
В примере, показанном на рисунке 16 выше, вы увидите, что я ищу элемент "loginReturn" в XML ответе, и затем я сравниваюсь его с обычным выражением для 10 символов, который включает символы верхнего или нижнего регистра и все десять цифр. Это заявление должно вернуться как true, если значение элемента соответствует тем параметрам. Именно поэтому мой ожидаемый результат - правильный.
Когда вы нажимаете на Save, вы добавляете утверждение к тестовому шагу. Вы должны иметь возможность видеть добавленное утверждение у основания окна запроса, как показано на рисунке 17.
Шаг 17: XPath Match добавлено к запросу.
В этой точке вы можете закрыть окно запроса входа в систему. Мы готовы идти дальше к следующему TestStep. Затем мы хотим выйти из системы. Вы можете добавить шаг выхода из системы с помощью тех же действий, которые мы использовали для входа в систему. Когда вы доберетесь до запроса выхода из системы, как показано в списке 5 ниже, вы увидите, что должны перейти в сессию от входа в систему
Если вы выполняете этот запрос, без перехода в сеансе, Вы получите режим выхода из системы «false». Причина проста - JIRA не знает, кто должен выйти из системы.
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://soap.rpc.jira.atlassian.com">
<soapenv:Header/>
<soapenv:Body>
<soap:logout soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<in0 xsi:type="xsd:string">?</in0>
</soap:logout>
</soapenv:Body>
</soapenv:Envelope>
Список 5
Чтобы фиксировать это, мы должны будем передать наш идентификатор сеанса от входа в систему до нашего запроса выхода из системы. Мы сделаем это, используя то, что называется Property transfer, вы щелкаете по кнопке Property Transfer в окне TestCase.
Шаг 18: кнопка Property Transfer button в TestCase .
В диалоге InsertStep, вы можете дать название свойству. Обычно я называю его как значение, которое я передаю.
Шаг 19: имя для Property Transfer.
Когда вы нажимаете OK, появляется окно Property Transfer для нового элемента. Для создания, нажмите кнопку add new property transfer в верхнем левом углу окна.
Шаг 20: кнопка adding a new property transfer.
Вы опять получите подсказку дать название передаче. Это потому, что вы можете захотеть передать несколько свойств. В этом одном окне Вы можете отобразить несколько свойств, для передачи. Это кажется несколько избыточным, потому что мы занимаемся только одним свойством, но на самом деле это очень полезно, если у Вас есть пять или шесть свойств, которые необходимо переместить между запросами.
Как только вы добавили передачу, вы можете сконфигурировать ее. Вы должны будете определить как источник, так цель для передачи. Мы выберем значение элемента из loginReturn в ответе Входа в систему и передадим это 0 элементу в запросе Выхода из системы. Вы можете посмотреть мою конфигурацию на рисунке 21.
Шаг 21: Установка параметров передачи свойств для сессии.
Если Вы синхронизируете зеленую стрелку наверху окна Property Transfer, то она выполнит передачу и покажет вам результаты в Журнале Передачи внизу окна.
Как вы можете видеть в примере выше, значение "TD9CJdR3F1" было найдено и передано. Теперь, если бы вы вернулись и запустили запрос Выхода из системы повторно, то он вернулся бы как true. Во время выполнения это значение будет перемещаться динамически между двумя запросами.
Если вы посмотрите на свой TestCase теперь, то увидите, что представлены все три элемента. Если ваши элементы не находятся в правильном порядке, вы можете просто перетащить их и поместить в желаемом порядке.
Шаг 22: завершенный тест кейс для входа и выхода из системы.
Следуйте далее и выполните свой тест кейс, используя зеленую кнопку на главной панели инструментов окна. Вы увидите, что и обновления строки состояния и сводный журнал тестов выведены на экран у основания окна TestCase, как показано на рисунке 23.
Шаг 23: Изложение результатов теста TestCase в soapUI.
И таким образом, мы успешно установили и провели наш первый тест для сервиса JIRA.
Следующие шаги
В следующей статье мы будем основываться на том, что сделали здесь, и посмотрим на проведение некоторых эксплуатационных тестов с использованием soapUI. Чтобы узнать больше о soapUI, его характеристиках, а также о том, над чем работает команда soapUI, смотрите вебсайтsoapUI. Другие статьи и посты в блоге относительно soapUI также предоставляются командой soapUI в разделе их сайта "in the news" listing. А чтобы получить больше информации о JIRA,интерфейсе и функциях, проверьте сайт продукта Atlassian .
