Как проверить базу 1С перед обновлением или внедрением: от копии до отчёта

Тестирование базы 1С делают на копии, а не на рабочей базе. Порядок для администратора такой: снять копию через Администрирование → Выгрузить информационную базу в Конфигураторе (или бэкапом СУБД), отключить в ней регламентные задания и обмены, прогнать Администрирование → Тестирование и исправление, затем проверить учёт, обмены и скорость под нагрузкой. Итог фиксируют в отчёте: что проверено, что упало, что исправлено.

Так проверяют базу перед обновлением конфигурации или платформы, перед вводом в эксплуатацию доработок, после сбоя питания или переноса на новый сервер.

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

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

Как сделать копию

Для серверной копии создайте новую информационную базу в консоли кластера и загрузите в неё .dt через Администрирование → Загрузить информационную базу. При восстановлении из бэкапа СУБД базу в кластере регистрируют поверх восстановленной базы данных.

Как изолировать копию

Копия, которая думает, что она рабочая, способна натворить бед: отправить письма клиентам, выгрузить заказы в интернет-магазин, отправить отчётность. Перед первым запуском:

• 🔒 В консоли кластера в свойствах новой базы включите флажок «Блокировка регламентных заданий включена».
• 📨 В конфигурациях на БСП при первом входе в копию программа спросит, перемещена ли база. Отвечайте, что это копия: тогда регламентные задания и синхронизация в ней не запустятся.
• 🔄 Отключите узлы обмена или поменяйте строки подключения к другим базам на тестовые.
• 📧 Удалите или испортите пароли учётных записей электронной почты.
• 🏷️ Переименуйте базу в списке так, чтобы в заголовке окна было видно слово «ТЕСТ».

Виды тестирования базы 1С: что и когда проверять

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

Базовых типов проверки пять:

1. 🧱 Техническая целостность — структура таблиц, индексы, ссылки, итоги.
2. 🧩 Проверка конфигурации — синтаксис модулей, некорректные ссылки в метаданных.
3. 📊 Учётная проверка — сходятся ли остатки, обороты, отчёты.
4. 🔁 Интеграции — обмены, загрузки, внешние компоненты.
5. ⚡ Производительность — время операций одного пользователя и под нагрузкой.

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

Главный штатный инструмент — режим Конфигуратора Администрирование → Тестирование и исправление. Он работает и для файловых, и для серверных баз.

Какие галочки ставить

• Реиндексация таблиц информационной базы — перестраивает индексы. Долго, но безопасно.
• Проверка логической целостности — находит нарушения во внутренней структуре данных.
• Проверка ссылочной целостности — ищет ссылки на несуществующие объекты (в формах они видны как <Объект не найден>).
• Пересчёт итогов — заново считает итоги регистров. Помогает, когда отчёты показывают одно, а документы другое.
• Сжатие таблиц и Реструктуризация таблиц — уменьшают размер и перестраивают таблицы. Для первичного теста не нужны.

Ниже галочек — переключатель режима: «Тестирование» или «Тестирование и исправление». Первый проход всегда делайте в режиме «Тестирование»: он только пишет протокол и ничего не меняет.

Что делать с битыми ссылками

Для ссылок на несуществующие объекты и для частичной потери данных программа предлагает варианты: создавать объекты, удалять ссылки или объекты, не изменять. Безопаснее «Создавать объекты»: появятся элементы-заглушки, их потом можно найти и разобрать вручную. Удаление ссылок стирает поле в документе навсегда, и восстановить, что там было, уже не получится.

Пакетный запуск из командной строки

Для регулярных проверок на копии тот же режим запускают без интерфейса. Пример bat-файла для файловой базы:

@echo off
set V8="C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe"
set IB=D:\Bases\Buh_TEST

%V8% DESIGNER /F"%IB%" /N"Администратор" /P"" ^
  /IBCheckAndRepair -LogAndRefsIntegrity -RecalcTotals -TestOnly ^
  /Out"D:\Logs\check_%date:~-4%%date:~3,2%%date:~0,2%.log"

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

chdbfl.exe для файловой базы

Если файловая база не открывается вовсе, Конфигуратор не поможет. В каталоге bin платформы лежит утилита chdbfl.exe: она проверяет физическую целостность файла 1Cv8.1CD. Укажите путь к файлу, сначала запустите без флажка «Исправлять обнаруженные ошибки». Работает только с закрытой базой и только с копией файла, если на кону важные данные.

Проверка целостности данных: скрытые ошибки учёта

