Варианты автоматического запуска сценариев

Запуск через CLI платформы 1С

Файл настроек запуска bddRunner.epf

Запуск через Vanessa-Runner

Файл настроек запуска Vanessa-Runner

 

Отчетность Allure

Установка Allure 2

Выгрузка результатов выполнения сценариев в формат Allure

Работа из консоли

Тренд (история) в отчете Allure

Создание скриншотов

Произвольные атачменты в отчетах: файлы, двоичные данные и ссылки

 

 

 

Мы уже рассмотрели  основы сценарного тестирования и BDD , разобрались как устанавливать и работать с необходимыми для этого инструментами, изучили сложные примеры сценарных тестов на основе типовой конфигурации "Управление торговлей 11" и даже научились создавать свои шаги, библиотеки и экспортные сценарии.  

 

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

Как и ранее, чтобы не перепечатывать примеры со скриншотов из публикации, Вам доступен репозиторий https://github.com/VladimirLitvinenko84/DevelopingAndTestingWithVanessa 

 

 

 

Варианты автоматического запуска сценариев

 

 

 

Запуск через CLI платформы 1С

 

Запуск консольной командой необходим для автоматизации выполнения сценарных тестов. Сформированную команду затем можно использовать в простейших планировщиках заданий (например в планировщике Windows) или встраивать её в сборочные линии серверов сборки (например Jenkins). Главное, чтобы механизм автозапуска позволял тест-клиенту взаимодействовать с рабочим столом операционной системы.

Как и любую другую внешнюю обработку bddRunner.epf можно открыть на выполнение используя ключ /Execute  командной строки 1С:Предприятия. Для этого у пользователя, под которым происходит запуск, также должна быть отключена защита от опасных действий. Как это сделать рассказано здесь: //infostart.ru/public/974944/#Необходимые_права 

 

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

"C:Program Files1cv88.3.14.1450in1cv8c.exe"  /TESTMANAGER /SHOST:1541ut_autotest  /Execute "C:Program Files (x86)OneScriptlibaddddRunner.epf" /N "Администратор" /P ""

 

Но такая строка всё ещё будет бесполезна, для запуска сценариев. Обработка bddRunner.epf будет открыта на выполнение и в неё будут загружены настройки, которые мы задавали в ней в последний раз (или настройки по умолчанию, если она ещё ни разу не запускалась), но она не будет знать, что делать дальше. Для того чтобы запустить на выполнение сценарии, нам потребуется файл настроек. И путь к этому файлу нужно будет передать обработке bddRunnr.epr через специальный параметр командной строки:

/C"StartFeaturePlayer;workspaceRoot=C:datafeatures;VBParams=C:datafeaturesddRunnerAutostartSettings.json"

 

Здесь ключ StartFeaturePlayer говорит, что сценарии необходимо загрузить для выполнения. Ключ workspaceRoot определяет каталог проекта. А ключ VBParams определяет путь к файлу с настройками запуска. Пример такого файла приведён ниже на скриншоте, а подробнее структура этого файла будет разобрана в следующем разделе публикации:

 

 

Все три приведённые выше ключа являются обязательными. Без задания ключа StartFeaturePlayer, настройки из файла, указанного в параметре VBParams вообще не будут прочитаны. Итоговая консольная команда для запуска будет выглядеть следующим образом:

"C:Program Files1cv88.3.14.1450in1cv8c.exe"  /TESTMANAGER /SHOST:1541ut_autotest  /Execute "C:Program Files (x86)OneScriptlibaddddRunner.epf" /N "Администратор" /P "" /C"StartFeaturePlayer;workspaceRoot=C:datafeatures;VBParams=C:datafeaturesddRunnerAutostartSettings.json"

 

Результат её выполнения будет следующим:

 

 

 

 

Файл настроек запуска bddRunner.epf

 

Итак, для запуска из консоли нам требуется создавать файл с настройками запуска и указывать его в консольной команде как VBParams=<Путь к json-файлу>.

Множество примеров таких json-файлов настроек для Vanessa-ADD можно найти здесь https://github.com/silverbulleters/add/tree/master/tools/JSON, а для Vanessa-Automation (возможна специфика этого фреймоврка) здесь https://github.com/Pr-Mex/vanessa-automation/tree/develop/tools/JSON   

Есть однозначное соответствие между большинством из этих параметров и настройками, задаваемыми на вкладке "Сервис" и вкладке "Библиотеки" в Vanessa-ADD:

 

 

 

Но возможности, предоставляемые файлом настроек и запуском из консоли всё же больше, чем предоставляют интерактивные настройки. Описание большинства из параметров также можно найти по приведённым выше ссылкам на репозитории github. Повторим здесь описание наиболее важных из них, и на их примере рассмотрим правила указания параметров в зависимости от их типа данных.

При указании значений значений, являющихся путями к каталогам, допустимо использовать шаблоны подстановки $workspaceRoot, вместо которого будет подставляться значение ключа командной строки workspaseRoot, и $instrumentsRoot — каталог установки Vanessa-ADD.

 

