Как выстроить проверку кода и конфигурации в 1С перед релизом
Содержание
Начните с малого: возьмите три самых денежных сценария (например, проведение реализации, расчёт зарплаты, выгрузку отчёта) и проверяйте их после каждого обновления по одному и тому же чек-листу. Это уже тестирование. Автотесты, BDD и CI добавляются поверх, когда ручные прогоны начинают занимать часы.
Организовать тестирование в 1С можно на трёх уровнях: проверки самой конфигурации, модульные тесты кода и сквозные сценарии «как пользователь». Ниже — что на каждом уровне делать, какими инструментами и в каком порядке их подключать.
Какие бывают виды тестирования в 1С
Сначала разложим проверки по уровням. Так проще понять, что автоматизировать в первую очередь.
| Уровень | Что проверяем | Чем | Скорость |
|---|---|---|---|
| Статический анализ | Синтаксис, мёртвый код, плохие приёмы | Проверка конфигурации, BSL Language Server, SonarQube | Секунды |
| Модульный | Отдельные процедуры и функции | xUnitFor1C, YAxUnit | Секунды–минуты |
| Интеграционный | Проведение документов, обмены, запросы | Те же xUnit-фреймворки на тестовой базе | Минуты |
| Сквозной (UI) | Сценарий глазами пользователя | Vanessa Automation, Тестировщик | Минуты–часы |
| Ручной | Новые функции, внешний вид, нестандартные случаи | Чек-листы, тест-кейсы | Часы |
Классическая «пирамида»: много быстрых модульных тестов внизу, немного медленных UI-сценариев наверху. В 1С она часто перевёрнута: есть только ручная проверка и пара сценариев в интерфейсе. Это рабочий старт, но дорогой в поддержке.
Статический анализ даёт больше всего пользы за минимум усилий. Настройте его первым, до любых автотестов.
Ручное тестирование: тест-кейсы и чек-листы
Ручная проверка нужна всегда. Автотест не заметит, что кнопка уехала за край формы или что подсказка путает пользователя.
Чтобы ручной прогон не превращался в «потыкали, вроде работает», фиксируйте три вещи:
- 📌 Исходные данные. Какая база, какие остатки, какой пользователь и с какими правами.
- 📌 Шаги. Нумерованный список действий до уровня «открыть документ, нажать Провести».
- 📌 Ожидаемый результат. Конкретно: «сумма НДС 2 000», «движения по регистру остатков — 3 строки».
Типовой набор проверок после обновления конфигурации:
- Открыть и записать по одному документу каждого ключевого вида.
- Провести документ задним числом и проверить, что итоги не «поплыли».
- Сформировать 3–5 основных отчётов и сравнить цифры с контрольными.
- Выполнить регламентные операции: закрытие месяца , обмен.
- Зайти под пользователем с ограниченными правами и убедиться, что нужное доступно, а лишнее нет.
Тестируйте на копии, а не в рабочей базе. Даже безобидный документ может запустить обмен или регламентное задание и уйти во внешнюю систему.
Автоматизация модульных тестов: xUnit для 1С
Модульный тест вызывает процедуру или функцию с известными входными данными и сравнивает результат с ожидаемым. Для 1С есть два распространённых открытых фреймворка: xUnitFor1C (давний, на его принципах построены многие проекты) и YAxUnit (более новый, с актуальными возможностями).
Что обычно тестируют модульно:
- 🔹 Расчётные функции: округления, ставки, периоды.
- 🔹 Разбор и формирование строк, XML и JSON.
- 🔹 Процедуры обработки данных, которые можно вызвать без интерфейса.
- 🔹 Тексты запросов: на тестовых данных запрос должен вернуть ожидаемые строки.
Пример теста в стиле утверждений:
Процедура ТестДолжен_РассчитатьНДС() Экспорт
Результат = РасчетыСервер.СуммаНДС(12000, 20);
// 12000 * 20 / 120 = 2000
ЮТест.ОжидаетЧто(Результат).Равно(2000);
КонецПроцедуры
Точные имена методов зависят от выбранного фреймворка и его версии. Сверяйтесь с документацией проекта, а не с примером выше.
Чтобы код вообще можно было тестировать, его приходится готовить:
- вынесите логику из обработчиков форм в общие модули;
- не обращайтесь внутри расчётной функции к глобальному состоянию (текущая дата, текущий пользователь), а передавайте их параметрами;
- разделяйте «получить данные» и «посчитать по данным».
Это полезная дисциплина и без тестов. Код становится короче и понятнее.
Сквозные сценарии: Vanessa Automation и BDD
Vanessa Automation запускает сценарии на языке Gherkin: человек пишет шаги на русском, а система выполняет их в реальном клиенте 1С. Идея BDD в том, что сценарий читают и аналитик, и разработчик, и тестировщик.
Фрагмент сценария:
Функционал: Реализация товаров
Сценарий: Проведение реализации с НДС 20%
Когда я открываю навигационную ссылку "e1cib/list/Документ.РеализацияТоваровУслуг"
И я нажимаю на кнопку с именем "ФормаСоздать"
И из выпадающего списка с именем "Организация" я выбираю по строке "Тестовая организация"
И я нажимаю на кнопку с именем "ФормаПровести"
Тогда в логе сообщений не должно быть ошибок
Что важно знать до внедрения:
- 🎯 Сценарий управляет клиентом через тестовый режим запуска 1С, поэтому нужна отдельная тестовая база и лицензия на сеанс клиента.
- 🎯 Шаги привязаны к именам элементов формы. Переименовали кнопку, и сценарий упал. Держите имена стабильными.
- 🎯 Сценарий должен сам готовить данные, а не рассчитывать на то, что «в базе что-то есть».
- 🎯 Начинайте с 5–10 сценариев на самые критичные процессы. Сотня хрупких UI-тестов станет обузой.
Vanessa Automation умеет записывать действия пользователя и превращать их в заготовку сценария. Заготовку всё равно придётся чистить руками: запись фиксирует всё подряд, включая случайные клики.
Покрытие кода и метрики качества
Покрытие показывает, какая доля строк кода выполнилась во время прогона тестов. Для 1С его замеряют через отладчик платформы: инструмент подключается к серверу отладки, собирает выполненные строки и строит отчёт. Популярное решение — Coverage41C, его результат можно отдать в SonarQube.
Как читать цифры:
- 100% покрытия не нужны и недостижимы. Ориентир для расчётного ядра — 70–80%, для остального кода планка ниже.
- Покрытие не равно качеству. Тест без проверок ничего не утверждает, но строки «покрывает».
- Полезнее смотреть на динамику: новый код без тестов — повод для вопроса на ревью.
Другие метрики, которые стоит собирать:
| Метрика | Что показывает |
|---|---|
| Число замечаний статического анализа | Состояние кодовой базы |
| Время прогона набора тестов | Можно ли запускать его на каждый коммит |
| Доля «мигающих» тестов | Падают без изменений в коде: их надо чинить или удалять |
| Ошибки, найденные в рабочей базе после релиза | Реальное качество проверки |
Покрытие кода через отладчик замедляет прогон в несколько раз. Включайте его в ночных запусках, а не на каждый коммит.
Непрерывная интеграция: запуск тестов без участия человека
CI нужен, чтобы проверки запускались сами при каждом изменении, а не «когда вспомнили». Типовая цепочка выглядит так:
- Разработчик отправляет изменения в Git.
- Сервер сборки (Jenkins, GitLab CI или аналог) забирает код.
- Создаётся чистая тестовая база и в неё загружается конфигурация.
- Запускаются статический анализ, модульные тесты, сценарии.
- Результат возвращается автору: зелёный или красный, с отчётом.
Основные «кирпичики» для сборки:
- Платформа в пакетном режиме. Запуск конфигуратора без интерфейса с параметром
/DisableStartupDialogsи командами загрузки и обновления конфигурации. - EDT и формат исходников. Исходный код в файлах (формат EDT или выгрузка конфигуратора) нормально сравнивается и ревьюится в Git. Для бинарного
.cfэто невозможно. - OneScript. Удобен для скриптов сборки: создание базы, запуск тестов, разбор результатов.
Пример запуска проверки конфигурации из командной строки:
"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F "C:\bases\test" /CheckConfig -ConfigLogIntegrity -IncorrectReferences /Out "C:\logs\check.log" /DisableStartupDialogs
Путь и версию подставьте свои. Набор ключей проверки зависит от версии платформы, полный список смотрите в справке к конфигуратору.
Полный CI с первого дня строить не нужно. Хватит ночной сборки по расписанию: она уже ловит большинство регрессий и показывает, что тесты вообще живы.
Тестовые данные: откуда их брать и как не навредить
Половина проблем с автотестами — не в коде, а в данных. Тест, который зависит от «живых» остатков, сегодня зелёный, завтра красный.
Три рабочих подхода:
- Создавать данные в самом тесте. Тест сам заводит контрагента, номенклатуру и документ-основание. Медленнее, зато независим и понятен.
- Эталонная база. Небольшая выгрузка с типовым набором данных, которую разворачивают перед прогоном. Быстро, но эталон надо обновлять вместе с конфигурацией.
- Обезличенная копия рабочей базы. Подходит для ручной приёмки. Перед использованием замените реальные ИНН, телефоны, почту и расчётные счета, а обмены и рассылки отключите.
Что настроить в тестовой базе сразу:
- 🔒 отключить регламентные задания, которые отправляют письма, платежи и данные во внешние системы;
- 🔒 сменить адреса веб-сервисов и обменов на тестовые;
- 🔒 завести пользователей с разными ролями: полный доступ, бухгалтер, менеджер, только чтение;
- 🔒 зафиксировать дату или проверять результат относительно текущей, а не по «зашитым» числам.
Если в базе остались настройки рабочего обмена, один «Провести» из теста может уйти в реальную систему. Проверьте соединения до первого запуска.
Что проверить перед стартом проекта по тестированию
Прежде чем покупать время разработчика, ответьте себе на пять вопросов:
- Есть ли отдельная тестовая база и кто отвечает за её актуальность?
- Лежит ли код в системе контроля версий?
- Кто принимает решение «релиз можно выпускать» и по каким критериям?
- Какие 3–5 процессов нельзя ломать ни при каком обновлении?
- Сколько времени сейчас уходит на ручную приёмку одного обновления?
Последний ответ — главный довод. Посчитайте так: часы приёмки в месяц умножьте на стоимость часа специалиста и сравните с разовыми затратами на автоматизацию. Разница и есть срок окупаемости.
Первые автотесты лучше поручить тому, кто знает предметную область, а не только язык 1С: сценарий должен проверять бизнес-смысл, а не просто «форма открылась».
После запуска раз в квартал пересматривайте набор: удаляйте сценарии по отключённым функциям и добавляйте те, где за период нашли реальные ошибки. Если приёмка занимает два часа раз в квартал, автотесты окупятся нескоро. Если шесть часов раз в неделю, окупятся за пару месяцев.
Типичные ошибки при организации тестирования
- ❌ Тесты на рабочей базе. Риск уйти во внешние системы и испортить данные. Только копия.
- ❌ Зависимость тестов друг от друга. Тест № 5 падает, если не прошёл № 4. Каждый тест готовит данные сам.
- ❌ Тесты на внешнем виде. Привязка к координатам и тексту подсказок ломается при любой правке формы.
- ❌ Игнор красных тестов. Если «упавший» набор привычно красный, на него перестают смотреть.
- ❌ Автоматизация всего подряд. Сначала проверьте, что сценарий повторяется и приносит деньги.