Проверка кода в 1С: инструменты разработчика и QA

Код в 1С проверяют на четырёх уровнях: синтаксис (Конфигурация → Синтаксический контроль), логика выполнения (отладчик Конфигуратора, F5), соответствие стандартам (АПК и BSL Language Server) и производительность (замер в отладчике, технологический журнал). Для разового исправления хватает отладчика и журнала регистрации. Для тиражного решения или командной разработки подключают автотесты и статический анализатор.

Ниже — конкретные пути меню и горячие клавиши для платформы 8.3 с интерфейсом «Такси». Инструменты работают и в Конфигураторе, и в 1С:EDT; где поведение различается, это отмечено.

Отладчик Конфигуратора: пошаговое выполнение

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

Перед запуском включите разрешение отладки. В Конфигураторе: Сервис → Параметры → Запуск 1С:Предприятия → Отладка — отметьте «Устанавливать режим разрешения отладки при запуске». Для серверной базы отладку дополнительно разрешают на сервере (ключ -debug у агента сервера либо через консоль администрирования кластера).

Базовый цикл работы:

1. Поставьте точку останова на строке — клавиша F9 или клик на поле слева от кода.
2. Запустите отладку — F5 (меню Отладка → Начать отладку). Платформа откроет 1С:Предприятие.
3. Выполнение остановится на точке. Дальше шагайте по коду:
   • F11 — шаг с заходом в вызываемую процедуру;
   • F10 — шаг через (процедуру выполнить целиком, не заходя внутрь);
   • Shift+F11 — шаг с выходом из текущей процедуры;
   • F5 — продолжить до следующей точки останова.
4. Наведите курсор на переменную — всплывёт её текущее значение. Сложные структуры удобнее смотреть в табло: Отладка → Табло.

Чтобы вычислить произвольное выражение прямо в точке останова, нажмите Shift+F9 («Вычислить выражение»). Там же можно развернуть коллекции — массивы, таблицы значений, структуры.

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

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

Журнал регистрации: где искать упавшие ошибки

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

Открыть журнал можно двумя способами:

• в режиме 1С:Предприятие — Все функции → Стандартные → Журнал регистрации (пункт «Все функции» включается в Главное меню → Сервис → Параметры → Отображать команду «Все функции»);
• в Конфигураторе — Администрирование → Журнал регистрации.

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

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

Синтаксический контроль и проверка конфигурации

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

Синтаксический контроль проверяет модули на ошибки компиляции: необъявленные переменные, незакрытые скобки, опечатки в именах методов. Запуск: Конфигурация → Синтаксический контроль. Для одного открытого модуля — Ctrl+F7. Результат выводится в окно сообщений: двойной клик по строке ошибки открывает проблемное место.

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

В 1С:EDT статическая проверка идёт непрерывно: редактор подчёркивает проблемы прямо при наборе, как в обычной IDE, и собирает их в панель «Проблемы». Отдельная команда «Проверить модуль» прогоняет расширенный набор правил. Это заметно удобнее, чем разовый синтаксический контроль в Конфигураторе, но набор проверок у инструментов различается — перед релизом полезно прогнать оба.

Не путайте проверку кода с процедурой Тестирование и исправление информационной базы (Администрирование → Тестирование и исправление в Конфигураторе). Последняя чинит структуру таблиц СУБД и логическую целостность данных, но кода не касается.

Автоматические тесты: unit и сценарные

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

В экосистеме 1С сложилось несколько открытых инструментов:

Unit-тест проверяет одну функцию в изоляции: подаёт на вход данные и сверяет результат с ожидаемым. Сценарный (BDD) тест на Gherkin описывает действия пользователя человекочитаемым текстом — «открыть документ, заполнить реквизит, провести» — и прогоняет их через интерфейс.

Встроенная в платформу возможность — режим автоматизированного тестирования (Сервис → Автоматизированное тестирование в Конфигураторе). Он позволяет записать действия в главном сеансе и воспроизвести их в тестовых сеансах. На практике этот механизм чаще используют как транспорт для Vanessa, а не напрямую.

Тесты имеет смысл запускать автоматически. Vanessa и xUnitFor1C управляются из командной строки, поэтому их встраивают в конвейер сборки (GitLab CI, Jenkins): при каждом коммите система разворачивает базу из файла поставки, накатывает расширение с тестами и прогоняет сценарии. Красный результат блокирует выгрузку в рабочую базу. Для одиночного разработчика достаточно прогонять набор локально перед каждым релизом.

Соответствие стандартам разработки

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

• АПК (Автоматизированная проверка конфигураций) — инструмент фирмы «1С» для проверки решений на соответствие требованиям к тиражируемым продуктам. Обязателен, если планируете сертификацию «1С:Совместимо».
• BSL Language Server — открытый линтер для встроенного языка. Работает в VS Code и 1С:EDT, подсвечивает диагностики прямо при наборе: когнитивную сложность методов, запросы в цикле, пустые блоки Попытка.
• SonarQube с плагином sonar-bsl-plugin-community — для командной разработки: собирает метрики качества по всему проекту и показывает динамику от релиза к релизу.

Статический анализ находит проблемы, которые отладчик не видит в принципе: он смотрит на структуру кода, а не на его выполнение. Для одиночного разработчика достаточно BSL Language Server в EDT; для команды имеет смысл поднять SonarQube.

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

Если операция выполняется медленно, нужно найти конкретную строку, которая съедает время. Гадать бесполезно — платформа даёт точный замер.

Замер производительности в Конфигураторе: Отладка → Замер производительности. Включите замер, выполните медленную операцию в 1С:Предприятии, остановите. Платформа покажет построчный отчёт: сколько раз выполнилась каждая строка и какой процент общего времени на неё пришёлся. Строки-лидеры по проценту времени — ваши кандидаты на оптимизацию.

Для серверной и клиент-серверной нагрузки применяют более тяжёлые инструменты:

• Технологический журнал — конфигурируется файлом logcfg.xml в каталоге conf платформы. Пишет события SDBL, DBPOSTGRS/DBMSSQL (текст запросов к СУБД), EXCP (исключения), длительность. Главный источник данных по реальной нагрузке на боевом сервере.
• APDEX — интегральная оценка удовлетворённости временем отклика ключевых операций. Настраивается в самой конфигурации (подсистема оценки производительности в типовых решениях на БСП).
• Центр управления производительностью (ЦУП) из состава КИП — сводит данные техжурнала и счётчиков в наглядные отчёты.

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

• соединения без индексов по полям связи — частая причина сканирования всей таблицы;
• ЛЕВОЕ СОЕДИНЕНИЕ с виртуальными таблицами остатков вместо параметров внутри самой виртуальной таблицы;
• получение одних и тех же данных несколькими запросами там, где хватило бы временной таблицы и пакета.

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

Режим совместимости и разные версии платформы

Код, написанный под одну версию платформы, на другой может вести себя иначе — меняются методы, свойства объектов, поведение форм. За это отвечает свойство конфигурации «Режим совместимости».

Откройте корень дерева конфигурации → палитра свойств → «Режим совместимости». Значение задаёт версию платформы, под поведение которой подстраивается конфигурация (например, «Версия 8.3.21»). Повышать режим совместимости нужно осознанно: после смены прогоняют автотесты и проверяют ключевые сценарии, потому что часть старых методов может изменить поведение.

Проверяя чужой или старый код, сверяйте требования:

• минимальная версия платформы — указывается в свойствах конфигурации и в поставке;
• режим совместимости — не должен быть ниже, чем требуют использованные конструкции;
• сравнивайте версии однозначно по номеру — «не ниже 8.3.21», а не «новее/старее».

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

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

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