Заглушки для веб-сервисов

Публикация № 1014870

Программирование - Практика программирования

Веб-сервисы SoapUI Vanessa ADD сценарное тестирование BDD

92
Разбираемся, что такое mock-сервисы и зачем они нужны. На основании реального веб-сервиса создадим сервис-заглушку в SoupUI, посмотрим как его запускать из консоли и напишем сценарий в Vanessa-ADD.

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

Содержание

С чем будем работать

Проблемы тестирования интеграции

Заглушки

Запускаем моки через SoapUI

Шаг 0. Готовим окружение

Шаг 1. Импортируем WSDL-схему

Шаг 2. Запускаем mock-сервис

Шаг 3. Настраиваем ответ

Запускаем проект SoapUI из консоли

Подключаем Ванессу

Готовим данные

Запускаем моки

Ждем запуска моков

Останавливаем мок-сервис

Результат

 

С чем будем работать

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

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

В целом, используется стандартная схема: 1С обращается к сервису, который опубликован на веб-сервере; веб-сервис обращается к базе данных и возвращает результат.

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

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

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

Именно такую задачу - подменять реальный объект или сервис его упрощенной реализацией — и помогают решить так называемые «mock-service» (от англ. mock object: «объект-имитация» или «подставка»). Еще их называют просто «моки» или «заглушки». 

 

Проблемы тестирования интеграции

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

  1. Тесты замедляются. Если поставщик сервиса находится далеко, сетевая среда нестабильная и при вызове сервиса происходит задержка, то время прохождения тестов может значительно увеличиваться.

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

  3. Тесты покрывают не все возможные варианты ответов сервиса. Не всегда есть возможность получить некоторые ответы от реального веб-сервиса и промоделировать все рабочие ситуации — следовательно, максимально полно протестировать взаимодействие.

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

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

 
 Вспомнилось

 

Давайте теперь поближе рассмотрим мок-объекты.

 

Заглушки

«Мок» в программировании - это объект-заглушка, реализующий заданный аспект моделируемого программного окружения.

Существует несколько видов объектов, которые позволяют симулировать поведение реальных объектов во время тестирования: 

  1. Dummy — пустые объекты, которые передаются в вызываемые методы, но не используются. Предназначены лишь для заполнения параметров методов.
  2. Fake — объекты, которые имеют реализации, но в таком виде, который делает их неподходящими для использования в рабочей ситуации.
  3. Stub —  предоставляют заранее заготовленные ответы на вызовы во время теста и не отвечают ни на какие другие вызовы, которые не требуются в тесте. 
  4. Mock — объекты, которые заменяют реальный объект в условиях теста и позволяют проверять вызовы своих методов. Содержат заранее подготовленные описания вызовов, которые они ожидают получить. Применяются в основном для тестирования поведения пользователя.

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

Правда, тут возникают две сложности.

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

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

Решение простое — для сервиса, который может быть подвержен изменениям нужно сделать набор дымовых тестов (smoke-тесты). Дымовые тесты проверяют, что основные методы сервиса не изменились и обращение к ним не вызывает ошибок.

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

Тестируемое приложение 1С больше не будет обращаться к удаленному сервису, а получит тот ответ, который мы заранее подготовили и опубликовали из SoapUI.

 

Запускаем моки через SoapUI
 

Шаг 0. Готовим окружение

Программа SoapUI (подробнее о ней можно прочитать в публикации Использование SoapUi для работы с веб-сервисами. Часть1) позволяет на основании WSDL-схемы сервиса создать Mock-service и опубликовать его на собственном веб-сервере, который умеет запускать.

SoapUI можно получить на официальном сайте компании SmartBear. Для наших целей достаточно бесплатной 32х-разрядной OpenSource версии — ее нужно скачать и установить.

В конфигурации 1С, которую мы дорабатываем, есть обработка Расчет трафика — она обращается к веб-сервису CalculateService и вызывает метод CalculateTraffic, в который передает несколько параметров, вроде ID, StoreID и других. Рассчитанный веб-сервисом результат записывается в регистр и запускает внутренний механизм расчетов (что он именно делает, в рамках статьи значения не имеет).

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

