Автоматическая приёмка доработок в 1С: от первого сценария до ночного прогона

УАТ в 1С (от англ. UAT, User Acceptance Testing) — это приёмочное тестирование: перед выпуском доработки или обновления робот проходит в базе те же действия, что бухгалтер или кладовщик, и сверяет результат с ожидаемым. Для 8.3 такую проверку собирают на механизме тест-клиента платформы, а сценарии чаще всего пишут на языке Gherkin в Vanessa Automation.

Типичная история: программист поправил расчёт скидки в реализации, а через неделю бухгалтер обнаружил, что перестала печататься ТОРГ-12. Ручная проверка «по списку» такое пропускает. Набор из 30–50 приёмочных сценариев ловит подобное за один ночной прогон.

Что такое приёмочное тестирование в 1С и чем оно отличается от других проверок

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

Сравнение уровней проверки:

Главная ценность UAT — сценарий понятен заказчику. Фраза «Когда я провожу реализацию на 10 шт., тогда остаток на складе уменьшается на 10» читается без знания встроенного языка. Её можно согласовать с главбухом до начала разработки.

Где это окупается быстрее всего:

• 🔄 регулярные обновления типовой конфигурации с доработками;
• 🧩 базы с десятками расширений и внешних обработок;
• 👥 команды из нескольких программистов, которые правят одни и те же объекты;
• 📦 внедрения, где приёмка этапа фиксируется актом.

Инструменты для автоматизации тестирования 1С

Все популярные инструменты используют один и тот же механизм платформы. Есть менеджер тестирования (управляет) и клиент тестирования (выполняет действия). Менеджер подключается к клиенту по TCP и командует: «открой форму», «введи значение», «нажми кнопку».

Тест-клиент запускается ключом командной строки:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8c.exe" ENTERPRISE /S"srv1c\buh_test" /N"Тестировщик" /P"" /TESTCLIENT -TPort 1538

Номер версии в пути подставьте свой. Менеджер запускается ключом /TESTMANAGER.

Основные инструменты:

• 🥇 Vanessa Automation — открытая внешняя обработка, стандарт де-факто для сценарного тестирования. Сценарии на Gherkin, большая библиотека готовых шагов, запись действий, видеоинструкции, отчёты Allure и jUnit.
• 🏢 «1С:Сценарное тестирование 8» — продукт фирмы 1С. Сценарии собираются в своей конфигурации, без Gherkin. Удобен, если команда не хочет работать с текстовыми файлами.
• 🧪 YAxUnit — модульные тесты в виде расширения. Дополняет UAT, а не заменяет.
• ⚙️ vanessa-runner (vrunner) — консольная утилита на OneScript. Сама не тестирует, а создаёт базы, загружает конфигурацию и запускает Vanessa Automation из скрипта. Без неё CI собирать неудобно.

Подготовка тестовой базы и окружения для UAT

Никогда не запускайте автотесты на рабочей базе. Сценарий создаёт, проводит и удаляет документы. На рабочих данных это испортит учёт.

Что нужно подготовить:

1. Отдельный сервер или хотя бы отдельную информационную базу. Для файлового варианта достаточно папки на диске, для клиент-серверного — отдельной базы в кластере.
2. Эталонную выгрузку .dt. Это база с минимальными данными: организация, склад, 3–5 контрагентов, номенклатура, учётная политика. Перед каждым прогоном база восстанавливается из этой выгрузки, и тесты всегда стартуют с одинакового состояния.
3. Пользователя для тестов. С полными правами или с ролью конкретного сотрудника, если проверяете права. У пользователя должна быть возможность открывать внешние обработки, иначе Vanessa Automation не запустится.
4. Лицензии. Сеанс тест-клиента — обычный клиентский сеанс и занимает лицензию. Менеджер тестирования — ещё один сеанс. Для параллельного прогона в 3 потока закладывайте минимум 6 сеансов.
5. Платформу одной версии на машине тестов и на сервере. Расхождение даёт ошибки подключения, которые выглядят как сбой теста.
6. Открытый порт для связи менеджера с клиентом. Если тест-клиент работает на другой машине, порт из параметра -TPort должен быть открыт в брандмауэре.

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

Как писать приёмочные сценарии на Gherkin

Сценарий — это текстовый файл .feature в кодировке UTF-8. В Vanessa Automation ключевые слова пишутся по-русски.

Структура файла:

• #language: ru — первая строка, включает русские ключевые слова;
• Функционал: — что проверяем, одна фраза;
• Контекст: — шаги, которые выполняются перед каждым сценарием;
• Сценарий: — одна проверка;
• Дано, Когда, Тогда, И — шаги: исходное состояние, действие, ожидаемый результат.

