Как проверять документы 1С на копии базы

Тест документов 1С проводите на отдельной копии базы: транзакция отменяет изменения данных в пределах одной транзакции, но не возвращает внешние действия и не заменяет резервную копию. Я показываю, как подготовить стенд, записать результат и понять, когда копию надо восстановить.

Зачем проверять изменения на копии

Я не запускаю эксперимент на рабочей базе только потому, что код выглядит коротким. Проведение документа может записать движения, изменить остатки, вызвать подписки и запустить настроенные обмены. Отключение одного тестового действия не всегда отключает весь маршрут, который за ним тянется. Поэтому отдельная копия нужна не для красоты: она дает возможность повторить сценарий и удалить испорченный стенд, не восстанавливая рабочую базу. В условном кейсе ООО «Утро-Трейд» я проверяю на копии один маршрут документов: что создается, какие движения появляются и какой отчет получает бухгалтер. Для настройки такой среды подойдет услуга сопровождения 1С. В копии могут оставаться реальные учетные и персональные данные, поэтому доступ к тестовому экземпляру тоже ограничиваю. Подпись «тест» в названии не заменяет права доступа. Перед запуском еще раз сверяю имя информационной базы и строку подключения: если они не совпали с планом, тест не стартует.

Сначала определяю вариант базы. В файловом варианте данные находятся в файле 1Cv8.1CD; прямое копирование делаю после закрытия сеансов, иначе можно получить копию не того состояния, которое собирался проверить. Для клиент-серверной базы резервную копию делают средствами используемой СУБД или штатным способом конфигурации, а не поиском мифического файла на диске. Если нужна переносимая выгрузка, у платформы есть отдельный механизм выгрузки и загрузки информационной базы; его не следует путать с обычным копированием. Подробности о формате копии и восстановлении разобраны в статье выгрузка и загрузка базы 1С. Рабочий экземпляр и тестовый должны иметь разные каталоги, доступы и понятные подписи. Иначе копия рано или поздно становится новой рабочей базой — обычно в пятницу вечером. После восстановления копии проверяю, что база открывается в нужном режиме и видна именно тестовая метка, а не рабочая. Если резервную копию нельзя восстановить и открыть отдельно, пока рано считать ее страховкой. Копию и исходный резерв храню раздельно, чтобы ошибка при тестировании не затронула оба экземпляра сразу.

• Определить файловый или клиент-серверный вариант.
• Снять резервную копию штатным способом.
• Создать отдельный тестовый экземпляр.
• Отключить интеграции и задания с внешними эффектами.

Что именно откатывает транзакция 1С

Встроенный язык позволяет явно начать транзакцию, зафиксировать ее при успехе или отменить при ошибке: НачатьТранзакцию(), ЗафиксироватьТранзакцию(), ОтменитьТранзакцию(). Эти вызовы не являются волшебной кнопкой «вернуть всё как было». Они управляют изменениями базы в рамках текущей транзакции. Если обработка уже отправила письмо, создала файл вне базы, вызвала стороннюю систему или успела зафиксировать предыдущую порцию данных, отмена этой транзакции не отменит такие действия. Я держу тест на копии даже тогда, когда в коде есть отмена: это второй рубеж, а не страховка от всех последствий. До запуска записываю исходное состояние объектов, которые будет трогать тест, и заранее решаю, какие действия должны остаться только в копии. Например, отправку сообщения заменяю тестовой записью, а обмен с внешней системой не запускаю. Так я проверяю учетную логику, не устраивая побочный эксперимент для соседних систем.

Ошибки базы данных требуют аккуратной обработки. Документация 1С отдельно предупреждает: после восстановимой ошибки базы текущую транзакцию нельзя продолжать или фиксировать; ее надо отменить целиком. Повторять запись в бесконечном цикле в той же транзакции — плохая идея, а новую попытку начинают с начала и только после разбора причины. Начало и завершение транзакции должны быть парными; вложенные транзакции усложняют поведение и требуют отдельного понимания счетчика транзакций. В моем сценарии исключение записывается в диагностический журнал, транзакция отменяется, а результат помечается как неуспешный. Кнопка «отменить» не машина времени: уже отправленный обмен ей не поймать. Блок Исключение нельзя оставлять пустым: я сохраняю описание ошибки, помечаю тест как упавший и прекращаю сценарий. Нельзя считать, что отсутствие сообщения означает успешную отмену. Сначала проверяется статус транзакции и ожидаемое состояние контрольных объектов, затем решается, годится ли копия для следующей попытки.

• Начать транзакцию перед изменениями.
• Проверить ожидаемый результат.
• Зафиксировать только успешный сценарий.
• При ошибке отменить всю транзакцию.

Как запускать повторяемый тест

Тест можно запускать вручную из отдельной копии или автоматизировать через поддерживаемые параметры запуска платформы. Внешняя обработка запускается в режиме 1С:Предприятие; для пакетного запуска я сверяю синтаксис именно с руководством администратора для установленной версии. Командный запуск создает еще один рабочий сеанс, но не превращает его в изолированную песочницу и не скрывает его от администрирования. Сеанс подключается к указанной базе и получает назначенные ему права. Поэтому прежде чем нажать «старт», проверяю строку подключения, выбранное имя базы и учетную запись. Один неверно выбранный путь — и все аккуратно написанные проверки отправятся не туда. Первый прогон делаю вручную и сверяю, куда подключился клиент и с какими правами. Только после этого переношу запуск в автоматизацию. Для воспроизводимости фиксирую установленный релиз платформы, вариант базы и путь к обработке; жестко вшитые пароли и пути к рабочим каталогам в файл сценария не добавляю.

