Как протестировать расширение 1С перед установкой в рабочую базу

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

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

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

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

Первый шаг — создать копию рабочей базы. Для файловой базы достаточно скопировать каталог с файлом 1Cv8.1CD или сделать выгрузку через конфигуратор в файл .dt и загрузить его в новую базу. Для клиент-серверной базы используйте выгрузку .dt либо средства СУБД (резервную копию SQL Server или PostgreSQL с последующим восстановлением под другим именем). Загрузка .dt в клиент-серверный вариант — самый простой путь для баз среднего размера.

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

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

Проверка совместимости до подключения

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

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

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

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

Ядро проверки — прохождение сценариев из чек-листа. Подключите расширение в тестовой базе (Администрирование — Печатные формы, отчеты и обработки — Расширения — Добавить из файла), перезапустите сеанс и последовательно выполните каждый сценарий. Фиксируйте не только падения, но и расхождения в данных: неверная сумма в отчёте — такой же дефект, как и окно с ошибкой.

Проверка изменённых форм и документов

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

Проверка отчётов и печатных форм

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

Граничные случаи

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

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

Тестирование под разными ролями и правами

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

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

Если расширение работает в фоновых заданиях, проверьте, под каким пользователем выполняется задание и хватает ли ему прав. Фоновое задание, падающее по правам, часто незаметно: пользователь видит лишь то, что «данные не обновились».

Производительность и журнал регистрации

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

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

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

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

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

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

Норма

Нет ошибок, связанных с расширением

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

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

Время проведения документа

Норма

Сопоставимо с показателями без расширения

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

Рост времени в разы на том же документе

Данные отчётов

Норма

Совпадают с эталоном или отличаются на ожидаемую величину

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

Расхождения без объяснимой причины

Работа под ролями пользователей

Норма

Все сценарии проходят без ошибок доступа

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

«Нарушение прав доступа» у части пользователей

Перенос в рабочую базу и план отката

Переносите расширение в рабочую базу в период минимальной активности пользователей и только после свежей резервной копии. Для файловой базы — копия каталога или выгрузка .dt, для клиент-серверной — бэкап средствами СУБД. Сохраните и сам файл расширения (.cfe) той версии, которая прошла тестирование, — не пересобирайте его «по памяти».

План отката прост: отключить расширение в списке расширений (снять флажок «Используется») и перезапустить сеансы. Но учтите ограничение: если расширение добавляло собственные объекты и в них накоплены данные, при отключении данные останутся, но станут недоступны, а при удалении расширения — будут потеряны. Если расширение изменило поведение проведения и документы уже проведены «по-новому», простое отключение не вернёт старые движения — нужен анализ и, возможно, перепроведение.

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

Инструменты: что использовать для тестирования

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

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

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

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

Можно ли тестировать расширение прямо в конфигураторе без подключения?

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

Расширение работало, а после обновления конфигурации сломалось. Что делать?

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

Как проверить расширение, если оно добавляет регламентное задание?

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

Два расширения конфликтуют за одну форму. Как понять, какое победит?

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

Нужно ли тестировать расширение, которое добавляет только одну печатную форму?

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

Как откатить расширение, если в рабочей базе уже пошли ошибки?

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