Мастер-класс: Реализация цикла CI/CD на практическом примере с использованием системы Тестер

О теме доклада

 

«Тестер» – это альтернативная система тестирования. Казалось бы, она делает все то же самое, что Vanessa Automation или Vanessa ADD, но генотип этого приложения немного другой. Эта система тестирования больше приближена к программисту, чтобы у программиста был удобный и максимально быстрый инструмент для тестирования своих задач.

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

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

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

 

 

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

• 1С

• VS Code

• EDT

• и развернута виртуальная машина на Windows, которая будет отвечать на внешние запросы для запуска тестирования – на ней также установлен 1С, EDT с утилитой ring и Git.

В EDT у меня разработано небольшое приложение для 1С – в нем пара справочников («Товары» и «Склады») и один документ «Приход».

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

Главное отличие CI/CD на базе системы тестирования «Тестер» от классического CI/CD заключается в том, что сам «Тестер» также используется как конвейер задач. Я об этом расскажу чуть подробнее дальше.

 

 

Итак, у нас есть приложение на 1С, и цель этого мастер-класса – разработать в «Тестере» для этого приложения небольшой тест «ПриходИзСписка», который открывает список документов «Приход» и вводит документ.

Сейчас вы видите готовую инфраструктуру для тестирования. А теперь давайте попробуем создать новый «Тестер», чтобы загрузить туда тесты и поработать с Git-репозиторием.

 

Установка и первоначальная настройка системы «Тестер»

 

Из репозитория на GitHub https://github.com/grumagargler/tester я скачаю файл конфигурации 1Cv8.cf.

В список баз добавим пустую базу, назовем ее «tester-demo».

 

 

В дополнительные параметры запуска добавим ключ /testmanager для запуска базы в режиме тест-менеджера.

Загрузим в пустую базу конфигурацию «Тестера», которую мы скачали с GitHub.

При первом запуске «Тестера» по умолчанию создается пользователь «Администратор» .

Фактически информационная база готова к работе.

 

 

Чтобы инициализировать «Тестер», первым делом мы должны создать в нем приложение, которое собираемся тестировать.

В списке «Приложения» создадим приложение «Склад». Компьютер – localhost, порт по умолчанию – 1538.

 

 

Следующим шагом на начальной странице создадим какую-нибудь папку для начала тестирования, например, «Документы». Эта папка будет принадлежать приложению «Склад».

 

 

Добавим папку «Приход». И в эту папку поместим сценарий «СозданиеДокумента» – у него будет критичная важность и сделаем его основным.

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

 

 

Перезапустим наше приложение «Склад» в режиме клиента тестирования на порту 1538 и включим запись в «Тестере».

• Откроем список «Товары» и создадим новый элемент с наименованием «товар5».

• Откроем список «Склады» и создадим новый склад с названием «склад5».

• Откроем список документов «Приход» – добавим новый документ, выберем склад и нажмем «Провести и закрыть».

Остановим запись.

У нас в «Тестере» получен результат «кнопконажималки». Я сам не любитель кнопконажималки, но с целью демонстрации это сокращает время на начальном этапе.

Давайте запустим этот тест, посмотрим, что он работает. Он отработал.

В среде тестирования Тестер код сформированного сценария выглядит непрезентабельно – белый фон, синий текст. Такие тесты читать сложно. Но на практике со временем редактирование сценариев уходит в VS Code, который автоматически синхронизируется с «Тестером». Чуть позже я расскажу, как настроить синхронизацию сценариев с репозиторием на диске, а по ссылке http://tester.help/vscode/ можно ознакомиться с тем, как настроить синхронизацию с VS Code – я сейчас не буду на этом подробно останавливаться.

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

Если вы разработчик, вы работаете с кодом тестирования вашего проекта на одном уровне сознания.

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

 

 

Добавим в наше приложение еще один документ – назовем его «Перемещение», добавим в него два реквизита «СкладОтправитель» и «СкладПолучатель» с типом «Справочник.Склады» и табличную часть «Товары» с реквизитом «Товар», имеющим тип «Справочник.Товары».

 

 

Теперь в Тестере таким же образом создадим папку «Перемещение» и сценарий «ВнутриОрганизации» с важностью «Средняя» и галочкой «Сделать основным».

 

 

Давайте запустим конфигурацию клиента тестирования и запишем действия для второго теста:

• откроем список документов «Перемещение»;

• нажмем кнопку «Создать»;

• в качестве склада-отправителя выберем «Склад1»;

• в качестве склада-получателя выберем «Склад5».

Второй тест готов. Давайте его тоже проверим – тест завершен успешно.

Буквально за 5 минут у нас уже готово тестовое окружение, где для нашей конфигурации написано два теста.

 

Структура дерева сценариев и синхронизация с Git

 

