Не с начала

Много вы знаете инструментов тестирования, которые умеют:

• Получать шаги на языке Gherkin сразу из того, что накликал пользователь?
• Создавать видео-инструкции автоматически, с субтитрами, black Jack'ом и Еленой?)
• Создавать *.feature файл на английском языке в румынском интерфейсе, для пользователя, говорящего на итальянском?

Об этом доступно и наглядно (с картинками) в этой статье, не переключайтесь...

Вступление

Данная статья представляет собой обзор созданного в недрах OpenSource инструмента тестирования прикладных решений 1С под названием vanessa-automation. Данный проект является прямым продолжением широко известного в узких кругах проекта vanessa-behavior (fork был создан на версии 1.1.131). Кстати, существуют и другие fork'и.

Контекст

Как бы не было приятно думать, что каждый читатель этой статьи на habr знает 1С, все таки, обманываться не вариант. Потому не рискну продолжить, не сформировав у читателя представления о платформе 1С и ее возможностях, используемых в vanessa-automation (далее va или Ванесса).

Итак, после установки платформы 1С её нужно запустить в режиме Предприятия или в режиме Конфигуратора.

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

Ситуацию спасает функциональность платформы под названием Автоматизированное тестирование, которая дает возможность записать, воспроизвести и проверить действий пользователя. Как данная функциональность меняет сценарий использования разработчиком платформы рассмотрим на примере, НО сначала о Внешних обработках.

Прикладные объекты конфигурации (они же "Метаданные", они же "Объекты конфигурации", она же Элла Кацнельбоген, она же Валентина Панияд)
описывают предметную область и имена этих объектов говорят сами за себя.

"Документы" отражают хозяйственные операции, к примеру, поступление товаров. "Справочники" нужны для того, чтобы ввести, к примеру, название контрагента 1 раз и далее выбирать его, а не вводить каждый раз заново. В "Регистрах" хранятся данные и по ним строятся виртуальные таблицы для выполнения сложных расчетов и формирования "Отчетов". Вот мы и добрались до Обработок, с их помощью обрабатывается информация базы данных (например, выполняется закрытие месяца в бухгалтерском учете или различные обмены между информационными базами), но нам они интересны возможностью выгрузки во внешние обработки.

Конфигурации поставляемые самой фирмой 1С находятся на поддержке (нельзя изменять, чтобы не лишиться автоматического обновления), а внешние обработки дают возможность без снятия с поддержки производить различные манипуляции с данными, ну и конечно — тестировать!

С определенной долей упрощения, можно сказать что технически, внешняя обработка 1С — это файл с расширением epf открыв который в конфигураторе, можно создать множество форм → разместить на формах элементы управления и запрограммировать некую функциональность в модулях этих форм. Ещё у внешних обработок есть "общий" модуль (он же "Модуль объекта") и макеты, НО это уже совсем другая история, а мы возвращаемся к тестирования.

Чтобы воспользоваться функциональностью Автоматизированное тестирование, нужно запустить два экземпляра 1С предприятия, первый с ключом менеджера тестирования (/TESTMANAGER), второй с ключом клиента тестирования (/TESTCLIENT) и установить соединение между менеджером и клиентом тестирования. Таким образом сценарий использования разработчиком платформы становится таким:

Из конфигуратора запускаем 1С в режиме предприятия с ключом менеджера тестирования → в предприятии открываем va и с его помощью запускаем ещё один экземпляр
1С в режиме предприятия с ключом клиента тестирования. Соединение менеджера и клиента тестирования va устанавливает автоматически после запуска клиента тестирования. Клиентом тестирования может быть как тонкий клиент, так и web-клиент.

Итого: Фирма 1С написала свой Selenium, который встроен в платформу 1С: Предприятие. И этот Selenium от 1С имеет преимущества. Например, любой элемент управления (он же control) на форме всегда имеет уникальное имя, которое в 99.99% случаев известно заранее. Соответственно нет проблем с локаторами, а чтобы найти элемент управления достаточно написать:

ИскомыйЭлементУправления = ФормаДокумента.НайтиОбъект(,,УникальноеИмя);

Закрепим материал на примере

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

• Разработка
• Настройка (выполняется 1 раз)
• Тестирование или более наглядный скринкаст.

Внимательный зритель мог заметить конструкцию

Если <шаг> Тогда

и вы не ошиблись, да — Ванесса использует свой диалект gherkin, в котором есть условия и циклы. Думаю, идея добавить в gherkin условия и циклы родилась примерно так:

Некоторые участники OpenSource сообщества данное решение критиковали, но если верить gitter, то сошлись на следующем — "человекочитаемости" фичи данная функциональность не вредит, а использовать её или нет — каждый решает сам.
Про turbo gherkin планируется отдельная статья, следите за обновлениями.

"BDD на 1С" и немного истории

