Практика применения DevOps. Тестирование

11.12.20

Разработка - Тестирование QA

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

Продолжаем цикл статей по практике применения DevOps.

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

Во второй части Виталий Подымников показал, как настраивать SonarQube для проверки качества кода.

А я в рамках своей части мастер-класса рассмотрю два инструмента тестирования – Vanessa Automation в связке с СППР и Сценарное тестирование.

 

Vanessa Automation в связке с СППР

Первый инструмент – это Vanessa Automation в связке с СППР.

Vanessa Automation – это инструмент для написания тестовых сценариев на языке Gherkin.

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

 

 

Vanessa Automation можно установить двумя способами:

  • скачать последний релиз из репозитория на GitHub https://github.com/Pr-Mex/vanessa-automation/releases;

  • либо, если у вас используется OneScript, установить в качестве пакета OneScript командой opm install vanessa-automation.

Vanessa Automation можно использовать в двух вариантах:

  • независимо, запуская ее в базе, в которой вы ведете разработку,

  • или вместе с СППР – в этом случае СППР хранит привязку тестов к метаданным, ответственным и функциям системы, и мы всегда достаточно легко можем сказать, какая функциональность у нас протестирована.

 

Настройка тестирования в СППР

 

 

Чтобы можно было запускать тестирование непосредственно из СППР, она должна быть запущена в режиме менеджера тестирования – для этого в параметрах ее запуска нужно указать ключ /testmanager.

 

 

Для пользователя, под которым запускается СППР, должна быть отключена защита от опасных действий, потому что Vanessa Automation при выполнении шагов вызывает другие внешние обработки.

 

 

Чтобы использовать тестирование в разделе «Администрирование» – «Общие настройки» – «Тестирование» установить флаг «Использовать сценарии тестирования».

 

 

Для пользователя, под которым будут запускаться тесты, необходимо в разделе «Органайзер» – «Персональные настройки» указать:

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

  • и указать путь к фреймворку тестирования – в данном случае это у нас Vanessa Automation.

 

Настройка проекта в СППР

 

 

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

 

 

Указываем наименование конфигурации и идентификатор программы.

 

 

Здесь также можно загрузить метаданные. Мы ведем разработку конфигурации «Конференция» в Git-репозитории с помощью EDT, поэтому указываем:

  • путь к нашему Git-репозиторию;

  • ветку, из которой мы хотим брать метаданные;

  • и путь к проекту в репозитории.

 

Настройка эталонной базы для тестирования

 

 

Следующим этапом в разделе «Тестирование» – «Эталонные базы тестирования» нам необходимо создать эталонную базу для тестирования. Здесь будут храниться параметры подключения к базе проекта, в которой будет производиться тестирование (логин, пароль).

Здесь на первой закладке указывается:

  • наименование;

  • идентификатор базы;

  • проект;

  • путь к выгрузке базы

 

 

А на второй закладке задается соответствие профиля пользователя СППР с логином и паролем пользователя в эталонной базе. Этот профиль необходимо потом указать в тестовом сценарии.

 

Настройки локального запуска сценариев

 

 

Основной справочник, в котором хранятся простейшие тесты – это «Сценарии работы пользователей», он находится в разделе «Тестирование».

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

 

 

Здесь указывается:

  • адрес информационной базы – его можно выбрать из списка;

  • эталонная база;

  • и менеджер тестирования – в нашем случае это текущий сеанс СППР, а в общем случае здесь можно выбрать сеанс любой другой базы, на которой вы хотите запускать менеджер тестирования.

Сценарии работы пользователей

 

 

Рассмотрим простейший сценарий работы пользователя. Здесь на закладке «Описание» указываются:

  • наименование;

  • проект;

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

 

Структура feature-файла

 

 

На закладке «Текст сценария» хранится текст самого сценария.

 

 

