Web services утилита для тестирования. Освоение тестирования SOAP API

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).
Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению.

Теоретическая база

Тот факт, что SOAP является протоколом, имеет большое значение для тестирования: нужно изучить сам протокол, «первичные» стандарты и протоколы, на которых он базируется, а также (по мере необходимости) существующие расширения.

XML
XML – язык разметки, схожий с HTML. Любое сообщение, отправляемое/получаемое через SOAP, – это XML-документ, в котором данные удобно структурированы и легко читаемы, например:

Юля
Наташа
Напоминалка
Не забудь написать статью!

Более подробно про XML можно узнать на w3schools или codenet (по-русски) . Обязательно обратите внимание на описание namespaces (метод разрешения конфликтов при описании элементов в XML) – в SOAP их использование необходимо.

XSD
При работе всегда удобно иметь стандартизированное описание возможных XML-документов и проверять их на корректность заполнения. Для этого существует XML Schema Definition (или сокращенно XSD). Две главные фичи XSD для тестировщика – это описание типов данных и наложение ограничений на возможные значения. Например, элемент из предыдущего примера можно сделать необязательным для заполнения и ограничить его размер 255 символами с помощью XSD:

...

...

Расширения SOAP
В работе вам также могут встретиться различные «расширения» SOAP – стандарты типа WS-* . Одним из самых распространенных является WS-Security позволяющий работать с шифрованием и электронными подписями. Нередко вместе с ним применяется WS-Policy, с помощью которого можно управлять правами на использование вашего сервиса.

Пример использования WS-Security:

Alice
6S3P2EWNP3lQf+9VC3emNoT57oQ=
YF6j8V/CAqi+1nRsGLRbuZhi
2008-04-28T10:02:11Z

Все эти расширения – достаточно сложные конструкции, используемые далеко не в каждом SOAP-сервисе; их подробное изучение на начальном этапе освоения тестирования SOAP вряд ли будет актуально.

Инструменты

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

Редакторы XML / XSD
Хороший тестировщик начинает тестирование еще на стадии написания документации, поэтому для проверки схем удобно использовать специальные редакторы. Два самых известных – Oxygen (кроссплатформенный) и Altova (только для Windows); оба они являются платными. Это очень мощные программы, которыми активно пользуются аналитики при описании сервисов.

В моей практике полезными оказались три фичи редакторов: визуализация XSD, генерация XML на основе XSD и валидация XML по XSD.

1. Визуализация XSD нужна для наглядного представления схемы, позволяющего быстро вычленить обязательные элементы и атрибуты, а также существующие ограничения. Например, для запроса CheckTextRequest обязательным является элемент text, а необязательными – все три атрибута (при этом у атрибута options установлено значение по умолчанию – ноль).

Визуализация необходима в том случае, когда типов и ограничений в схеме много. Если вам нужна только она, и вы не хотите платить за специальные редакторы, то можно рассмотреть бесплатные альтернативы (например, JDeveloper).

2. Генерация XML на основе XSD полезна тогда, когда вы хотите увидеть корректный пример сообщения. Я пользуюсь ей для того, чтобы быстро поэкспериментировать с возможным заполнением сообщения и проверить нюансы работы ограничений.

3. После использования фичи из пункта 2 полезно провести валидацию XML по XSD – то есть проверить сообщение на корректность. Вместе фичи 2 и 3 позволяют отлавливать хитрые дефекты в XSD еще тогда, когда сам сервис находится в разработке.

Инструмент тестирования – SoapUI

Тестирование SOAP практически всегда подразумевает использование SoapUI . Прочитать про использование этого инструмента можно в разных источниках ( , ), но эффективнее всего будет ознакомиться с официальной документацией . Я выделяю 8 условных уровней владения SoapUI:

Уровень 1 – умею отправлять запросы
Научитесь создавать проект на основе WSDL. SoapUI может сгенерировать все необходимые запросы для вас; вам останется лишь проверить правильность их заполнения и нажать кнопочку «Send». После выработки навыков создания корректных запросов вы должны овладеть искусством формирования некорректных запросов, вызывающих появление ошибок.

