0. sergey_garin 176 15.03.19 12:02 Сейчас в теме

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

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

Перейти к публикации

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


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

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

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

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

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

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

И ещё это внешний по отношению к тестируемой системе инструмент. Если мы хотим провести не только модульный, но интеграционный тест, убедиться в том, что сервис нормально публикуется и отвечает на внешние запросы, то в этом случае внешний инструмент даст более объективную информацию.
2. YPermitin 3336 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 176 18.03.19 08:48 Сейчас в теме
(6) Хорошая идея. Получается, в начале пайплайна поднять все моки, которые будут использоваться в тестах?
А всегда ли это будет удобно?
Например, на моем текущем проекте используется около 40 веб-сервисов: описания моков сохранены в отдельные файлы и про прогоне тестов моки по очереди поднимаются и опускаются (правда, немного не так, как описано в статье, но суть такая же). И получается, что во время прохождения отдельного сценария поднят только тот мок, который нужен сейчас.
11. kuzyara 775 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 1143 21.03.19 12:14 Сейчас в теме
(0) Отличная статья, полезнейшие кейсы, детально расшифрованные.
9. artbear 1143 21.03.19 12:26 Сейчас в теме
(0) по поводу шага "Я выполняю команду "

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


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

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

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

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

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


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

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

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

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

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

Вакансии

Бизнес-аналитик 1С
Москва
зарплата от 140 000 руб. до 200 000 руб.
Полный день

Консультант 1С (Бухгалтерия)
Санкт-Петербург
зарплата от 100 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Программист 1С
Тюмень
зарплата от 70 000 руб.
Полный день

Программист 1С
Москва
зарплата от 150 000 руб. до 150 000 руб.
Полный день