va, каким мы его видим сейчас, виделся его создателям иначе. Делать тот же cucumber + selenium на 1С было решено только после того как испытали самые очевидные и низкозатратные варианты. В определенный момент стало ясно, что если использовать cucumber и selenium, то именно эти инструменты и придется дорабатывать, чтобы получить необходимую функциональность тестирования прикладных-бизнес решений 1С. Данный расклад, в рамках opensource и реалий мира 1С, усложнял и растягивал по времени развитие проекта. В итоге было решено обойтись только средствами платформы 1С: Предприятие.

На примере с продажей товара мы увидели как работает va, теперь давайте посмотрим как это реализовано.

Проверка шагов

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

Допустим, есть фича со сценарием:

Сценарий: Согласованный пересчет суммы
  Когда я в поле "Количество" ввожу  10
  И я в поле "Цена" ввожу 300
  Тогда поле "Сумма" имеет значение 3000

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

В результате, в том же каталоге, что и фича будет создан каталог step_definitions, а в нем будет создана внешняя обработка, с тем же именем что и фича.

..\СогласованныйПересчетСтрокТабличнойЧасти.feature
..\step_definitions\СогласованныйПересчетСтрокТабличнойЧасти.epf

Процедуры проверки шагов будут распологаться в модуле формы обработки.

Далее, при загрузке фичи va выполнит поиск и последовательное подключение внешних обработок, чтобы узнать процедуры проверки каких шагов в них (внешних обработках) реализованы. За это отвечает следующая процедура:

Последовательность поиска процедур проверки шагов следующая:

1. Во внешней обработке, соответствующая feature
2. Во внешних обработках, из того же каталоге, что и фича
3. Во внешних обработках, из каталогов указанных в списке библиотек

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

Реализовав проверку шага один раз, её можно использовать в других фичах (повторное использование шагов). Собственно по этому, в модуле формы внешней обработки, мы видим две процедуры проверки сценария из трех шагов.

Шаги "из воздуха" и WYCIWYG

Немного о Функциональности Автоматизированное тестирование платформы 1С. Напомню, Автоматизированное тестирование позволяет записывать, воспроизводить и проверять воспроизведенные действия пользователя. На деле это всё те же клиент тестирования и менеджер тестирования, только на стороне клиента включается запись журнала действий пользователя.

В результате мы имеем xml-файл с описанием действий пользователя:

<?xml version="1.0" encoding="UTF-8"?>
<uilog xmlns:d1p1="http://v8.1c.ru/8.3/uilog">
    <ClientApplicationWindow isMain="true">
        <CommandInterface>
            <CommandInterfaceGroup title="Панель функций текущего раздела">
                <CommandInterfaceButton title="Продажа товара">
                    <click/>
                </CommandInterfaceButton>
            </CommandInterfaceGroup>
        </CommandInterface>
    </ClientApplicationWindow>
    <ClientApplicationWindow caption="Продажа товара">
        <Form title="Продажа товара">
            <FormGroup name="ФормаКоманднаяПанель" title="Командная панель">
                <FormButton name="ФормаСоздать" title="Создать">
                    <click/>
                </FormButton>
            </FormGroup>
        </Form>
    </ClientApplicationWindow>
    <ClientApplicationWindow caption="Продажа товара (создание)">
        <Form title="Продажа товара (создание)">
            <FormTable name="Товары" title="Товары">
                <FormGroup name="ТоварыКоманднаяПанель" title="Командная панель">
                    <FormButton name="ТоварыДобавить" title="Добавить">
                        <click/>
                    </FormButton>
                </FormGroup>
                <FormField name="ТоварыТовар" title="Товар">
                    <closeDropList/>
                    <executeChoiceFromDropList presentation=""/>
                </FormField>
            </FormTable>
        </Form>
    </ClientApplicationWindow>
    <ClientApplicationWindow caption="Номенклатура">
        <Form title="Номенклатура">
            <FormTable name="Список" title="Список">
                <gotoRow direction="down">
                    <Field title="Код" cellText="000000001"/>
                    <Field title="Наименование" cellText="Монитор"/>
                </gotoRow>
                <choose/>
            </FormTable>
        </Form>
    </ClientApplicationWindow>
    <ClientApplicationWindow caption="Продажа товара (создание) *">
        <Form title="Продажа товара (создание) *">
            <FormTable name="Товары" title="Товары">
                <endEditRow cancel="false"/>
            </FormTable>
            <FormGroup name="ФормаКоманднаяПанель" title="Командная панель">
                <FormButton name="ФормаПровестиИЗакрыть" title="Провести и закрыть">
                    <click/>
                </FormButton>
            </FormGroup>
        </Form>
    </ClientApplicationWindow>
</uilog>

Лежит ли на поверхности идея создать функциональность преобразования журнала действий пользователя в шаги сценария, сейчас сказать сложно, НО первым догадался и реализовал эту идею — Паутов Леонид (pr-mex). Объем проделанной работы можно оценить по содержанию и размеру библиотеки, ведь кроме перевода журнала действий пользователя на язык gherkin, требовалось реализовать процедуры выполнения и процедуры проверки шагов.

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