Рассмотрим подробнее синтаксис языка Gherkin и структуру feature-файла.

  • Первой строкой идет комментарий специального вида #language: ru, который показывает, что в тесте используется русский язык

  • Дальше указан тег @tree – он подключен во всех сценариях СППР по умолчанию и означает, что шаги сценария могут быть декомпозированы на подшаги. Это удобно, если мы для пользователей пишем описание теста в своих терминах и уже программист делает подшаги, которые реализуют эти шаги на языке 1С.

  • Дальше идет пользовательская история, которая начинается со слов «Функциональность» – здесь мы описываем, что мы хотим проверить в данном сценарии.

  • Следующим этапом идет «Контекст» – это общие действия, которые выполняются для всех указанных в feature-файле сценариев.

  • И непосредственно «Сценарий», который состоит из простейших шагов или сниппетов.

    • Шаги сценария начинаются со слов: «Когда», «И», «Тогда». Эти ключевые слова взаимозаменяемые и служат для того, чтобы сценарий проще читался пользователем.

    • Шаг «Создаем город» – это шаг группы, и если мы откроем сценарий во фреймворке тестирования, то увидим, что вложенные в группу шаги открываются свернутыми, то есть по умолчанию скрыты от пользователя.

 

Запуск фреймворка тестирования Vanessa Automation из формы сценария

 

 

Запустим данный сценарий во фреймворке тестирования.

 

 

Открылось дерево шагов – как вы видите, группа шагов по умолчанию свернута.

 

Автоматизированное создание текста сценария через запись действий пользователя

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

 

 

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

 

 

Следующим шагом на этой же закладке «Работа с UI» нажмем кнопку «Начать запись действий пользователя».

 

 

Допустим, мы хотим записать шаг, который создает еще один город. Переходим в раздел Справочники – Города. И создаем здесь город Москва.

 

 

Возвращаемся обратно в СППР и завершаем запись действий пользователя.

 

 

Здесь у нас появился сценарий, написанный на языке Gherkin. Его можно скопировать и вставить в справочник «Сценарии работы пользователя» в СППР.

Также в сценарий можно добавить известный шаг из библиотеки известных шагов.

 

Загрузка известных шагов Vanessa Automation в СППР

 

 

Шаги из библиотеки известных шагов можно добавить в СППР. Для этого нужно сохранить шаги в формате JSON.

 

 

В разделе «Тестирование» есть справочник «Шаги сценариев пользователя». Здесь эти шаги из Vanessa Automation можно загрузить.

 

 

Если мы перезайдем в сценарий, эти шаги появятся на закладке «Текст сценария».

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

 

Добавление своего шага

Но если нам известных шагов недостаточно, и мы хотим добавить свой, то мы можем его реализовать самостоятельно.

 

 

Например, у нас есть сценарий «Пример своего шага», где просто добавлена фраза «И я выполняю свой шаг».

 

 

Если мы сейчас запустим сценарий в фреймворке тестирования, то шаг «И Я выполняю свой шаг» будет подсвечен желтым. Если мы выведем колонку «Обработка», то увидим, что для данного шага нет обработки, которая содержит его реализацию.

 

 

Для генерации обработки с реализацией данного шага предназначена закладка «Генератор EPF». Устанавливаем флаги «Генерировать управляемую форму» и «Создать области» – это просто удобно. Нажимаем кнопку «Создать и обновить шаблоны обработок».

 

 

Автоматически открылась папка step_definitions со сформированной обработкой Test.epf – папка step_definitions была также автоматически создана в каталоге feature-файла.

Откроем обработку в конфигураторе.

 

 

Если мы посмотрим модуль формы, то здесь в самом низу у нас создалась функция с названием «ЯВыполняюСвойШаг». По умолчанию функция содержит «ВызватьИсключение "Не реализовано"».

 

 

Пока мы шаг не реализуем, обработка тестирования на этом шаге будет падать, поэтому убираем из функции вызов исключения. И реализуем здесь что-нибудь, например, напишем просто «Сообщить("Мой шаг")». Сохраняем.

 

 

Если мы хотим добавить этот шаг в библиотеку известных шагов, это тоже можно сделать. Для этого предназначена функция ПолучитьСписокТестов(), которая по умолчанию добавляет этот шаг в список шагов Vanessa Automation.

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

Сохраняем обработку.

 

 

Возвращаемся обратно в СППР и перезапустим Vanessa Automation.

Мы видим, что шаг у нас перестал подсвечивается желтым, и если мы выведем опять колонки «Сниппет» и «Обработка», то у нас уже определилась обработка, которая реализует данный шаг.

 

 