Пример проверки продажи в БП 3.0:

#language: ru

Функционал: Продажа товара со склада

Контекст:
	Дано Я открыл новый сеанс TestClient или подключил уже существующий
	И я закрываю все окна клиентского приложения

Сценарий: Проведение реализации уменьшает остаток
	Когда я открываю навигационную ссылку "e1cib/list/Документ.РеализацияТоваровУслуг"
	И я нажимаю на кнопку с именем 'ФормаСоздать'
	И из выпадающего списка с именем "Контрагент" я выбираю по строке 'Альфа'
	И я нажимаю на кнопку с именем 'ФормаПровестиИЗакрыть'
	Тогда в логе сообщений TestClient нет строки "Не удалось провести"

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

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

• 🎯 Обращайтесь к элементам по имени, а не по заголовку. Заголовок «Провести и закрыть» меняется при локализации и обновлении, имя ФормаПровестиИЗакрыть — реже.
• 🧱 Один сценарий — одна бизнес-проверка. Сценарий на 200 шагов падает в середине, и непонятно, что именно сломалось.
• 🧹 Сценарий не должен зависеть от предыдущего. Если тест 5 работает только после теста 3, параллельный запуск сломает оба.
• 🔁 Повторяющиеся куски выносите в экспортные сценарии. Создание контрагента пишется один раз и вызывается как шаг.
• 📋 Для однотипных проверок используйте Структура сценария с таблицей Примеры. Например, одна проверка на ставки НДС 0, 10 и 20 %.

Запуск тестов в CI/CD

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

Типовой конвейер:

1. Сборка. Из Git (выгрузка конфигурации или расширения в файлы) собирается .cf или .cfe.
2. Подготовка базы. Тестовая база создаётся из эталонного .dt, в неё загружается собранная конфигурация и обновляется структура.
3. Запуск сценариев. vrunner стартует Vanessa Automation с файлом настроек.
4. Публикация результатов. Отчёт jUnit читает CI-сервер, Allure даёт подробный отчёт со скриншотами.
5. Решение. Упал хотя бы один обязательный сценарий — сборка не идёт дальше.

Шаги 1 и 2 выполняет vrunner: команды vrunner init-dev и vrunner update-dev, параметры смотрите в справке vrunner help. Запуск сценариев — vrunner vanessa с указанием файла настроек.

Vanessa Automation можно запустить и без vrunner, напрямую через платформу:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8c.exe" ENTERPRISE /F"C:\TestBase" /N"Тестировщик" /TESTMANAGER /Execute "C:\VA\vanessa-automation.epf" /C"StartFeaturePlayer;VAParams=C:\VA\VAParams.json"

В VAParams.json указывают каталог с .feature-файлами, параметры подключения к тест-клиенту, каталоги отчётов и признак закрытия после прогона. Без этого признака процесс 1С останется висеть, и задание CI не завершится.

Выбор CI-сервера:

Ночной прогон по расписанию лучше начинать после окончания ночных регламентных заданий. Иначе обновление тестовой базы столкнётся с обменом или пересчётом итогов.

Разбор результатов и типичные ошибки внедрения

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

Падение не всегда значит ошибку в доработке. Сначала отделите «настоящие» падения от «шумных»:

• ✅ Настоящее. Поведение изменилось: не проводится документ, не тот остаток, пропала печатная форма. Это и есть находка теста.
• 🌫️ Шумное. Тест не дождался открытия формы, поменялось имя элемента после обновления, в базе остались данные прошлого прогона.

Шумные падения нужно чинить в тот же день. Если набор месяц краснеет «по пустякам», на него перестают смотреть.

Ошибки самого внедрения, а не отдельных тестов:

1. Начать со сложного. Первая цель — 10 дымовых сценариев, которые проходят стабильно. Сквозной процесс «закупка — продажа — закрытие месяца» пишут вторым этапом.
2. Писать тесты без участия пользователя. Программист проверяет то, что сделал, а не то, что нужно бухгалтеру. Ключевой пользователь должен согласовать формулировки Тогда.
3. Не обновлять эталон. Через полгода данные эталонной базы расходятся с учётной политикой нового релиза, и половина тестов падает.
4. Хранить сценарии вне Git. Тест и доработка должны меняться в одном коммите, иначе непонятно, какая версия теста к какой версии кода.
5. Нет владельца. Кто-то один отвечает за то, чтобы красный прогон разбирали утром, а не через неделю.

Частые вопросы