"КаталогФич": "$workspaceRoot/features"   — задаёт абсолютный или относительный путь к каталогу с файлами сценариев, которые будут открываться на исполнение. Это аналог интерактивного выполнения команды Загрузить фичи → Загрузить файлы из каталога. При использовании в путях обратных слешей их нужно экранировать, указывая вместо одного слэша два \

 

"КаталогиБиблиотек" — задаёт массив путей к библиотекам, которые после загрузки тест-менеджера также появятся на вкладке "Библиотеки". Массив в формате Json задаётся в квадратных скобках, элементы массива перечисляются через запятую.

 

"ВыполнитьСценарии" — булево. Задавать значение типа булево для bddRunner.epf можно как в виде литералов true / false, так и в виде строк "Истина" / "Ложь". Как уже было сказано выше, если мы хотим, чтобы сценарии после открытия bddRunner.epf загрузились на вкладку выполнения сценариев необходимо передавать в этот параметр Истину. Но также это приведёт к автоматическому старту выполнения сценариев после их загрузки.

 

"ЗакрытьTestClientПослеЗапускаСценариев" — булево. Определяет будет ли закрыто тестируемое приложение (тест-клиент), но не после запуска сценариев, как можно подумать исходя из названия параметра, а после выполнения всех сценариев.

"ЗавершитьРаботуСистемы" — булево. Определяет будет ли закрыт тест-менеджер после выполнения сценариев.

При автоматизации тестирования на сервере CI оба этих параметра "ЗакрытьTestClientПослеЗапускаСценариев" и "ЗавершитьРаботуСистемы" имеет смысл устанавливать в Истину. Ведь нам не нужно чтобы на сервере накапливались незакрытые сеансы 1С. Но например для случая отладки бывает смысл устанавливать эти параметры в Ложь, чтобы подключившись к серверу увидеть в каком состоянии находятся тест-менеджер и тест-клиент своими глазами.

 

"ДелатьСкриншотПриВозникновенииОшибки"  — булево. Определяет будет ли автоматически выполняться скриншот при возникновении ошибки. Крайне важный параметр для автоматизации тестирования. Без скриншота при возникновении ошибки мы будем иметь только тестовые логи выполнения сценариев и зачастую будет сложно или невозможно сразу понять в чём причина ошибки. Скриншоты часто позволяют экономить время и не прогонять повторно весь сценарий вручную, чтобы увидеть где возникла ошибка. Есть аналогичный параметр, который говорит о том, что нужно делать скриншот каждого окна. Но обычно в его установке нет необходимости и создание скриншотов каждого окна только замедлит выполнение сценариев.

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

"КаталогOutputСкриншоты": "$workspaceRoot/build/output/screenshots"  — определяет куда будут складываться скриншоты.

"КомандаСделатьСкриншот": ""C:\Program Files (x86)\IrfanView\i_view32.exe" /capture=1 /convert="  — определяет консольную команду для создания скриншотов.

Тему создания скриншотов мы разберём отдельно ниже, когда будем рассматривать отчетность Allure.

 

"ДелатьОтчетВФорматеАллюр" — булево. Определяет необходимость формировать данные, которые затем фреймворк Allure сможет "перварить" в красивый отчёт HTML.

"КаталогOutputAllureБазовый": "$workspaceRoot/build/output/allure/results-vb-testing" — задаёт каталог для выгрузки json-файлов, содержащих данные для фреймворка Allure из которых впоследствии можно формировать отчет в  HTML.

 

"ДелатьЛогВыполненияСценариевВТекстовыйФайл" — булево. Позволяет указать системе, что необходимо вести онлайн-лог выполнения сценариев в текстовый файл. Это бывает полезно, чтобы например отследить зависшие сценарии или просто понимать, на каком этапе находится процесс. Ниже будет рассмотрено использование этой настройки на примере запуска сценарного тестирования через Vanessa-Runner. Применение Vanessa-Runner позволит автоматически выводить содержимое этого файла в консоль.

"ИмяФайлаЛогВыполненияСценариев": "$workspaceRoot/build/vanessaonline_testing.txt"  — задаёт соответствующий файл для ведения лога.

 

Следующие параметры соответствуют настройкам "Список исключаемых тэгов" и "Тэгов для запуска" на вкладке "Сервис". Они задаются как массивы строк:

 "СписокТеговОтбор": ["СценариТолькоСЭтимиТегами", "БудутВыполняться"]

 "СписокТеговИсключение":[ "Подготовка", "Видео",  "Черновик",  "ВРазработке"  ]

 

 

 

 

 

Запуск через Vanessa-Runner

 

Как мы видели выше, ручное формирование параметров запуска является проблематичным. Нам необходимо при каждом запуске прописывать путь к платформе, путь к обработке bddRunner.epf и ключ /TESTMANAGER.