Уровень 2 – умею делать Test Suites и Test Cases
Начните делать мини-автотесты. Тест-комплекты и тест-кейсы позволяют создавать сценарии тестирования API, подготавливать данные для запросов и автоматически проверять полученный ответ на соответствие ожидаемому. На первых порах их можно использовать просто как коллекции запросов. Например, если вы завели дефект и хотите быстро проверить его после фикса, можно выделить отдельный тест-комплект конкретно под запросы-дефекты.

Уровень 3 – умею писать Assertions
После освоения тест-кейсов вам будет полезно научиться делать их автоматически проверяемыми. После этого вам уже не нужно будет искать «глазами» информацию об ответе: при наличии автоматической проверки кейсы будут помечаться зеленым (если проверка пройдена) или красным (если не пройдена). SoapUI предоставляет большой набор возможных проверок (assertions), но самые удобные и простые – это Contains и Not Contains. С их помощью можно проверить факт наличия конкретного текста в полученном ответе. Эти проверки также поддерживают поиск с помощью регулярных выражений.

Уровень 4 – использую XPath и/или XQuery в Assertions
Для тех, кто немного знаком с UI с помощью Selenium, язык XPath – знакомая вещь. Грубо говоря, XPath позволяет искать элементы в XML-документе. XQuery – похожая технология, которая может использовать XPath внутри себя; этот язык гораздо мощнее, он напоминает SQL. Оба эти языка можно использовать в Assertions. Проверки с их помощью получаются более прицельными и стабильными, поэтому ваши кейсы будут пользоваться большим доверием.

Уровень 5 – умею писать сложные тесты с помощью специальных шагов

В тест-кейсах может содержаться не только один запрос, но и несколько (к примеру, когда вы хотите эмулировать стандартный сценарий работы пользователя «создать сущность» → «экспортировать сущность»). Между запросами могут находиться другие специальные шаги, например:

Properties и Property Transfer (помогают переиспользовать данные и передавать их между запросами);
JDBC Request (используется для получения данных из базы данных);
Conditional Goto (позволяет сделать разветвления или циклы в тест-кейсе);
Run TestCase (помогает вынести какие-то типовые запросы в отдельные тест-кейсы и вызывать их там, где нужно).

Уровень 6 – использую скрипты на Groovy

SoapUI позволяет писать скрипты на Groovy в различных местах. Простейший случай – это генерация данных в самом запросе с помощью вставок ${=}. Я постоянно пользуюсь такими вставками:

${=new Date().format(«yyyy-MM-dd’T’HH:mm:ss»)} – для вставки текущей даты и времени в необходимом формате;
${=java.util.UUID.randomUUID()} – для вставки корректно сформированного случайного GUID.

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

Уровень 7 – использую MockServices
SoapUI на основе WSDL может генерировать Mock-объекты . Mock-объект – это простейшая симуляция сервиса. С помощью «моков» можно начать писать и отлаживать тест-кейсы еще до того, как сервис реально будет доступен для тестирования. Также их можно использовать в качестве «заглушек» для временно недоступных сервисов.

Уровень 8 – бог SoapUI
Вы знаете разницу между платной и бесплатной версиями SoapUI и используете SoapUI API в коде. Вы используете плагины и запускаете выполнение кейсов через командную строку и/или CI. Ваши тест-кейсы просты и легко поддерживаются. В общем, вы «съели собаку» на этом инструменте. Я бы с радостью пообщалась с тем, кто освоил SoapUI на таком уровне. Если вы являетесь таковым – отпишитесь в комментариях!

Тестирование с помощью языков программирования

Приведу пример того, как выглядит запрос к YandexSpeller API, выполненный с помощью groovy-wslite:

import wslite.soap.*
def client = new SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") {
body {
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") {
text("ошипка")
}
}
}
assert "ошибка" == response.CheckTextResponse.SpellResult.error.s.text()
assert "1" == [email protected]()

Насколько я знаю, высокоуровневых фреймворков (по типу Rest-assured) для тестирования SOAP пока не существует, но недавно появился интересный инструмент – karate . С его помощью можно описывать кейсы для тестирования SOAP и REST в виде сценариев по типу Cucumber / Gherkin . Для многих тестировщиков обращение к karate будет идеальным решением, ведь такие сценарии по сложности написания и поддержки кейсов будут лежать где-то посередине между использованием SoapUI и написанием собственного фреймворка для тестирования SOAP.