Каким образом нам смонтировать запуск этого тестового окружения в удаленный git-репозиторий, чтобы при изменении кода в проекте или появлении новых тестов мы могли синхронизироваться с сервером тестирования?

 

 

Чтобы не тратить время, я переключусь уже на готовый «Тестер». Здесь мы видим более полную структуру тестирования.

• общие тесты, которые я уже загрузил из репозитория;

• и частные тесты, которые принадлежат конкретному приложению.

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

• в папке «Общие» находятся общие тесты на прикладную функциональность:

  • для перехода к какому-нибудь отчету, списку;

  • проверяем, создано ли окружение;

  • проверяем движение по какому-нибудь универсальному алгоритму.

• в папке «Тестер» находятся инструментальные общие тесты, которые могут выполнять всю подноготную, которая требуется, чтобы поддерживать CI/CD-систему в автоматизированном режиме – умеют запускать 1С:Предприятие в режиме конфигуратора, с передачей ключей, запускать EDT и т.д.

Как это работает на файловом уровне?

В конфигурации «Тестер» для каждого приложения может быть настроен репозиторий – локальное хранилище, с которым вы будете синхронизировать ваши тесты.

 

 

Например, для приложения «Склад» настроен репозиторий, где указано, что для сессии grumagargler приложение «Склад» синхронизируется с папкой C:\Users\Dmitry\git.meetup\storage\tests.

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

 

 

Соответственно, все тесты для сессии приложения «Склад» располагаются в папке с папке C:\Users\Dmitry\git.meetup\storage\tests. Здесь лежат папки «Групповые», «Документы», «Справочники» – вы их видели в дереве сценариев.

 

 

Причем, папка C:\Users\Dmitry\git.meetup\storage\tests связана с исходным кодом, который контролирует EDT, потому что папка storage помимо папки tests содержит папку, где находится проект EDT.

И, несмотря на то, что папка tests – не EDT-шная папка, я ее сам сюда положил, EDT следит за содержимым обоих папок и выводит на панели Git изменения, которые я внес в сценарий.

 

 

Следующий шаг – фиксация изменений в EDT. Я пишу сообщение «тест» и отправляю коммит с изменениями в GitLab-репозиторий, где у меня настроено окружение для CI/CD.

 

 

Мы видим, что изменения синхронизировались с GitLab – здесь вывелся мой последний комментарий.

Сейчас я вам показал, как с нуля загрузить Тестер, и как им можно быстро локально протестировать ваше небольшое приложение. Но я не показал, как в Тестер загрузить общие тесты.

Общие тесты можно загрузить в базу из репозитория https://github.com/grumagargler/CommonTests. Мы их скачиваем, распаковываем по удобному пути. Теперь вопрос – как сделать так, чтобы эти тесты появились у нас в тестовом окружении.

 

 

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

 

 

Чтобы общие тесты появились в дереве тестов, их нужно загрузить – для этого можно воспользоваться сочетанием клавиш Ctrl+Shift+L или вызвать обработку «Загрузка» из главного меню.

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

 

Сервер CI/CD для тестирования на базе Тестера

 

Итак, мы разрабатываем какое-то приложение, пишем для него тесты, эти тесты синхронизируются с удаленным репозиторием – с этим все хорошо.

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

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

В Тестере эта логика описывается 1С-овским кодом. Я сейчас расскажу, как это работает.

 

 

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

Идем в настройки (Settings) и запускаем вебхуки (WebHooks) – я сюда уже добавил вызов веб-сервиса, который будет реагировать на то, что ему посылает GitLab.

С помощью этого вебхука, когда мы фиксируем изменения и делаем выгрузку на удаленный репозиторий, GitLab автоматически выполняет вызов веб-сервиса с передачей параметров.

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

 

 

В этой виртуальной машине установлено не так много софта: платформа 1С, сам «Тестер», EDT с утилитой ring, и Git для Windows. Git нужен, чтобы «пасти» изменения в общих тестах.

 

 

Обратите внимание на то, каким образом на виртуальной машине устроено хранение общих тестов и файлов конфигурации в формате EDT.

• Папка ct – это общие тесты, которые синхронизируются и живут отдельно. Вы разрабатываете общие тесты не в EDT. Вы это делаете в самом «Тестере», потому что общие тесты не привязаны ни к какой конфигурации, они могут работать для всего. Эти изменения лежат отдельно, отдельными файлами, и за ними следит Git, который у меня установлен.

• А папка storage – это зеркало удаленного репозитория. Здесь находятся тесты и исходники.

Чтобы не путаться – это не моя локальная машина, это «Тестер», который работает на виртуальной машине. Можно сказать, что это некий Jenkins, но на самом деле, это все тот же «Тестер» все с теми же тестами, который синхронизируется через удаленный Git-репозиторий.

 

 

