Тестирование 1С: от отладчика до нагрузочных тестов

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

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

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

Уровни проверки и выбор инструмента

Прежде чем что-то запускать, определитесь, что именно вы проверяете. От этого зависит инструмент — универсального «тестировщика 1С» не существует.

Отладчик и встроенная проверка кода

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

Синтаксический контроль проверяет весь код конфигурации, не выполняя его. В Конфигураторе: Конфигурация → Синтаксический контроль. Платформа найдёт неописанные переменные, опечатки в именах методов, незакрытые скобки. Это первое, что стоит запускать после правки модуля.

Проверка конфигурации шире — Конфигурация → Проверка конфигурации. В диалоге отметьте нужные пункты:

• 🔍 синтаксический контроль модулей;
• 🔗 проверку логической целостности (битые ссылки на реквизиты, удалённые объекты);
• 🔐 проверку прав на объекты в ролях;
• 📋 поиск некорректных ссылок.

Отладчик запускает конфигурацию и даёт пройти код по шагам. Основное:

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

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

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

В 1C:EDT (среда разработки на базе Eclipse) есть собственный отладчик с похожей логикой точек останова и пошагового прохода — если команда разрабатывает в EDT, а не в Конфигураторе.

Автотесты интерфейса через Vanessa Automation

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

Vanessa Automation — свободный фреймворк сценарного тестирования интерфейса. Сценарии пишутся на русском в стиле «Дано — Когда — Тогда» (формат Gherkin) и хранятся в .feature-файлах. Пример смысла сценария:

Дано Я открываю новый документ "Реализация товаров"
Когда Я заполняю контрагента "ООО Ромашка"
И добавляю строку с номенклатурой и количеством 5
Тогда поле "Сумма" заполнено автоматически
И документ проводится без ошибок

Под капотом Vanessa использует штатный механизм платформы: менеджер и клиент тестирования. Конфигуратор запускается в двух ролях через параметры командной строки 1cv8 ... /TESTMANAGER (управляет сценарием) и 1cv8 ... /TESTCLIENT (выполняет действия в интерфейсе). Vanessa эмулирует клики и ввод так, как это делает живой пользователь.

Зачем это нужно на практике:

• 🧪 прогнать типовые операции (продажа, оплата, закрытие месяца ) после обновления — за минуты, а не за часы;
• 🔁 повторять один и тот же сценарий без человеческого фактора;
• 📝 держать проверки как документацию: сценарий читается как инструкция.

Модульные тесты кода с xUnitFor1C

Автотест интерфейса проверяет сценарий целиком. Но если нужно убедиться, что конкретная функция считает правильно при любых входных данных, удобнее модульный (юнит) тест.

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

Что тестируют юнит-тестами в первую очередь:

• расчётные функции (цены, скидки, налоги, округления);
• парсинг и преобразование строк, работа с датами;
• алгоритмы в общих модулях, которые вызываются из многих мест.

Логика теста простая: подготовили вход → вызвали функцию → сверили факт с эталоном. Если позже кто-то «улучшит» функцию и сломает расчёт, тест сразу покраснеет. Это дешевле, чем ловить расхождение в суммах через полгода.

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

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

Нагрузочное тестирование и производительность

Код может быть корректным, но валить базу на пике нагрузки. Это проверяют отдельно.

Замер производительности встроен в Конфигуратор: меню Отладка → Замер производительности. Запускаете замер, выполняете операцию (например, проведение тяжёлого документа), останавливаете. Платформа покажет таблицу: сколько раз вызвана каждая строка кода и сколько времени заняла. Строки-«рекордсмены» по времени — и есть узкие места.

Нагрузочное тестирование эмулирует параллельную работу многих пользователей. Здесь применяют Тест-центр — конфигурацию для нагрузочных тестов (входит в состав инструментального пакета 1С для разработчиков). Как это работает:

1. В Тест-центре описываются сценарии — последовательности действий виртуального пользователя.
2. Задаётся число параллельных пользователей и интенсивность.
3. Виртуальные пользователи запускаются на клиентах тестирования и работают с базой одновременно.
4. Собирается статистика времени отклика по каждой операции.

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

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

Проверка прав доступа и ролевой модели

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

Базовая проверка — запуск под тестовым пользователем с нужной ролью. Создайте пользователя с минимальным набором ролей и пройдите под ним типовой сценарий: открываются ли нужные разделы, проводятся ли документы, не вылезает ли «Нарушение прав доступа».

Что проверять в ролевой модели:

• 👤 набор ролей у пользователя — лишние роли дают лишние права;
• 📂 права на объекты (справочники, документы, регистры) — чтение, добавление, изменение, проведение;
• 🔐 ограничения на уровне записей (RLS) — когда роль видит не все записи, а только свои (по организации, складу, подразделению).

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

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

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

Тестирование обменов и интеграций

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

Ручная проверка обмена между базами 1С строится по шагам:

1. На узле-источнике внесите тестовое изменение (создайте или проведите документ).
2. Убедитесь, что изменение зарегистрировалось к выгрузке на нужный узел плана обмена.
3. Выполните выгрузку, затем загрузку в приёмнике.
4. Проверьте в приёмнике: объект создан, реквизиты сопоставлены верно, документ проводится.

На что смотреть при проверке интеграций:

• 🔄 полнота переноса — все ли реквизиты и табличные части дошли;
• 🧭 сопоставление — верно ли подобрались ссылки (контрагенты, номенклатура) по идентификаторам, а не задвоились;
• 🌐 web- и HTTP-сервисы — для внешних систем проверяется ответ сервиса на тестовый запрос и обработка ошибок связи.

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

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

Чек-лист перед выкаткой доработки

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

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