Заключение

Вряд ли вам когда-либо захочется тестировать SOAP просто так, для себя (как могло бы получиться с REST-ом). Это тяжеловесный протокол, который используется в серьезных корпоративных решениях. Но его тяжеловесность одновременно является подарком тестировщику: все используемые технологии стандартизированы, имеются качественные инструменты для работы. От тестировщика требуется лишь желание их изучить и использовать.

Давайте соберем воедино тот самый чек-лист необходимых навыков для тестировщика. Итак, если вы только начинаете тестировать SOAP сервисы, вам нужно знать и уметь использовать:

WSDL.
SOAP.
Редакторы XML / XSD (на уровне визуализации XSD).
SoapUI на уровне 1.

Как видите, основной упор приходится на изучение стандартов, в SoapUI достаточно просто уметь выполнять запросы. По мере погружения в тестирование SOAP перед вам будут возникать задачи, которые потребуют уже более серьезных навыков и знаний, но не стоит пытаться изучить всё и сразу. Гораздо важнее последовательность в повышении уровня сложности выполняемых задач. Следуя этой рекомендации, в один прекрасный момент вы поймете, что стали хорошим специалистом в этой области!

В наше время редко современное приложение обходится без API. Это справедливо как для простого сайта так и для высоконагруженных распределенных систем. Тестирование API — является одной из главных задач в процессе обеспечения качества. Неудивительно, что спрос на тестировщиков, которые умеют тестировать API повышается изо дня в день. На данном курсе вы получите понимание о методах, инструментах и подходах в тестировании API, приобретете необходимые знания, что несомненно благоприятно отразится на Вашей стоимости как специалиста в тестировании.

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

Программа курса:

Занятие 1. Вводная. Протокол SOAP

Коротко о лекторе;
Цели курса;
Что такое API, WS и зачем они нужны;
Роль тестирования API в процессе обеспечения качества;
Обзор инструментария для тестирования WS;
Методики применяемые в тестировании WS;
История возникновения SOAP;
Терминология и главные понятия (XML, XSD, Endpoint, WSDL).

Занятие 2: Протокол SOAP. Архитектура REST

Терминология и главные понятия (UDDI, XSLT, XPath, XQuery, HTTP methods, HTTP statuses);
Структура и главные компоненты SOAP;
Сфера применения;
Особенности работы;
Преимущества и недостатки;
Особенности REST архитектуры;
Терминология и главные понятия (WADL, RESTful, JSON, JSONPath);
Принципы REST;
Статус код и основные статусы;
CRUD глаголы;
Преимущества и недостатки.

Занятие 3. Знакомство с SoapUI. Работа с REST проектом

Установка Java;
Установка SoapUI;
Обзор основных элементов интерфейса;
Подключение учебного проекта;
Обзор методов проекта;
Отправка запроса и анализ полученного ответа;
Изучение доступных веб-сервисов проекта;
Составление плана тестирования;
Написание тест-кейсов;
Элементы “TestSuite», “TestCase”, “TestSteps”.

Занятие 4. Работа с REST проектом (XML)

Блок “Assertions”;
Запуск тестов на различных уровнях;
Элемент “Properties”, основные возможности;
Работа с Properties;
Элемент “Property Transfer”;
Работа с Assertions.

Занятие 5. Работа с REST проектом (JSON)

Условия и ветвления;
Работа с Assertions;
TestRunner, особенности работы;
Запуск TS, TC из командной строки;
Работа с Test runner;
Работа с Groovy скриптами.

Занятие 6. Работа с Groovy скриптами

Работа со статическими и динамическими данными;
Генерируем тестовые данные;
Получаем данные из “Properties”;
Запись и трансфер данных;
Условия и ветвления;
Script Assertion.

Занятие 7. Дополнительные возможности

Подключение внешних библиотек и кастомных классов;
Mock-сервисы;
Зачем нужны Mock-сервисы;
Пример работы с Mock-сервисом;
А как же CI?
Устанавливаем Jenkins;
Запуск проекта на Jenkins.

Здравствуйте!

