В наше время редко современное приложение обходится без 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.

В последние годы увеличилось использование API и зависимость от веб-сервисов. Вот список из 12 инструментов тестирования веб-сервисов, которые значительно помогут вам.

За последние несколько лет популярность и использование веб-сервисов или API повысились. Веб-сервис или API – это набор процедур или программных компонентов, которые помогают приложению взаимодействовать или выполнять какой-либо процесс / транзакцию, формируя соединение между другим приложением или сервером. В основном существуют два типа веб-сервиса: REST и SOAP для передачи данных и информации через интернет-протокол.

Поскольку эти веб-службы доступны в Интернете и распространяются по разным сетям, они уязвимы для вирусов и угроз безопасности, которые влияют на процессы, основанные на них. Следовательно, тестирование веб-служб или API-интерфейсов становится необходимым для обеспечения правильной работы и корректного ответа на запросы. Тестирование ПО является перспективным направлением в сфере IT, получить необходимые знания Вы можете на

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

Здесь вы найдете 12 отличных инструментов тестирования веб-сервисов, на счет которых вам следует подумать для вашего API или требований тестирования веб-сервисов:

SoapUI

SoapUI – это инструмент для кросс-платформенного тестирования с открытым исходным кодом. Он может автоматизировать функциональные, регрессионные, согласованные и нагрузочные тесты как SOAP, так и REST-сервисов. Он прост в использовании и поддерживает передовые технологии и стандарты для моделирования и стимулирования поведения веб-сервисов.

Ключевые особенности:

• Предоставляет отчеты для печати, экспорта и HTML на уровне Project, TestSuite, TestCase или LoadTest.
• Возможность взаимодейсвтия с Hudson, Bamboo, Maven, ANT и JUnit.
• Позволяет разрабатывать собственный набор функций в виде плагинов SoapUI.
• Записывает, контролирует и отображает все данные.
• Поддерживает WS-Security и SSL-расшифровки.

TestingWhiz

TestingWhiz это “codeless” инструмент автоматизации тестирования который совместим с API/веб сервисами. Он позволяет проводить функциональное, тестирование совместимости и нагрузочное тестирование и работать с веб-службами REST и SOAP через WSDL-интерфейс через HTTP и FTP.

Ключевые особенности:

• Поддерживает сравнение строк для проверки ответа API.
• Помогает в поиске API-дефектов с помощью интегрированных инструментов отслеживания ошибок, таких как JIRA, Mantis и Fogbugz.
• Создает визуальные журналы и отчеты о проведении теста с помощью электронной почты.
• Обеспечивает непрерывную интеграцию с Jenkins, Bamboo & Hudson.
• Поддерживает тестирование, основанное на данных и ключевых словах.

SOAPSonar

SOAPSonar обеспечивает комплексное тестирование веб-сервисов для HTML, XML, SOAP, REST и JSON. Он обеспечивает функциональное тестирование, тестирование производительности, совместимости и тестирование безопасности с помощью стандартов OASIS и W3C.

Ключевые особенности:

• Поддерживает тестирование уязвимостей с XSD-мутацией.
• Обеспечивает всесторонний анализ WSDL и Schema.
• Выполняет нагрузочное тестирование с моделированием поведения и несколькими одновременными процессами загрузки.
• Предоставляет отчеты в форматах XML, DOC, XLS, PDF, RTF и RPT.
• Взаимодействует с Центром качества HP.

SOAtest

SOAtest – это инструмент для тестирования и проверки API-интерфейсов и приложений, управляемых API. Он обеспечивает надежную поддержку функционального блока, интеграцию, безопасность, симуляцию, проведение нагрузочного тестирования при помощи таких технологий, как REST, JSON, MQ, JMS, TIBCO, HTTP и XML.

Ключевые особенности:

• Обеспечивает End-to-End тестирование
• Поддерживает 120+ протоколов / типов сообщений.
• Поставляется с простым в использовании интерфейсом.
• Помогает создавать сложные, расширяемые и многоразовые тесты без кодирования.
• Поддерживает непрерывное интеграционное тестирование

TestMaker

TestMaker – это инструмент с открытым исходным кодом для тестирования и мониторинга производительности веб-сервисов и приложений SOA с помощью PushtoTest. Он работает на Jython (Python написанный на Java). TestMaker может перепрофилировать тесты Selenium, тесты SoapUI, тесты Sahi или любые тесты, написанные в Groovy, Java, Python, PHP, Ruby и Perl, в функциональные, нагрузочные тесты.