Сервис, к которому мы обращаемся, расположен по адресу http://localhost/DEMO/ws/CalculateService.1cws?wsdl 

! Поскольку я воспроизвожу пример для статьи на своем компьютере, в адресе вы видите «localhost». Но подразумевается, что в рабочей ситуации мы будем обращаться к рабочему сервису на рабочем сервере.

 

Для начала запустим браузер и убедимся, что веб-сервис доступен:

Дальше добавим веб-сервис в SoapUI и сделаем для него заглушку.

 

Шаг 1. Импортируем WSDL-схему

Запустим SoapUI и создадим новый проект.

Импортируем в проект описание нашего веб-сервиса: File -> New Soap Project:

Если при импорте возникает ошибка, дело скорее всего в авторизации: нужно ввести имя пользователя и пароль.

 

Забегая немного вперед, добавлю, что в SoapUI есть удобный способ сохранить данные авторизации: нужно заполнить параметры Username и Password  на вкладке Auth, которая станет доступна в редакторе запроса к сервису:

В дереве проекта появился веб-сервис CalculateService.

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

 

Шаг 2. Запускаем mock-сервис

Добавляем метод CalculateTraffic в новый мок-сервис: контекстное меню -> Generate Soap MOCK Service:

Задаем параметры MockService:

Обратите внимание на порт, на котором будет доступен сервис и на путь к нему.

Жмем ОК и заполняем имя мок-сервиса:

Открывается окно, из которого можно запустить мок-сервис и указать его настройки:

Зайдем в настройки и укажем, что мок будет подниматься на локальном интерфейсе localhost:

Жмем на Запуск. Если запуск пройдет успешно, станет доступна кнопка Открыть WSDL-схему в браузере:

Проверяем - должна открыться WSDL-схема по адресу http://localhost:8090/MockCalculateService?WSDL.

 

Теперь имеем:

  • реальный сервис на http://localhost/DEMO/ws/CalculateService.1cws?wsdl 
  • mock-реализацию на http://localhost:8090/MockCalculateService?WSDL

В дереве проекта появился мок-сервис MoskCalculateService с методом CalculateTraffic:

 

Шаг 3. Настраиваем ответ

Открываем редактор ответа Response 1. В этой форме можно определить данные, которые будет возвращать наш мок-сервис.

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

Я покажу простой вариант: получаем из входящего запроса значения параметров StoreID и Offset, сам запрос сохраняем на диск, а клиенту возвращаем значение, рассчитанное по формуле Offset*24 + StoreID:

Сохраняем проект командной Project -> Save project as на диск — этот файл нам понадобится дальше.

Я сохранил проект в d:\BASE1C\DEMO\MockCalculateService.xml

 

Запускаем проект SoapUI из консоли

Часть дела сделана — наш «заглушечный» веб-сервис запущен и к нему уже можно обращаться из 1С, но поскольку наша главная цель - автоматизировать его запуск, идем дальше.

Для того чтобы поднять мок-сервис из командной строки (а, следовательно, иметь возможность сделать это программным образом), нужно выполнить файл mockservicerunner.bat из директории C:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin.

Подробное описание параметров запуска mockservicerunner.bat можно найти на странице сайте SoapUI или в консоли:

Главный обязательный параметр — путь к xml-файлу с проектом из SoapUI. Программа считывает настройки проекта из файла и по умолчанию поднимает все мок-сервисы, которые в нем описаны.

Открываем консоль в папке c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\ и запускам наш сервис командной:

c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin>mockservicerunner.bat d:\BASE1C\DEMO\MockCalculateService.xml

В консоли наблюдаем, что MockService started on port 8090:

Подробный лог запуска записывается в c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\soapui.log, а ошибки можно найти в файлах soapui-errors.log и errors.log

 
 Если возникает ошибка ERROR [errorlog] java.lang.ClassNotFoundException

Проверим еще раз, что WSDL-схема доступна по адресу http://localhost:8090/MockCalculateService?WSDL.

Теперь мы умеем запускать заглушки с помощью командной строки. Пойдем дальше и попробуем прикрутить все это дело к Ванессе.

 

Подключаем Ванессу

