Как тестировать код 1С: практическое руководство

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

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

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

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

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

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

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

Как подготовить тестовую среду

Первое и не обсуждаемое правило: тестируют только на копии рабочей базы. Для файловой базы достаточно скопировать каталог или выгрузить и загрузить dt-файл. Для клиент-серверной базы копию создают средствами СУБД (резервная копия в MS SQL или PostgreSQL) и подключают её под отдельным именем в кластере.

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

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

Ручное тестирование: чек-лист сценариев

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

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

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

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

Отладчик конфигуратора: как находить причину ошибки

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

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

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

// Точка останова с условием: остановка только для нужного товара
// В конфигураторе: правый клик по точке останова -> Условие
// Условие: СтрокаТовары.Номенклатура = НужнаяНоменклатура

// Временная диагностика в коде (удалить после проверки)
Сообщить("Сумма до расчёта: " + СуммаДокумента);

Автоматизированные тесты: когда они окупаются

Автотесты в экосистеме 1С пишут с помощью специализированных инструментов. Наиболее известны Vanessa Automation (сценарные тесты на языке Gherkin, проверяющие поведение системы через интерфейс и программные вызовы) и xUnitFor1C (модульные тесты для функций и процедур). Эти решения распространяются как открытые проекты и применяются в командах, где доработки выпускаются регулярно.

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

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

Проверка производительности и запросов

Код, который работает правильно, но медленно, в рабочей базе считается неработающим. Типичные источники проблем: запросы в цикле, обращения к данным через точку от результата запроса, отсутствие индексов по полям условий, выборка лишних полей. Всё это выявляется на копии с реальным объёмом данных простым замером времени выполнения до и после изменений.

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

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

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

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

Частые вопросы о тестировании кода 1С