Как проверять доработки в 1С: ручные сценарии, автотесты и нагрузка

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

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

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

Тест без ожидаемого результата — не тест. До первой проверки у вас должны быть три вещи.

1. Критерии приёмки. Не «отчёт должен работать», а «отчёт по остаткам за 01.03–31.03 сходится с оборотно-сальдовой ведомостью по счёту 41 до копейки».
2. Отдельная тестовая база. Копия рабочей, развёрнутая из выгрузки .dt. Тестировать на боевой базе нельзя: проведённые документы придётся откатывать, а регламентные задания могут отправить письма и обмены реальным контрагентам.
3. Набор данных. Нужны типичные случаи и крайние: нулевое количество, отрицательный остаток, документ на границе периода, контрагент без ИНН, валюта.

Что проверять в первую очередь

Не пытайтесь покрыть всё. Начните с мест, где ошибка дороже всего:

• 💰 документы, создающие проводки и движения регистров;
• 📊 регламентированные отчёты и выгрузки в контролирующие органы;
• 🔄 обмены между базами и с внешними сервисами;
• 🔐 права ролей и ограничения доступа на уровне записей;
• 🛠 всё, что вы изменили или добавили в конфигурации.

Ручное функциональное тестирование

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

Как записать сценарий

Сценарий — это короткая таблица: шаги, входные данные, ожидаемый результат. Пример для доработки «Реализация товаров» в Бухгалтерии 3.0:

Арифметика проверяется сразу: 12 000 × 20 / 120 = 2 000, значит выручка без НДС — 10 000.

Приёмочное тестирование силами пользователей

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

Встроенная проверка самой базы

Платформа умеет проверять целостность данных и структуры. В Конфигураторе: Администрирование → Тестирование и исправление. Режимы:

• 🔍 логическая проверка целостности;
• 🔗 проверка ссылочной целостности;
• 🧱 реиндексация таблиц и сжатие.

Для проверки самого кода: Конфигурация → Проверка конфигурации. Отметьте синтаксический контроль модулей, поиск неиспользуемых процедур и проверку обращений к несуществующим объектам. Запускайте её перед каждой выгрузкой доработки в .cfe или .cf.

Автоматизированное тестирование: Vanessa Automation и xUnit

Ручной прогон 40 сценариев занимает день. Автотесты — десять минут. Окупается всё, что вы запускаете чаще двух-трёх раз.

Сравнение подходов:

Сценарные тесты: как это выглядит

Vanessa Automation работает на подключении к базе в режиме тестового клиента. Платформа запускается с ключами /TESTMANAGER для управляющего сеанса и /TESTCLIENT для клиента, которым управляют. Сценарии пишутся на человеческом языке в файлах .feature в формате Gherkin:

Функционал: Проведение реализации

Сценарий: Реализация товара с НДС 20%
    Когда я открываю форму создания документа "Реализация"
    И я заполняю поле "Склад" значением "Основной склад"
    И я добавляю товар "Стол офисный" количеством 10 по цене 1200
    И я нажимаю на кнопку "Провести"
    Тогда в документе нет сообщений об ошибках
    И сумма НДС в документе равна 2000

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

Модульные тесты: xUnit в 1С

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

Процедура ТестРасчетНДС() Экспорт
    Результат = ОбщегоНазначения.РассчитатьНДС(12000, 20, Истина);
    юТест.ПроверитьРавенство(Результат, 2000, "НДС в том числе");
КонецПроцедуры

Фреймворки (xUnitFor1C, YAxUnit, Vanessa-ADD) различаются синтаксисом и способом запуска. Выбирайте тот, который поддерживает ваш процесс сборки и ваша команда. Названия методов проверки в каждом свои, поэтому берите их из документации выбранного фреймворка, а не из примера выше.

Что хорошо ложится на модульные тесты:

• ⚙️ расчёты: НДС, налоги, коэффициенты, округления;
• 🗂 разбор файлов и строк, формирование выгрузок;
• 🔎 запросы: подставили тестовые данные, проверили выборку.

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

Функционально всё верно, а проведение занимает 40 секунд? Для пользователя это такая же ошибка.

Отладчик

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

Замер производительности и технологический журнал

Для времени есть два штатных инструмента:

1. Замер производительности в Конфигураторе. Включаете, выполняете операцию, смотрите, какие строки кода и запросы заняли больше всего времени.
2. Технологический журнал. Настраивается файлом logcfg.xml в каталоге conf платформы. Пишет события сервера: долгие запросы, блокировки, ожидания. Включайте точечно: полный журнал за час забивает диск гигабайтами.

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

• 🐌 запросы в цикле: на 500 строк документа 500 обращений к базе вместо одного;
• 🔒 ожидания на блокировках при параллельном проведении;
• 📦 обращения через точку к реквизитам ссылки внутри запроса;
• 🗃 виртуальные таблицы регистров без отбора по условиям.

Журнал регистрации (Администрирование → Журнал регистрации) нужен для другого: он покажет, кто и когда провёл документ и какие ошибки возникали у пользователей.

Оценка в цифрах

Договоритесь о порогах заранее. Пример рабочего ориентира:

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

Регрессионное тестирование конфигурации

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

Когда запускать:

• 🔄 после обновления релиза типовой конфигурации;
• 🧩 после загрузки расширения или внесения правок в конфигурацию;
• 🖥 после смены версии платформы;
• 🗄 после переноса на другой сервер или СУБД.

Состав регрессионного набора

Не нужно проверять всё. Хороший набор — 20–50 сценариев, которые покрывают главный денежный и отчётный путь. Для торговой компании на Бухгалтерии 3.0 это может быть так:

1. Поступление товаров → проведение → проверка остатков.
2. Реализация → счёт-фактура → книга продаж.
3. Банковская выписка → списание и поступление → сверка расчётов.
4. Закрытие месяца → оборотно-сальдовая ведомость → сверка с эталоном.
5. Регламентированный отчёт → проверка контрольных соотношений.

Эталонные значения

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

Для сравнения самих конфигураций используйте Конфигурация → Сравнить, объединить с конфигурацией…. Так видно, что именно обновление изменило в вашей доработанной конфигурации. Если доработка сделана расширением, сравнение проще, а конфликты редки.

Нагрузочное тестирование и стресс-проверка

Одна операция быстрая, а при 30 пользователях одновременно база встаёт? Это и ловит нагрузочное тестирование.

Что и как моделировать

1. Выберите 3–5 самых массовых операций: проведение реализации, ввод поступления, формирование отчёта, поиск в справочнике.
2. Определите профиль: сколько пользователей, как часто, в каких пропорциях.
3. Запустите нагрузку на копии, близкой по данным и железу к рабочей. На пустой базе или слабой виртуалке цифры ничего не скажут.
4. Параллельно снимайте метрики: загрузка процессора и памяти сервера 1С и СУБД, время ответа, число блокировок и таймаутов.

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

Ступенчатая нагрузка

Начните с 10 пользователей, потом 20, 40, 80. Рисуйте график времени отклика. Точка, где кривая резко идёт вверх, и есть предел вашей системы. Его вы знаете заранее, а не узнаёте в день закрытия квартала.

Типичные ошибки при тестировании

• ❌ Тест на рабочей базе. Это не тест, это риск для данных. Только копия.
• ❌ Пустая база. Без реальных объёмов проблемы производительности не видны.
• ❌ Автотесты на всё подряд. Тысяча хрупких сценариев тратит больше времени на починку, чем экономит. Автоматизируйте устойчивое и повторяемое.
• ❌ Нет ожидаемого результата. Тест «посмотрели, вроде нормально» ничего не доказывает.
• ❌ Забыли права. Всё работает под администратором, а у бухгалтера доступа к кнопке нет. Прогоните ключевые сценарии под пользователем с реальной ролью.
• ❌ Не фиксируют версии. Без записи, на каком релизе и платформе был прогон, результаты нельзя сравнивать.

Как встроить тестирование в рабочий процесс

Разовая проверка перед релизом лучше, чем ничего, но настоящий эффект даёт регулярность. Минимальный контур выглядит так:

1. Изменения хранятся в системе контроля версий (Git), каждое — отдельной задачей.
2. На каждую выгрузку автоматически запускается проверка конфигурации.
3. Модульные и сценарные тесты идут на тестовой базе ночью.
4. Утром в очереди задач виден список упавших тестов.
5. Перед выкладкой в рабочую базу — ручная приёмка критичных сценариев и свежая резервная копия.

Каждая найденная в продакте ошибка превращается в новый тест. Через полгода у вас накопится набор, который знает «больные места» именно вашей базы.

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