Поскольку на Инфостарте уже есть замечательные статьи про тестирование и применение Ванессы на практике, сразу перехожу к делу.

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

 
 Обращение к веб-сервису из 1С

 

Определим примерный набросок сценария:

  1. Поднимаем сервис из файла;

  2. Проверяем, что сервис доступен;

  3. Заполняем параметры на форме обработки;

  4. Выполняем вызов процедуры, которая обращается к сервису;

  5. Проверяем результат расчета;

  6. Завершаем работу мок-сервиса.

Создадим файл ПроверкаСервиса.feature (я взял за основу одну из своих существующих фич) и загрузим его в Ванессу:

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

 

Подготовка данных

Пара слов о том, как будем хранить настройки для обращений к веб-сервисам. 

Полный путь к файлу mockservicerunner.bat записываем в константу ПутьКЗапускателюЗаглушекВебСервисов, а для описаний веб-сервисов добавим справочник ВебСервисы:

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

И добавлять новый элемент в справочник Веб-сервисы:

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

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

Чтобы создать данные для макета идем в Внешние инструменты -> Генератор макетов данных и в колонке «Данные для выгрузки» выбираем наш справочник ВебСервисы:

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

 

Запускаем моки

Для запуска моков нам нужно выполнить батник mockservicerunner.bat с параметром d:\BASE1C\DEMO\MockCalculateService.xml.

Посмотрим, можно ли это сделать стандартным шагом. Идем в Библиотеки -> Добавить известный шаг и поищем по строке «выполн»:

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

Можно было бы воспользоваться этим шагом, но, как говорится — есть нюансы.

Во-первых, придется каждый раз писать что-то вроде «Я запускаю команду 'c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\mockservicerunner.bat' с параметром «d:\BASE1C\DEMO\MyServiceProject.xml» — это длинно и неудобно.

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

Вот так реализован шаг Я запускаю команду в файле из поставки libraries\Плагины\step_definitions\Фича_УправлениеПриложениями.epf:

А вот реализация функции Выполнить команду ОС без показа черного окна в одной из главных обработок Ванессы bddRunner.epf:

Видно, что вызывается метод Run() объекта WScript.Shell и параметр ЖдатьОкончания вроде бы есть, но передать значения в него нельзя. Баг это или фича, честно говоря, я не понял :) Удобнее всего для запуска моков создать свой шаг, в котором можно принудительно указать параметр метода Run().

Реализуем шаг Я запускаю моки из файла:

 
Шаг «Я Запускаю моки из файла»
&НаКлиенте
Процедура ЯЗапускаюМокиИзФайла(Парам01) Экспорт
	
	ЯЗапускаюМокиИзФайлаНаСервере(Парам01)

КонецПроцедуры

