Администрирование · 11 мин
Как проходит тестирование в 1С: от копии базы до проверки результата
Как проходит тестирование в 1С: ручные и автоматизированные проверки, тестирование и исправление ИБ, работа на копии, типичные ошибки и контроль результата.
Тестирование в 1С — это проверка корректности работы конфигурации, данных и новых доработок до того, как изменения попадут в рабочую базу. В зависимости от задачи под этим термином понимают разные вещи: проверку нового функционала после обновления, регламентную операцию «Тестирование и исправление» информационной базы, нагрузочные испытания или приёмочное тестирование доработок от подрядчика. Общий принцип один: сначала проверяем на копии, фиксируем результат, только потом переносим в рабочую среду.
Главное правило, которое нельзя нарушать: любые испытания проводятся на копии базы или в отдельной тестовой среде. Запуск «Тестирования и исправления» в режиме исправления на рабочей базе без резервной копии — прямой путь к потере данных, потому что механизм может физически удалять «битые» объекты. Перед любым тестом убедитесь, что у вас есть свежая выгрузка .dt и вы умеете из неё восстанавливаться.
Ниже разобраны основные виды тестирования в 1С, порядок подготовки тестовой среды, работа со штатным инструментом «Тестирование и исправление», подходы к проверке доработок и типичные ошибки, которые приводят к потере данных или ложным выводам.
Какие виды тестирования применяются в 1С
В практике работы с 1С выделяют несколько разных задач, которые все называют тестированием. Проверка целостности данных — штатная операция «Тестирование и исправление», которая ищет логические и физические повреждения в информационной базе. Функциональное тестирование — проверка того, что документы, отчёты и доработки работают как задумано: проводки формируются, остатки сходятся, печатные формы выводятся корректно.
Регрессионное тестирование выполняется после обновления конфигурации: нужно убедиться, что старые сценарии не сломались новым релизом. Нагрузочное тестирование актуально для крупных баз и кластеров серверов — оно показывает, как система ведёт себя при одновременной работе десятков или сотен пользователей. Наконец, приёмочное тестирование — это проверка доработок от внедренца или подрядчика по заранее согласованным сценариям.
Подготовка тестовой среды и резервной копии
Первый шаг любого тестирования — создание копии базы. Для файловой базы достаточно выгрузить данные через конфигуратор (Администрирование → Выгрузить информационную базу) или скопировать файл 1Cv8.1CD при остановленной работе пользователей. Для клиент-серверного варианта делается выгрузка .dt либо копия средствами СУБД (например, резервная копия MS SQL или PostgreSQL), после чего копия разворачивается на отдельном сервере или в отдельной базе.
Тестовая база должна быть максимально похожа на рабочую: та же версия платформы, тот же релиз конфигурации, актуальные данные. Если тестируется обновление, сначала на копию ставится текущий рабочий релиз, затем выполняется обновление — именно так воспроизводится реальный сценарий. После развёртывания копии полезно установить в константах признак «Это копия информационной базы» (в типовых конфигурациях есть соответствующий механизм), чтобы отключить автоматическую отправку писем, обмены с банками и синхронизацию с внешними системами.
- 1Сделайте выгрузку .dt или копию средствами СУБД из рабочей базы
- 2Разверните копию в отдельном каталоге или на отдельном сервере
- 3Отключите регламентные задания, обмены и отправку почты
- 4Установите нужную версию платформы и релиз конфигурации
- 5Проверьте, что база открывается и ключевые отчёты формируются
Тестирование и исправление информационной базы
Штатный инструмент запускается из конфигуратора: Администрирование → Тестирование и исправление. Он доступен только в монопольном режиме — все пользователи и фоновые сеансы должны быть завершены. Для файловой базы это означает, что никто не должен держать открытым файл 1Cv8.1CD; для клиент-серверной — что база заблокирована для сеансов.
В диалоге выбираются проверки: реиндексация таблиц, проверка логической целостности, проверка ссылочной целостности, пересчёт итогов, сжатие таблиц и реструктуризация. Режим «Тестирование» только находит ошибки и пишет их в журнал, режим «Тестирование и исправление» пытается их устранить. Опасный момент: при обнаружении объектов с битой ссылкой или повреждённых записей инструмент может удалить их физически, если выбран соответствующий вариант обработки. Поэтому первый прогон всегда делайте в режиме «Тестирование» и изучите список ошибок до включения исправления.
Длительность операции зависит от размера базы: на небольших файловых базах это минуты, на больших клиент-серверных — часы. Прерывать процесс нельзя, особенно в режиме исправления и реструктуризации, поэтому операцию планируют на нерабочее время.
Проверка обновлений и доработок на копии
Обновление типовой конфигурации сначала «прогоняется» на тестовой базе: устанавливается новый релиз, выполняется обновление версии программы, наблюдаются отложенные обработчики обновления данных. После завершения проверяются ключевые показатели: оборотно-сальдовая ведомость, остатки по складу и расчётам, открытие основных документов, формирование регламентированной отчётности. Если отложенные обработчики завершились с ошибками, в рабочую базу обновление не переносят до выяснения причины.
Доработки проверяются по сценариям, написанным до начала разработки. Хороший сценарий описывает исходные данные, действия пользователя и ожидаемый результат: «при проведении реализации с товаром из группы X должна создаваться запись в регистре Y с суммой Z». Проверять нужно не только «счастливый путь», но и граничные случаи: отмена проведения, изменение документа задним числом, работа под пользователем с ограниченными правами, повторное выполнение операции.
Как проверить результат тестирования
Итоги по счетам совпадают с контрольными значениями
Суммы изменились без документированной причины
Все обработчики завершены без ошибок
Есть незавершённые обработчики или ошибки в журнале
Открываются, проводятся и формируются штатно
Ошибки при проведении, пустые или искажённые отчёты
Типовые роли работают как раньше
Пользователи потеряли доступ или получили лишний
Ручное и автоматизированное тестирование
Ручное тестирование остаётся основным способом проверки в небольших внедрениях: тестировщик или ключевой пользователь проходит сценарии в интерфейсе и фиксирует расхождения. Его сила — гибкость и возможность заметить неочевидные проблемы с удобством и логикой. Слабость — трудоёмкость и зависимость от внимательности: повторять один и тот же набор проверок после каждого обновления вручную долго и скучно, поэтому проверки со временем выхолащиваются.
Автоматизированное тестирование опирается на сценарные инструменты и фреймворки, которые воспроизводят действия пользователя в клиентском приложении или проверяют логику на уровне кода. Такой подход окупается, когда конфигурация сильно доработана, обновления выходят часто, а регрессионный набор сценариев велик. Ограничения: разработка и поддержка автотестов требует отдельных компетенций, а хрупкие сценарии, привязанные к элементам интерфейса, ломаются при изменении форм. Разумная стратегия — автоматизировать критичные и часто повторяемые проверки (проведение ключевых документов, расчёт себестоимости, формирование отчётности), а разовые и исследовательские проверки оставить ручными.
Ручное или автоматизированное тестирование
Подходит для небольших баз, разовых проверок и оценки удобства. Ограничение — трудоёмкость при частых обновлениях.
Оправдано при частых релизах и большом регрессионном наборе. Ограничение — затраты на разработку и сопровождение сценариев.
Автотесты покрывают критичные операции, ручные — новые доработки и интерфейсные проверки. Оптимален для большинства внедрений.
Типичные ошибки при тестировании в 1С
Самая дорогая ошибка — запуск исправления на рабочей базе без копии. Вторая по частоте — тестирование на устаревшей копии: данные месячной давности не покажут проблем, которые возникнут на актуальных объёмах и свежих документах. Третья — проверка только под полными правами: большинство пользователей работает с ограниченными ролями, и ошибки прав доступа всплывают именно у них.
Также часто забывают про фоновые и регламентные задания: доработка может конфликтовать с ночным обменом или расчётом итогов. Ещё одна ошибка — перенос изменений в рабочую базу без фиксации результата теста: когда через неделю что-то ломается, невозможно понять, было ли это проверено и что именно изменилось. Ведите хотя бы простой журнал: дата, что тестировалось, кто проверял, результат.
FAQ: частые вопросы о тестировании в 1С
Можно ли запускать «Тестирование и исправление» при работающих пользователях?
Нет. Операция требует монопольного доступа к информационной базе: все сеансы, включая фоновые задания и соединения веб-сервисов, должны быть завершены. В клиент-серверном варианте базу блокируют для сеансов через консоль кластера, в файловом — добиваются, чтобы никто не открывал базу.
Чем отличается проверка в конфигураторе от утилиты chdbfl.exe?
«Тестирование и исправление» в конфигураторе проверяет логическую и ссылочную целостность данных и работает с базой любого типа. Утилита chdbfl.exe проверяет физическую целостность файла 1Cv8.1CD и применяется только к файловым базам, обычно когда база вообще не открывается или выдаёт ошибки формата потока.
Как понять, что обновление на тестовой копии прошло успешно?
Признаки успеха: обновление завершилось без ошибок, все отложенные обработчики отработали, контрольные отчёты (ОСВ, остатки склада, взаиморасчёты) совпадают со значениями до обновления, ключевые документы открываются и проводятся. После этого сценарий можно повторять на рабочей базе.
Нужно ли тестировать базу, если ничего не менялось?
Периодическая проверка целостности полезна даже без изменений: она помогает выявить накапливающиеся проблемы данных, битые ссылки и ошибки индексов до того, как они приведут к сбою. Регулярность зависит от интенсивности работы и размера базы, но после аварийных завершений и сбоев оборудования проверка обязательна.
Кто должен проводить приёмочное тестирование доработок?
Лучше всего — ключевой пользователь того участка учёта, под который сделана доработка: бухгалтер проверяет учётные сценарии, кладовщик — складские. Разработчик проверяет техническую корректность, но только пользователь способен заметить, что решение неудобно или не соответствует реальному процессу.
Что делать, если «Тестирование и исправление» нашло ошибки?
Сначала сохраните список ошибок и сделайте копию базы. Затем оцените характер ошибок: битые ссылки часто означают удалённые объекты, на которые остались ссылки; ошибки итогов лечатся пересчётом. Исправление запускайте на копии, после него проверьте, что нужные данные на месте и отчёты сходятся, и только потом повторяйте процедуру на рабочей базе.
Что важно запомнить
Любое тестирование в 1С начинается с резервной копии и проводится в тестовой среде с отключёнными обменами. «Тестирование и исправление» запускается только в монопольном режиме, сначала в режиме диагностики. Результат считается успешным, когда контрольные отчёты сходятся, обработчики обновления завершены, а типовые сценарии работают под обычными правами пользователей.