Тестирование релизов 1С: четыре уровня от дешёвых проверок до пользовательской приёмки

14 мая 2026 · infolimp.ru

Автор: 1С Инсайдер · роль: практик 1С · проверка: типовые конфигурации и рабочие сценарии · 0 комментариев

Чем «релиз 1С» отличается от обычного ПО

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

Что у вас уже есть, даже если вы об этом не думали

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

Это базовая страховочная сетка. Она ловит явные катастрофы, но не ловит «вроде работает, но при проведении документа сумма стала на 1 копейку меньше».

Уровни тестирования — от дешёвого к дорогому

1. Smoke-тесты

Самые дешёвые. Цель — поймать «совсем не запускается». Базовый набор: проводится главная форма, открываются три самых частых документа, формируется один отчёт, делается одна типовая операция. Если хотя бы что-то падает — релиз останавливают, и причина расследуется до прохода дальше.

Smoke можно запустить как простую обработку в Конфигураторе:

// Простой smoke-набор: проверяем, что ключевые операции не падают
Процедура ВыполнитьSmokeПроверки() Экспорт

    Ошибки = Новый Массив;

    Попытка
        // 1. Документы открываются
        Реализация = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
        Реализация = Неопределено;
    Исключение
        Ошибки.Добавить("Создание реализации: " + ОписаниеОшибки());
    КонецПопытки;

    Попытка
        // 2. Базовый запрос к регистру отрабатывает
        Запрос = Новый Запрос("ВЫБРАТЬ ПЕРВЫЕ 1 Ссылка ИЗ Справочник.Контрагенты");
        Запрос.Выполнить();
    Исключение
        Ошибки.Добавить("Запрос к контрагентам: " + ОписаниеОшибки());
    КонецПопытки;

    Если Ошибки.Количество() = 0 Тогда
        ЗаписьЖурналаРегистрации("Smoke.Прошло",
            УровеньЖурналаРегистрации.Информация);
    Иначе
        Для Каждого ТекстОшибки Из Ошибки Цикл
            ЗаписьЖурналаРегистрации("Smoke.Провал",
                УровеньЖурналаРегистрации.Ошибка, , , ТекстОшибки);
        КонецЦикла;
    КонецЕсли;

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

Запускается одной командой после обновления. Если в журнале появилось «Smoke.Провал» — релиз не катят пользователям, идут разбирать.

2. Регрессионные сценарии

Это уже про «работает так же, как раньше». Если правок в конфигурации мало и релизы — это типовые обновления вендора, регрессионные сценарии можно вести вручную по чек-листу. Автоматизация через xUnit-фреймворк (на рынке несколько вариантов — Vanessa Automation, ADD, xUnitFor1C, YAxUnit; выбор по тому, что уже использует команда) окупается, когда правок много и релизы регулярные. Принцип общий: фиксируете набор бизнес-цепочек (создал заказ → отгрузил → провёл реализацию → начислил налоги), запускаете до обновления, сохраняете результат, повторяете после обновления — сравниваете. Расхождение — основание разобраться.

3. Нагрузочное тестирование

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

4. Пользовательская приёмка

Самый дорогой уровень — час бухгалтера стоит больше часа автотеста. Поэтому пользовательскую приёмку применяют точечно: бухгалтер открыл свой рабочий день, попробовал три ключевые операции, подтвердил. Не «протестируйте всю систему» — а «откройте свой обычный сценарий и скажите, заметили ли вы разницу».

Не пытайтесь сразу выстроить все четыре уровня. Начните с первого — smoke на каждом релизе. Когда он стал привычным и не съедает время — добавьте регрессию на ключевые сценарии. Дальше по мере роста команды и критичности системы. Пытаться внедрить всё разом — гарантированный способ потратить квартал и не получить ничего.

Чек-лист «как собрать процесс за месяц»

1. Определите, что у вас «релиз». В одних командах это коммит в конфигурацию, в других — пакет изменений раз в неделю, в третьих — выгрузка от вендора 1С. Без определения процесс не построить.
2. Сделайте копию продуктива на отдельном сервере. На этой копии будут идти все тесты — на проде ничего не трогается до прохождения проверок. Если в базе есть персональные данные или коммерческая тайна — копию обезличивают перед использованием. Для очень больших баз вместо полной копии берут срез по периоду или подсистеме.
3. Напишите Smoke-обработку из 5–10 проверок. Это вечер работы, но он окупается на первой же поломке релиза.
4. Определите 3–5 регрессионных сценариев в виде «что делает пользователь от и до». Сохраните как описание процесса — даже если автоматизировать пока не будете, это уже артефакт для будущего.
5. Договоритесь с бизнесом: какие пользователи готовы участвовать в приёмке, как часто, в каком окне.
6. На третий-четвёртый цикл начните автоматизировать регрессию через выбранный xUnit-фреймворк — к этому моменту вы уже знаете, какие сценарии стоит автоматизировать первыми.
7. Раз в квартал пересматривайте набор тестов: что устарело, что нужно добавить, какие проверки больше не ловят реальных проблем.

Типичные ошибки

• «Сначала автоматизируем всё, потом будем тестировать». Полгода тратится на инфраструктуру тестов, релизы идут без проверок. Лучше неделя smoke и регулярные релизы, чем идеальный CI через полгода.
• Тесты на пустой демо-базе. Smoke на пустой базе показывает, что код запускается, но не показывает, что данные миграции прошли корректно. Только копия продуктива.
• Без копии продуктива. «Накатим обновление сразу на бою, если что-то сломается — откатим». Откатить без потери данных можно только из резервной копии, сделанной непосредственно перед обновлением; «просто вернуть конфигурацию назад» нельзя, потому что обновление меняет и данные. Копия продуктива — обязательный артефакт релизного процесса.
• Только пользовательская приёмка. «Тестируют пользователи, технических тестов нет». На небольших командах с простым контуром учёта это может закрывать основные риски, но по мере роста объёма и сложности учёта только приёмки становится недостаточно — нужны smoke и регрессия.
• Не фиксируем критерии прохождения. Тест запускается, что-то выводится, никто не понимает, прошёл ли он. Каждый сценарий должен иметь явный «ожидаемый результат» — иначе тест бессмыслен.
• Релиз катят, не дождавшись завершения тестов. «Тесты идут, но мы уже катим — потом исправим если что». В половине случаев исправить «потом» дороже, чем подождать час.