Перейти к содержанию

Vanessa Automation

GitHub release Build Status GitHub Releases GitHub All Releases telegram

BDD for 1С:Enterprise

Документация

Также можно посмотреть

Статьи по Vanessa Automation

СППР + Vanessa Automation

Внешняя компонента VanessaExt

Видео материалы

Курсы

Как стать контрибьютором (предложить свои доработки) проекта?

Рекомендуемая концепция написания тестовых сценариев

  1. Надо разделять тестирование форм и тестирование движений документов.
  2. Для тестирования движений лучше использовать так называемые "цепочки документов".
    • Документы заранее созданы в эталонной базе и они непроведены
    • Сценарий проводит документы, распроводит документы программно, без открытия формы.
    • После окончания выполнения сценарий распроводит все документы и тем самым приводит базы в эталонное состояние.
    • Результат проведения проверяется программно с помощью заранее сохраненных вариантов отчетов.
    • Пример Gherkin И я отменяю проведение всех документов этого сценария по их навигационным ссылкам (расширение) И я выполняю проведение документа по навигационной ссылке "e1cib/data/Документ.ПриобретениеТоваровУслуг?ref=a4224cedfb3d3b3611ee20bd70c73364" (расширение) И я выполняю проведение документа по навигационной ссылке "e1cib/data/Документ.ЗаказКлиента?ref=a4224cedfb3d3b3611ee20bd70c7334f" (расширение) И вариант отчета "ОстаткиИДоступностьТоваров" "Остатки и доступность товаров" равен макету "ЭталонноеЗначениеОтчета" (расширение) И я отменяю проведение всех документов этого сценария по их навигационным ссылкам (расширение)
  3. При тестировании форм нужно максимально использовать возможность "накликивать" сценарий.
  4. Там где это возможно надо использовать подсценарии, что уменшить количство дублирования строк в сценариях тестирования.

Сборка из исходников

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

  1. Чтобы работала сборка epf надо установить OneScript версии 1.4.0.177 или выше.
  2. Также, чтобы работала сборка и разборка epf надо установить платформу 1С:Предприятие 8.3.17.
  3. Для запуска сборки epf из исходников надо запустить Compile.bat.
  4. Скрипты по сборке/разборке файлов.

Если вы дорабатываете Vanessa Automation и хотите зафиксировать изменения epf файлов, нужно запустить Decompile.bat.

Установка через OneScript

Для обычной сборки

  • Для текущей мажорной версии (например 1.2.041.1)
opm install vanessa-automation
  • Для текущей релизной версии (например 1.2.041.22)
opm install vanessa-automation@SNAPSHOT

Для сборки VASingle.

  • Для текущей мажорной версии (например 1.2.041.1)
opm install vanessa-automation-single
  • Для текущей релизной версии (например 1.2.041.22)
opm install vanessa-automation-single@SNAPSHOT

VASingle отличается от обычной сборки тем, что поставляется в виде одного epf файла, который по функциональности полностью совпадает с основной сборкой.

Описание простого использования

  • Feature файлы пишутся на языке Turbo Gherkin - рекомендуется использовать встренный редактор (VAEditor), созданный на базе VSCode.
# encoding: utf-8
# language: ru

Функционал: Запуск и получение результатов запуска сценариев
Как любой разработчик продукта
Я хочу иметь возможность запустить проверку сценариев поведения на конфигурации 1С:Предприятие

# Контекст сценария выполняется всегда перед каждым сценарием

Контекст:
    Когда существует разрабатываемая мною конфигурация 1С
    И существуют требования заказчика к ожидаемому поведения в каталоге ".\features"

# Каждый сценарий состоит из последовательных связанных шагов

Сценарий: Запуск в интерактивном режиме
    Дано я открыл обработку "vanessa-automation.epf"
    Когда я нажал кнопку "Загрузить фичи из каталога"
    И указал каталог с требованиями заказчика равным ".\features"
    И затем нажал кнопку "Сгенерировать шаблоны обработок"
    Также в каталоге ".\features" возникли epf файлы идентичные имени feature файла
    И при нажатии кнопки "Запустить сценарии" я вижу автоматизированный запуск обработок с признаком "pending" (ожидает реализации)

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

Фактически данный вариант использования представляет собой следующий порядок действий:

  • зафиксировали требования к информационной системе;
  • создали автоматизированные сценарии проверки в виде epf файлов, если не хватает уже готовых;
  • наполнили шаги сценариев (сниппеты) кодом проверки поведения;
  • запустили сценарии проверки поведения и убедились, что они НЕ работают;
  • разработали функционал;
  • запустили сценарии проверки поведения;
  • убедились что сценарии проверки работают и отчет о проверки показывает "Зелёный" статус.