Для упрощения запуска платформы 1С:Предприятия и управления из консоли различными составляющими платформы существует удобный инструмент — Vanessa-Runner, который также как и Vanessa-ADD может устанавливаться как одна из библиотек OneScript. Этот инструмент предоставляет удобные возможности для управления кластером серверов 1С через службу администрирования RAS, управления хранилищем, компиляции/декомпиляции файлов конфигурации и внешних обработок,  команды для запуска платформы 1С в различных режимах и т.д.

 

Как и в случае с большинством библиотек OneScript установка Vanessa-Runner может быть выполнена менеджером пакетов opm через команду  opm install vanessa-runner:

 

Представление о возможностях Vanessa-Runner можно получить вызвав справку по перечню доступных команд через runner help  (синоним — vanessa-runner help) или справку по конкретной команде этой утилиты через runner help <имя_команды> (синоним vanessa-runner help  <имя_команды>) :

 

Среди этих команд есть две важные для тестирования прикладных решений:

 

Получим справку по команде runner vanessa:

 

Параметр —vanessasettings  заменяет параметр VBParams, который мы указывали при запуске bddRunner.epf из командной строки без применения Vanessa-Runner. Через него мы будем передавать путь к json-файлу настроек для запуска bddRunner.epf.

 

Доступен параметр —workspace, определяющий каталог проекта и заменяющий параметр workspaceRoot, который мы задавали при использовании CLI платформы 1С. Если параметр —workspace не задавать, то он всё равно будет явно передаваться в команду запуска платформы 1С, но при этом будет автоматически устанавливаться в значение текущего каталога:

 

 

Рассмотрим, что происходит при выполнении команды

runner vanessa —workspace "features" —vanessasettings "featuresddRunnerSettings.json" —ibconnection /SHOST:1541ut_autotest —db-user "Администратор" —db-pwd ""

 

Vanessa-Runner видит команду vanessa и понимает, что необходимо запустить Vanessa-ADD. Для этого она формирует нужную строку запуска платформы 1С и затем выполняет её:

1)  Она автоматически определяет путь к наиболее старшей версии платформы из установленных в системе и запускает платформу по этому пути. Этим поведением можно управлять через параметр —v8version.

2)  Также она автоматически подставляет путь ко внешней обработке bddRunner.epf. Если Vanessa-ADD установлена как библиотека OneScript в каталог OneScript/lib/add, то путь подставляемый по умолчанию подойдёт. Если же установка была произведена в другой каталог, то следует воспользоваться параметром —pathvanessa чтобы явно задать путь к bddRunner.epf.

3) Такие параметры как /TESTMANAGER , /DisableSturtupDialogs, /C"StartFeaturePlayer" подставляются в командную строку запуска платформы 1С автоматически.

4) Другие опции запуска получаются путем преобразования параметров Vanessa-Runner в параметры Vanessa-ADD или параметры тонкого клиента.

 

Параметр —additional — это то, что ранее мы передавали как значение параметра  /C. Так как для задания VBParams он нам больше не нужен, и ключ StartFeaturePlayer тоже подставляется автоматически, то в большинстве случаев запуска bddRunner.epf его не нужно будет указывать. Но при необходимости мы по прежнему можем передавать через него любые дополнительные параметры, например при использовании типовых конфигураций может оказаться удобен ключ "РежимОтладки".

Также рекомендую обратить внимание на параметр —v8version. Он позволяет автоматически подбирать заданную версию платформы, а не последнюю из доступных. Например, если в системе установлены 8.3.10.2466,  8.3.12.1529 и 8.3.14.1450, можно запустить версию 8.3.12.1529 вместо последней из доступных указав параметр —v8version 8.3.12

 

 

Крайне важной особенностью запуска Vanessa-ADD через Vanessa-Runner является возможность их взаимодействия через временный текстовый файл. Платформа 1С не умеет работать с потоками stdout и stderr (а значит и с cmd и ssh) в реальном времени. Чтобы узнать результат выполнения какой-либо операции нам приходится дожидаться её полного завершения. А Vanessa-Runner может получать информацию о ходе выполнения сценариев и/или дымовых тестов от Vanessa-ADD онлайн, не дожидаясь завершения тестирования. Это преимущество может показаться незначительным, до тех пор пока мы итак смотрим глазами на результат выполнения команд и на процесс работы тест-клиента и тест-менеджера. Но ценность вывода лога выполнения в stdout и stderr становится очевидна при запуске сценариев на CI-сервере, когда текстовый лог выполнения — это основа мониторинга состояния выполняемого приложения со стороны CI-сервера. 

 

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

"ДелатьЛогВыполненияСценариевВТекстовыйФайл": true,

"ИмяФайлаЛогВыполненияСценариев": "$workspaceRoot/vanessaonline.txt"

 

Посмотрим на процесс запуска и выполнения сценариев через Vanessa-Runner теперь. На протяжении всего хода выполнения сценариев мы видим прогресс и служебные сообщения в консоли:

 

 

 

 

 

 

