Как организовать автоматическое тестирование в 1С:УПП и конфигурациях на обычных формах

← На главную

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

Главное ограничение обычных форм в 1С

Штатный механизм автоматизированного тестирования платформы «1С:Предприятие 8.3» (режим запуска /TestManager, клиенты и менеджеры тестирования) предназначен исключительно для **управляемых форм**. В толстом клиенте на обычных формах нет встроенных средств платформы для эмуляции действия пользователя (кликов, интерактивного ввода данных) или записи пользовательских сценариев с экрана.

Кроме того, в решениях на базе УПП значительная часть логики (проверки заполнения, вычисления, вызовы алгоритмов) исторически располагается непосредственно в модулях обычных форм, а не в модулях объектов или менеджеров. Это создает трудности при попытке протестировать функции системы без открытия форм.

Подход 1. Регламентный прогон и контроль движения по регистрам

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

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

Такой подход позволяет отловить до 80% критических ошибок в бизнес-логике, возникающих при обновлении конфигурации или доработке модулей проведение документов.

Подход 2. Модульное и интеграционное тестирование (Backend-тесты)

Если необходимо проверять конкретные алгоритмы и функции backend-логики, тестирование переносится с уровня форм на уровень программного кода 1С. Для этого используются специализированные фреймворки: xUnitFor1C или его современный аналог YAXUnit.

Суть метода заключается в том, что разработчик создает программные модули, которые создают объект (например, документ РеализацияТоваровУслуг), заполняют его реквизиты, заставляют записаться и провериться на выходе.

Проанализируем пример структуры программного теста, создающего документ и проверяющего факт его проведения:


Процедура Тест_ПроведениеДокументаРеализация() Экспорт

    // 1. Подготовка тестовых данных
    ДокументОбъект = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
    ДокументОбъект.Дата = ТекущаяДата();
    ДокументОбъект.Организация = Справочники.Организации.НайтиПоКоду("000000001");
    ДокументОбъект.Контрагент = Справочники.Контрагенты.НайтиПоКоду("000000001");
    
    // Заполнение табличной части
    СтрокаТЧ = ДокументОбъект.Товары.Добавить();
    СтрокаТЧ.Номенклатура = Справочники.Номенклатура.НайтиПоКоду("000000001");
    СтрокаТЧ.Количество = 1;
    СтрокаТЧ.Цена = 100;
    СтрокаТЧ.Сумма = 100;

    // 2. Выполнение тестируемого действия
    ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);

    // 3. Проверка результатов (Assert)
    Утверждения.ПроверитьИстину(ДокументОбъект.Проведен, "Документ должен быть успешно проведен");

КонецПроцедуры

Основные преимущества фреймворков семейства xUnit:

Простота и скорость: тесты выполняются быстро, так как не тратится время на отрисовку графического интерфейса.
Чистота кода: заставляет разработчиков выносить бизнес-логику из модулей обычных форм в экспортные процедуры модулей объектов и менеджеров.
Интеграция с CI/CD: результаты выполнения тестов легко выгружаются в форматах JUnit/Allure для систем автоматической сборки (Jenkins, GitLab CI).

Подход 3. Сценарии BDD и привлечение бизнес-аналитиков

Инструмент Vanessa-Behavior позволяет описывать тестовые сценарии на естественном языке Gherkin (файлы с расширением .feature). Это даёт возможность бизнес-аналитикам принимать участие в составлении тестов.

Однако при работе с УПП на обычных формах сценарии Gherkin не могут управлять кликами мыши по кнопкам формы. Вместо интерфейсных шагов аналитик описывает бизнес-действия, за которыми скрываются серверные процедуры 1С:


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

Сценарий: Расчет скидки для оптового покупателя
    Дано Я создаю документ "Заказ Покупателя"
    И Указываю контрагента "Покупатель Опт"
    Когда Я вызываю перерасчет цен в документе
    Тогда Сумма документа должна быть равна "9000"

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

Организация тестового окружения

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

Использование эталонного снимка: перед каждым запуском тестовых сценариев тестовая база данных должна восстанавливаться из чистого снимка (дампа СУБД) или обновляться до начального состояния.
Автоматизация через OneScript: запуск платформы 1С, прогон тестов и формирование отчетов автоматизируются с помощью скриптов OneScript без участия пользователя.
Изоляция логики: при доработке конфигурации следует строго разграничивать интерфейсную часть формы и прикладную бизнес-логику, вынося алгоритмы расчетов в экспортные функции общих модулей.