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

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

1. Подготовка к тестированию: копирование и изоляция базы

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

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

  • 📁 Резервное копирование через 1С:Предприятие (Администрирование → Выгрузить информационную базу). Подходит для небольших баз (до 50 ГБ).
  • 🖥️ Утилиту chdbfl.exe (для файловых баз). Команда для создания копии:
    chdbfl.exe C:\Path\To\Source C:\Path\To\Copy /D
  • 🔄 SQL-дамп (для клиент-серверных баз). Используйте SQL Server Management Studio или pg_dump для PostgreSQL.

Важно: после копирования проверьте целостность данных утилитой chdbfl.exe с ключом /C (для файловых баз) или командой DBCC CHECKDB (для MS SQL). Это выявит повреждённые таблицы на раннем этапе.

💡

Если тестируете обновление конфигурации, предварительно отключите всех пользователей в рабочей базе через Администрирование → Активные пользователи → Завершить сеансы. Это предотвратит блокировки при выгрузке данных.

⚠️ Внимание: При работе с PostgreSQL версии 12+ учитывайте изменения в механизме транзакций. Копирование базы через pg_dump может занять на 30-40% больше времени из-за новых алгоритмов сжатия.

2. Виды тестирования: что и когда проверять

Тестирование базы условно делится на 4 уровня, каждый из которых решает свои задачи. Пропуск хотя бы одного уровня увеличивает риск критичных сбоев после обновления.

Тип тестирования Цель Инструменты Время выполнения
Функциональное Проверка работоспособности бизнес-логики (документы, отчёты, обработки) Ручной тест, Тест-центр 1С, скрипты на OneScript От 2 часов до 2 дней
Нагрузочное Оценка производительности при пиковых нагрузках 1С:Тест-центр, JMeter, LoadRunner От 4 часов
Интеграционное Проверка обменов с другими системами (банк-клиент, ЕГАИС, CRM) Логи обменов, Postman для API, SoapUI От 1 часа
Регрессионное Выявление ошибок, появившихся после изменений Автотесты, Vanessa-ADD, сравнение отчётов От 30 минут

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

📊 Какой тип тестирования вы проводите чаще всего?
Функциональное
Нагрузочное
Интеграционное
Регрессионное
Не тестирую системно

3. Автоматизация тестов: инструменты и скрипты

Ручное тестирование отнимает до 70% времени администратора. Автоматизация позволяет сократить этот показатель до 20-30%, исключив человеческий фактор. Рассмотрим 3 клювых инструмента для :

  • 🤖 Тест-центр 1С (входит в дистрибутив платформы). Позволяет записывать и воспроизводить действия пользователя, сравнивать результаты с эталоном. Подходит для тестирования форм и отчётов.
    Как настроить Тест-центр для проверки печатных форм?

    1. Запишите сценарий открытия документа (например, Реализация товаров). 2. Добавьте шаг «Печать» с сохранением в PDF. 3. В настройках теста укажите эталонный PDF-файл для сравнения. 4. Запустите тест — система автоматически выявит расхождения в макете.

  • 📜 Vanessa-ADD (бесплатный фреймворк). Пишет автотесты на языке , интегрируется с Jenkins для CI/CD. Пример скрипта для проверки создания документа:
    Тест = Новый Тест();
    

    Тест.Действие("ОткрытьСписокДокументов", "РеализацияТоваровУслуг");

    Тест.Действие("СоздатьНовый");

    Тест.Проверка.Равенство(Тест.Значение("Номер"), "000000001");

  • 🔄 OneScript + xUnitFor1C. Дляunit-тестирования отдельных функций. Например, проверка расчёта скидки:
    Функция ТестРасчетаСкидки()
    

    Утв = Документы.УстановкаЦен.СоздатьДокумент();

    Утв.Товар = Справочники.Номенклатура.НайтиПоНаименованию("Телевизор");

    Утв.Цена = 50000;

    Утв.Скидка = 10;

    Утверждать.Что(Утв.ИтоговаяСумма()).Равно(45000);

    КонецФункции

Для интеграционного тестирования обменов с ЕГАИС или банк-клиентами используйте мокирование: вместо реальных систем подключайте тестовые сервисы (например, Mockoon или Postman Mock Server). Это ускорит проверку и исключит риск отправки тестовых данных в производственные системы.

Создать резервную копию тестовой базы|Установить Тест-центр 1С или Vanessa-ADD|Подготовить эталонные данные (PDF, Excel, JSON)|Настроить права доступа для тестового пользователя|Отключить фоновые задачи (Регламентные задания)

-->

4. Стресс-тестирование: как проверить базу на устойчивость

Нагрузочное тестирование выявляет узкие места в производительности: медленные запросы, блокировки таблиц, утечки памяти. Для актуальны два сценария:

  1. Имитация пиковой нагрузки (например, одновременная работа 50+ пользователей).
  2. Длительные операции (закрытие месяца, перепроводка документов за год).

