веб-сервисы становятся все более популярными во многих проектах разработки. В Java или .NET представить свой компонент бизнес-логики как веб-сервис так же просто, как добавить несколько аннотаций метаданных. Аналогично, если у вас есть веб-сервис, вы можете использовать любой клиент для его использования, верно?
Однако прежде чем сделать все свои веб-службы общедоступными, необходимо убедиться, что они работают. Единственный способ сделать это — написать функциональные тесты для ваших веб-сервисов.
Так много для теории. Я видел очень мало проектов, которые фактически проводят какое-то время, тестируя веб-сервисы, которые они выставляют. В большинстве случаев эти веб-службы тестируются как часть общей системы с использованием любого пользовательского интерфейса. Я сам был виноват в этом, прежде чем открыл SoapUI .
Со дня, когда я открыл SoapUI почти 4 года назад, однако ничто не мешает мне писать функциональные тесты для этих веб-сервисов. SoapUI делает почти заманчивым написание тестов с использованием их графического интерфейса. Вы можете создавать новые тестовые наборы, добавлять тестовые наборы и добавлять утверждения в тестовые наборы. Этот инструмент прост в использовании; вам не нужно быть разработчиком Java, чтобы писать функциональные тесты.
Тесты, которые вы пишете в SoapUI, очень управляемы. Я постоянно слышу, как разработчики говорят: я понятия не имею, что делает этот тест; Я не писал. Тесты должны поддерживаться так же, как и ваш код. После того, как вы загрузите и установите SoapUI, вы сможете запустить функциональные тесты за считанные минуты. Можете ли вы написать такой же тест за несколько минут без SoapUI? Ни за что.
Разработчики слишком часто пишут тесты без утверждений assert. Зачем вообще писать тест без утверждений? С SoapUI вы можете легко добавить много типов утверждений. Вы можете добавить утверждения assert одним нажатием кнопки. Если того, что в SoapUI, недостаточно для ваших требований, я покажу вам, как использовать Groovy в SoapUI, что сделает ваше тестирование еще проще.
ХОРОШО. Вы пишете свои тесты, используя SoapUI, добавляете некоторые утверждения и фактически запускаете их время от времени. Это лучше, чем ничего, но все же в значительной степени бессмысленно. Тесты должны быть интегрированы в вашу сборку и должны запускаться одним щелчком мыши. Да, признаюсь, я самый ленивый разработчик, которого вы когда-либо видели. Зачем делать одно и то же снова и снова, когда мы можем сделать то же самое одним нажатием кнопки?
Если вы автоматизировали свои сборки, и они выполняются как часть вашей непрерывной интеграции, конечно, вам даже не о чем беспокоиться (теперь это лениво!). SoapUI здесь также пригодится. Вы можете запустить наборы тестов и все тестовые наборы, которые вы создали в нем, и, прежде всего, вы можете потерпеть неудачу при сборке так же, как и при любом другом модульном тесте. Круто, не правда ли? Я взволнован, а ты?
ХОРОШО. Вещи лучше. Теперь у вас есть свои тесты, у вас есть отличные скрипты, и все они интегрированы с CI. Какая польза от ваших тестов без отчетов? SoapUI также приходит нам на помощь. Вы можете создавать отчеты JUnit.
Давайте посмотрим, как мы можем достичь всего этого. В этой статье я расскажу о тестировании функциональных веб-сервисов с использованием SoapUI, но не волнуйтесь, там будет больше статей поSoapUI и Groovy, а также SoapUI и непрерывная интеграция в ближайшие недели.
Часть 1. Тестирование функциональных веб-сервисов с использованием SoapUI
Прежде чем мы начнем писать тесты, нам сначала понадобятся две вещи:
1. Загрузите и установите SoapUI отсюда .
2. Далее, давайте получим WSDL от NOAA . Я хотел сосредоточиться на SoapUI, а не на какой-либо одной технологии, чтобы публиковать вашу бизнес-логику в виде веб-сервисов. Итак, я выбрал легкий путь и обнаружил некоторые интересные вещи об этом общедоступном веб-сервисе.
Согласно веб-сайту NOAA, этот веб-сервис позволяет вам получать данные о погоде. У него девять функций. Вот фактический wsdl с веб-сайта:
http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Теперь, когда мы загрузили SoapUI и веб-сервис, который мы можем протестировать, давайте начнем работать.
3. Создайте новый проект в SoapUI; дать ему имя; и скопируйте и вставьте в него URL-адрес WSDL. Вещи должны выглядеть так:
[Img_assist | NID = 2713 | название = | убывание = | ссылка = нет | ALIGN = слева | ширина = 456 | высота = 270]
После успешного создания проекта вы сможете увидеть все девять функций, которые нам предоставляет NOAA. Мы будем использовать только три из них, как показано ниже на снимке экрана:
[Img_assist | NID = 2714 | название = | убывание = | ссылка = нет | выравнивание не = средняя | ширина = 279 | высота = 313]
4. Теперь пришло время выполнить эти запросы, чтобы убедиться, что они действительно работают. Дважды щелкните по запросу 1 . Откроется редактор для запроса LatLonListZipCode . Введите почтовый индекс для вашего города. Я сделал 20904 для Серебряной весны. Нажмите зеленую кнопку в редакторе запроса 1, и вы сможете увидеть ответ в правой части редактора.
Попробуйте еще несколько запросов со следующими данными:
а. NDFDgenByDay Запрос 1
<ndf:NDFDgenByDay soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<latitude xsi:type="xsd:decimal">39.0138</latitude>
<longitude xsi:type="xsd:decimal">-77.0242</longitude>
<startDate xsi:type="xsd:date">2008-05-07</startDate>
<numDays xsi:type="xsd:integer">1</numDays>
<format xsi:type="dwml:formatType" xmlns:dwml="http://www.weather.gov/forecasts/xml/DWMLgen/schema/DWML.xsd">12 hourly</format>
</ndf:NDFDgenByDay>
б. NDFDgenByDayLatLonList Запрос 1
<ndf:NDFDgenByDayLatLonList soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<listLatLon xsi:type="dwml:listLatLonType" xmlns:dwml="http://www.weather.gov/forecasts/xml/DWMLgen/schema/DWML.xsd">39.0138,-77.0242</listLatLon>
<startDate xsi:type="xsd:date">2008-05-07</startDate>
<numDays xsi:type="xsd:integer">1</numDays>
<format xsi:type="dwml:formatType" xmlns:dwml="http://www.weather.gov/forecasts/xml/DWMLgen/schema/DWML.xsd">12 hourly</format>
</ndf:NDFDgenByDayLatLonList>
5. Теперь, когда у вас есть несколько запросов, давайте создадим Test Suite и добавим несколько тестовых случаев.
Следуй этим шагам:
а. Щелкните правой кнопкой мыши на узле вашего проекта, в нашем случае это NOAA-Weather-Service . Выберите пункт меню « Новый TestSuite» . Диалог будет отображаться; введите имя TestSuite , Silver-Spring-Test-Suite . Нажмите OK, и откроется редактор Silver-Spring-Test-Suite. Если требуется какая-либо инициализация всего набора, вы можете сделать это в скрипте установки, а затем выполнить любую очистку в скрипте TearDown. Мы оставляем это поле пустым прямо сейчас, но в следующей части мы также собираемся использовать эти сценарии.
б. Давайте добавим несколько тестовых примеров в этот набор тестов . Есть много способов сделать это, но поскольку я ленивый, мы сделаем это простым способом прямо сейчас. Щелкните правой кнопкой мыши по каждому из запросов 1, которые мы успешно выполнили, и добавьте их в TestCase. Как только вы добавите все три, вы должны увидеть что-то вроде этого в вашем редакторе SoapUI:
с. Теперь у нас есть TestSuite и 3 тестовых случая . Давайте запустим эти тесты. Дважды щелкните на Silver-Spring-Test-Suite . Редактор должен открыться. Нажмите зеленую кнопку, и все три тестовых набора в этом тестовом наборе должны пройти успешно.
6. Если вы откроете любой из этих редакторов тестовых примеров, вы увидите, что у каждого из них есть только одно утверждение: SoapResponse Valid. Мы добавим еще несколько, чтобы сделать наши тесты более надежными. В тестовом примере LatLonListZipCode я использовал почтовый индекс 20904 , и для этого почтового индекса широта и долгота составляют 39.0138, -77.0242 . Чтобы проверить это, добавьте простое утверждение Contains со значением 3 9.0138, -77.0242 . Запустите тестовый пример, и вы должны увидеть зеленые полосы. Тем не менее, как вы знаете, это на самом деле работает? Измените почтовый индекс на 20794 , который является Laurel (рядом с Silver Spring), но имеет другую широту и долготу. Запустите тестовый пример, и он жалуется, что наше утверждение не удалось, как это:
Как упомянуто в документации SoapUI, мы можем добавить много видов ответных утверждений:
Практически во всех гибких проектах функциональное тестирование начинается, как только вы закончите статью в рамках итерации и код для нее будет проверен модульно. Это когда вы будете использовать SoapUI.
Теперь, когда мы проверили, работает ли функциональность веб-службы погоды, нам также необходимо включить отрицательные и граничные условия. Я оставлю это вам в качестве упражнения.
Просто запомните, создайте наборы тестов и контрольных примеров, добавьте утверждения и запустите тесты. Мы даже никогда не открывали нашу любимую IDE. И в довершение всего, это было легко и весело.
В этой статье мы увидели, как использовать SoapUI для написания функциональных тестов. Мы пытались оставаться внутри самого SoapUI. Выход на следующую неделю — это то, что мы делаем в любом корпоративном приложении. Мы хотим, чтобы пользователь вошел в систему, получил идентификатор SessionID, отправил этот идентификатор обратно в заголовок Soap во всех последующих запросах и успешно вышел из системы. Это всего лишь сценарий, но он типичен для того, что мы делаем, верно? Сделайте запрос, получите что-то уникальное в ответе, используйте это в последующих запросах и так далее.
Следующая часть этой серии статей подробно описывает Groovy , как использовать свойства, переносить свойства из одного ответа в другой запрос, как устанавливать глобальные свойства и многое другое. Оставайтесь в курсе.
Запись: Файл проекта SoapUI был прикреплен к этой статье. Открыть созданный нами проект так же просто, как выбрать пункт меню «Импорт проекта» и указать место, где вы сохранили загруженный файл проекта. Выкрикните, если у вас возникнут какие-либо проблемы.