Перейдем на закладку «Работа с UI», нажмем кнопку «Добавить известный шаг» – как видите, этот шаг у нас появился в библиотеке известных шагов, мы можем его использовать.

 

 

По умолчанию, Vanessa Automation ищет известные шаги в стандартной библиотеке шагов (находится в каталоге features\Libraries самого фреймворка), а также в текущем каталоге файлов функциональности (там, где находится открытая фича).

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

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

 

Интерфейс обработки Vanessa Automation

 

 

Какие еще закладки есть в обработке Vanessa Automation?

Это закладка «Клиенты тестирования». Здесь мы можем задать возможность подключения одного тест-менеджера (текущего сеанса с Vanessa Automation) к различным клиентам тестирования – с разными параметрами запуска, с разной платформой, из-под разных пользователей.

 

 

Также есть закладка «Сервис». Здесь указаны основные настройки:

  • галка «Тег @tree включен по умолчанию»;

  • каталог инструментов;

  • каталог проекта, где хранятся наши данные.

 

 

На закладке «Отчет о запуске сценариев», мы можем вывести результаты нашего тестирования в формате Allure, JUnit, Cucumber.

 

 

И закладка «Автоинструкции».

Vanessa Automation предоставляет довольно широкие возможности для написания тестовых сценариев, поэтому мы предлагаем использовать именно ее.

 

Сценарное тестирование

Второй инструмент, который будет рассмотрен – это инструмент «Сценарное тестирование», который предоставляет фирма «1С».

Конфигурация «Сценарное тестирование» позволяет:

  • Разрабатывать сценарии тестирования с использованием автоматизированного тестирования – можно записать сценарий по действиям пользователя, добавить в него обработчики и параметры, потом воспроизводить сценарий вручную;

  • Автоматически запускать тестирование по расписанию;

  • Хранить сценарии и тесты с привязкой к релизу конфигурации;

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

  • Контролировать процессы доработки тестов через задачи по доработке.

 

Первоначальная настройка томов хранения файлов

 

 

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

 

 

Эти настройки находятся в пункте меню «Администрирование» – «Начальная настройка системы».

 

 

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

 

Первоначальная настройка пользователей

 

 

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

  • настройка с предопределенным названием «РабочийКаталог» – путь к рабочему каталогу, где будет храниться информация о тестировании;

  • и пути к исполняемым файлам платформы.

 

Первоначальная настройка справочника «Конфигурации»

 

 

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

 

 

Указываем ее сборку.

 

 

Для сборки на закладке «Структура метаданных» можно загрузить метаданные, но здесь есть существенное отличие от СППР:

  • СППР позволяет загружать метаданные в формате EDT и нам это удобно, потому что мы ведем разработку в EDT;

  • а Сценарное тестирование загружает конфигурацию только в формате, который получен из конфигуратора (Конфигурация – Сохранить конфигурацию в файлы).

 

Первоначальная настройка – проекты

 

 

Дальше нам необходимо создать проект.

 

 

Здесь мы указываем состав проекта. В проекте может быть несколько конфигураций. В нашем случае только одна.

 

 

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

 

Работа с обработкой тестирования

 

 

Для непосредственного запуска сценариев нам необходимо сохранить обработку в файл из меню Администрирование – Сервис – Сохранить обработку в файл.

 

 

Сохраняем основной вариант обработки.

 

 

При этом в выбранную папку будет записано две обработки:

  • основная обработка сценарного тестирования STest_3_0_18_2.epf;

  • и обработка сценарного тестирования интерактивных действий iSTest_3_0_18_2.epf.

 

 

Запустим нашу конфигурацию «Конференция» с флагом «/testmanager».

 

 

И откроем основную обработку сценарного тестирования STest_3_0_18_2.epf.

Выдается окно Быстрый старт. Здесь можно:

  • подключиться к тестируемому приложению;

  • открыть сценарий для редактирования;

  • открыть сценарий для выполнения;

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

Подключимся к тестируемому приложению.

 

 

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

 

 

После запуска клиента тестирования мы можем записать интерактивные шаги из журнала. Это примерно так же, как мы делали в Vanessa Automation, когда записывали наши шаги.

 

 

