Как тестировать конфигурацию 1С

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

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

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

Какие виды тестирования применяются в 1С

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

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

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

Первое действие — снять полную копию рабочей базы. Для файловой базы достаточно выгрузки через «Администрирование → Выгрузить информационную базу» в конфигураторе или копирования файла 1Cv8.1CD при отсутствии сеансов. Для клиент-серверной базы корректнее делать выгрузку средствами СУБД (MS SQL, PostgreSQL), чтобы тестовая база максимально точно повторяла рабочую по объему и структуре.

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

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

Технические проверки в конфигураторе

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

Затем выполняется «Тестирование и исправление» на копии базы в монопольном режиме. Минимальный набор проверок: референсная целостность (битые ссылки), логическая целостность данных, пересчет итогов и проверка индексов. Режим исправления выбирайте осознанно: для битых ссылок безопаснее сначала прогнать проверку без исправления, оценить список проблемных объектов и только потом решать, что удалять, а что восстанавливать вручную.

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

1. 1
   Создайте копию рабочей базы и отключите регламентные задания обменов
2. 2
   Запустите контроль конфигурации с полным набором проверок, исправьте ошибки
3. 3
   Выполните «Тестирование и исправление» сначала в режиме только проверки
4. 4
   Разберите найденные проблемы, при необходимости повторите с исправлением
5. 5
   Войдите под типовыми ролями пользователей и проверьте доступность новых объектов

Проверка обновления конфигурации

Обновление — самый рискованный сценарий, потому что обработчики обновления меняют существующие данные. Тестируется оно только на копии рабочей базы с реальным объемом данных: обработчик, отрабатывающий за секунды на пустой базе, на рабочей может выполняться часами и заблокировать запуск системы.

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

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

Контрольные точки

Как проверить результат обновления

Журнал регистрации после обновления

Норма

Нет ошибок обработчиков обновления

Тревожный признак

Ошибки данных, незавершенные отложенные обработчики

Остатки по складу и взаиморасчетам до и после

Норма

Цифры совпадают полностью

Тревожный признак

Расхождения сумм или количества

Время выполнения обновления

Норма

Укладывается в допустимое окно простоя

Тревожный признак

Обновление длится часами, база недоступна

Функциональное тестирование бизнес-сценариев

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

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

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

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

Если конфигурация регулярно дорабатывается или обновляется, ручной прогон сценариев быстро становится узким местом. Для автоматизации в экосистеме 1С применяются открытые инструменты: Vanessa Automation — для сценарных тестов, написанных на языке Gherkin (шаги вида «Я создаю документ», «Тогда в регистре появляется запись»), и Vanessa ADD / xUnitFor1C — для модульных тестов отдельных процедур и функций.

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

Дополнительно для контроля качества кода используется статический анализ — например, 1C:EDT с встроенными проверками или SonarQube с плагином для языка 1С. Эти инструменты находят типовые дефекты (запросы в цикле, обращение к несуществующим реквизитам, игнорирование исключений) до запуска базы.

Ручное и автоматизированное тестирование

Ручное тестирование

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

Сценарные тесты (Vanessa Automation)

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

Модульные тесты (ADD, xUnitFor1C)

Подходят для проверки алгоритмов расчета и функций. Ограничение: не проверяют интерфейс и интерактивную работу

Контрольный список перед обновлением рабочей базы

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

1. 1
   Контроль конфигурации пройден без ошибок
2. 2
   Обновление успешно выполнено на копии с реальным объемом данных
3. 3
   Ключевые сценарии проверены: документы, проводки, отчеты, обмены
4. 4
   Проверена работа под типовыми ролями пользователей
5. 5
   Снята свежая резервная копия рабочей базы и проверена её восстанавливаемость
6. 6
   Пользователи предупреждены о времени простоя, сеансы завершены

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

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

Можно ли тестировать обновление на рабочей базе в нерабочее время?

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

Чем отличается контроль конфигурации от тестирования и исправления?

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

Сколько времени должно занимать тестирование перед обновлением?

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

Нужно ли тестировать типовое обновление, если конфигурация без доработок?

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

Что делать, если на тестовой базе всё работает, а на рабочей появились ошибки?

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

С чего начать автоматизацию тестов, если раньше всё проверялось вручную?

Выберите 3–5 самых критичных сценариев, которые проверяются перед каждым обновлением, и опишите их в Vanessa Automation. Убедитесь, что тесты стабильно проходят на копии базы, и только потом расширяйте покрытие. Начинать с попытки покрыть всю систему — путь к заброшенному проекту.