Файл настроек запуска Vanessa-Runner

 

Помимо того, что утилита Vanessa-Runner может оперировать файлом с параметрами запуска Vanessa-ADD, она также может принимать свои собственные параметры в виде json-файла.  Это позволяет сократить длину консольной команды для запуска, что удобно, когда параметры командной строки при запуске меняются редко и при этом их достаточно много. А ведь это типичная ситуация в случае автоматического запуска сценарных и дымовых тестов.

Путь к этому файлу задаётся через специальный параметр —settings консольной команды runner (или её синонима vanessa-runner).

Файл позволяет задавать настройки по умолчанию в специальном блоке default. Для каждой отдельной команды Vanessa-Runner (таких как run, xunit, vanessa) могут быть заданы одноимённые блоки, где переопределяются настройки по умолчанию. То есть при выполнении конкретной команды берутся настройки по умолчанию, а затем дополняются и переопределяются настройками заданными для конкретной команды.

Возьмем например файл приведенный в репозитории на github:

https://github.com/silverbulleters/add/blob/38336a264557b235aabfa29e48345b880d08cecf/tools/JSON/vrunner.json

 

Согласно нему для всех команд кроме команд runner vanessa и runner xunit будет использоваться база данных по относительному пути build/ib. Но для команды runner xunit будет использоваться другая база из каталога build/ibservicexdd.

Для всех команд рабочим каталогом будет считаться текущий каталог. Но для команды runner vanessa рабочим каталогом (каталогом проекта) будет являться подкаталог features текущего каталога.

Таким образом преимуществом задания параметров в файле является не только сокращение консольных команд, но и возможность задать параметры сразу для многих команд Vanessa-Runner и использовать один файл для команд run, vanessa, xunit и так далее.

 

Поскольку сейчас мы планируем выполнять только команду runner vanessa, запускающую сценарное тестирование, то настройки можно задавать как в блоке default , так и в блоке vanessa и даже свободно перемещать между ними. На результат запуска это не повлияет. Но всё же правильно будет оставить параметр —vanessasettings в специфичном для команды runner vanessa блоке:

 

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

runner vanessa —settings featuresVanessaRrunnerSettings.json

 

Несмотря на удобную возможность задать все параметры Vanessa-Runner в одном файле, иногда имеет смысл вынести ряд параметров из этого файла обратно в командную строку. Например, когда мы не хотим хранить параметры авторизации в текстовых файлах. Особенно это важно в случае, если файлы с параметрами запуска находятся под версионным контролем git или другой VCS, ведь в этом случае даже удалив пароли из файлов их можно будет найти в истории репозитория.

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

 

 

 

 

 

 

 

Отчетность Allure

 

 

Наиболее популярным и простым способом визуализации результатов выполнения сценариев в Vanessa-ADD является представление этих результатов в виде отчетности Allure. Allure — это универсальный фреймворк, пригодный для визуализации результатов тестирования продуктов, созданных на любых платформах и любых языках. Для ознакомпления с его возможностями рекомендую две публикации на habr.com:

 

https://habr.com/ru/company/jugru/blog/337386

https://habr.com/ru/company/sberbank/blog/359302

 

Официальная объемная документация на английском языке доступна по следующей ссылке:

https://docs.qameta.io/allure

 

 

---

Пара замечаний перед чтением раздела:

1)   Для всех примеров, связанных с отчетностью Allure, использовалась версия Vanessa-ADD 5.6.0. В версии 5.7.0 есть проблемы, которые на данный момент устранены только в ветке develop. Если вы используете версию 5.7.0, то это должна быть версия из ветки develop.

2)   Каталог исходных данных для отчетов Allure в примерах ниже по старой памяти назвал xml_for_allure. Хотя правильно было бы назвать его json_for_allure, так как сейчас данные для Allure 2 формируются в формате json. Исправления не делаю чтобы не переснимать множество скриншотов.

3)   Allure — широко распространенный фреймворк для отображения результатов тестирования. Поэтому если у Вас возникнут вопросы "а что значит бомбочка в отчете?" или "как мне поставить плагин Allure для Jenkins?" не обязательно ждать ответа от 1С-ников. Хотя можно и ждать )) В сети много информации, содержащей ответы на эти и многие другие вопросы. На помощь придут не только форум https://xdd.silverbulleters.org или телеграм-канал https://t.me/testspro1c, но и https://stackoverflow.com и официальная документация и https://habr.com

---

 

Установка Allure 2

 

 

Для тех, кто не знаком с концепцией релизов Open Source проектов на github установка Allure может превратиться в настоящий квест )) Многие такие проекты не имеют официального сайта со специальным разделом для скачивания дистрибутива. В документации по Allure приводится инструкция по установке из командной строки используя установщик Scoop: https://docs.qameta.io/allure/#_installing_a_commandline

