Проверка базы и конфигурации 1С: от ручных сценариев до автотестов
Содержание
Чтобы протестировать 1С на ошибки, начните с трёх проверок на копии базы: Администрирование → Тестирование и исправление в Конфигураторе (целостность данных), Конфигурация → Проверка конфигурации (ошибки кода и метаданных) и прогон ключевых сценариев пользователей — ввод и проведение документов, формирование отчётов, обмен. Дальше подключают автотесты, замер производительности и регрессионный прогон после каждого обновления.
Типичная ситуация: после обновления релиза у бухгалтера перестала проводиться реализация, а у кладовщика «поплыли» остатки. Ошибку нашли бы за полчаса, если бы перед переносом в рабочую базу кто-то проверил десяток основных операций. Ниже — порядок такой проверки для файловых и клиент-серверных баз на платформе 8.3.
Что подготовить до начала проверок
Тестировать в рабочей базе нельзя. Любой пробный документ создаёт движения по регистрам, а исправление ошибок в Конфигураторе требует монопольного доступа.
Минимальная подготовка:
- 📦 Копия базы. Выгрузите информационную базу в
.dt(Администрирование → Выгрузить информационную базув Конфигураторе) и загрузите в отдельную тестовую базу. Для клиент-серверного варианта можно восстановить бэкап СУБД в новую базу на кластере. - 🏷️ Пометка тестовой базы. Измените заголовок окна или имя базы в списке, чтобы пользователи не перепутали её с рабочей. В типовых конфигурациях при запуске копии появляется вопрос о перемещении базы — ответьте, что это копия: регламентные задания и обмены в ней отключатся.
- 🔌 Отключение внешних связей. В копии отключите отправку почты, ЭДО, обмены с другими базами и загрузку из банка. Иначе тестовый документ может уйти контрагенту.
- 📝 Список сценариев. Выпишите 10–20 операций, без которых работа встанет: поступление, реализация, оплата, расчёт зарплаты, закрытие месяца , печать основных форм, обмен с сайтом или кассой.
- 🧾 Эталонные цифры. До изменений сформируйте в копии оборотно-сальдовую ведомость, остатки по складам и расчётный листок за последний закрытый месяц. Сохраните их в файл — с ними будете сравнивать результат.
Для файловой базы до запуска Конфигуратора полезно проверить физическую целостность файла 1Cv8.1CD утилитой chdbfl.exe из каталога bin платформы. Она работает только с закрытой базой: попросите пользователей выйти.
Проверка целостности данных, конфигурации и кода
Это первый слой тестирования: он находит битые ссылки, нарушенные итоги и ошибки в модулях без участия пользователя.
Тестирование и исправление информационной базы
В Конфигураторе откройте Администрирование → Тестирование и исправление. Режим требует монопольного доступа, поэтому на рабочей базе его запускают только в нерабочее время.
| Флажок | Что проверяет | Когда включать |
|---|---|---|
| Реиндексация таблиц | Перестраивает индексы | При ошибках сортировки и поиска |
| Проверка логической целостности | Структуру данных информационной базы | Всегда |
| Проверка ссылочной целостности | «Битые» ссылки на удалённые объекты | Всегда |
| Пересчёт итогов | Итоги регистров накопления и бухгалтерии | При расхождении остатков в отчётах |
| Сжатие таблиц | Размер файловой базы | По необходимости |
| Реструктуризация таблиц | Полное пересоздание таблиц | Только при серьёзных сбоях, долго |
Сначала запустите режим «Только проверка». Посмотрите протокол и только потом решайте, исправлять ли. Для битых ссылок выбирайте «Создавать объекты» — так видно, какие документы ссылаются на пропавший элемент, и их можно поправить вручную. Вариант «Удалять ссылки» молча очищает реквизиты.
Проверка конфигурации
В Конфигураторе: Конфигурация → Проверка конфигурации. Отметьте логическую целостность, поиск некорректных ссылок и синтаксический контроль модулей для нужных режимов запуска (тонкий клиент, сервер, веб-клиент). Протокол покажет вызовы несуществующих методов, неверные типы реквизитов и обращения к удалённым объектам.
Те же проверки запускаются из командной строки — удобно для ночной автоматической проверки:
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\TestBase" /N"Администратор" /P"" ^
/CheckModules -ThinClient -Server ^
/Out"D:\Logs\check.txt"
Номер платформы в пути подставьте свой.
Встроенные проверки учёта
В типовых конфигурациях есть свои механизмы. В 1С:Бухгалтерии 3.0 — Отчёты → Анализ учёта → Экспресс-проверка ведения учёта: она находит пропуски счетов-фактур, отрицательные остатки, нарушения последовательности. В ЗУП 3.1 сверку начислений удобно делать по своду начислений против эталона, снятого заранее.
Поиск ошибок в коде доработок
Для типовой конфигурации без изменений этот этап короткий: достаточно проверки конфигурации. Если есть доработки, ошибки чаще всего прячутся в них.
Что делать:
- 🔎 Сравнение с поставщиком.
Конфигурация → Сравнить, объединить с конфигурацией поставщикапоказывает, какие объекты изменены. Именно их проверяйте в первую очередь. - 🧩 Расширения. Откройте
Конфигурация → Расширения конфигурациии проверьте, что все расширения применяются к новому релизу без ошибок. Расширение, написанное под старую версию, после обновления может перестать подключаться. - 🐞 Отладчик. Включите отладку в настройках Конфигуратора и поставьте точку останова в процедуре, где возникает ошибка. В пошаговом режиме видно значения переменных и момент, когда ссылка становится пустой.
- 📜 Журнал регистрации.
Администрирование → Журнал регистрациив Конфигураторе или в режиме Предприятия. Фильтр по уровню «Ошибка» за нужный период показывает текст исключения, пользователя и объект. - 🧪 Статический анализ. SonarQube с плагином BSL Language Server находит запросы в цикле, неиспользуемые переменные и ошибки, которые синтаксический контроль пропускает.
Прежде чем лезть в код, воспроизведите ошибку на тестовой базе под тем же пользователем. Половина «ошибок программы» оказывается настройками прав или данных одной записи.
Ручное тестирование: прогон пользовательских сценариев
Автоматические проверки не скажут, что в печатной форме съехала сумма прописью. Это видит только человек, который проходит операцию от начала до конца.
Как построить прогон
Для каждого сценария из списка зафиксируйте три вещи: исходные данные, действие и ожидаемый результат. Пример:
| Сценарий | Действие | Ожидаемый результат |
|---|---|---|
| Реализация товаров | Ввести и провести на 3 позиции, 120 000 ₽ с НДС 20% | Проводки Дт 62 Кт 90.01 на 120 000, Дт 90.03 Кт 68.02 на 20 000, остаток на складе уменьшился |
| Оплата от покупателя | Загрузить выписку, провести поступление | Долг по 62 закрыт, в акте сверки нули |
| Печать УПД | Открыть печать из документа | Все реквизиты заполнены, сумма прописью верная |
| Закрытие месяца | Выполнить обработку | Все этапы зелёные, 90.09 и 99 закрыты |
Проверка 120 000 ₽: НДС 20% внутри суммы = 120 000 × 20 / 120 = 20 000 ₽.
Что проверять в каждом модуле
- 📄 Документы: запись, проведение, отмена проведения, повторное проведение, ввод на основании, пометка на удаление.
- 📊 Отчёты: формирование за короткий и длинный период, отборы, расшифровка до документа, вывод в Excel.
- 🖨️ Печатные формы: реквизиты организации и контрагента, итоги, подписи, многостраничные документы.
- 👥 Права: вход под пользователем с урезанной ролью. Часть ошибок «Нарушение прав доступа» видна только так — администратор их не встретит.
- 🌐 Режимы клиента: если базой пользуются через веб-клиент или тонкий клиент по HTTP, пройдите сценарии и там.
Если в рабочей базе нужно проверить проведение «на живом» документе, не проводите копию существующего документа без необходимости: она задвоит движения. Если всё же провели — сразу отмените проведение и удалите копию.
Автотесты: Vanessa Automation, YAxUnit и сценарное тестирование
Ручной прогон 20 сценариев занимает полдня. После третьего обновления за квартал его начинают пропускать. Автотесты решают эту проблему: один раз записали — дальше прогоняете за минуты.
Механизм платформы
Платформа 8.3 умеет запускать клиент в двух ролях: менеджер тестирования (/TestManager) и клиент тестирования (/TestClient). Менеджер управляет формами клиента программно: открывает, заполняет поля, нажимает кнопки. На этом механизме построены все популярные инструменты.
Инструменты
| Инструмент | Что тестирует | Как пишутся тесты | Кому подходит |
|---|---|---|---|
| Vanessa Automation | Пользовательские сценарии через интерфейс | Язык Gherkin («Дано — Когда — Тогда»), можно записывать действия | Внедренцам, тестировщикам, аналитикам |
| YAxUnit | Отдельные процедуры и функции | Модульные тесты на встроенном языке в расширении, среда EDT | Разработчикам |
| 1С:Сценарное тестирование | Сценарии по интерфейсу | Запись и редактирование сценариев | Командам на типовых продуктах 1С |
| SonarQube + BSL Language Server | Качество кода, а не поведение | Статический анализ, сотни правил | Командам с собственной доработкой |
Пример сценария Vanessa Automation в упрощённом виде:
Функционал: Реализация товаров
Сценарий: Проведение реализации
Дано Я открываю основную форму списка документа "РеализацияТоваровУслуг"
И я нажимаю на кнопку "Создать"
И в поле "Контрагент" я ввожу текст "ООО Ромашка"
И я нажимаю на кнопку "Провести и закрыть"
Тогда я жду закрытия окна в течение 20 секунд
Конкретные шаги берите из библиотеки шагов самого инструмента: имена шагов должны совпадать дословно, иначе сценарий не запустится.
С чего начать автоматизацию
- Возьмите 5 сценариев, которые чаще всего ломались.
- Запишите их в Vanessa Automation на тестовой базе с фиксированными данными.
- Прогоните после ближайшего обновления и сравните с ручной проверкой.
- Добавляйте по 2–3 сценария после каждой найденной ошибки — так покрытие растёт там, где реально больно.
Проверка обменов данными
Ошибки обменов коварны: документ уходит, но приходит с пустым реквизитом или дважды. Обнаруживается это через месяц, при сверке.
Порядок проверки:
- 🔁 Поднимите две тестовые копии — источник и приёмник — и настройте между ними синхронизацию заново или с копией настроек.
- ➕ Создайте в источнике по одному объекту каждого типа, который участвует в обмене: контрагент, номенклатура, документ.
- ▶️ Выполните синхронизацию вручную и сравните объекты: реквизиты, табличные части, суммы.
- ✏️ Измените объект в источнике и синхронизируйте ещё раз. В приёмнике должен обновиться тот же объект, а не появиться второй.
- ❌ Пометьте объект на удаление и проверьте, как это отразилось в приёмнике.
- 📋 Проверьте журнал регистрации обеих баз с отбором по событиям обмена данными.
Дубли чаще всего появляются, когда объекты в двух базах заведены вручную и не сопоставлены. Если правила обмена ищут по ИНН или коду, проверьте объекты с пустым или повторяющимся значением этого поля.
Тестирование производительности и нагрузки
Жалоба «1С тормозит» — тоже ошибка, и её тоже тестируют, но с цифрами.
Замер производительности
В Конфигураторе запустите базу в режиме отладки, откройте Отладка → Замер производительности и выполните медленную операцию. Замер покажет, какие строки кода заняли больше всего времени. Обычно это запрос в цикле или обращение к реквизиту через точку в большой выборке.
Технологический журнал
Для клиент-серверной базы настройте технологический журнал файлом logcfg.xml в каталоге conf платформы. Собирайте события долгих запросов и управляемых блокировок, чтобы увидеть ожидания на блокировках и тяжёлые запросы к СУБД.
Технологический журнал без отбора по длительности за несколько часов заполняет диск сервера. Ставьте порог длительности и ограничивайте срок хранения логов.
Нагрузка
- 🧮 Тест Гилева — быстрая оценка однопоточной производительности сервера и сравнение «до и после» смены железа.
- 👥 Тест-центр из 1С:КИП — эмуляция работы десятков пользователей одновременно. Нужен перед переходом с 10 на 100 активных пользователей.
- ⏱️ Методика APDEX — оценка времени ключевых операций глазами пользователя: задают целевое время (например, проведение реализации — 2 секунды) и считают долю укладывающихся замеров.
Регрессионная проверка после обновления
Регрессия — когда после обновления сломалось то, что раньше работало. Её ловят повторным прогоном одних и тех же сценариев.
Порядок:
- Обновите тестовую копию до нового релиза, включая обновление конфигурации базы данных и обработку обновления при первом запуске.
- Запустите проверку конфигурации и тестирование базы (раздел выше).
- Прогоните автотесты или ручной чек-лист сценариев.
- Сформируйте те же отчёты, что сохранили эталоном, и сравните цифры за закрытые периоды. Они не должны измениться.
- Проверьте расширения, внешние обработки и печатные формы: их обновление не затрагивает.
- Только после этого обновляйте рабочую базу, предварительно сделав её резервную копию.
Обновление рабочей базы требует монопольного доступа на этапе обновления структуры. Предупредите пользователей заранее: незавершённые сеансы будут прерваны, несохранённые данные потеряются.
Расхождение в закрытом периоде — главный сигнал. Если сальдо на 31.12 прошлого года после обновления стало другим, кто-то из обработчиков обновления перезаписал движения. С этим разбираются до переноса в рабочую базу.
Как фиксировать найденные ошибки
Ошибка без описания — это ошибка, которую исправят неправильно. Для каждой найденной проблемы записывайте:
- 🔢 версию платформы и релиз конфигурации;
- 👤 пользователя и его роль;
- 🪜 шаги воспроизведения — по порядку, с данными;
- 🧾 точный текст ошибки (скопируйте из окна, а не пересказывайте);
- ✅ ожидаемый и фактический результат;
- 📎 скриншот и выгрузку из журнала регистрации.
Ведите реестр в любом трекере или даже в таблице. После исправления повторите тот же сценарий на тестовой базе и добавьте его в регрессионный набор. Так одна и та же ошибка не вернётся с очередным релизом.
Если ошибка в типовом коде, а не в доработке, отправьте описание в поддержку фирмы-разработчика или своему партнёру 1С. До выхода исправления можно закрыть проблему расширением, не снимая конфигурацию с поддержки.