Ключевые особенности:

• Использует запрос командной строки для тестирования функциональности, нагрузки и производительности.
• Интуитивно понятный внешний вид со стандартной многооконной IDE.
• Предоставляет контрольную панель для запуска тестов и отображения результатов в реальном времени.
• Позволяет получать доступ ко всем Java-библиотекам и классам языка Jython.

Postman

Postman – еще один инструмент тестирования API / веб-сервисов, который имеет мощную поддержку HTTP-клиента. Он имеет простой в использовании конструктор запросов, который позволяет писать тест-кейсы и управлять данными ответов и временем отклика для эффективного тестирования и управления тест-кейсами API.

Ключевые особенности:

• Позволяет организовывать API в функции, называемые сборками Postman.
• Облегчает совместную работу и совместное использование данных API и средств контроля.
• Позволяет записывать логические тесты в Postman Interface.

vRest

VRest – это инструмент, предназначенный для тестирования, тестирования REST APIS и веб-сервисов. Он также поддерживает тестирование веб-приложений, мобильных и настольных приложений, которые взаимодействуют со сторонними API-интерфейсами или службами HTTP.

Ключевые особенности:

• Имеет функциональность макетного сервера для создания макета API за считанные минуты.
• Существует расширение Chrome для записи и воспроизведения тест-кейсов.
• Поддерживает интеграцию с Jenkins для непрерывной работы серверов и Jira для отслеживания ошибок.
• Облегчает управление разрешениями.
• Позволяет экспортировать и импортировать тест-кейсы и отчеты из внешних инструментов, таких как Postman Collections, Swagger 2.

HttpMaster

HttpMaster – еще один эксклюзивный инструмент для тестирования веб-сервисов REST. Это помогает тестировщикам тестировать поведение API REST и проверять выходные данные в таких форматах, как XML, JSON и HTML. Благодаря универсальному HTTP-инструменту HttpMaster также помогает разработчику моделировать активность клиента и поведение ответа приложения API.

Ключевые особенности:

• Имеет простой в использовании и элегантный пользовательский интерфейс, который не требует передовых технических навыков.
• Использует HTTP-методы, такие как GET, POST, DELETE и т. Д.
• Предоставляет различные типы и выражения для проверки для облегчения тестирования.
• Использует интерфейс командной строки для создания и выполнения теста.
• Позволяет хранить всю информацию – вызовы API и данные проекта в одном месте.

Runscope

Runscope – простой инструмент для проверки и мониторинга производительности API. Runscope также поддерживает тестирование API-интерфейсов и бэкэнд мобильных приложений.

Ключевые особенности:

• Позволяет создавать тесты с динамическими данными даже для сложных случаев.
• Отображает показатели и аналитику для выявления проблем.
• Работает с такими инструментами, как HipChat, Webhooks, Slack и PagerDuty для уведомления о сбое API.
• Позволяет повторно использовать и выполнять тесты в нескольких местах.
• Облегчает централизованное управление тестированием для улучшения совместной работы.

Rapise

Rapise – это надежный инструмент автоматизации с мощными и расширяемыми функциями. Он основан на открытой и гибкой архитектуре для быстрого функционального тестирования веб-сервисов REST / SOAP. Rapise также обеспечивает поддержку тестирования веб-приложений, встроенных в Java, .NET, Ajax, Silverlight и Flash.

Ключевые особенности:

• Использует стандартные методы HTTP, такие как POST, GET, PUT и DELETE.
• Позволяет хранить прототипированные запросы в отношении определенной веб-службы.
• Содержит встроенный конструктор определений REST и библиотеку объектов.
• Имеет мощные возможности отчетности.
• Поддерживает кросс-браузерное тестирование и параллельное выполнение.

WebInject

WebInject – это бесплатный инструмент для автоматизированного функционального, приемного и регрессионного тестирования веб-сервисов. Это инструмент командной строки и основан на Perl, что упрощает выполнение тестов, поскольку не требуется тратить время на командную строку. Кроме того, у него нет IDE-интерфейса, который означает, что тесты записываются вне пользовательского интерфейса WebInject. Он может работать на платформах с интерпретатором Perl.

Ключевые особенности:

• Обеспечивает отображение результатов в режиме реального времени.
• Контролирует время отклика системы.
• Поддерживает различное использование – как полноценную тестовую платформу, так и автономный тестировщик.
• Создает отчеты в форматах HTML и XML.
• Позволяет интегрировать с другой системой в качестве плагина для внешнего мониторинга.

Storm

Наконец, Storm – еще один инструмент с открытым исходным кодом от CodePlex для тестирования веб-сервисов, написанных на Java или.NET. В настоящее время он поддерживает только веб-сервис SOAP.

Ключевые особенности:

• Позволяет тестировать несколько веб-сервисов из единого пользовательского интерфейса.
• Помогает редактировать необработанные запросы SOAP.
• Позволяет ссылаться на методы веб-службы, содержащие сложные типы данных.
• Поддерживает тестирование приложений WCF.

Конечно, список здесь не заканчивается, так как для тестирования веб-сервисов существует огромное множество инструментов.

Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!

Веб-сервисы в 1С

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

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

Риски использования веб-сервисов 1С

В платформе 1С81 появилась реализация веб-сервисов.

Но их использование чревато рисками:

1. 1С8 плохо работает через HTTPS, средства диагностики отсутствуют, поэтому понять, почему при наличии сертификата сервис не хочет работать через HTTPS порой невозможно. Выход - реализация веб-сервисов через CURL или поднятие HTTPS-туннеля.
2. 1С8 придерживается своих правил валидации WSDL-схем. Порой по необъяснимым причинам WSDL-схема не хочет загружаться в WS-ссылку. Узнать причину можно только на партнерском форуме у одного специалиста. Средства диагностики WSDL-схемы отсутствуют, не указывается даже причина или строка, на которой прерывается загрузка схемы.

Правила построения сервисов по продаже

Клиенту выдается документ о продаже (чек) только в том случае, если транзакция по сервису прошла успешно. Иначе возможна ситуация, когда клиент получит чек и будет пребывать в уверенности, что получил услугу, а на самом деле это не так.

Использование внешних SOAP-сервисов

Веб-сервисы SOAP используют WSDL схемы и объекты XDTO для представления данных.

Загрузка WSDL

Для того, чтобы использовать внешний сервис, нужно загрузить его WSDL-схему.

Проверка валидности WSDL-схемы

Иногда WSDL-схема не загружается в 1С. Проверить валидность (правильность) схемы можно любым валидатором WSDL-схем, например http://www.validwsdl.com/ .

Нужно загрузить схему на какой-нибудь http-сайт (можно по ftp) и указать адрес файла, в который загружена схема:

Особенности загрузки WSDL в 1С

Особенность загрузки WSDL в 1С в том, что валидные схемы могут не загружаться. Никакого встроенного валидатора нет, поэтому приходится искать ошибку методом деструктивного анализа, последовательно уменьшая количество элементов в схеме. Можно, например, удалить описание веб-сервиса.

Обработка для тестирования работающего внешнего веб-сервиса

Для тестирования работающего внешнего веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf» из пакета к этой статье.