Техническая проверка может пройти без единой ошибки, а учёт при этом будет кривым. Типичные скрытые проблемы:

• 📄 Документы, которые были проведены, а после сбоя или обмена потеряли движения.
• ➖ Отрицательные остатки на складах и счетах, где их быть не может.
• 🔗 Элементы-заглушки после исправления ссылок.
• 🧾 Расхождения между регистрами: например, взаиморасчёты в оперативном учёте не совпадают с бухгалтерскими.

Сравнение отчётов «до» и «после»

Самый надёжный учётный тест перед обновлением — сравнить одинаковые отчёты в базе до обновления и в обновлённой копии. Что сформировать:

1. Оборотно-сальдовую ведомость за последний закрытый год и текущий период.
2. Остатки товаров по складам на дату.
3. Взаиморасчёты с контрагентами.
4. Регламентированные отчёты за последний квартал: суммы в строках должны совпасть.

Сохраните отчёты в Excel и сравните построчно. Любая разница в закрытом периоде — повод остановить обновление и разбираться.

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

В 1С:Бухгалтерии 3.0 есть отчёт Отчёты → Анализ учета → Экспресс-проверка: он ищет типовые учётные ошибки по разделам. В конфигурациях на БСП есть механизм контроля ведения учёта: проверки запускаются по расписанию или вручную из раздела Администрирование, найденные проблемы видны прямо в формах объектов.

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

Тестирование обменов данными на копии

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

Порядок проверки

1. Сделайте копии обеих баз в один момент, чтобы номера сообщений обмена совпадали.
2. В копиях перенастройте подключение: каталог, FTP или веб-сервис должны указывать друг на друга, а не на рабочие базы.
3. Запустите синхронизацию вручную из раздела Администрирование → Синхронизация данных.
4. Посмотрите протокол обмена: предупреждения, ошибки, объекты, не прошедшие загрузку.
5. Создайте тестовые документы в источнике и проверьте, как они легли в приёмник: реквизиты, суммы, проведение.

Что ломается чаще всего

• 🧷 Несовпадение версий формата обмена после обновления одной из сторон.
• 🗂️ Новые реквизиты, которые есть в одной базе, но не попадают в правила.
• 🔢 Дубли справочников, когда сопоставление идёт не по ИНН или коду, а по наименованию.
• 🔐 Права пользователя, от имени которого идёт обмен.

Автоматизация тестов: инструменты и сценарии

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

Основа почти всех инструментов — режимы платформы «менеджер тестирования» и «клиент тестирования». Клиент запускается с параметром /TESTCLIENT, менеджер — с /TESTMANAGER, и менеджер управляет формами клиента, как живой пользователь.

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8c.exe" ENTERPRISE /F"D:\Bases\Buh_TEST" ^
  /N"Тестировщик" /P"" /TESTCLIENT -TPort 1538

Для старта хватит 10–15 сценариев на самые частые операции: поступление, реализация, оплата, расчёт зарплаты, закрытие месяца . Их гоняют после каждого обновления и сравнивают результат с эталоном.

Нагрузочное тестирование: как база держит много пользователей

Стресс-тест отвечает на вопрос, выдержит ли сервер реальную нагрузку. Особенно нужен при переезде на новое железо, смене СУБД и росте числа пользователей.

Инструменты

• ⏱️ Тест Гилева — бесплатная обработка, даёт условный балл производительности связки «сервер 1С + СУБД + диски». Удобен, чтобы сравнить старый и новый сервер одной цифрой.
• 🏋️ Тест-центр из 1С:КИП — эмулирует работу десятков виртуальных пользователей по сценариям и измеряет время операций.
• 📈 Технологический журнал — пишет события платформы: исключения, ожидания на блокировках, взаимоблокировки.

Минимальный технологический журнал

Файл logcfg.xml кладут в каталог conf платформы на сервере 1С. Пример, который ловит исключения и проблемы с блокировками:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\v8logs" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <property name="all"/>
  </log>
</config>

history="24" — хранить логи 24 часа. На время теста этого хватает, а диск не забьётся. После теста файл удалите или переименуйте: журнал с широким фильтром на рабочем сервере быстро съедает место.

Что измерять

Зафиксируйте время 5–10 ключевых операций: открытие списка документов, проведение реализации на 100 строк, формирование ОСВ за год, закрытие месяца. Замерьте при одном пользователе и при расчётной нагрузке. Рост времени в 2–3 раза под нагрузкой и ошибки TTIMEOUT в журнале — сигнал разбираться с блокировками и железом до запуска.

Анализ результатов и отчёт о тестировании

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

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

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