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

29.11.2021 Операции

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

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

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

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

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

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

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

1С8 плохо работает через HTTPS, средства диагностики отсутствуют, поэтому понять, почему при наличии сертификата сервис не хочет работать через HTTPS порой невозможно. Выход - реализация веб-сервисов через CURL или поднятие HTTPS-туннеля.
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С передает только информацию для пробития чеков.

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

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

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

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

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

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

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

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

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

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

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

ИначеЕсли ВидОперации Перечисления.ВидыОперацийЧекККМ.Возврат И Выборка.НомеклатураСсылка = Справочники.Номенклатура.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 ;

В последние годы увеличилось использование 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.

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

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

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