В нескольких статьях я расскажу о возможностях протестировать с помощью SoapUI, как работают веб-сервисы 1С. Также приведу примеры возврата из 1С документов в формате PDF и сложных xml-файлов. Некоторые вещи сходны с вот , однако я рассмотрю более сложные примеры работы с веб-сервисами. Но для начала я по шагам рассмотрю процесс запуска веб-сервисов и работы с SoapUI, чтобы легче было разобраться в их функционировании с нуля.

1. Простой веб-сервис

Для начала возьмем каркасную конфигурацию без веб-сервисов и пройдем по шагам процесс их создания.

Добавим новый веб-сервис с именем test1 и создадим в нем операцию hello с возвращаемым типом string. Имена веб-сервисов и операций лучше всегда задавать на латинице.

Также нужно задать URI пространства имен и имя файла публикации:

При нажатии на лупу в поле "Имя процедуры" будет открыт модуль веб-сервиса и можно будет реализовать функцию hello.

Функция hello() возврат "строка из веб-сервиса 1с"; КонецФункции

2. Публикация веб-сервиса.

Теперь, чтобы получившаяся функция была доступна по http, нужно опубликовать наш сервис на веб-сервере. Для этого подойдет Apache 2.2. Я почитал статьи о том, как можно настроить работу с IIS и мне это показалось гораздо сложнее. После установки и запуска Apache 2.2 нужно зайти в меню Администрирование - Публикация на веб-сервере. Поле "каталог" должно быть заполнено и содержать каталог установки Apache. Запомните поля "имя" и "адрес" веб-сервиса, они нам пригодятся на следующем шаге.

3. Тестирование с помощью SoapUI

Для тестирования создадим отдельного пользователя WsUser, с простым паролем и дадим ему полные права.

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

Заходим в меню File - New SOAP project, задаем имя проекта hellotest а в поле Initial WSDL пропишем вот такую ссылку:

http://localhost/test_ws/ws/test1.1cws?wsdl

В ней часть "test_ws" была задана на прошлом этапе в поле "имя" а test1.1cws в поле "адрес".

Нажимаем ОК и на этом этапе нужно будет авторизоваться, войдя под тестовым пользователем WsUser. Будет создан проект и два элемента binding.

Soap12Binding отличается тем, что работает по новой версии стандарта SOAP 1.2. Откроем в test1Soap12Binding элемент Request1 и увидим вот что:

SoapUI показывает, какой xml будет передано в нашу функцию. Перед запуском теста есть еще один нюанс, по умолчанию SoapUI будет требовать авторизацию для каждого отдельного элемента Request. Поэтому, чтобы не задавать ее каждый раз, нужно кликнуть правой кнопкой мышки на testSoap12Binding, выбрать Show interface view и в открывшемся окне на вкладке "Service Endpoint" задать имя и пароль пользователя веб-сервисов:

Если этого не сделать, то для каждого Request нужно будет задавать авторизацию, в нижней панели по кнопке Auth.

Теперь можно наконец-то выполнить запрос к функции hello и посмотреть ответ:

Отлично, все заработало!

4. Передача простых параметров в функцию.

Теперь сделаем новую функцию с параметрами, например проверим работу с датами, сделаем функцию getSaleDocNumbersByDate, которая будет принимать дату документа (расходной накладной) и возвращать номера документов за эту дату строкой. Добавим к операции параметр date с типом dateTime:

код такой:

Функция getSaleDocNumbersByDate(date) // датаНачала = началоДня(date); датаКонца = конецДня(date); выборкаДокументов = документы.Расходная.Выбрать(датаНачала, датаКонца); номера=""; пока выборкаДокументов.Следующий() цикл номера = номера+" №"+выборкаДокументов.Номер+";"; конеццикла; возврат номера; КонецФункции

Теперь в SoapUI правой кнопкой мыши нужно кликнуть на элемент testSoap12Binding и выбрать пункт Update Definition. После этого в проекте появится функция getSaleDocNumbersByDate и готовый Request к ней. Для заполнения даты нужно использовать формат "YYYY-MM-DDThh:mm:ss" (можно посмотреть на w3schools и ОЧЕНЬ рекомендую пользоваться этим сайтом для понимания работы с xml)

Тогда получатся вот такие запрос и ответ:

5. Пакеты XDTO

Если необходимо передавать в функции более сложные параметры (например, xml с несколькими полями), или получать в ответ сложные по структуре xml, то нам не обойтись без пакетов XDTO.

