Как проверить 1С перед обновлением, доработкой и запуском в работу
Содержание
Тестировать 1С нужно на копии рабочей базы, а не на самой базе. Порядок такой: сделали копию, отключили в ней всё, что умеет отправлять данные наружу, прогнали заранее составленные сценарии и записали результат. Всё остальное — детали, и они ниже.
Без проверки обновление «на живой» базе заканчивается знакомо: в понедельник утром не открывается отчёт, не уходит обмен или падает проведение. Исправлять это под давлением в десять раз дороже, чем найти заранее. Дальше — как организовать тестирование 1С так, чтобы оно занимало часы, а не недели.
Тестовая среда: как сделать безопасную копию базы
Копия должна быть максимально похожей на рабочую базу: та же конфигурация, тот же релиз, те же доработки, свежие данные. Чем сильнее отличия, тем меньше смысла в проверке.
Откуда взять копию
- 📦 Файловая база. Закройте всех пользователей и скопируйте каталог с файлом
1Cv8.1CD. Это самый быстрый способ. - 🗄 Клиент-серверная база
. Выгрузите информационную базу в
.dtчерез Конфигуратор и загрузите в новую пустую базу. Либо восстановите резервную копию СУБД под другим именем. - 🧪 Только структура. Если данные тестировать не нужно, возьмите конфигурацию и наполните демо-данными. Для проверки отчётов и проведения такой вариант не годится.
Что отключить в копии до первого запуска
Это самый важный шаг. Копия «помнит» все настройки боевой базы, включая рассылки и обмены.
- Откройте базу с ключом запуска, который блокирует регламентные задания (в списке параметров запуска он называется «отключить выполнение регламентных заданий»), либо отключите задания в администрировании.
- Уберите пользовательские настройки почты: адреса SMTP/IMAP и учётные записи.
- Отключите обмены: с другими базами, сайтом, банком, ЭДО, кассами и маркировкой. Проверьте, что в настройках не остались рабочие адреса и логины.
- Смените или очистите ключи внешних сервисов (интернет-поддержка, онлайн-касса, ЭДО).
- Подпишите базу визуально: заголовок окна «ТЕСТ» сильно снижает шанс, что бухгалтер внесёт реальный документ в копию.
Если в копии остались включёнными рассылки и обмены, клиенты получат письма из тестовой базы, а контрагенты — тестовые документы по ЭДО. Проверяйте это до первого входа пользователей.
Для тестов хватает отдельного сервера или даже рабочей станции с запасом по памяти. Главное, чтобы копия не делила с боевой базой каталог, порт и учётные записи.
Виды тестирования 1С: что и когда проверять
Под словом «тест» обычно скрываются разные вещи. Их удобно разделить по цели.
| Вид | Что проверяет | Когда нужен |
|---|---|---|
| Проверка целостности | Структура базы, битые ссылки, индексы | Перед обновлением, после сбоев |
| Проверка конфигурации | Синтаксис, ссылки в метаданных, права | После доработок |
| Функциональное | Ключевые сценарии: ввод, проведение, отчёты | После любого изменения |
| Регрессионное | Что старый функционал не сломался | После обновления релиза |
| Интеграционное | Обмены, API, внешние сервисы | После изменения любой стороны обмена |
| Нагрузочное | Скорость при реальном числе пользователей | Перед запуском и ростом базы |
| Приёмочное | Устраивает ли результат тех, кто работает | Перед вводом в эксплуатацию |
Встроенные проверки платформы
Платформа уже умеет часть работы. В Конфигураторе есть пункт Администрирование → Тестирование и исправление: он проверяет логическую и ссылочную целостность и перестраивает индексы. Запускайте его на копии, а результат читайте внимательно: сообщения о потерянных ссылках бывают признаком реальных проблем.
Для конфигурации есть Конфигурация → Проверка конфигурации. Если нужны разные проверки, отметьте нужные флажки: поиск неиспользуемых процедур, проверка модулей на синтаксис, контроль ссылок. На типовой конфигурации без доработок ошибок быть не должно. На доработанной посмотрите, что вносит ваш код.
Для файловых баз остаётся утилита chdbfl.exe из каталога платформы. Она нужна, когда база не открывается или ведёт себя странно.
Что считать приоритетным
Не пытайтесь проверить всё. Выберите 10–20 сценариев, на которых держится работа учёта: приход и реализация, банк, зарплата, закрытие месяца , регламентированная отчётность. Остальное проверяйте выборочно.
Сценарии проверки: как составить тест-план
Тест-план — это таблица, где у каждой проверки есть шаги и ожидаемый результат. Без него проверка превращается в «посмотрели, вроде работает».
Минимальный формат строки:
- Название сценария («Поступление товара с НДС»).
- Исходные данные (контрагент, номенклатура, сумма).
- Шаги: создать документ , заполнить, провести.
- Ожидаемый результат: проводки, остатки в регистрах, строка в отчёте.
- Фактический результат и отметка «пройден / не пройден».
Пример с числами
Проверяете реализацию после обновления. Берёте товар по себестоимости 600 ₽, продаёте за 1 200 ₽ с НДС 20%. Ожидаете: выручка без НДС 1 000 ₽, НДС 200 ₽. Если в отчёте выручка 1 200 ₽ или НДС 240 ₽, сценарий не пройден, и тестовая база только что сэкономила вам нервы.
Храните ожидаемые результаты рядом с шагами. Через год вы или коллега повторите те же сценарии и сразу увидите расхождение.
Автоматизация: инструменты для повторяемых проверок
Ручная проверка хороша один раз. Если те же сценарии нужно гонять после каждого релиза, их стоит автоматизировать.
Что обычно используют
- 🧩 Сценарное тестирование платформы. Режим с записью действий пользователя и их воспроизведением. Подходит для проверки интерфейса.
- 🥒 Vanessa Automation. Бесплатный инструмент на основе сценариев на языке Gherkin: шаги читаются почти как обычный текст. Часто выбирают для приёмочных проверок.
- 🧪 Модульные тесты. Для кода, написанного разработчиками, используют отдельные фреймворки модульного тестирования на языке 1С. Они проверяют отдельные функции без интерфейса.
- 📋 Проверочные обработки. Простая внутренняя обработка, которая создаёт документы по шаблону и сверяет результат. Дёшево, но поддерживать придётся самим.
Как не потратить месяцы впустую
Начните с 5–10 самых важных сценариев и только потом расширяйте. Автотест, который нужно чинить после каждого обновления интерфейса, тоже стоит времени. Автоматизируйте то, что стабильно и часто повторяется.
Автотесты нельзя запускать на боевой базе: они создают и проводят документы. Только копия, только тестовые контрагенты.
Проверка обновления конфигурации: порядок без сюрпризов
Обновление — самый частый повод для тестирования. Схема простая.
- Выгрузите рабочую базу в
.dtи сохраните копию в надёжном месте. - Разверните копию, отключите обмены и задания (см. выше).
- Обновите копию до нужного релиза — именно тем способом, которым будете обновлять боевую базу: через меню
Администрирование, черезcfu-файл или файл поставки. - Дождитесь завершения обработчиков обновления. На больших базах это от нескольких минут до нескольких часов.
- Прогоните тест-план и сравните отчёты.
- Если вы дорабатывали конфигурацию, проверьте, что доработки не слетели: в режиме сравнения и объединения посмотрите, какие объекты изменились.
Что смотреть в первую очередь
- 🔍 Журнал регистрации: нет ли ошибок обновления и падений обработчиков.
- 🔍 Доработанные отчёты и формы: именно они чаще всего ломаются.
- 🔍 Внешние обработки и расширения: совместимы ли они с новым релизом.
- 🔍 Время открытия основных документов: оно не должно вырасти в разы.
Замерьте время обновления копии. Это ваше «окно» для боевой базы: если на тесте обновление шло 40 минут, планируйте минимум час и не назначайте его на начало отчётного дня.
Не обновляйте боевую базу, пока обновление не прошло на копии целиком и вы не сохранили резервную копию. Откат проще, когда он подготовлен.
Обмены и API: как проверить интеграции
Здесь тестируют границу между 1С и внешним миром: распределённые базы, обмен с сайтом, банк-клиент, ЭДО, веб-сервисы и HTTP-сервисы.
Что проверять
- Правила обмена. Выгрузите небольшой набор данных и убедитесь, что поля попали туда, куда нужно.
- Обратное направление. Загрузите данные и посмотрите, не задвоились ли справочники.
- Ошибки. Отправьте заведомо некорректные данные и посмотрите, как система сообщит об этом.
- Границы. Пустые значения, длинные строки, спецсимволы, нулевые суммы.
Для сопоставления полей составьте таблицу соответствия: поле во внешней системе, реквизит в 1С, правило преобразования.
Особенности тестирования API
Для HTTP-сервисов и веб-сервисов 1С удобно использовать отдельные инструменты для запросов: отправили запрос, получили ответ, сравнили с ожидаемым. Проверьте не только «успешный» ответ, но и поведение при неверной авторизации, неверном формате и повторной отправке одного и того же запроса. Последний случай часто создаёт дубли.
На время тестов используйте тестовые учётные записи внешних систем (тестовый контур банка, песочница ЭДО), а не рабочие.
Нагрузочное тестирование: проверка производительности
Нагрузка показывает, как база ведёт себя, когда работают много людей одновременно. Нужна она перед запуском новой базы, переходом на новый сервер или заметным ростом числа пользователей.
Как подойти
- Опишите типичную нагрузку: сколько человек, какие операции, как часто.
- Определите «хорошо»: например, проведение документа за 3 секунды, открытие отчёта за 10.
- Воспроизведите нагрузку: скриптами эмуляции пользователей или реальными сотрудниками в согласованное время.
- Одновременно собирайте данные о сервере: загрузка процессора, память, диски, блокировки.
Чем замерять
- ⏱ Замер производительности (в составе платформы и типовых конфигураций) — время выполнения ключевых операций.
- 📜 Технологический журнал — подробные события сервера: долгие запросы, блокировки, ожидания.
- 🧮 Мониторинг СУБД — медленные запросы, нехватка индексов, рост журнала транзакций.
Если время растёт непропорционально числу пользователей, смотрите на блокировки и на запросы без индексов. Такие вещи на малых нагрузках не проявляются.
Не запускайте нагрузочный тест на сервере, где параллельно работает боевая база. Тест с сотней «виртуальных пользователей» может остановить реальную работу.
Как читать результаты и вести отчётность
Результат тестирования — не «всё хорошо», а документ, по которому можно принять решение.
В отчёте фиксируйте:
- версию конфигурации и платформы до и после;
- дату и среду (какая копия, какого числа снята);
- список сценариев и результат каждого;
- найденные ошибки: что сделали, что получили, что ожидали;
- решение: можно ли обновлять боевую базу.
Как классифицировать замечания
| Уровень | Пример | Решение |
|---|---|---|
| Блокирующее | Документ не проводится | Обновление откладывается |
| Серьёзное | Отчёт считает неверно | Исправить до запуска или найти обходной путь |
| Незначительное | Съехала форма, не тот шрифт | Исправить позже |
Блокирующие замечания обязательно повторно проверяйте после исправления на свежей копии, а не на той же, где уже сделаны ручные правки.
Типичные ошибки при тестировании 1С
Эти промахи повторяются из проекта в проект.
- ❌ Тест на «пустой» базе. Без объёма реальных данных не видны ни медленные запросы, ни проблемы конвертации. Берите копию, близкую к боевой.
- ❌ Один тестировщик — разработчик. Автор доработки проверяет то, что он и так знает. Подключите бухгалтера или менеджера, который работает с этой функцией.
- ❌ Проверили только «успешный путь». Ошибки вылезают на редких вводных: пустых полях, нулевых суммах, возвратах, частичных оплатах.
- ❌ Не повторили тест после исправления. Исправление одной ошибки может сломать соседнюю. Сценарии нужно прогонять заново.
- ❌ Не проверили права. Администратор видит всё, а у бухгалтера может не открыться нужная форма. Войдите под ролями реальных пользователей.
- ❌ Не записали, что и как проверено. Через месяц никто не вспомнит, на какой версии и с какими данными проходил тест.
Если нужно проверить не всё, а только один критичный участок, начните с проведения и отчётности по основным документам, а остальное сверяйте выборочно.