&НаСервере
Процедура ЯЗапускаюМокиИзФайлаНаСервере(ФайлСОписаниемМокСервисов)

	ПутьКЗапускателю = Константы.ПутьКЗапускателюЗаглушекВебСервисов.Получить();

	Если НЕ ЗначениеЗаполнено(ПутьКЗапускателю) Тогда
		ВызватьИсключение "Не заполнена константа ПутьКЗапускателюЗаглушекВебСервисов";
	КонецЕсли;

	ТекстКоманды = """" + ПутьКЗапускателю + """" """" + ФайлСОписаниемМокСервисов + """";
	ИмяВременногоФайлаКоманды = ПолучитьИмяВременногоФайла("bat");
	ЗТ = Новый ЗаписьТекста(ИмяВременногоФайлаКоманды, КодировкаТекста.ANSI);
	ЗТ.Закрыть();
	ЗТ = Новый ЗаписьТекста(ИмяВременногоФайлаКоманды, КодировкаТекста.UTF8, , Истина);
	ЗТ.ЗаписатьСтроку("chcp 65001");
	ЗТ.ЗаписатьСтроку(ТекстКоманды);
	ЗТ.Закрыть();

	WshShell = Новый COMОбъект("WScript.Shell");
	Рез = WshShell.Run("""" + ИмяВременногоФайлаКоманды + """", 0, 0);
	WshShell = Неопределено;

КонецПроцедуры

 

Ожидание запуска моков

Чтобы понять, что мок-сервис поднялся корректно, нужно к нему обратится. Если он недоступен — подождать немного и попробовать обратиться еще — и так несколько раз. А если он и после 10-й попытки недоступен - значит, что-то пошло не так и тест провален.

Чтобы сделать цикличную проверку доступности сервисов, используем функцию ПодключитьОбработчикОжидания и функцию Ванессы ПродолжитьВыполнениеШагов:

 
Шаг "Я Ожидаю поднятия мок-сервиса"
&НаКлиенте
Процедура ЯОжидаюПоднятиеМок_сервиса(Парам01) Экспорт

	КонтекстСохраняемый.Вставить("МокСервис", Парам01);
	КонтекстСохраняемый.Вставить("НомерПопытки", 1);

	Ванесса.ЗапретитьВыполнениеШагов();

	ПодключитьОбработчикОжидания("ПроверитьДоступностьМокСервисов", 1);

КонецПроцедуры

&НаКлиенте
Процедура ПроверитьДоступностьМокСервисов() Экспорт

	ШагУпал = Ложь;

	Если КонтекстСохраняемый.НомерПопытки <= 10 Тогда

		КонтекстСохраняемый.НомерПопытки = КонтекстСохраняемый.НомерПопытки + 1;

		Если ВебСервисДоступенНаСервере(КонтекстСохраняемый.МокСервис) Тогда
			ОтключитьОбработчикОжидания("ПроверитьДоступностьМокСервисов");
			Ванесса.ПродолжитьВыполнениеШагов();
		КонецЕсли;

	Иначе

		ОтключитьОбработчикОжидания("ПроверитьДоступностьМокСервисов");
		ШагУпал = Истина;
		Ванесса.ПродолжитьВыполнениеШагов(ШагУпал);

	КонецЕсли;

КонецПроцедуры

 

Остановка мок-сервисов

После того как тестируемая программа выполнила обращение к мок-сервису, нужно остановить его работу.

При использовании графического интерфейса SoapUI все просто: для остановки мок-сервиса нужно на красную кнопку Stop the mock service.

При запуске через командную консоль тоже проблем нет — достаточно нажать сочетание клавиш Ctrl+C (или Ctrl+Z).

А в случае, когда мы запускаем процесс через WScript.Shell, все несколько сложнее —  штатного способа остановить выполнение его нет.

Например, вот вопрос в официальном сообществе SoapUI, который так и остался без ответа: Stop mock service using mockServiceRunner.

Вопрос достаточно распространенный и разработчики предлагают разные решения:

  1. Запоминать PID (идентификатор) процесса и «пристреливать» его после завершения теста. Пример для Linux: Sample script to start/stop soapui mockservicerunner with nohup 

  2. Сделать обертку над SoapUI, которая после запуска веб-сервиса будет пытаться прочитать внешний файл-флаг. Если файла нет — все ок, работаем дальше. Если файл появился — завершаем работу сервиса. Проект на гитхабе: Wrapper to start SoapUI MockService Runner

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

Пока в публичном доступе готового решения для Windows не найдено, остановимся на простом варианте — будем завершать работу процесса java.exe командой

 taskkill /FI "IMAGENAME eq java.exe"  /F 

это сработает, если больше нет запущенных процессов java.exe (точнее говоря, они все будут завершены в момент выполнения этой команды).

Или можно использовать более продвинутый вариант:

powershell (Get-WmiObject Win32_Process  -FILTER "Commandline like '%MyServiceProject.xml%'").Terminate()

скрипт завершит работы всех процессов, у которых в параметрах запуска есть название нашего файла с проектом: «MyServiceProject.xml».

Коллеги, если у кого есть более изящное решение, сообщите :)

 

Результат

Теперь мы можем составить полный текст нашего сценария «Расчет трафика»:

 
Полный текст фичи
#language: ru

Функционал: Расчет трафика

Как программист 1С
Я хочу проверить работу механизма расчета трафика
Чтобы убедиться, что доработки его не поломали