Но на самом деле всё можно сделать намного проще. У большинства Open Source проектов есть свой раздел на github.com. И, помимо возможностей загрузить исходный код и самостоятельно собрать из него исполняемые файлы или клонировать себе репозиторий, у многих проектов есть раздел с релизами, где можно скачать уже собранный и готовый для использования проект. Таким образом, например, можно скачать и релиз Vanessa-ADD 5.6.0, использовавшийся для демонстрации примеров из этого раздела: https://github.com/silverbulleters/add/releases

 

У фреймворка Allure есть два репозитория на github. Один для первой версии этого фреймворка https://github.com/allure-framework/allure1. Он устарел и использовать его не имеет смысла. Раздел с релизами для актуальной второй версии фреймворка доступен по ссылке:

https://github.com/allure-framework/allure2/releases

 

На этой странице есть ссылка для загрузки zip-архива с последней версией фреймворка, который подходит для операционной системы Windows.

 

 

После скачивания и распаковки этого архива полный путь к подкаталогу bin, где хранится исполняемый файл allure.bat, необходимо добавить в системную переменную PATH:

 

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

Если всё сделано правильно, то при определении из консоли месторасположения файла, отвечающего за команду allure, мы получим наш путь:

 

На этом установка Allure 2 закончена.

 

 

 

Выгрузка результатов выполнения сценариев в формат Allure

 

Общий алгоритм работы с Allure следующий:

• Внешняя по отношению к нему программа (в нашем случае это Vanessa-ADD) должна подготовить JSON-файлы со структурированными данными, пригодными к обработке фреймворком Allure. Эти файлы благодаря формату JSON являются чловекочитаемыми, однако понять их содержимое не намного проще, чем любые текстовые логи. Они не предназначены для анализа человеком. Располагаться эти файлы могут как в одном каталоге, так и в любом количестве разных каталогов.

• Фреймворку Allure посылается команда сгенерировать из JSON-файлов отчет в формате HTML. Входными данными для этой команды являются все каталоги с исходными JSON-файлами. Эти каталоги также могут содержать подкаталоги history, для того чтобы в HTML-отчете можно было видеть не только последние результаты, но и динамику выполнения. Выходными данными (результатом выполнения команды генерации отчета) является каталог с отчетом в формате HTML и необходимыми для его отображения файлами (картинками, js-скриптами и т.д).

Команда генерации может быть вызвана либо из консоли (allure generate) либо её можно доверить специализированным инструментам на сервере сборок.

• Результат генерации HTML можно либо сделать постоянно доступным, настроив веб-сервер (например Apache или IIS) на чтение каталога с результатами генерации HTML-отчета, либо открывать самостоятельно через встроенный во фреймворк Allure веб-сервер. Для второго варианта во фреймворке Allure предусмотрена специальная команда allure open.

 

В данной публикации мы не рассматриваем работу с Apache или Jenkins — это отдельная большая тема, которая потребовала бы публикации совсем другого объема. Поэтому сейчас мы будем пользоваться консольными командами, которые нам предоставляет сам фреймворк Allure, и стандартными возможностями, предоставляемыми Vanessa-ADD.

 

Посмотрим сначала на пример создания отчета применяя только графический интерфейс Vanessa-ADD. Для генерации отчета Allure на вкладке сервис предусмотрены следующие настройки:

1)  Флаг "Формировать данные для отчета Allure". Его установка приведёт к генерации JSON-файлов из которых затем можно сформировать отчет в виде HTML.

2)  Поле "Временный каталог файлов результатов Allure". Именно в этот каталог будут складываться файлы, хранящие результаты тестирования.

3)  Флаг "Отображать отчет Allure в браузере". Установка этого флага приведёт к тому, что Vanessa-ADD самостоятельно вызовет консольные команды формирования HTML-отчета из JSON-файлов и затем запустит встроенный в Allure веб-сервер для отображения этого HTML-отчета.

 

 

Намеренно внесём ошибку в любой из наших сценариев, чтобы в отчёте мы смогли увидеть хотя бы один упавший тест. И запустим выполнение сценариев с указанными выше настройками. После выполнения сценариев Vanessa-ADD самостоятельно выполняет консольную команду allure open и тем самым открывает сформированный отчет Allure. Успешно пройденные тесты выделяются зелёным. Упавшие — красным. Пропущенные в результате наличия нереализованных шагов — сиреневым. Перейдя в раздел Suites мы получаем возможность фильтровать результаты по статусам, например отключив отображение успешно выполненных сценариев.

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

 

 

 

 

 

Работа из консоли

 

Выше мы видели, что для любой настройки, выполняемой через графический интерфейс Vanessa-ADD, есть соответствующая настройка, которую можно указать в json-файле для запуска из консоли. В разделе, посвященном файлу настроек запуска bddRunner.epf, уже были рассмотрены настройки, необходимые для формирования отчетности Allure. Добавим теперь их в наш файл:

 

 