Использование в режиме проверки поведения пользовательского интерфейса

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

  • зафиксировали требования к информационной системе;
  • разработали управляемые формы или рабочие столы конфигурации в режиме прототипирования;
  • запустили запись интерактивных действий пользователя в режиме менеджера тестирования;
  • дополнили сценарии шагами, проверяющими результат работы (например, проверка движений документа)
  • разработали основной функционал;
  • запустили сценарии проверки поведения;
  • убедились что сценарии проверки работают и отчет о проверки показывает "Зелёный" статус.

Кто пишет feature файлы ?

Feature файлы могут писать все участники команды:

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

Если вы не уверены в правильности ожидаемого поведения, используйте для этого системы тэгов:

  • "@Draft@" - черновик требования
  • "@Предварительно" - начальные заметки

и подобные им обозначения

Файл профиля запуска обработки

Для запуска в консольном режиме используется понятие профиль консольного запуска. Профиль консольного запуска предназначен для удобной передачи параметров. Профиль запуска представляет собой текстовый файл в формате VAParams.json.

Текущие параметры запуска:

  • Каталог фич - каталог где собраны требования заказчика описанные на языке Gherkin
  • ВыполнитьСценарии - признак того, что необходимо запустить выполнение сценариев
  • ДелатьОтчетВФорматеАллюр - признак того, что необходимо формировать HTML отчёт о результатах проверки
  • КаталогOutputAllureБазовый - адрес каталога для где будет формироваться HTML отчёт
  • ЗавершитьРаботуСистемы - признак того, что окончанию работы необходимо завершить работу 1С предприятия
  • ВыгружатьСтатусВыполненияСценариевВФайл - признак, что необходимо формировать файл с финальным статусом проверки
  • ПутьКФайлуДляВыгрузкиСтатусаВыполненияСценариев - по данному пути будет сформирован файл со статусом проверки (обычно используется на серверах сборки для автоматизированного указания статуса сборки)
  • СписокТеговИсключение - массив текстовых тэгов, для исключения из проверки (используется например для черновиков сценариев и требований)
  • СписокТеговОтбор - массив текстовых тэгов для запуска проверки поведения по сценариям, содержащим любой из указанных тэгов
  • и другие

Подробно про запуск Vanessa Automation из командной строки Примеры JSON файлов Описание всех параметров VAParams.json (ru) Описание всех параметров VAParams.json (en) Параметры, которые раньше можно было передавать только в командной строке, но теперь можно передавать в файле VAParams.json

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

%V83PATH% /Execute C:\vanessa-automation\vanessa-automation.epf /TESTMANAGER /C"StartFeaturePlayer;VAParams=C:\VAParams.json"

Описание всех параметров командной строки можно найти тут

Загрузка глобальных переменных из внешнего файла

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

Чтобы воспользоваться этой функциональности, нужно выполнить следующее:

  1. У себя в каталоге с обработкой ванессы создать файл user_settings.json. Сам файл user_settings.json должен отвечать специальному формату:
{
    "userSettings": [
        {
            "user": "USERNAME_1",
            "settings": {
                "ИМЯ_ПЕРЕМЕННОЙ_1": "ЗНАЧЕНИЕ_ПЕРЕМЕННОЙ_1",
                "ИМЯ_ПЕРЕМЕННОЙ_2": "ЗНАЧЕНИЕ_ПЕРЕМЕННОЙ_2",
            }
        },
        {
            "user": "USERNAME_2",
            "settings": {
                "ИМЯ_ПЕРЕМЕННОЙ_1": "ЗНАЧЕНИЕ_ПЕРЕМЕННОЙ_1",
                "ИМЯ_ПЕРЕМЕННОЙ_2": "ЗНАЧЕНИЕ_ПЕРЕМЕННОЙ_2",
            }
        }
    ]
}
  1. В свойства user поставить доменное (локальное) имя пользователя, для которого должны применяться настройки. Именно по этому свойству будет определяться, какие пользовательские настройки нужно загружать.

  2. В свойстве settings прописать конкретные настройки для каждого пользователя. Состав настроек необязательно должен совпадать между пользователями, для какого-то пользователя настройки могут отсутствовать.

  3. Открыть обработку AD - файл user_settings.json подтянется автоматически из каталога, в котором находится AD (поле каталог инструментов на вкладке Сервис). Если такого файла нет, то загрузка молча игнорируется. Имеется возможность указать свой каталог загрузки настроек, он подчиняется свойству Каталог проекта на вкладке Сервис.

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

Замечания:

  • пожелания к использованию можно фиксировать в виде Github Issues;

Родительский проект

Полезные ссылки:

Лицензии

  • основная лицензия продукта - BSD v3
  • лицензии стороннего кода - Apache License, GitHub CLA, Freeware, etc