Контекст:

   Дано Я запускаю сценарий открытия TestClient или подключаю уже существующий
   И Я удаляю все элементы справочника "ВебСервисы"
   И Я устанавливаю значение константы "ПутьКЗапускателюЗаглушекВебСервисов" равным "c:\Program Files (x86)\SmartBear\SoapUI-5.5.0\bin\mockservicerunner.bat"
   И Я создаю fixtures по макету "ТестовоеОкружение"

Сценарий: Расчет трафика и выполнение расчетов
   Когда Я запускаю моки из файла "d:\BASE1C\DEMO\MockCalculateService.xml"
   И Я ожидаю поднятие мок-сервиса "MockCalculateService"
   Тогда В командном интерфейсе я выбираю 'Тестирование' 'Расчет трафика'
   Когда открылось окно 'Расчет траффка'
   И в поле 'ID' я ввожу текст '10'
   И в поле 'Store ID' я ввожу текст '5'
   И в поле 'Date' я ввожу текст '2019-02-01'
   И в поле 'Offset' я ввожу текст '2'
   И в поле 'Logistic ID' я ввожу текст '2'
   И в поле 'Main status' я ввожу текст 'true'
   И я нажимаю на кнопку 'Рассчитать'
   Тогда элемент формы с именем "Результат" стал равен '1 253'
   И я выполняю команду "taskkill" с параметрами '/FI "IMAGENAME eq java.exe" /F'
   И Я закрываю окно 'Расчет трафика'

 

 

Результатом работы служит пройденный без ошибок сценарий: 

 

Мы решили поставленную задачу в минимальном варианте, на основании которого можно реализовать уже более сложную логику.

92

См. также

Специальные предложения

Лучшие комментарии
1. Vladimir Litvinenko 1717 15.03.19 15:02 Сейчас в теме
Спасибо! Шикарная возможность SoapUI рассмотрена, да ещё и в связке с Ванессой.

SoapUI можно кстати хорошо в общий тестовый пайплайн встроить при тестировании в обратном направлении - проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С. Правда публикация отчетности возможна только в формате JUnit в то время как от Ванессы лучше получать отчетность в Allure.

На одном из этапов сборочной линии из командной строки можно вызывать выполнение тест-кейса или тест-сьюта вроде такого:

cd /D C:\Program Files\SmartBear\SoapUI-5.5.0\bin\.
cmd.exe /C testrunner.bat -s"<TestSuiteName>" -r -a -j -J -f"<JUnitOutputPath>" -I -i "<PathToSoapProjectXMLFile>"

А потом в пайплайне вызывать генерацию отчета из xml-файлов в формате JUnit. В результате выполнения пайплайна будем иметь два отчета. Один в виде JUnit о тестировании наших веб-сервисов, а другой Allure о выполнении дымовых и функциональных сценарных тестов. Например в Jenkins команда публикации выглядит так:

junit allowEmptyResults: true, testResults: '<JUnitOutputPath>/*.xml'


В целом при использовании Jenkins должно получиться что-то типа такого:
   stages {

        stage('Выполнение тестов SOAP') {

            steps {

                timestamps {

                     cmd "rmdir /S /Q JUnitResults"
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName1>\" -c\"<TestCaseName1>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\"" 
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName2>\" -c\"<TestCaseName2>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\""

                }             
            }
        }

        stage('Публикация отчета JUnit') {

            steps {

                timestamps {
                    junit allowEmptyResults: true, testResults: 'JUnitResults/*.xml'
                }
                
            }
        }

Показать


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


P.S.: К слову, есть большой полюс связки SoapUI и Jenkins. В обоих инструментах используется Groovy для создания скриптов и оба работают на JVM. Переключаться между контекстами легко.
CSiER; karnilaev; sergey_garin; fancy; ArchLord42; YPermitin; vikad; +7 Ответить
Остальные комментарии
Избранное Подписка Сортировка: Древо
1. Vladimir Litvinenko 1717 15.03.19 15:02 Сейчас в теме
Спасибо! Шикарная возможность SoapUI рассмотрена, да ещё и в связке с Ванессой.

SoapUI можно кстати хорошо в общий тестовый пайплайн встроить при тестировании в обратном направлении - проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С. Правда публикация отчетности возможна только в формате JUnit в то время как от Ванессы лучше получать отчетность в Allure.

На одном из этапов сборочной линии из командной строки можно вызывать выполнение тест-кейса или тест-сьюта вроде такого:

cd /D C:\Program Files\SmartBear\SoapUI-5.5.0\bin\.
cmd.exe /C testrunner.bat -s"<TestSuiteName>" -r -a -j -J -f"<JUnitOutputPath>" -I -i "<PathToSoapProjectXMLFile>"

А потом в пайплайне вызывать генерацию отчета из xml-файлов в формате JUnit. В результате выполнения пайплайна будем иметь два отчета. Один в виде JUnit о тестировании наших веб-сервисов, а другой Allure о выполнении дымовых и функциональных сценарных тестов. Например в Jenkins команда публикации выглядит так:

junit allowEmptyResults: true, testResults: '<JUnitOutputPath>/*.xml'


В целом при использовании Jenkins должно получиться что-то типа такого:
   stages {

        stage('Выполнение тестов SOAP') {

            steps {

                timestamps {

                     cmd "rmdir /S /Q JUnitResults"
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName1>\" -c\"<TestCaseName1>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\"" 
                     cmd "cmd.exe /C testrunner.bat -s\"<TestSuiteName2>\" -c\"<TestCaseName2>\" -r -j -J -fJUnitResults -I -S -i \"<PathToSoapProjectXMLFile>\""

                }             
            }
        }

        stage('Публикация отчета JUnit') {

            steps {

                timestamps {
                    junit allowEmptyResults: true, testResults: 'JUnitResults/*.xml'
                }
                
            }
        }

Показать


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


P.S.: К слову, есть большой полюс связки SoapUI и Jenkins. В обоих инструментах используется Groovy для создания скриптов и оба работают на JVM. Переключаться между контекстами легко.
CSiER; karnilaev; sergey_garin; fancy; ArchLord42; YPermitin; vikad; +7 Ответить
3. ArchLord42 68 15.03.19 18:03 Сейчас в теме
(1)
проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С


А почему бы не тестировать сервисы нативно?)
т.е. код выносим в модули, а там уже обычными тестами покрываем, имхо так гораздо удобней и быстрей выходит.

Вот пример с HTTP сервисом:

Есть метод "ОчередиExtGET" (см скрин)

Чтобы его покрыть тестом, надо всего навсего вызвать метод из модуля, где параметр метода "Запрос" будет обработкой, эмулирующий объект "HTTPСервисЗапрос"
Прикрепленные файлы:
4. Vladimir Litvinenko 1717 15.03.19 21:59 Сейчас в теме
(3) Если обычные тесты - это юнит-тесты на основе xUnitFor1C (теперь в составе Vanessa-ADD), то конечно можно и так. В этом случае не придётся изобретать свой формат отчетности и логов.

Удобно чтобы механизм позволял удобно отображать отчетность о результатах всех проверок в одном месте. Например на странице конкретной сборки в веб-интерфейсе CI-сервера, где фиксируются все этапы проверок и их результаты (артефакты и все отчёты). Так быстрее пройтись по цепочке от сообщения об ошибке к выявлению её причины. Да и в целом визуальная информация, собранная в одном месте, лучше воспринимается.

У SoapUI есть ещё такое преимущество как распространенность среди QA-инженеров веб-программистов. То есть созданными тест-кейсами можно будет поделиться с теми, кто наиболее вероятно будет писать и проверять клиентов для наших сервисов.

И ещё это внешний по отношению к тестируемой системе инструмент. Если мы хотим провести не только модульный, но интеграционный тест, убедиться в том, что сервис нормально публикуется и отвечает на внешние запросы, то в этом случае внешний инструмент даст более объективную информацию.
2. YPermitin 3029 15.03.19 15:22 Сейчас в теме
(0) Отличная статья!

Спасибо автору за труды!
5. Кадош 16.03.19 08:20 Сейчас в теме
6. vlad.frost 185 16.03.19 14:35 Сейчас в теме
Пока в публичном доступе готового решения для Windows не найдено, остановимся на простом варианте — будем завершать работу процесса java.exe командой

Долго мучался с этой проблемой. В итоге решил с помощью Jenkins: отдельным шагом пайплайна запускаю java-процесс с помощью команды START. Мок запускается в отдельном окне и по окончании работы пайплайна Jenkins его сам прибивает.
Scorpion4eg; karnilaev; sergey_garin; Vladimir Litvinenko; +4 Ответить
7. sergey_garin 172 18.03.19 08:48 Сейчас в теме
(6) Хорошая идея. Получается, в начале пайплайна поднять все моки, которые будут использоваться в тестах?
А всегда ли это будет удобно?
Например, на моем текущем проекте используется около 40 веб-сервисов: описания моков сохранены в отдельные файлы и про прогоне тестов моки по очереди поднимаются и опускаются (правда, немного не так, как описано в статье, но суть такая же). И получается, что во время прохождения отдельного сценария поднят только тот мок, который нужен сейчас.
11. kuzyara 754 26.06.19 04:43 Сейчас в теме
(6)
C:\soapui.net\bin>StandardConsoleApp.exe /?
start [/F Filepath] [/S Filepath] [/T:timeout]
/F                   Set XML SoapUI Project, by default using "project.xml" in root directory.
Filepath             Full filepath.
/S                   Set stop file if need to shut down server by file.
Filepath             Full filepath.
/T:timeout           Timeout in seconds if need to shut down server by timeout.

только тссс...
8. artbear 1133 21.03.19 12:14 Сейчас в теме
(0) Отличная статья, полезнейшие кейсы, детально расшифрованные.
9. artbear 1133 21.03.19 12:26 Сейчас в теме
(0) по поводу шага "Я выполняю команду "

А вот реализация функции Выполнить команду ОС без показа черного окна в одной из главных обработок Ванессы bddRunner.epf:


1 ты почему-то посмотрел код метода из модуля объекта bddRunner, который выполняется на толстом клиенте в обычных формах.
Это устаревший код :)