Сразу после того как я в Тестере на локальной машине введу в сценарии «ПриходИзСписка» комментарий //test и отправлю изменения на GitLab, в Тестере на виртуальной машине изменения в том тесте, где я ввел комментарий, полностью синхронизируются. При этом автоматически запустятся тесты, которые тестируют приложение.

 

 

Тестер в виртуальной машине почти не отличается от моего локального Тестера за небольшими нюансами.

Во-первых, в списке пользователей у этого Тестера есть специальный пользователь – «Тестер», который определен как агент. Это значит, что у этой сессии, помимо того, что она делает все то, что делает обычный программист, эта сессия еще может работать с заданиями.

 

 

У «Тестера» есть механизм заданий, эти задания формируются и выполняются агентом. Агентов может быть очень много, они могут быть раскиданы по разным машинам.

 

 

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

 

 

Это агентская сессия. Я запустился под пользователем «Тестер», также у меня в настройках на удаленной тестовой машине есть настройки, где указывается сценарий, который будет обрабатывать вебхук.

Работает это так: у нас есть GitLab, который сообщает нам по веб-сервису обо всех изменениях, которые мы в него вносим. Тестер воспринимает сообщение от GitLab и запускает отмеченный в этом поле сценарий.

 

 

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

Задачи этого сценария:

• Во-первых, отреагировать на внешний запрос GitLab’а – ответить ему, что все хорошо.

• Также я здесь определяю, что поменялось: слежу за ветками develop и master – смотрю, изменились они или нет. Если никакая из этих веток не была изменена, мы просто завершаем этот сценарий – дальше ничего не происходит.

• Если изменены ветки develop или master, создается задание «Тестер.СкачатьИзменения», где выполняется определенный набор команд по работе с Git.

• Дальше я смотрю, что изменилось: тесты или исходный код – если изменились исходники, создается задание «Групповые.Запуск» с параметрами. При формировании задания мы можем указать, какой сценарий запускать. В данном случае, если изменились только тесты – происходит групповой запуск этих тестов.

Важно понимать, что машина, которая следит за изменениями GitLab’а – это не обязательно та же машина, которая будет делать тесты. Эта машина просто создает задание и помещает его в список заданий. Другие компьютеры, которые следят за этими заданиями, могут находиться, где угодно – это задание может прийти через обмен по РБД и запуститься на другой машине.

 

 

Если мы откроем сценарий «Групповые.Запуск», тут формируется структура параметров.

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

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

И в конце вызывается сценарий «Тестер.Выполнить», который выполняет другие сценарии.

 

 

Если мы его откроем – здесь происходит:

• установка текущего приложения, потому что одна тестовая машина может тестировать множество приложений – УТ, БП, какую-то вашу собственную разработку;

• устанавливается версия, если вы используете версионирование;

• производится попытка закрытия предыдущих сессий тестирования;

• восстанавливается начальная база;

• проверяется тестирование окружения: то есть, вы можете создать специальный тест, который проверит окружение и стоит ли эти тесты вообще дальше запускать;

• и запускаются тесты – мы говорим о том, что у нас есть отдельная процедура, которая начинает в цикле их запускать.

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

Одно дело, когда мы создаем что-либо и совсем другое дело – когда мы начинаем это менять. Тут нам помогает работа с кодом, потому что тут мы можем гибко эволюционировать, проводить изменения, рефакторинг наших тестов.

 

Отчеты системы тестирования

 

Давайте немного сравним системы тестирования в плане отчетов по результатам тестирования.

Если говорить про Vanessa Automation (Vanessa ADD), то там есть определенная идеология – эта технология выполнена в виде отдельных обработок, и она очень плотно задействует другие сервисы, например, тот же Allure.

В «Тестере» это реализовано иначе – все отчеты делаются внутри него самого. Есть система отчетов:

Я могу сформировать отчет о тестировании из задания или из журнала запуска.

 

 

Покажу на примере. Допустим, у меня здесь будет какая-нибудь абракадабра, чтобы тест упал.

 

 

В журнале ошибок я сразу же увижу, где ошибка. При нажатии на нее я сразу попадаю в строку, на которой она возникла.

 

 

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

 

 

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

 

 

Такая же колонка с областью есть и в отчете о тестировании.

Цель моего доклада – показать, что можно использовать нехитрый набор инструментов, не затрачивая время на установку на свой компьютер каких-нибудь внешних программ. У меня установлены только 1С, EDT и настроен удаленный репозиторий – этого достаточно, чтобы проводить тестирование по той логике, которая описана самим кодом.

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

Это и было моей целью – показать не очень требовательный, но в то же время быстрый способ развернуть цикл CI/CD у себя на рабочем месте.

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

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "DevOps в 1С: Тестирование и контроль качества решений на 1С".