Очень подробно работа с XDTO рассмотрена в цикле статей . По сути, пакет определяет структуру и тип полей используемых xml-файлов.

Я рассмотрю пример передачи и получение xml-файла, тип которого определен в пакете

А также в следующих статьях я рассмотрю примеры:

передача в 1с xml-файла, не описанного в пакете, в формате base64
получение из 1с документа pdf в формате base64 и его декодирование
получение из 1с xml-файла со вложенной структурой элементов и определение их количества

6. Передача в 1с в параметре xml-файла, тип которого определен в пакете.

Задача будет такая: найти документ расходной накладной по заданным во входящем xml номеру и дате и вернуть найденный документ. Возвращать нужно также в виде xml с номером, датой, контрагентом и его кодом и табличной частью товаров.

Создадим пакет packet1 с пространством имен packet1_ns. Для входящего xml-файла определим тип объекта InDocSaleQuery с полем number типа string и полем date типа dateTime. Для выходного файла определим сначала тип для одной строки табличной части товаров: SaleItem с полями name типа string, price sum, quantity типа decimal. А сам документ SaleDoc будет у нас составного типа: поля number, date, partnerName и поле SaleItems у которого будет тип SaleItem и максимальное количество -1. Именно такое поле обозначает, что в нем может присутствовать массив из нескольких элементов. Вот так всё это выглядит в конфигураторе:

Сначала продемонстрирую код функции, а уже затем объясню что происходит

Код:

Функция getSaleDoc(incomingXML) НомерДок = incomingXML.number; ДатаДок = incomingXML.date; запрос = новый запрос; запрос.Текст = "ВЫБРАТЬ | РасходнаяТовары.Номенклатура.Наименование как name, | РасходнаяТовары.Цена как price, | РасходнаяТовары.Количество как quantity, | РасходнаяТовары.Сумма как sum, | РасходнаяТовары.Ссылка |ИЗ | Документ.Расходная.Товары КАК РасходнаяТовары |ГДЕ | РасходнаяТовары.Ссылка.Номер = &Номер | И РасходнаяТовары.Ссылка.Дата = &ДатаДок"; запрос.УстановитьПараметр("Номер",номерДок); запрос.УстановитьПараметр("ДатаДок",ДатаДок); выборка = запрос.Выполнить().Выбрать(); если выборка.Количество()=0 тогда //вернем ошибку ТипДокумента = ФабрикаXDTO.Тип("packet1_ns", "SaleDoc"); ПакетДокумента = ФабрикаXDTO.Создать(ТипДокумента); ПакетДокумента.number = "Документов Не найдено!"; Возврат ПакетДокумента; иначе //создаем типы ТипДокумента = ФабрикаXDTO.Тип("packet1_ns", "SaleDoc"); ТипТабличнойЧасти = ФабрикаXDTO.Тип("packet1_ns", "SaleItem"); ПакетДокумента = ФабрикаXDTO.Создать(ТипДокумента); //выбираем из табличной части сч=0; пока выборка.Следующий() цикл если сч=0 тогда //заполним реквизиты документа док = выборка.ссылка; ПакетДокумента.number = док.Номер; ПакетДокумента.date = док.Дата; ПакетДокумента.partnerName = строка(док.Контрагент); конецесли; //заполняем табличную часть ПакетТабличнойЧасти = ФабрикаXDTO.Создать(ТипТабличнойЧасти); ЗаполнитьЗначенияСвойств(ПакетТабличнойЧасти,выборка); //добавляем ее в документ ПакетДокумента.SaleItems.Добавить(ПакетТабличнойЧасти); сч=сч+1; конеццикла; Возврат ПакетДокумента; конецесли; КонецФункции

Здесь два основных нюанса. Первый: так как был задан тип входящего параметра incomingXML и он был описан этот тип в пакете, то сразу возможно обращаться к полям этого входящего xml. Второй: работа с фабрикой XDTO. Из нее был получен тип для результирующих выходных параметров и создано ЗначениеXDTO этого типа, у которого были заполнены необходимые поля. Также стоит заметить, что в типе SaleDoc следует ввести отдельное поле для ошибки, но для тестовых целей ошибки будут записаны в поле number.

Вот как выглядит результат этого запроса в SoapUI: