Проверка конфигурации 1С перед обновлением: тестовая база, сценарии, нагрузка, откат

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

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

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

Подготовка тестового стенда: копия базы и изоляция

Тестовая база должна быть максимально похожа на рабочую: те же данные, версия платформы, режим работы (файловый или клиент-серверный) и набор расширений. Иначе вы проверите не то, что будет работать у пользователей.

Как получить копию

1. Дождитесь окончания рабочего дня или попросите всех выйти из базы.
2. Откройте базу в Конфигураторе и выберите Администрирование → Выгрузить информационную базу.
3. Разверните выгруженный .dt-файл в новой пустой базе: Администрирование → Загрузить информационную базу.

То же из командной строки (удобно для автоматизации):

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\bases\work" /DumpIB "D:\backup\work.dt"
"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\bases\test" /RestoreIB "D:\backup\work.dt"

Номер платформы в пути подставьте свой. Для клиент-серверной базы вместо /F "путь" указывают /S "сервер\имя_базы".

Что отключить в копии

Скопированная база помнит все внешние связи рабочей. Если их не отключить, тестовая база начнёт жить своей жизнью:

• 📧 Почта и рассылки. Регламентные задания отправят письма настоящим контрагентам.
• 🔄 Обмены. Обмен с сайтом, банком, другой базой запишет тестовые данные в боевые контуры.
• ⏰ Регламентные задания. Отключите всё, что не нужно для проверки.
• 📡 ЭДО и отчётность. Сертификаты и учётные записи в тестовой базе использовать нельзя.

Размер данных влияет на результат. Если на тесте лежит выборка за один месяц, а в рабочей базе пять лет, замер скорости ничего не покажет. Для проверки производительности берите полную копию.

Функциональное тестирование: сценарии и проверка конфигурации

Здесь два уровня. Первый автоматический: платформа сама ищет синтаксические и логические ошибки в конфигурации. Второй ручной или сценарный: человек (или скрипт) повторяет реальные операции.

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

В Конфигураторе откройте Конфигурация → Проверка конфигурации и отметьте нужные пункты. Для доработанной конфигурации полезны такие проверки:

Из командной строки та же проверка запускается в пакетном режиме:

1cv8.exe DESIGNER /F "D:\bases\test" /CheckConfig -ConfigLogIntegrity -IncorrectReferences -ThinClient -Server /Out "D:\log\check.txt"

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

Ручные сценарии

Составьте список из 10-20 операций, без которых компания не работает в течение месяца. Не пытайтесь проверить всё подряд, берите то, что делают чаще всего и что дороже всего ломается.

Пример набора для торгового предприятия:

• ✅ Создать и провести поступление товаров, реализацию, возврат.
• ✅ Сформировать счёт-фактуру и печатную форму накладной.
• ✅ Закрыть месяц и сформировать регламентированный отчёт.
• ✅ Загрузить банковскую выписку.
• ✅ Рассчитать зарплату по одному подразделению (если ведётся в этой базе).
• ✅ Построить оборотно-сальдовую ведомость и сверить итоги с рабочей базой.

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

Автоматическое сценарное тестирование

Если проверки повторяются перед каждым обновлением, ручной прогон быстро надоедает. В платформе есть режим тестового клиента, который управляется из внешней программы, и на нём построены популярные бесплатные инструменты: Vanessa Automation (сценарии на человекопонятном языке) и xUnitFor1C (модульные тесты для кода на встроенном языке). Для маленькой базы это перебор. Для конфигурации с большим числом доработок окупается после второго-третьего релиза.

Целостность данных и техническое обслуживание базы

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

Тестирование и исправление информационной базы

В Конфигураторе: Администрирование → Тестирование и исправление. Для первой проверки включайте режим «Только тестирование», без исправлений. Типовой набор:

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

Для автоматизации есть пакетный режим:

1cv8.exe DESIGNER /F "D:\bases\test" /IBCheckAndRepair -TestOnly -ReIndex -LogIntegrity -RecalcTotals /Out "D:\log\ibcheck.txt"

Если тест нашёл ошибки, сначала выясните, есть ли они и в рабочей базе. Ошибки, которые есть и там и там, не связаны с вашим обновлением, но их всё равно лучше исправить заранее.

Что сверить после обновления