Тестирование можно использовать на примере сервиса Morpher , склоняющего имена (адрес сервиса http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

Таким способом можно протестировать любой сервис, который имеет простые точки входа, содержащие параметры простых типов: число, дата, строка.

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

Стандартные средства отладки сервисов

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

SOAP и HTTPS

К сожалению, SOAP в 1С достаточно капризно ведет себя при работе через протокол HTTPS, практика показывает, что добиться HTTPS соединения невозможно, хотя возможность и продекларирована в платформе. Сказывается отсутствие средств диагностики и отладки для выяснения причин, из-за которых не устанавливается соединение. Поэтому удобно использовать SOAP через CURL.

Встроенный механизм использования HTTPS подразумевает, что все сертификаты должны быть опубликованы в общем файле pem в каталоге программы 1С.

Использование 1С как сервиса

Правила разработки сервиса на базе 1С

Операция «Hello»

Правилом хорошего тона является создание в сервисе операцию, которая информирует о том, что сервис доступен. Это облегчает жизнь интеграторов, им будет проще проверять, налажена ли связь с сервисом.

Например, можно использовать операцию Hello без параметров, которая просто возвращает булево значение Истина.

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

Процедура хорошо описана в документации: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634 :

Задача публикации Web-сервисов сводится к размещению конфигурационных файлов *.1cws Web-сервисов в соответствующем каталоге веб-сервера с соответствующими настройками для веб сервера. Для того, чтобы выполнить публикацию Web-сервисов, следует выполнить команду меню «Администрирование | Публикация Web-сервисов».

В результате выполнения этой команды будет открыто окно публикации Web-сервисов.

Окно публикации Web-сервисов содержит путь к веб-серверу и два списка:

• «Web-сервисы» - список Web-сервисов конфигурации;
• «Публикация» - список Web-сервисов, опубликованных на указанном веб-сервере.

С помощью кнопки «Соединение…» следует указать веб-сервер, на котором требуется опубликовать Web-сервисы.

Окно выбора пути к веб-серверу позволяет указать путь двумя способами:

• на закладке «Файлы» - этот способ используется в том случае, когда публикация выполняется на том же компьютере, на котором установлен веб-сервер. В качестве пути указывается локальный каталог, соответствующий интернет-странице, с которой будет выполняться вызов публикуемого Web-сервера;
• на закладке «FTP сайт» - этот способ используется в том случае, когда требуется опубликовать Web-сервис на удаленном компьютере. Для выполнения публикации необходимо указать параметры FTP-соединения с удаленным компьютером и каталог, в котором будет опубликован Web-сервис.

Публикация выбранного Web-сервиса осуществляется с помощью кнопки «Опубликовать»

Для отмены публикации Web-сервиса используется кнопка «Удалить».

Публиковать можно в локальном каталоге или по FTP. Можно публиковать и на удаленный сервер по UNC-пути, если удаленный сервер входит в локальную сеть.

После публикации веб-сервис доступен по адресу «http://localhost/test.1cws» или «http://xxx.ru/test.1cws», где xxx.ru - адрес удаленного сервера а localhost - типовой адрес локального сервера.

Авторизация к веб-сервису 1С

Для доступа к сервису нужно пройти аутентификацию.

Вопросы авторизации хорошо рассмотрены тут: http://www.forum.mista.ru/topic.php?id=341168 и в документации file:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm

Обычно веб-сервис работает под одним конкретным пользователем (чаще - специально созданным). Можно пользователя 1С "прикрепить" средствами Windows-аутентификации к пользователю Windows IUSR_ (для пользователя отключить авторизацию 1С). Как вариант, можно очистить список пользователей 1С, тогда авторизация не требуется.

Если требуется несколько пользователей, то можно создать несколько логинов для веб-сервера, к каждому из них привязать пользователя Windows и соответственно, прописать в 1С доступ к пользователям Windows.

В свойствах Пользователь и Пароль объекта WSПрокси используется не логин 1С, а логин пользователя веб-сервера.

Тестирование веб-сервиса 1С

Для тестирования 1С как веб-сервиса используйте обработку «ТестПроизвольногоВебСервиса.epf», как описано в разделе «Тестирование работающего внешнего веб-сервиса».

Файл 1cws и является WSDL-описанием веб-сервиса 1С.

Использование сервисов в Рознице

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

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

Сервис может быть по-разному интегрирован в розничную программу, написанную на языке 1С (УТ, Розница и другие):

1. Может быть написана обработка или код на языке 1С, который выполняет всю работу с сервисом.
2. Может использоваться программа, которая работает с сервисом, а в 1С передает только информацию для пробития чеков.

Организация служебных данных в 1С

Для хранения информации о транзакции в чеке необходимо создать дополнительную табличную часть «Сложные продажи» с реквизитами:

• Номенклатура - привязка к номенклатуре чека.
• Параметр - ссылка на справочник «Сложные продажи: Параметры».
• Значение - значение параметра, составного типа. Строковое представление должно быть довольно длинным (1024 символа), чтобы помещался текст чека.

Справочник «Сложные продажи: Параметры» содержит перечень параметров транзакции.

Табличную часть выгоднее использовать, чем набор реквизитов, т.к. у транзакции их может быть очень много, а в других чеках, не связанных с сервисом, эти реквизиты не будут использоваться, и будут занимать лишнее место. Кроме того, такое решение универсально для любого сервиса и не требует реструктуризации данных после внедрения нового сервиса.

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

Использование обработок на языке 1С

Рассмотрим на примере условной услуги Paym для конфигурации «Розница».

1. Заведем в 1С предопределенный элемент справочника номенклатуры «Paym». В режиме 1С:Предприятия после обновления конфигурации ему нужно назначить вид товара «Услуга».
2. В процедуре «Добавить номенклатуру в таб. часть» модуля формы «Регистрация продаж» вызываем обработку работы с сервисом, написанную на языке 1С. В случае успешного осуществления платежа записываем и проводим чек:

Если (Номенклатура = Справочники.Номенклатура.Paym) И (ВидОперации Перечисления.ВидыОперацийЧекККМ.Возврат) Тогда ОбработкаПлатежа = Функции.ДатьВнешнююОбработку("Paym"); ФормаПлатежа = ОбработкаПлатежа.ПолучитьФорму(); Результат = ФормаПлатежа.ОткрытьМодально(); Если Результат = Неопределено Тогда Возврат; КонецЕсли; ЭтотОбъект.Записать(РежимЗаписиДокумента.Проведение); КонецЕсли;

1. Обработка должна напечатать предчек (если требуется), заполнить табличную часть сложных продаж и подготовить текст печати чека в предопределенном реквизите «PaymТекстЧека».
2. В процедуре «Провести и распечатать чек» модуля чека подменяем наименование товара на сохраненное в реквизите для чека. Текст подменяется только для продажи, для возврата печатается просто название услуги, как обычно.

ИначеЕсли ВидОперации Перечисления.ВидыОперацийЧекККМ.Возврат И Выборка.НомеклатураСсылка = Справочники.Номенклатура.Paym Тогда //Осипов PaymMaster СтрокаСложныхПродаж = СложныеПродажи.Найти(Справочники.СложныеПродажиПараметры.PaymТекстЧека, "Реквизит"); Если СтрокаСложныхПродаж Неопределено Тогда Товар.Наименование = СокрЛП(СтрокаСложныхПродаж.Значение); КонецЕсли;

Отдельный вопрос - как обеспечить завершенность транзакции. Т.е. если транзакция прошла в сервисе, как сделать, чтобы она не потерялась в 1С. Наиболее оптимальный путь - сверка реестров. Но это предмет отдельного рассмотрения.

Использование программ, интегрируемых с 1С

XDTO

Часто в веб-сервисах используется XDTO. Приведем наиболее важные советы и рецепты по использованию XDTO в 1С.

XDTO в платформе 1С

XDTO-пакеты, описанные в ветке «XDTO-объекты» конфигурации, доступны для создания типов и объектов в глобальной фабрике Фабрика XDTO. Это не сразу становится очевидным.

Некоторые типы в схеме не имеют имени, чтобы их получить, надо пройтись по иерархии типов.

В примере был описан список System, содержавший структуры XDTO. Чтобы создать саму структуру, нужно было получить ее тип таки вот образом:

Тип = Фабрика.Тип("urn:my.ru:MasterData:Business", "Business").Свойства.Получить("System").Тип;

Частые проблемы с XDTO

Разные форматы XSD-схем

В некоторых форматах теги называются xs:, в некоторых xsd:, но 1С благополучно понимает оба формата. Однажды была ситуация, что XSD нормально без ошибок импортировалась в 1С, но не создавала ни одного пакета. Причина была в отсутствии атрибута targetNamespace у тега, соответственно 1С не знала, в какой пакет помещать схему, но ошибок не выдавала.

Сопровождение сервисов

Учитывая, что сервис - это совокупность двух систем - 1С и внешней, ошибки могут быть в обоих системах, что снижает общую надежность работы.

Для того, чтобы проще было разбираться в причинах отказов в работе сервисов, рекомендуется использовать комплекс мер.

Протоколирование запросов

Ссылки

• XDTO
  • Хорошее описание XDTO http://pro1c.org.ua/index.php?showtopic=214
• Бесплатные интересные веб-сервисы:
  • Аэрофлот - информация о расписании самолетов
  • Морфер - склонение имен http://www.morpher.ru/WebServices/Morpher.aspx
• Неразобранные:
  • Установка и использование Веб-сервисов
    • v8: как изменить конфигурационный файл апача?
    • v8: продолжение темы с web-сервисами - не могу подключить web-сервис
    • v8: дальше ползу по веб-сервисам - не могу создать прокси...
    • Книга знаний: v8: Использование внешних web-сервисов в 1С:Предприятие 8 ;

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

В нескольких статьях я расскажу о возможностях протестировать с помощью 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:

Как видно, все работает, но еще есть что улучшить - например, хотелось бы знать какое количество элементов SaleItems у нас в документе.

Об этом и о более сложных примерах я расскажу уже в следующей статье.

В приложенном архиве - выгрузка информационной базы и проект SoapUI.

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