Файл настроек для Vanessa-Runner не нуждается в изменениях. Он по прежнему должен ссылаться на файл настроек для bddRunner.epf в параметре —vanessasettings:

 

 

В результате выполнения команды runner —settings VanessaRunnerSettings.json не будет автоматически открыт HTML-отчет. Но мы получим данные для его формирования в заданном каталоге:

 

 

Сформированные json-файлы выглядят следующим образом:

 

 

То, что отчет HTML не генерируется сразу при работе из консоли, это преимущество, а не недостаток. Потому что перед его формированием можно выполнить много различных тестов, например дымовые, сценарные тесты под разными пользователями или в разных базах. Разместить результаты в разных каталогах. И только потом подать все эти каталоги на вход команды allure generate, которая сформирует консолидированный HTML-отчет для всех результатов. Это особенно удобно при автоматизации процесса тестирования на сервере сборок.

 

Для формирования отчета из исходных json-файлов необходимо выполнить команду

allure generate <исходный каталог 1> <исходный каталог 2> ….    -o  <каталог для html-отчета>

 

При этом если в каталоге для html-отчета уже есть файлы, то эта команда выдаст ошибку, предупредив о необходимости использовать ключ -c или —clean для предварительной очистки каталога. Чтобы не чистить каталог самостоятельно задействуем и этот ключ.

Сформированный HTML-отчет затем можно попытаться открыть в браузере самостоятельно. В Mozilla Firefox это сделать получится. Но например Google Chrome не отобразит большую часть данных из-за настроек безопасности. Универсальным способом открыть отчет является запуск web-сервера и открытие отчета через него. Allure имеет простейший встроенный веб-сервер. Запустить этот сервер и сразу же открыть отчет можно всего одной командой:

allure open <каталок с html-отчетом>

 

Нужно понимать, что это "локальная" команда, которая меняет порт веб-сервера при каждом запуске. Она не подходит для того, чтобы обеспечить постоянную доступность отчета с других компьютеров. Для постоянной доступности и обновления результатов тестирования лучше настроить Apache или IIS на работу с каталогом, содержащим HTML-отчет и с отключенным кэшированием (чтобы результаты действительно были актуальны и обновлялись при перезагрузки страницы с отчетом).

 

Итак, сейчас нам потребуются две команды:

           allure generate —clean C:dataallurexml_for_allure -o C:dataallurehtml_report

           allure open C:dataallurehtml_report

 

Выполнив их получим следующий результат:

 

 

 

 

 

Тренд (история) в отчете Allure

 

 

Тренд — это отдельный блок в отчетности Allure, отображающий историю выполнения тестов. Сейчас, сколько бы мы не выполняли генерацию отчетности, блок с трендом будет пуст:

 

Файлы, необходимые для заполнения этого блока, создаются при генерации html-отчета. Allure сохраняет в специальном подкаталоге history в каталоге с HTML-отчетом:

 

 

Если эти файлы будут содержать информацию только о текущем прогоне тестов, то информация из них не будет транслироваться в блок Trend отчета. Для того, чтобы эти файлы пополнялись историческими данными, их необходимо переносить их каталога с html-отчетом в каталог с исходными данными для формирования отчетов. Если таких каталогов несколько, то можно переместить history в любой из этих исходных каталогов. Главное чтобы каталог history было только в одном из них, иначе возможны ошибки.

 

То есть, прежде чем очищать каталог с HTML-отчетом вручную или через allure generate с ключем —clean, нам необходимо забирать каталог history из него и перемещать его в один из каталогов, который мы будем подавать на вход команде allure generate:

 

Теперь выполнив сценарии ещё раз и сформировав отчет мы увидим заполненный блок Trend:

 

 

 

 

 

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

 

 

Очистим каталог с json-файлами и ранее сохраненной историей, являющийся входящим для команды allure generate:

 

Возьмём последнюю актуальную историю из каталога с HTML-отчетом:

 

 

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

 

 

Выполним команды

vanessa-runner vanessa —settings featuresVanessaRrunnerSettings.json

allure generate —clean allurexml_for_allure -o allurehtml_report

allure open allurehtml_report

 

Теперь мы видим, что тренд отображает динамику по результатам последних трёх прогонов тестов:

 

 

Здесь стоит повторить то, что уже было написано в первой публикации этого цикла. Тренд — это одна из самых эффектных визуализаций Allure. Но на практике далеко не самая полезная из них.

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

 

 

 

В этом случае гораздо большую пользу будут приносить фильтры по статусам в разделе Suites:

 

 

 

 

Плагины Allure для серверов сборок дают больше преимуществ. Например в случае с Jenkins блок Trend хорош тем, что содержит не только график с историей, но и позволяет переходить к соответствующим версиям отчетов:

 

 

Также при применении таких инструментов, как Jenkins, тренд формируется проще. Больше не нужно вручную или отдельными консольными командами выполнять очистку каталога с HTML-отчетом и перенос каталога history из него. Все эти действия выполняются автоматически всего одной командой. Команда для Jenkins, которая выполняет все необходимые действия, может выглядеть следующим образом:

 

 

 

 

 

 