Начинаем запись.

 

 

Допустим, мы также создадим еще один город.

Вернемся в менеджер тестирования и остановим запись шагов.

 

 

Вот у нас вывелись те шаги, которые мы накликали. Переносим это в сценарий по кнопке «Записать и закрыть».

 

 

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

Обратите внимание, здесь можно выполнить запрос или серверную процедуру.

 

 

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

 

 

После реализации шагов сохраняем сценарий в файл.

 

 

Указываем здесь путь к сохраняемому сценарию и возвращаемся в базу «Сценарного тестирования».

 

Хранение и запуск тестов – справочник Тесты

 

 

Основные справочники для хранения тестов в «Сценарном тестировании» – это «Тесты», «Сценарии» и «Пакетное выполнение».

 

 

В справочнике «Тесты» мы задаем общее описание того, что мы хотим протестировать.

 

 

И для каждого теста создаем сценарий.

 

 

В сценарии указаны:

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

 

Пакетное выполнение

 

 

Для предварительной подготовки среды тестирования и последовательного запуска нескольких сценариев тестирования используется объект «Пакетное выполнение». В пакетном тестировании можно установить административные действия, как по подготовке среды тестирования, так и по исполнению сценариев тестирования. Например, можно создать новую базу, загрузить из архива, обновить базу и т.д.

Можно запустить менеджер тестирования под разными видами клиентов, запустить один и тот же сценарий несколько раз с разными параметрами

 

 

В пакете мы указываем параметры запуска сценария.

 

 

  • «Размещение информационной базы» – путь к тестовым данным сценария;

  • «Платформа 1С:Предприятие» – путь к исполняемым файлам платформы, под которой мы хотим запускать.

 

 

Для шага «Создать тестовую информационную базу» мы указываем тест и сценарий.

Файл тестовой информационной базы у нас заполняется из сценария – при запуске сценария эта база будет создана.

 

 

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

 

 

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

 

 

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

В следующей заключительной части Валерий Пронин расскажет про написание сборочной линии для проекта на Jenkins и в зависимости от результата – создания cf-файла релиза или отправки сообщения об ошибках на email.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2019 Inception.

Инфостарт A&PM Event 2026

Вступайте в нашу телеграмм-группу Инфостарт

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Инструментарий разработчика Нейросети DevOps и автоматизация разработки Тестирование QA Разработчик 1С 8.3 Бесплатно (free)

Открытый набор правил и скриптов на GitHub для ИИ-агента (агента искусственного интеллекта: Claude Code, Codex и других). Агент сам снимает опись машины, предлагает путь проверки кода: плагин Unica или BSL Language Server со справкой платформы. С вашего «да» ставит недостающее, затем выгружает внешнюю обработку, заводит git и доводит её до зелёного теста YAxUnit. Оба пути проверены с нуля свежим агентом на копии демобазы «Управление торговлей» 11.5, платформа 8.3.27. Новая часть: для задач по данным базы агент выгружает конфигурацию в XML, строит карту объектов и пишет запросы только по именам, найденным в выгрузке. Внутри гайд «Unica на Windows» с известными ошибками и проверенными обходами.

10.11.2026    453    Iliaelagin    0    

1

Тестирование QA Разработчик 1С:Предприятие 8 Бесплатно (free)

Когда полная сборка автотестов занимает полчаса, даже небольшая автоматизация может изменить рабочий процесс. Рассказываю, как Python-утилита Phase Switcher постепенно превратилась в KOT for 1C — open-source расширение для VS Code. KOT 3.0 объединяет в одной рабочей среде библиотеку шагов и сценариев, IntelliSense, поддержку СППР и самостоятельных feature Vanessa Automation, исследователь форм, запись действий и управление выполнением через MCP. В статье — история разработки проекта от небольшой Python-утилиты до расширения для VS Code, практические примеры, неудачные эксперименты и решения, которые помогли инструменту прижиться в нашей команде.

02.11.2026    473    alexiosus    0    

2

Тестирование QA Бесплатно (free)

