Пятница, 17:40. Разработчик выкатил обновление конфигурации — небольшая правка в модуле ценообразования. Тестировщик проверил скидки, всё работает. Обновили рабочую базу. Суббота, 09:12 — звонок от магазина: возвраты не проводятся. Кассир пробует оформить возврат товара — документ падает с ошибкой «Поле объекта не обнаружено». Очередь из покупателей растёт. Администратор магазина звонит в IT-отдел, IT-отдел звонит разработчику. Разработчик открывает ноутбук, ищет проблему, откатывает обновление. Час простоя, недовольные клиенты, испорченные выходные.
Правка в ценообразовании не имела прямого отношения к возвратам. Но она затронула общий модуль, который использовался при проведении — и побочный эффект проявился в совершенно другом месте. Ручное тестирование проверило то, что менялось. Автотест проверил бы всё, что могло сломаться.
Почему ручное тестирование 1С не работает
Ручное тестирование создаёт иллюзию контроля. Тестировщик проверяет изменённый функционал, убеждается, что «работает», ставит галочку. Проблема в том, что конфигурации 1С — это не изолированные модули. Это плотно связанная система, где изменение в одном документе может повлиять на десяток других через общие модули, подписки на события, регламентные задания, механизмы проведения.
Кастомная конфигурация розничной сети, с которой мы работали, содержала более 400 объектов метаданных. Модуль обработки заказов имел цикломатическую сложность 369 — это означает 369 независимых путей выполнения кода. Ни один тестировщик не в состоянии вручную пройти все 369 ветвлений при каждом обновлении. Даже если выделить на это целый день — а в реальности тестирование занимает час-два перед релизом.
Вторая проблема — повторяемость. Человек устаёт, пропускает шаги, по-разному заполняет документы от раза к разу. Баг, который зависит от конкретной комбинации реквизитов (сумма предоплаты больше нуля, частичный возврат, контрагент с особыми условиями), может не воспроизводиться месяцами — пока кассир не создаст именно такую комбинацию в рабочей базе.
Третья проблема — масштабирование. Каждая новая доработка увеличивает количество сценариев, которые нужно проверять. Через год объём ручного тестирования удваивается, через два — утраивается. Команда тестирования не растёт пропорционально, и всё больше сценариев остаётся непроверенными. Регрессии накапливаются.
Автоматические тесты решают все три проблемы. Они проверяют все заданные сценарии при каждом обновлении. Они воспроизводят одни и те же шаги с точностью до миллисекунды. И они масштабируются линейно: добавить новый сценарий — это написать текст, а не нанять ещё одного человека.
BDD-подход: сценарии на языке бизнеса
BDD — Behavior-Driven Development — это методология, в которой тесты описываются на языке, понятном бизнесу. Не «вызвать процедуру ОбработкаПроведения с параметрами X, Y, Z», а «Когда кассир оформляет возврат предоплаченного заказа, тогда сумма возврата равна сумме оплаты».
Формат описания — Gherkin. Три ключевых слова: Допустим (начальное состояние), Когда (действие), Тогда (ожидаемый результат). На русском языке — платформа Vanessa поддерживает русскоязычные ключевые слова из коробки.
Пример сценария для создания заказа клиента:
Сценарий: Создание заказа клиента с двумя товарами
Допустим я открываю форму документа "Заказ клиента"
И я заполняю поле "Контрагент" значением "Розничный покупатель"
Когда я добавляю строку в табличную часть "Товары"
И я выбираю значение "Кабель HDMI 2м" в поле "Номенклатура"
И я указываю количество "3"
И я добавляю ещё одну строку
И я выбираю значение "Адаптер USB-C" в поле "Номенклатура"
И я указываю количество "1"
Тогда сумма документа равна сумме всех строк
И документ проводится без ошибок
И движения по регистру "Заказы клиентов" сформированыКлючевое преимущество: этот сценарий может прочитать руководитель отдела продаж. Он понимает, что проверяется, и может подсказать, какие ситуации не учтены. «А что если контрагент с предоплатой? А если товар под заказ?» Каждый такой вопрос — потенциальный сценарий, который предотвращает баг до того, как он доберётся до рабочей базы.
BDD меняет процесс: тестирование перестаёт быть финальным этапом и становится частью проектирования. Сценарии пишутся до кода — как техническое задание, только исполняемое. Разработчик видит, что именно должен делать код, и может убедиться, что реализация соответствует ожиданиям, запустив тесты ещё до передачи в тестирование.
Как мы внедряли Vanessa-Automation
Vanessa-Automation — инструмент для BDD-тестирования 1С. Он запускает клиент 1С, эмулирует действия пользователя (нажатия кнопок, заполнение полей, навигация по формам), проверяет результаты. Сценарии описываются на Gherkin, шаги привязаны к предустановленной библиотеке действий — «открыть форму», «заполнить поле», «нажать кнопку», «проверить значение».
Проект: розничная сеть, кастомная конфигурация на базе 1С:Управление торговлей, более 200 пользователей, ежедневные изменения. После каждого обновления — регрессии. Ломались возвраты, ценообразование, формирование заказов. Каждый раз — в разных местах.
Этап 1: аудит критических путей
Начинать с покрытия «всего» — ошибка. Мы начали с того, что приносит деньги и ломается чаще всего. Совместно с бизнесом определили пять критических бизнес-процессов:
- Создание и проведение заказа клиента.
- Оформление возврата (полного и частичного).
- Расчёт и применение скидок.
- Приёмка товара и оприходование.
- Формирование отчёта по продажам за период.
Для каждого процесса выписали варианты: заказ с предоплатой, заказ с доставкой, заказ со скидкой по промокоду, возврат полный, возврат частичный, возврат предоплаченного заказа. Получилось 42 сценария на первую итерацию.
Этап 2: подготовка тестовой среды
Отдельная база для тестирования — копия рабочей структуры, но с фиксированными данными. Справочник контрагентов: «Тестовый розничный», «Тестовый оптовый», «Тестовый с предоплатой». Справочник номенклатуры: 15 позиций с заранее известными ценами. Перед каждым прогоном — восстановление базы из эталонного бэкапа. Это гарантирует, что тесты не зависят друг от друга и результат одного прогона не влияет на следующий.
Этап 3: написание сценариев и отладка шагов
Библиотека шагов Vanessa покрывает типовые действия: работу с формами, табличными частями, командами панели. Для специфической логики пришлось написать собственные шаги — 23 кастомных шага для работы со скидками, промо-механиками и нестандартными контролями при проведении.
Самый сложный сценарий — частичный возврат предоплаченного заказа. Двойная негация количества: в документе возврата количество положительное, но движения по регистрам — со знаком минус, а сумма возврата пересчитывается с учётом уже возвращённой части предоплаты. Три связанных документа (заказ, оплата, возврат), четыре регистра, два контроля остатков. Один сценарий потребовал 34 шага и покрывал ситуацию, которая при ручном тестировании проверялась «ну вроде работает».
Этап 4: статический анализ как дополнение
Параллельно с BDD-тестами подключили BSL Language Server для статического анализа кода. Это не замена функциональных тестов, но дополнительный рубеж защиты. Анализатор проверяет код на типичные ошибки: неиспользуемые переменные, пустые блоки исключений, запросы в цикле.
Правило CreateQueryInCycle срабатывало на конструкцию с Выполнить() внутри цикла — разработчик формировал текст запроса динамически и выполнял его на каждой итерации. Технически это не «запрос в цикле» в классическом понимании, но анализатор справедливо указал на потенциальную проблему производительности. Рефакторинг — вынос запроса из цикла с параметризацией — ускорил обработку партий заказов втрое.
Отдельная находка: три бага, которые маскировали друг друга. В одном модуле обработки возвратов обнаружились одновременно пустая ссылка (обращение к реквизиту незаполненного поля), ложное совпадение при вызове НайтиПоРеквизиту (метод находил «не тот» элемент из-за неуникального значения реквизита) и опечатка в имени переменной (кириллическая «о» вместо латинской в идентификаторе). Каждый баг в отдельности приводил к ошибке, но вместе они компенсировали друг друга: пустая ссылка обходила ветку с ложным совпадением, а опечатка приводила к использованию переменной по умолчанию, которая случайно содержала корректное значение. Исправление любого одного бага «ломало» систему, потому что оставшиеся два переставали компенсироваться. Только исправление всех трёх одновременно дало корректный результат. Без статического анализа и автотестов найти эту связку методом «поменял — проверил» было бы крайне сложно.
Интеграция с CI/CD — тесты при каждом коммите
Автотесты без автоматического запуска — это библиотека, которую никто не читает. Чтобы тесты работали, они должны запускаться при каждом изменении кода, без участия человека.
Мы интегрировали Vanessa-тесты в CI/CD-пайплайн на GitHub Actions с self-hosted раннером. Раннер — машина внутри контура заказчика, на которой установлена платформа 1С и тестовая база. Последовательность при каждом пуше в ветку develop:
- BSL Lint. Статический анализ кода. 1–2 минуты. Если код не проходит проверку — пайплайн останавливается, разработчик получает отчёт.
- Восстановление тестовой базы. Эталонный бэкап разворачивается в тестовую базу. 3–4 минуты. Чистое состояние для каждого прогона.
- Загрузка конфигурации. Изменения из ветки загружаются в тестовую базу. 5–7 минут.
- Прогон Vanessa-тестов. Все 148 сценариев. 23 минуты. Результат — Allure-отчёт со скриншотами каждого шага.
- Уведомление. Результат в Telegram: зелёный — все тесты прошли, красный — список упавших сценариев со ссылками на отчёт.
Суммарное время пайплайна — около 35 минут. Это дольше, чем деплой без тестов, но существенно быстрее, чем разбор инцидента в субботу утром.
Важная деталь: тесты запускаются в headless-режиме — без отображения интерфейса 1С на экране. Vanessa управляет клиентом через COM-соединение. Это позволяет запускать тесты на сервере без GUI, в том числе ночью по расписанию.
Правило, которое мы установили: merge в ветку productive (рабочая база) возможен только при зелёных тестах. Технически это реализовано через GitHub branch protection rules — pull request в productive не принимается, пока статус «vanessa-tests» не станет «success». Ни один разработчик не может обойти это правило, даже с правами администратора репозитория.
Отдельно про Allure-отчёты. Каждый упавший сценарий сопровождается скриншотом экрана 1С в момент ошибки, полным логом шагов и временем выполнения каждого шага. Разработчик открывает отчёт, видит: «Шаг 18: нажать кнопку Провести — ошибка через 2.3 секунды», скриншот с сообщением платформы. Диагностика, которая раньше занимала час («а что именно не работает? а как воспроизвести?»), сокращается до минут.
При необходимости внести изменения в типовую конфигурацию — например, когда типовая 1С не покрывает требования бизнеса — автотесты становятся страховочной сетью. Они гарантируют, что доработка не сломает существующий функционал. А при выборе между расширением и прямой доработкой конфигурации тесты позволяют объективно оценить влияние изменений на систему.
Результаты: цифры за полгода
Внедрение заняло шесть недель: две недели на аудит и настройку инфраструктуры, четыре — на написание и отладку сценариев. После запуска в промышленную эксплуатацию собрали статистику за полгода.
148 BDD-сценариев. Покрытие пяти критических бизнес-процессов: заказы, возвраты, скидки, приёмка, отчётность. Каждый сценарий — конкретная бизнес-ситуация, а не абстрактный юнит-тест.
23 минуты — время полного прогона. Все 148 сценариев на выделенном раннере. Достаточно быстро, чтобы запускать при каждом коммите, а не откладывать на ночь.
34 бага поймано до продакшена. Каждый из них прошёл бы через ручное тестирование — потому что тестировщик проверяет то, что изменилось, а не то, что могло сломаться косвенно. Среди найденного: некорректный расчёт скидки при комбинации двух промо-акций, потеря строки табличной части при копировании документа, ошибка округления при частичном возврате в валюте.
0 инцидентов от обновлений за полгода. До внедрения автотестов в среднем два-три инцидента в месяц. После — ни одного. Не потому что разработчики стали писать идеальный код, а потому что каждая ошибка обнаруживалась и исправлялась до того, как попадала в рабочую базу.
Экономический эффект. Один инцидент в рознице — это час простоя магазина, время разработчика на диагностику и откат, время администратора на восстановление, потерянные продажи. Консервативная оценка: один инцидент обходился компании в 200–400 BYN прямых затрат, не считая репутационных. 15–18 предотвращённых инцидентов за полгода — это 3 000–7 000 BYN экономии. При затратах на внедрение (наши услуги + время команды заказчика на участие в аудите и приёмке) вложения окупились за три месяца.
Побочный эффект, которого мы не ожидали: разработчики стали писать код иначе. Зная, что каждое изменение пройдёт через 148 проверок, они начали декомпозировать модули, выносить логику в отдельные функции, избегать неявных зависимостей. Цикломатическая сложность модуля обработки заказов за полгода снизилась с 369 до 214 — не потому что кто-то поставил такую цель, а потому что тестируемый код по своей природе проще и чище.
Автотесты для 1С — это не серебряная пуля и не модный тренд. Это инженерная практика, которая превращает обновление конфигурации из стрессового события в рутинную операцию. 148 сценариев работают 23 минуты и делают то, что команда тестировщиков не способна сделать за целый день: проверить каждый критический путь, каждую комбинацию данных, каждый раз одинаково.
Практический совет для тех, кто рассматривает внедрение: не пытайтесь покрыть тестами всю конфигурацию за один подход. Начните с пяти самых болезненных сценариев — тех, по которым чаще всего звонят пользователи. Первые результаты появятся через две-три недели. Когда команда увидит, что тесты реально ловят баги — расширение покрытия пойдёт само. Разработчики начнут добавлять сценарии при каждой доработке, потому что это быстрее, чем объяснять тестировщику, что именно нужно проверить.