Создание скриншотов

 

 

В рассмотренных выше примерах отчетности сценарии, которые были выполнены с ошибками, выделялись красным цветом.

 

В расшифровке мы также могли увидеть, на каком шаге произошла ошибка:

 

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

 

Например мы забыли указать цену в заказе клиента и потом попытались провести его, ожидая что вместо окна документа "Заказ клиента" откроется другое окно  (например ранее открытая форма списков заказов). В этом случае отчет о выполнении сценария сообщит нам, что ошибка зафиксирована на шаге, проверяющем, что открыта форма списка заказов. Но настоящая причина в том, что не было закрыто окно нового заказа при его проведении. При этом даже саму кнопку "Провести и закрыть" в тест-клиенте нажать удалось. А окно в свою очередь не закрылось из-за ошибок в заполнении документа и появления ошибки уже после нажатия на кнопку "Провести и закрыть".

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

 

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

Для создания скриншотов Vanessa-ADD использует внешние инструменты. Для этого она может взаимодействовать с двумя приложениями: Nircmd или IrfanView. Команды, которые необходимо использовать как для Nircmd, так и для InfranView описаны в F.A.Q. по фреймворку:

 

https://github.com/silverbulleters/add/blob/fbda12379141e7e6beeda05cb4f8ebd86b9b0f77/F.A.Q.MD

 

 

Настроим снятие скриншотов на примере Nircmd.  Загрузить 32-битную утилиту можно с официального сайта http://www.nirsoft.net/utils/nircmd.html  по ссылке http://www.nirsoft.net/utils/nircmd.zip

Подобно тому, как мы делали с фреймворком Allure, добавим путь к утилите в переменную PATH и убедимся, что система её находит выполнив команду where nircmd:

 

 

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

 

 

Указать необходимость делать скриншот и команду для его снятия можно в графическом интерфейсе Vanessa-ADD. Но мы уже хорошо умеем работать с консолью )) Поэтому сразу перейдём к конфигурационному файлу и добавим в него необходимые для этого строки:

 

 

Выполним команду  vanessa-runner vanessa —settings featuresVanessaRrunnerSettings.json

Результатом будут скриншоты окон, снятые в момент возникновения ошибок. И часть файлов, содержащих исходные данные для генерации HTML-отчета, будут ссылаться на эти скриншоты:

 

 

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

 

 

Важно! При автоматизации выполнения сценариев на серверах сборок необходимо обеспечить возможность взаимодействия исполняющей службы (узла сервера сборок) с графической подсистемой операционной системы. Иначе про скриншоты можно будет забыть и вместо них мы будем видеть чёрные квадраты и прямоугольники. Добиться взамодействия этого можно по разному. В случае применения Jenkins одним из простейших способов является интерактивный запуск узла-сборщика и следование инструкции https://support.smartbear.com/testcomplete/docs/testing-with/running/via-rdp/keeping-computer-unlocked.html. Но есть и другие способы вплоть до замыкания двух сеансов RDP друг на друга, применения VNC и прочие технические хитрости.

 

Пример обсуждения, в котором рассматривались различные подходы можно прочитать здесь: https://t.me/testspro1c/2617

 

 

 

 

Произвольные атачменты в отчетах: файлы, двоичные данные и ссылки

 

 

Итак, мы научились прикреплять скриншот об ошибке к нашему отчету Allure. А что если мы хотим прикрепить данные не только к ошибочному шагу? Что если мы хотим прикрепить произвольные данные после выполнения произвольного шага? Думаю что полезность этих возможностей не вызывает сомнения. Так как же сделать это?

 

Здесь нам вновь поможет информация о внутреннем устройстве Vanessa-ADD. За работу с отчетом Allure отвечает плагин  addpluginsАллюр2Отчет.epf. Если открыть модуль формы этой обработки, то в нем можно обнаружить два нужных нам метода:

 

Методы похожи. Оба из них прикрепляют двоичные данные к отчету Allure сохраняя их в файл. Но метод ДобавитьФайлКТекущемуШагу получает эти двоичные данные из заданного файла, а не берёт произвольные.

 

Попробуем подключить с помощью них к шагу текстовый файл.

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

 

Он действительно сработает, и похожий шаг понадобится нам дальше, когда мы будем прикреплять графический файл. Но сейчас есть способ проще. Если из конфигуратора мы выполним поиск модулей в каталоге с библиотечными шагами OneScriptlibaddfeatureslibraries, содержащих текст "ДобавитьФайлКТекущемуШагу",  то сможем найти обработку setlabelsallure.epf, содержащую такие замечательные шаги как

 

И Я подключаю файл ‘$workspaceRoot/fixtures/file.xls’ к шагу ‘id’

и

И Я устанавливаю ссылку ‘http://test/issue’ с именем ‘SUP-222’"

 