В клиенте тестирования воспроизвести действия пользователя, например функциональности, которую нужно доработать или ошибки, которую нужно исправить. Ну и завершить запись действий пользователя. Таким образом реализуется "WYCIWYG" подход к разработки тестов (What you click is what you get).

Шаги, например, проверяющие результат действий пользователя в сценарий можно добавить из библиотеки.

Детализация шагов и экспортные сценарии

К сожалению в реальности сценарий состоит из множества шагов, больше чем на следующем скриншоте.

Есть, как минимум, два варианта облегчить восприятие таких сценариев.

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

Второй, делать сценарий лаконичным и универсальным и экспортировать. Думаю у меня не получиться описать данную функциональность лучше, чем Елена на видео "Использование тега tree и шаги из воздуха" и "Передача параметров в сценарий".

Данные видео (1, 2) также созданы из сценариев на Gherkin и с помощью движка "АвтоВидеоИнструкций" преобразованы в mp4 формат за один клик.

Да, Ванесса умеет создавать видео ролики о том как работает Ванесса)

АвтоВидео

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

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

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

Немного скучной статистики

va поддерживает:

• Версии платформы 1С: Предприятие начиная с 8.3.6 и выше (рекомендуется использовать платформу 8.3.10 и выше).
• Управляемые и как "обычные" формы (тестируемая конфигурация может находится в режиме совместимости 8.2 или выше).
• Режим асинхронных вызовов.

Чтобы корректно работать на таком "зоопарке", va пришлось научиться тестировать саму себя. Отчет о "self" тестировании выглядит примерно так:

Скрипты для "self" тестирования находятся в том же репозитории.

Библиотека шагов

В поставку va входит библиотека стандартных шагов Gherkin, которая позволяет решать повседневные задачи автотеситрования, такие как работа и интерфейсом приложения (кнопки, поля, таблицы и т.д.), работа с файлами, ОС и т.д. На данный момент это более 400 шагов.

Локализация

Интерфейс va локализован на 20 языков:

RU, am, az, bg, et, fr, ka, de, en, hu, it, lv, lt, mn, pl, ro, sl, es, sv, tr, vi.

Локализацию va можно разделить на 3 составляющих:

• Интерфейс (используется штатный механизм синонимов платформы 1С: Предприятие).
• Сообщения пользователю (вместо вызовов НСтр() используется макеты с переводами сообщений).
• Перевод шагов Gherkin из стандартной библиотеки va. Т.е. вместо того, чтобы реализовывать шаг "И я нажимаю на кнопку 'ИмяКнопки'" на каждом языке заново используется "маппинг" в соответствующий шаг Gherkin, который уже реализован на русском.
  На английском этот шаг будет

And I click 'ButtonName' button

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

Логично, что для поддержки такой локализации пришлось реализовать дополнительный инструментарий по работе с макетами (макет — это что-то вроде таблицы excel) для вставки/удаление значений, сортировка строк и т.д. напрямую в исходниках (xml файлах).

"TDD в 1С", тестирование процедур и функций (unit тесты)

С помощью va можно проверять "поведение" процедур и функций. Достаточно написать подобный сценарий:

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

Варианты поставки

Изначально проект поставлялся только в виде набора epf файлов, которые можно было собрать из исходников на github, либо скачать готовый релиз. Начиная с версии 1.2.009 va поставляется ещё и как один epf файл, который включает в себя все библиотеки, плагины, пакеты локализации, модули сборки видео и т.д. Так сказать — всё в одном.

Этот вариант фреймворка получил название vanessa-automation-single. Он хорошо подойдёт тем пользователям, которые не планируют дорабатывать va, а будут только использовать. Также этот вариант поставки хорошо подходит для включения в состав других конфигураций или расширений (благо лицензия проекта FreeBSD это позволяет).

Сверху вниз и снизу вверх

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

Мораль

Надеюсь у читателя сложилось (ключевое слово "сложилось") представление о va как о серьезном инструменте тестирования. Посматривая на зарубежные аналоги на старте, сейчас va их превосходит, по моему скромному мнению. Расширение функциональности работы с gherkin, дало (обещанную, но не воплощенную до turbo gherkin) возможность вовлечь в процесс разработки и аналитика и разработчика и тестировщика. Поясню, аналитик пишет сквозной, верхнеуровневый сценарий → разработчик детализирует этот сценарий в том числе с помощью экспортных сценариев, и кроме кода он практически ничего не пишет (все необходимые шаги UI уже в библиотеке) → тестировщик добавляет сценарии, чтобы под "другим углом" проверить функциональность и всё это — в одном feature-файле, ура товарищи!

P.S.

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

Спасибо за внимание!

Ссылки

• Вебинар
• Доклад на infostart event 2015
• Доклад на infostart event 2016 и ответы на вопросы