Как проверять конфигурацию 1С: от ручных прогонов до автотестов и CI

Тестирование в 1С — это проверка конфигурации до выпуска в рабочую базу: вручную по сценариям, автоматически через Vanessa Automation и модульные тесты, плюс отладка и замер скорости. Начните с ручных прогонов и встроенной проверки конфигурации. Автотесты подключайте там, где одни и те же сценарии гоняют после каждого обновления.

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

С чего начать: ручное тестирование и верификация функционала

Ручная проверка — основа. Автотест можно написать только на то, что вы уже умеете проверить руками.

Тестовая база и данные

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

1. Сделайте выгрузку рабочей базы (.dt) или копию файловой базы .
2. Разверните её как отдельную информационную базу с понятным именем, например «Тест — после обновления».
3. Отключите в копии регламентные задания, обмены и рассылки. Иначе тестовая база отправит реальные письма контрагентам или заберёт документы из реального обмена.
4. Проверьте, что адреса сервисов (ЭДО, банк, онлайн-кассы) не указывают на боевые контуры.

Сценарии для ручной проверки

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

Для каждого сценария заранее знайте контрольное число. «Вроде похоже» — это не результат проверки.

Что ловят ручные тесты, а что нет

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

💡 Совет: храните контрольную базу с «эталонными» документами. После обновления вы сверяете одинаковые отчёты до и после.

Приёмочное тестирование с пользователями

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

Организуйте проверку просто:

1. Выдайте каждому тестировщику 3-5 живых задач из его повседневной работы, а не «пощёлкайте и скажите».
2. Попросите фиксировать расхождения: что делал, что ожидал, что получил, скриншот.
3. Разберите замечания и разделите их на ошибки, пожелания и недопонимание.
4. Повторите прогон после исправлений, а не ограничивайтесь проверкой правок.

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

Встроенные средства платформы для проверки конфигурации

Прежде чем писать автотесты, используйте то, что уже есть в Конфигураторе.

• 🔍 Синтаксический контроль модуля — ловит опечатки и неизвестные переменные до запуска.
• 🧩 Проверка конфигурации — находит битые ссылки на объекты, ошибки в формах, макетах и правах. Запускается из меню «Конфигурация» в Конфигураторе.
• 📋 Проверка в пакетном режиме — тот же контроль из командной строки, удобно для сервера сборки.

Пакетный запуск выглядит так:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "C:\Bases\Test" /CheckConfig -ConfigLogIntegrity -IncorrectReferences -ThinClient -Server /Out "C:\Temp\check.log"

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

Лог check.log потом можно разбирать скриптом. Пустой лог без ошибок — зелёный результат.

Vanessa Automation: сценарное автотестирование

Vanessa Automation (VA) — бесплатная внешняя обработка для 1С. Она запускает клиент и повторяет действия пользователя по сценарию: нажимает кнопки, заполняет поля, проверяет значения на форме.

Как устроены сценарии

Сценарии пишут на языке Gherkin, он почти читается как обычный русский текст. Файл с расширением .feature хранит один функционал и набор сценариев.

# language: ru

Функционал: Проведение реализации

Сценарий: Реализация товара проводится без ошибок
	Когда я открываю навигационную ссылку "e1cib/list/Документ.РеализацияТоваровУслуг"
	И я нажимаю на кнопку с именем "ФормаСоздать"
	И я перехожу к закладке "Товары"
	И в таблице "Товары" я нажимаю на кнопку "Добавить"
	Тогда открылось окно "Реализация товаров и услуг (создание)"

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

Как запустить первый сценарий

1. Скачайте обработку Vanessa Automation с её страницы проекта и откройте в тестовой базе.
2. Укажите каталог со сценариями (.feature).
3. Настройте запуск клиента тестирования: для этого в базе нужен режим, в котором клиент управляется программно. Подробности есть в документации VA.
4. Нажмите выполнение и следите за шагами.

Многие шаги можно не писать вручную: VA умеет записывать действия пользователя и превращать их в сценарий. Запись даёт черновик, его всё равно придётся править: убирать лишнее и заменять случайные данные.

Где VA окупается

• регресс после каждого обновления релиза;
• типовые цепочки: заказ, реализация, счёт-фактура, оплата;
• проверка прав разных ролей;
• сценарии, которые нужны документам для приёмки доработки.

Модульные тесты и Unit-тесты в 1С

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

Какие фреймворки есть

В сообществе используют несколько инструментов:

• YAxUnit — расширение с набором утверждений и запуском тестов из консоли;
• xUnitFor1C — более ранний фреймворк, у многих он работает до сих пор;
• тесты в составе Vanessa-ADD (Automation Development Tools), которые запускаются из того же окружения.

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

Как писать код, который можно тестировать

Модульным тестом не покрыть процедуру, которая на 400 строк читает форму, пишет в регистр и открывает диалог. Делите логику:

1. Расчёт выносите в отдельную функцию общего модуля, без обращения к форме.
2. Функция принимает параметры и возвращает результат, а не пишет в реквизиты формы.
3. Запросы оборачивайте так, чтобы подставить в них тестовые данные.

Пример структуры теста:

Процедура ТестРасчётСкидки() Экспорт
	Результат = Скидки.РассчитатьСкидку(1000, 10);
	ЮнитТест.ПроверитьРавенство(Результат, 900);
КонецПроцедуры

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

⚠️ Тест должен быть независим от соседних. Если он ждёт, что предыдущий оставил документ в базе, при другом порядке запуска он упадёт без причины.

Отладка кода и анализ производительности

Тест показал, что что-то не так. Теперь нужно понять, где.

Отладчик Конфигуратора

Запуск в режиме отладки — клавиша F5, точка останова — F9. Остановившись на строке, смотрите значения переменных и вычисляйте выражения, а шаги идут по F10 (через вызов) и F11 (внутрь).

Полезные приёмы:

• 🔴 условная точка останова: остановка только для нужного контрагента или документа;
• 📍 остановка по ошибке: удобно ловить исключение, которое «проглатывает» Попытка…Исключение;
• 🧮 окно вычисления выражения: проверить результат запроса, не меняя код.

Скорость: где тормозит

Медленный отчёт или проведение — тоже дефект. Для поиска причин:

Начните с замера: он покажет, какая именно операция просела. Дальше лезьте в технологический журнал и смотрите конкретные запросы.

Непрерывная интеграция: как запускать проверки автоматически

CI (continuous integration) — это когда проверки запускаются сами после каждой правки в репозитории, а не «когда вспомнили».

Что нужно для старта

1. Хранение исходников в Git. Конфигурацию выгружают в файлы: через Конфигуратор или в EDT. Тогда у каждого изменения есть автор и история.
2. Сервер сборки. Подойдёт Jenkins или GitLab CI. Это обычная машина с установленной платформой 1С.
3. Раннер для 1С. Распространён vrunner из проекта vanessa-runner: он запускает платформу, обновляет базу и вызывает тесты.
4. Тестовая база. Её пересоздают из эталона для чистоты прогона.

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

1. Разработчик отправляет изменения в Git.
2. Сервер собирает конфигурацию в тестовую базу из исходников.
3. Запускается проверка конфигурации и синтаксический контроль.
4. Идут модульные тесты.
5. Идёт набор сценариев Vanessa Automation.
6. Результат уходит в отчёт, при падении сборка помечается красной.

Статический анализ кода добавляется отдельным шагом: хорошо работает BSL Language Server и плагин для SonarQube, они указывают на сложные места, дубли и типичные ошибки стиля.

💡 Не пытайтесь с первого дня собрать полный конвейер. Сначала один шаг, проверка конфигурации после каждой правки. Остальное нарастите по очереди.

Стратегия тестирования: что и насколько покрывать

Покрыть тестами всё нельзя и не нужно. Стратегия отвечает на вопрос: на что тратить силы.

Пирамида тестов

• 🔺 Мало дорогих сценариев через интерфейс. Они медленные и хрупкие.
• 🔷 Больше интеграционных проверок: документ проводится, движения верные.
• 🟩 Много быстрых модульных тестов на расчётную логику.

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

Что покрывать в первую очередь

• Расчёты денег: зарплата, НДС, скидки, себестоимость.
• Обработчики проведения и закрытие периода .
• Обмены с внешними системами.
• Права доступа к чувствительным данным.
• Всё, что уже ломалось раньше: каждый найденный баг превращайте в тест.

Покрытие кода

Платформа и сторонние инструменты умеют показывать, какие строки кода выполнились во время тестов. Это полезно для поиска «слепых зон», но цель в 100% ставить не стоит. Покрытие 100% не гарантирует отсутствие ошибок, потому что тест может выполнить строку и не проверить результат.

Ориентир для старта: начните с критичных модулей, а общий процент не гоните. Ценнее честные проверки на деньги и проведение.

Когда автотесты делать не нужно

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

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