Если взглянуть на методы, реализующие эти шаги

 

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

 

И Я подключаю файл ‘$workspaceRoot/fixtures/file.xls’ к шагу

 

 

Причина таких сложностей в поиске этих шагов заключается в том, что при объявлении этих шагов не заполнены последние параметры метода Ванесса.ДобавитьШагВМассивТестов. Из публикации по созданию собственных шагов //infostart.ru/public/992320 мы знаем, что это ведёт к невозможности увидеть их в форме выбора библиотечных шагов. Тем не менее, полученная информация о внутреннем устройстве этих шагов и реализующих их методов поможет нам дальше:

 

Несколько примеров применения этих и похожих библиотечных шагов можно найти в фича-файле, описывающем функционал обработки setlabelsallure.epf  

https://github.com/silverbulleters/add/blob/master/features/libraries/manually/setlabelsallure.feature :

 

 

Итак, задействуем в нашем сценарии эти два шага. Один будет добавлять ссылку к логу выполнения сценария, а другой — прикреплять файл к шагу:

И Я подключаю файл ‘$workspaceRoot/allure/ПроизвольныйФайл.txt’ к шагу

И Я устанавливаю ссылку "//infostart.ru/public/1010127" с именем "Публикация с секретными возможностями Vanessa-ADD"

 

 

Загрузим один этот сценарий в bddRunner.epf и убедимся, что шаги корректно связались с реализующими их обработками:

 

 

Запустим наши команды по выполнению сценариев, генерации и открытию отчета Allure:

vanessa-runner vanessa —settings featuresVanessaRrunnerSettings.json

allure generate —clean allurexml_for_allure -o allurehtml_report

allure open allurehtml_report

 

Теперь можно увидеть, что нам стал доступен раздел Links, где есть нужная нам ссылка:

 

 

Также в отчете о выполнении сценариев появился новый шаг с прикрепленным к нему файлом. Файл фигурирует как параметр шага, который можно развернуть и сразу увидеть содержимое файла. Для того, чтобы содержимое файла можно было просмотреть прямо в отчете Allure, а не просто скачав его по ссылке, текстовое содержимое файла должно быть в  кодировке UTF-8. Если кодировка будет другой, то русские буквы будут отображаться некорректно и для просмотра файла его придется предварительно скачать нажав значок дискеты:

 

 

Прикрепить к шагу можно не только файл с текстовым содержимым (txt, json, xml) , но и например бинарный файл или картинку :

 

Существующий шаг встроенной библиотеки, как мы видели из кода реализующего его метода, определяет тип файла для отчета Allure исходя из его расширения. Но тип "jpg" не является валидным для Allure. Получив тип "jpg" фреймворк не в состоянии понять, что этот файл следует отобразить не как бинарные данные, а как изображение:

 

 

 

Чтобы передать правильный тип такого файла можно написать собственный шаг по образцу типового. Но можно воспользоваться и шагом исполнения произвольного кода. Передадим в метод ДобавитьФайлКТекущемуШагу описание типа, которое Allure сможет корректно обработать:

    И затем я выполняю код встроенного языка

|' ПутьКФайлу = "C:dataallureПроизвольныйГрафическийФайл.jpg";    '|

|' ПлагинАллюра = Ванесса.Плагин("Аллюр2Отчет");                     '|

|' ПлагинАллюра.ДобавитьФайлКТекущемуШагу(ПутьКФайлу, "image/jpeg"); '|

   

 

Снова выполнив сценарии и сгенерировав отчет, мы увидим, что теперь  Allure корректно отображает подключенное изображение:

 

 

 

 

 

Что дальше?

 

На этом цикл публикаций, посвященных сценарному тестированию и BDD заканчивается. Но возможности Vanessa-ADD и параллельного проекта Vanessa-Automation не ограничиваются тем, что мы рассмотрели в этих пяти публикациях.

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

• Возможности автоматической генерации инструкций в HTML и видео-инструкций.
• Возможность подключить SikuliX для выхода за пределы платформы 1С, для чего будет достаточно шагов встроенной библиотеки.
• Дымовое тестирование с помощью вошедшего в состав фреймворка xUnitFor1C.
• Разработка сборочной линии на Jenkins, Gitlab CI или другом сервере сборок, ведь автоматизация тестирования и CI/CD идут рука об руку.
• Возможность поучаствовать в развитии фреймворков и утилит. Проекты являются открытыми для контрибьютинга и Вы можете принять участие в их разработке или тестировании.
• И ещё многое другое.

 

Для того, чтобы быть в курсе последних событий и новых возможностей фреймворков рекомендую присоединиться к каналам в Telegram:

https://t.me/testspro1c 

https://t.me/silvernation

Ну и если вы прочитали все публикации и дошли до сюда, то уверен Вы знаете, что делать дальше ))  Конечно, плюсовать публикацию и делиться ссылкой на неё с коллегами! А уже потом….