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

15.03.19

Интеграция - WEB-интеграция

Разбираемся, что такое 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'
   И Я закрываю окно 'Расчет трафика'

 

 

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

 

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

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

См. также

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

Сайты и интернет-магазины WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме. Без существенных изменений типовой конфигурации. Проверено с брендами: Интеграция 1С и GEELY Интеграция 1С и HAVAL Интеграция 1С и KIA Интеграция 1С и FORD Интеграция 1С и LADA ГАРАНТИЯ 100% ВНЕДРЕНИЯ!

36000 руб.

03.08.2020    15729    10    17    

11

Интеграция 1С — Битрикс24. Обмен задачами

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс24. Разработка имеет двухстороннюю синхронизацию 1С и Битрикс24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (8.3.18.1289). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    17545    6    15    

13

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16354    42    49    

23

[Расширение] БОР-Навигатор.Культура

Зарплата Бюджетный учет WEB-интеграция Обмен с ГосИС Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Расширение конфигурации, включающее в себя объекты, необходимые для подготовки и сдачи отчета "Штатная численность" системы "БОР-Навигатор.Культура" в программе "1С:Зарплата и кадры государственного учреждения", редакция 3.1.

8400 руб.

01.02.2019    25736    9    0    

7

Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС

Обмен с ГосИС WEB-интеграция Платформа 1С v8.3 Управляемые формы 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия государственного учреждения 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Обработка является альтернативой механизму, разработанному фирмой 1С и заполняющему реквизиты контрагента по ИНН или наименованию. Не требуется действующей подписки ИТС. Вызывается как внешняя дополнительная обработка, т.е. используется, непосредственно, из карточки контрагента. Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС (egrul.nalog.ru) для БП 2.0, БП 3.0, БГУ 1.0, БГУ 2.0, УТ 10.3, УТ 11.x, КА 1.1, КА 2.x, УПП 1.x, ERP 2.x, УНФ 1.5, УНФ 1.6, УНФ 3.0, ДО 2.1

2400 руб.

28.04.2016    88576    160    215    

318
Отзывы
1. Vladimir Litvinenko 2869 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 2869 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 83 15.03.19 18:03 Сейчас в теме
(1)
проверке работоспособности SOAP- или HTTP-сервисов опубликованных из 1С


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

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

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

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

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

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

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

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

Долго мучался с этой проблемой. В итоге решил с помощью Jenkins: отдельным шагом пайплайна запускаю java-процесс с помощью команды START. Мок запускается в отдельном окне и по окончании работы пайплайна Jenkins его сам прибивает.
Scorpion4eg; karnilaev; sergey_garin; Vladimir Litvinenko; +4 Ответить
7. sergey_garin 202 18.03.19 08:48 Сейчас в теме
(6) Хорошая идея. Получается, в начале пайплайна поднять все моки, которые будут использоваться в тестах?
А всегда ли это будет удобно?
Например, на моем текущем проекте используется около 40 веб-сервисов: описания моков сохранены в отдельные файлы и про прогоне тестов моки по очереди поднимаются и опускаются (правда, немного не так, как описано в статье, но суть такая же). И получается, что во время прохождения отдельного сценария поднят только тот мок, который нужен сейчас.
11. kuzyara 1900 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 1448 21.03.19 12:14 Сейчас в теме
(0) Отличная статья, полезнейшие кейсы, детально расшифрованные.
9. artbear 1448 21.03.19 12:26 Сейчас в теме
(0) по поводу шага "Я выполняю команду "

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


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

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

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

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

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


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

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

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

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

- например, сделать доп.шаг - я запускаю процесс "какая строка запуска" на выполнение и сохраняю его идентификатор как переменную "ИдПроцесса"
- реализация шага проста.
- также можно сделать доп.шаг для запуска на сервере - я запускаю на сервере процесс "какая строка запуска" на выполнение и сохраняю его идентификатор как переменную "ИдПроцесса"
10. s_vidyakin 63 25.06.19 12:19 Сейчас в теме
Когда пробовал писать скрипты на SoapUI понял что проще развернуть тестовый веб-сервис на копии базы и написать обработку тестирования, чем тыкаться в бесполезную справку SoapUI и городить моки. Там нигде не описано как писать на Groovy в контексте вызовов и ответов, как передавать данные между несколькими вызовами и обрабатывать между вызовами. Только один абзац по передаче переменной между сессиями и всё. Где вы брали инфу по вот этому всему - "GroovyUtils(context)" и т.д?
Если веб-сервис внешний и у нас нет контроля бэкэнда то да, локальные моки это тема. А если есть под рукой база, то зачем?
12. berezdetsky 620 26.06.19 09:04 Сейчас в теме
(0) Если запускать процесс не через WScript.Shell, а через WMI - можно получать в ответ конкретный PID запущенного процесса.
13. Arm12 08.10.19 16:20 Сейчас в теме
Подскажите а можно ли использовать защищенное соединение OpenSSL для обращения к сервису SoapUI ???
14. Flok 2 18.08.21 00:06 Сейчас в теме
Огромное спасибо за Статью !
Оставьте свое сообщение