Для автоматического прогона использую отдельную учетную запись с минимальными правами, храню ее реквизиты в защищенной настройке среды, а не в тексте скрипта. В журнал регистрации можно писать начало и итог теста, но платформа не обязана сама фиксировать каждую границу транзакции так, как нужно автору теста. Журнал предназначен для событий работы с информационной базой; дополнительные диагностические события разработчик записывает явно. Поэтому добавляю в тест собственный идентификатор запуска, имя сценария и итог проверки. Если такой записи нет, нельзя заключить, что откат не сработал: сначала выясняю, была ли вообще настроена запись события. И наоборот, строка «ошибка» в журнале сама по себе не доказывает, что данные повреждены. Запись делаю на каждом завершении: отдельное событие для успешного результата и отдельное для ошибки с кратким контекстом. Не кладу в журнал большие куски данных и не записываю лишние сведения о пользователях. В итоговом отчете указываю время, идентификатор запуска, версию конфигурации и ссылку на сохраненные диагностические материалы.

• Сверить базу и способ подключения.
• Использовать отдельную учетную запись.
• Записывать идентификатор и итог теста.
• Проверять параметры запуска в документации своей версии.

Как проверить результат после отката

Я проверяю не абстрактное «все работает», а заранее заданные условия: тестовый документ не остался записанным, нужные движения появились или исчезли именно так, как требует сценарий, а контрольный отчет вернул ожидаемый результат. Сравнивать все таблицы базы целиком обычно бессмысленно: в них могут меняться служебные данные и отметки запуска. Для каждого теста выбираю небольшую проверяемую область и фиксирую исходное состояние до выполнения. Если расхождение найдено, не продолжаю следующий сценарий на этой же копии. Сохраняю журналы и экземпляр для разбора, а новый запуск делаю на чистой копии. Для отдельной диагностики файловой базы см. Материал о тестировании и исправлении базы 1С. До теста задаю контрольные значения и критерий сравнения: какие документы должны быть, какие движения ожидаются, какие суммы или статусы должны получиться. Иначе проверка превращается в просмотр экрана с надеждой заметить неладное. Если критерии зависят от настройки учета, сверяю их с владельцем процесса до запуска, а не после найденного расхождения.

«Тестирование и исправление информационной базы» — инструмент диагностики и исправления ошибок хранения, а не обязательный ритуал после каждого штатного отката. Его применяют, когда есть основания подозревать проблему с базой; перед исправлением сохраняют отдельную копию. Важная деталь из документации 1С: такая процедура выполняется только в монопольном режиме, то есть пользователи в это время не работают с базой. Не запускайте ее на живой системе ради красивой галочки в чек-листе. Если копия после теста подозрительна, оставьте ее для анализа и поднимите новую из проверенного резерва. Сценарий восстановления после реального сбоя — отдельная задача, о ней есть статья восстановление базы 1С после сбоя. Перед ТиИ я предупреждаю пользователей и проверяю, что все сеансы действительно закрыты; в клиент-серверном варианте действую по правилам администрирования кластера. Диагностику нельзя запускать параллельно с тестовой записью. После исправления снова проверяю копию прикладными сценариями и только потом решаю, можно ли взять из нее отдельные диагностические выводы.

• Сверить тестовые данные с ожидаемыми.
• Сохранить журнал и идентификатор запуска.
• При расхождении остановить серию тестов.
• ТиИ запускать отдельно и в монопольном режиме.

Как встроить проверку в CI

Автоматизация полезна, когда она каждый раз поднимает чистую копию и проверяет один и тот же ожидаемый результат. Я строю процесс вокруг четырех условий: версия платформы и конфигурации записаны; база для запуска однозначно выбрана; интеграции с реальными системами отключены или заменены тестовыми; итог проверки возвращается в систему сборки вместе с журналом. Если проверка упала, рабочая база не «откатывается» из резерва — прекращается только прогон тестовой копии. Такой стенд можно связать с системой CI, но скорость зависит от размера базы, восстановления и самих сценариев. Я не обещаю одинаковые 10 минут для всех: размер базы не читает маркетинговые обещания. Для параллельных сборок выдаю каждому запуску отдельный экземпляр базы: два сценария на общей копии могут мешать друг другу и портить результат сравнения. При ошибке система CI хранит статус и журнал, но не пытается автоматически перезаписать рабочие данные. Это простое правило убирает опасный соблазн сделать восстановление частью обычной кнопки «повторить».

В условном кейсе ООО «Утро-Трейд» я оформляю сценарий как последовательность: поднять экземпляр из контрольной копии, отключить реальные обмены и задания, создать тестовые документы, проверить движения и отчет, отменить тестовую транзакцию, записать итог. Перед следующим прогоном база поднимается заново, чтобы остатки первого запуска не влияли на второй. Если конфигурация изменилась, рядом с результатом сохраняются ее версия и версия платформы — без них повторить неудачный тест трудно. Выход для команды — воспроизводимый набор шагов и понятный отчет «прошел / не прошел», а не обещание нулевого риска. Автоматизация убирает ручную рутину; думать о том, куда уходит тестовый запрос, она за вас не будет. В карточке сценария я описываю исходные данные, ожидаемое поведение документа и способ проверки движений. Так коллега может повторить тест без устных подсказок и без доступа к рабочей базе. Если проверяется не типовая конфигурация, критерии согласуются с ее правилами учета; универсального набора проводок для всех баз 1С не существует.

• Создавать чистую копию для каждого прогона.
• Сохранять версии платформы и конфигурации.
• Передавать статус и журнал в CI.
• Останавливать прогон при первом расхождении.

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