• Версию конфигурации и платформы в справке О программе.
• Что обработка обновления информационной базы завершилась без сообщений об ошибках (при первом запуске после смены релиза она идёт автоматически).
• Что регламентные операции выполнены: пересчёт итогов, обновление индексов, актуальные курсы валют.
• Размер базы: резкий рост или падение в разы после обновления указывает на проблему.

Нагрузочное тестирование и замер производительности

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

Что измерять

Сравнивайте не «ощущения», а время конкретных операций. Выберите 5-7 тяжёлых процедур и замерьте каждую до и после на одинаковых данных:

Для точных замеров на сервере используют технологический журнал: он настраивается конфигурационным файлом logcfg.xml на стороне сервера и пишет длительные вызовы и блокировки. Для простой оценки хватит секундомера. Скорость самого сервера удобно сравнивать тестом Гилёва: он даёт сопоставимые баллы для разных машин.

Многопользовательская нагрузка

Однопользовательский тест не покажет блокировок. Есть два пути:

1. Организационный. Попросите 5-10 сотрудников одновременно поработать на тестовой базе по сценариям из списка выше. Грубо, зато выявляет блокировки на живых действиях.
2. Автоматический. Запуск нескольких тестовых клиентов скриптами. Сложнее, но воспроизводимо.

Смотрите на два признака: операция стала дольше в разы и появилось сообщение об ошибке блокировки при параллельном проведении документов. Оба называют узкое место, которое надо чинить до выпуска.

Права доступа и роли после обновления

Новый релиз часто меняет состав ролей и прав: добавляются новые объекты, которых нет в старых профилях. В итоге кладовщик внезапно видит чужие отчёты, а бухгалтер не может открыть новую форму.

Как проверить

1. Запустите тестовую базу под учётной записью с полными правами и откройте список пользователей.
2. Для каждой типовой должности (бухгалтер, кладовщик, менеджер по продажам, руководитель) выберите одного показательного пользователя.
3. Запустите конфигурацию под его именем. В Конфигураторе есть режим запуска от имени пользователя: в диалоге запуска отметьте нужного пользователя и откройте базу.
4. Пройдите сценарии своей должности: должны быть доступны все нужные операции и недоступны чужие.

В Конфигураторе также есть отчёт по правам доступа объектов: в нём видно, какие роли дают права на выбранный объект. Если после обновления пользователь «пропал» из какой-либо операции, это первое место поиска.

На что смотреть отдельно

• 🔐 Права на интерактивное удаление и проведение: они часто расходятся с правами на чтение.
• 🔐 Ограничения на уровне записей (RLS): после обновления они могут перестать срабатывать, если изменилась структура данных.
• 🔐 Роли, добавленные вручную: типовое обновление их не знает и не обновляет.

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

Итоговая проверка и план отката

Тестирование заканчивается не словами «вроде нормально», а чек-листом с отметками и подписью ответственного. Решение «выпускать или нет» принимайте по результатам, а не по настроению.

Критерии готовности

• ✅ Проверка конфигурации и тестирование базы без критичных замечаний.
• ✅ Все ключевые сценарии пройдены, итоги отчётов совпали.
• ✅ Нет деградации скорости более чем на согласованную величину (обычно 10-20%).
• ✅ Пользователи основных ролей подтвердили доступ к своим операциям.
• ✅ Есть письменный план отката и проверенная резервная копия.

План отката

План пишется до обновления, а не в момент аварии. В него входит:

1. Резервная копия рабочей базы непосредственно перед обновлением: .dt-файл либо копия каталога файловой базы, либо бэкап СУБД для клиент-серверной.
2. Проверка копии. Разверните её в отдельной базе и убедитесь, что она открывается и данные на месте. Копия, которую ни разу не открывали, копией не считается.
3. Окно работ. Время, когда в базе никто не работает, и время, до которого принимается решение об откате.
4. Точка невозврата. Как только пользователи начали вводить документы в обновлённой базе, откат на копию потеряет их данные. Определите момент, после которого откат уже невозможен без ручного переноса.
5. Ответственный. Кто принимает решение и кто выполняет.

Порядок выпуска в работу

1. Закрыть доступ пользователям (блокировка новых сеансов в консоли кластера или в списке активных пользователей).
2. Сделать резервную копию.
3. Обновить конфигурацию , дождаться окончания обработки обновления.
4. Прогнать короткий набор из 3-5 сценариев.
5. Открыть доступ сначала узкой группе, затем всем.

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

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