Резкий рост числа пользователей, консолидация систем или миграция в облако требуют заранее понять, выдержит ли инфраструктура новую нагрузку. Рассказываем, как с помощью LLM команда за 16 недель подготовила и провела нагрузочные тесты для шести баз: автоматизировала анализ технологических журналов и журналов регистрации, формирование реалистичных сценариев и создание обработок для «1С:Тест-центра» и JMeter. Показываем, как оркестратор, AI-агенты и MCP-серверы помогают сократить объем ручной работы, а также объясняем, почему контроль со стороны 1С-эксперта по-прежнему остается обязательным. Разбираем архитектуру решения, уже работающие инструменты и направления дальнейшей автоматизации нагрузочного тестирования.

31.10.2026    530    gabrielyants    0    

5

Инструментарий разработчика Тестирование QA Разработчик Стажер 1С 8.3 Абонемент ($m)

Проверила пять пакетных команд платформы 8.3.27 на контрольном расширении Нано-УТ: они обнаружили 4 из 28 заложенных пунктов. В набор входят ошибки применимости, предупреждения и сведения для ручного разбора. Проверка XML-выгрузки отметила все 28 пунктов и 15 из 15 на похожем слепом наборе. Показываю журналы, ограничения и сценарий обновления основной конфигурации. Прилагаются инструмент с 69 тестами и материалы опыта.

7 стартмани

28.10.2026    393    Ninel_S    2    

2

Инструментарий разработчика Мобильная разработка Тестирование QA Разработчик 1С 8.3 Абонемент ($m)

Скрипт form_diff_mobile.py сравнивает две выгрузки конфигурации 1С и показывает, что в формах удалено и переименовано, где на это ещё ссылаются и какой код попадает в мобильные контексты. На «Нано-УТ 2.0» сделано 13 изменений форм: платформа 8.3.27.2130 отметила 7, в остальных шести промолчала, и в четырёх из них скрипт нашёл обращение к удалённому элементу, строку с прежним именем формы, смену директивы или выход формы из мобильной области. На чистой УТ 11.5 сравнение с копией дало 0 находок, а с копией с пятью правками ровно семь. В архивах скрипт, 74 теста, стенд, чек-лист выпуска, журнал выпуска и скрипты опытов на платформе.

7 стартмани

27.10.2026    347    Ninel_S    0    

1

Тестирование QA Разработчик 1С 8.3 Абонемент ($m)

Прогнала через 1С 8.3.27 и валидатор .NET 21 файл XML по одной схеме: базовый пример и типичные отклонения. Вердикты совпали в 20 случаях (у .NET включены предупреждения), дата без времени дала расхождение. В архиве - схема, тесты, закреплённая версия учебной базы и исправленный сценарий проверки, включая выгрузку и обратное чтение 30 продаж.

1 стартмани

26.10.2026    340    Ninel_S    0    

1

Рефакторинг и качество кода Тестирование QA Системный администратор Разработчик 1С 8.3 Абонемент ($m)

В базе 1С на PostgreSQL копятся индексы, которыми никто не пользуется: их создаёт флажок «Индексировать» у реквизитов или их добавляют вручную. Каждый такой индекс замедляет запись: в опыте на тестовой таблице восемь лишних индексов сделали вставку 300 000 строк в четыре-шесть раз дольше. Скрипт на Python смотрит статистику PostgreSQL и показывает, какие индексы ни разу не использовались и какой реквизит 1С их создал. На нашей конфигурации «Нано-УТ» он нашёл четыре ненужных индекса документа и один дубль, добавленный вручную. После того как я сняла флажки и обновила конфигурацию, индексов стало 227 вместо 234, данные не пострадали. В архиве скрипт, запросы и примеры.

5 стартмани

23.10.2026    507    Ninel_S    4    

1

Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)

Скрипт, который должен был проверять код 1С в Docker, на деле проверял только, что файл не пустой: из 11 модулей с ошибками он пропустил все. Я переписала проверку и сравнила её с самой 1С на тех же 11 модулях из нашей конфигурации «Нано-УТ». Новый скрипт нашёл незакрытые «Если», процедуры и скобки в 10 случаях из 11. Вызов несуществующей процедуры находит только сама 1С. В архиве скрипт, файлы для Docker, примеры с ошибками и журналы проверки.

5 стартмани

23.10.2026    495    Ninel_S    4    

0
Для отправки сообщения требуется регистрация/авторизация