Инструкция по тестированию с помощью JMeter:

  1. Скачайте и установите Apache JMeter + плагин 1C Protocol.
  2. Создайте Thread Group с количеством потоков, равным пиковому числу пользователей (например, 100).
  3. Добавьте HTTP Request с адресом вашего сервера (например, http://server/1c_base/ws/StandardOData).
  4. Настройте Timer для имитации задержек между действиями (например, 5 секунд).
  5. Запустите тест на 1-2 часа и анализируйте метрики:
    • 📈 Время отклика (должно быть < 3 сек для критических операций).
    • 🔴 Ошибки (коды 500, таймауты).
    • 💾 Использование RAM (мониторьте через Диспетчер задач или PerfMon).
  6. Критичные показатели для 1С: ERP 2.5 на MS SQL:

    • 🚨 Блокировки: если в логах SQL Server появляются сообщения о deadlock, проверьте транзакции в модулях документов.
    • Длительные запросы: запросы свыше 10 секунд требуют оптимизации (добавьте индексы или перепишите код).
    💡

    При стресс-тестировании клиент-серверной базы на PostgreSQL отслеживайте параметр work_mem. Его значение должно быть не менее 16 МБ на соединение, иначе сортировки больших таблиц будут «валиться» в временные файлы, тормозя систему.

    5. Проверка целостности данных: скрытые ошибки

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

    • 🔗 Битые ссылки на удалённые элементы справочников.
    • 💰 Расхождения итогов в регистрах накопления (например, остатки товаров не сходятся с оборотками).
    • 📅 Некорректные даты в документах (будущие даты в проведённых операциях).

Для выявления таких ошибок используйте:

  1. Встроенные отчёты :
    • Администрирование → Тестирование и исправление (проверяет ссылки и индексы).
    • Отчёты → Стандартные → Анализ данных (для поиска дублей).
  • SQL-запросы (для клиент-серверных баз). Примеры:
    -- Поиск битых ссылок в документах
    

    SELECT Документ.Ссылка

    FROM Документ.РеализацияТоваровУслуг AS Документ

    WHERE Документ.Контрагент IS NULL;

    -- Проверка остатков по регистру "ТоварыНаСкладах"

    SELECT Товар, Склад, SUM(Количество)

    FROM РегистрНакопления.ТоварыНаСкладах

    GROUP BY Товар, Склад

    HAVING SUM(Количество) < 0;

  • Сторонние утилиты:
    • 🛠️ 1С:Ревизор — анализирует логическую целостность данных.
    • 🔍 DBComparer — сравнивает структуры таблиц между базами.
  • Особое внимание уделите регистрам сведений с периодичностью «Секунда» (например, курсы валют). В них часто накапливаются дублирующие записи, которые тормозят выборки. Для чистки используйте обработку ПоискИУдалениеДублей из 1С:ИТС.

    ⚠️ Внимание: В базах 1С:ЗУП 3.1 после обновления до версии 3.1.18+ автоматически включается контроль актуальности кадровых данных. Если в справочнике ФизическиеЛица есть сотрудники с пустыми полями ДатаРождения или ИНН, система будет выдавать предупреждения при проведении документов. Проверьте эти данные заранее.

    6. Тестирование обменов данными

    Обмены с внешними системами (банки, ЕГАИС, Диадок, МойСклад) — одно из самых уязвимых мест в . Ошибки здесь проявляются не сразу, а через дни или недели. Чтобы их выявить:

    1. Проверьте форматы данных:
      • 📄 Для XML-обменов валидируйте схему через XML Spy или онлайн-валидаторы.
      • 📊 Для JSON используйте JSONLint.
  • Имитируйте сбои связи:
    • 🔌 Отключите интернет на 10-15 секунд во время обмена (например, через Файрвол Windows).
    • Проверьте, восстановится ли обмен после восстановления связи.
    • Тестируйте крайние случаи:
      • 📦 Отправьте документ с максимально допустимым количеством строк (например, 10 000 позиций в РеализацияТоваров).
      • 💰 Укажите в платежном поручении сумму с 10 знаками после запятой.

    Для обменов с ЕГАИС обязательно проверьте:

    • 🍷 Корректность формирования TTN (транспортная накладная) при частичной отгрузке.
    • 🔞 Совпадение АлкоКодов в справочнике Номенклатура с данными ЕГАИС.

    Пример скрипта для проверки обмена с банк-клиентом (формат 1С:БанкКлиент):

    // Проверяем корректность реквизитов платежного поручения
    

    Процедура ПроверитьПлатежку(Платежка)

    Если НЕ ЗначениеЗаполнено(Платежка.Сумма) Тогда

    ВызватьИсключение "Не указана сумма платежа!";

    КонецЕсли;

    Если НЕ Регламентные.ПроверитьБИК(Платежка.БанкПолучателя.БИК) Тогда

    ВызватьИсключение "Некорректный БИК банка получателя!";

    КонецЕсли;

    КонецПроцедуры

    7. Анализ результатов и формирование отчёта

    После тестирования необходимо систематизировать результаты и принять решение о готовности базы к обновлению или внедрению. Структура отчёта:

    1. Общая информация:
      • 📅 Дата и время тестирования.
      • 🖥️ Версия платформы и конфигурации.
      • 👥 Количество тестовых пользователей.
  • Выявленные ошибки (с приоритетом):
    Тип Описание Приоритет Статус
    Критическая Падение сервера при закрытии месяца Высокий Не исправлено
    Ошибка Некорректный расчёт НДС в отчёте Средний В работе
    Предупреждение Длительное выполнение запроса (8 сек) Низкий На оптимизацию
  • Рекомендации:
    • 🔧 Исправить ошибки с приоритетом «Высокий».
    • ⚡ Оптимизировать медленные запросы (добавить индексы).
    • 📋 Повторить тестирование обменов с ЕГАИС после исправлений.
  • Для визуализации результатов используйте:

    • 📊 Grafana + Prometheus для мониторинга производительности.
    • 📈 Excel + Power Query для анализа логов.

    Если ошибок не обнаружено, перед внедрением изменений в рабочую базу:

    1. Создайте ещё одну резервную копию тестовой базы.
    2. Повторите критичные тесты (например, закрытие месяца).
    3. Согласуйте отчёт с руководителем проекта или главным бухгалтером.
    💡

    В отчёте обязательно укажите время простоя (если оно потребуется для обновления рабочей базы) и обратную совместимость (будут ли работать старые отчёты и обработки после обновления).

    FAQ: Частые вопросы по тестированию 1С

    🔹 Как часто нужно тестировать базу, если обновления выходят ежемесячно?

    Для минорных обновлений (например, 3.0.83 → 3.0.84) достаточно регрессионного тестирования критичных участков (отчёты, обмены). Для мажорных (3.0 → 3.1) — полный цикл (функциональное + нагрузочное + интеграционное).

    Если в базе ведётся активная разработка (доработки конфигурации), тестируйте перед каждым релизам в продуктив.

    🔹 Можно ли тестировать базу на том же сервере, где работает продуктив?

    Нет, это рискованно. Даже тестовые операции создают нагрузку на дисковую подсистему и SQL, что может тормозить работу пользователей. Оптимальные варианты:

    • 🖥️ Виртуальная машина с копией базы.
    • ☁️ Облачный сервер (например, 1С:Fresh для тестов).

    Исключение — тестирование в нерабочие часы (ночь/выходные), но только для проверки производительности.

    🔹 Какие ошибки чаще всего пропускают при тестировании?

    Топ-5 упущений:

    1. 📅 Документы с будущей датой (например, приходная накладная на 31.12.2026 в базе на 2026 год).
    2. 🔄 Непроводимые документы (остаются в статусе «Не проведён» из-за ошибок в модуле).
    3. 💾 Переполнение числовых полей (например, сумма превышает 10^15).
    4. 🔗 Битые ссылки в регистрах сведений (не видны в интерфейсе, но тормозят отчёты).
    5. 📊 Расхождения в аналитических разрезах (например, остатки по складу не сходятся с остатками по номенклатуре).

    Используйте обработку ПоискОшибокВДанных из 1С:ИТС — она находит 80% таких проблем.

    🔹 Как протестировать обмен с МойСклад, если нет тестового аккаунта?

    Возможные решения:

    • 📤 Мокирование API: разверните локальный сервер (например, Mockoon) и настройте его на ответы в формате МойСклад.
    • 📄 Тестовые данные: экспортируйте реальные данные из продуктива, замените чувствительную информацию (ИНН, телефоны) и загрузите в тестовую базу.
    • 🔄 Песочница МойСклад: запросите доступ к тестовому контуру через поддержку (обычно предоставляется на 14 дней).

    Для проверки корректности JSON-структур используйте валидатор JSONLint.

    🔹 Нужно ли тестировать базу после обновления Windows Server или MS SQL?

    Да, обязательно! Обновления ОС или СУБД могут:

    • 🔧 Изменить планы выполнения запросовMS SQL после апдейтов часто сбрасывается кэш планов).
    • 🛡️ Ужесточить политики безопасности (например, Windows Server 2022 блокирует нешифрованные соединения по умолчанию).
    • Поменять приоритеты процессов (в новых версиях Windows фоновые задачи могут получать меньше CPU).

    Проведите стресс-тест и проверьте логи SQL Server на ошибки совместимости.