Если посмотришь код этого же метода из упр.формы bddRunner, ты увидишь там нормальный код

&НаКлиенте
Функция ВыполнитьКомандуОСБезПоказаЧерногоОкна(Знач ТекстКоманды, Знач ЖдатьОкончания = Истина,
	Знач ИспользоватьКодировкуТекстаUTF8 = Истина) Экспорт

	УправлениеПриложениями = Плагин("УправлениеПриложениями");
	Возврат УправлениеПриложениями.ВыполнитьКомандуОСБезПоказаЧерногоОкна(ТекстКоманды, ЖдатьОкончания,
		ИспользоватьКодировкуТекстаUTF8);

КонецФункции
Показать


в плагине "УправлениеПриложениями" передача параметров уже давно доработана.
и в т.ч. и для толстого клиента обычного приложения, и для сервера также :)

2 У шага "Я выполняю команду " свое назначение - он выполняет именно команду и ждет ее завершения.

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

Этот кейс возможно также решить с помощью плагина "УправлениеПриложениями"

- например, сделать доп.шаг - я запускаю процесс "какая строка запуска" на выполнение и сохраняю его идентификатор как переменную "ИдПроцесса"
- реализация шага проста.
- также можно сделать доп.шаг для запуска на сервере - я запускаю на сервере процесс "какая строка запуска" на выполнение и сохраняю его идентификатор как переменную "ИдПроцесса"
10. s_vidyakin 60 25.06.19 12:19 Сейчас в теме
Когда пробовал писать скрипты на SoapUI понял что проще развернуть тестовый веб-сервис на копии базы и написать обработку тестирования, чем тыкаться в бесполезную справку SoapUI и городить моки. Там нигде не описано как писать на Groovy в контексте вызовов и ответов, как передавать данные между несколькими вызовами и обрабатывать между вызовами. Только один абзац по передаче переменной между сессиями и всё. Где вы брали инфу по вот этому всему - "GroovyUtils(context)" и т.д?
Если веб-сервис внешний и у нас нет контроля бэкэнда то да, локальные моки это тема. А если есть под рукой база, то зачем?
12. berezdetsky 421 26.06.19 09:04 Сейчас в теме
(0) Если запускать процесс не через WScript.Shell, а через WMI - можно получать в ответ конкретный PID запущенного процесса.
Оставьте свое сообщение