Администрирование · 11 мин
Дымовой тест в 1С: что это и как его проводить
Что такое дымовой тест в 1С, когда он нужен после обновления и доработок, как составить сценарии, проверить результат и избежать типичных ошибок.
Дымовой тест (smoke test) в 1С — это короткая проверка работоспособности системы после обновления конфигурации, установки релиза платформы или внедрения доработок. Его задача — быстро ответить на вопрос: запускается ли база, открываются ли ключевые формы и выполняются ли основные операции без критических ошибок. Название пришло из электроники: новое устройство сначала включают и смотрят, не пошёл ли дым, — и только потом тестируют глубоко.
В отличие от полноценного регрессионного тестирования, дымовой тест не проверяет корректность расчётов, проводок и отчётов до копейки. Он подтверждает, что система «жива» и с ней можно начинать работу или переходить к более детальным проверкам. Обычно такой тест занимает от 15 минут до часа в зависимости от размера конфигурации.
Дымовое тестирование особенно важно в 1С, потому что обновления типовых конфигураций выходят часто, а доработанные решения чувствительны даже к небольшим изменениям объектов метаданных. Пропущенный на этом этапе сбой может вылиться в остановку учёта: менеджеры не смогут провести реализацию, а бухгалтер — закрыть месяц.
Когда проводить дымовой тест
Главный повод — любое изменение программного слоя, способное повлиять на работу пользователей. Классические ситуации: обновление конфигурации на новый релиз, обновление платформы 1С:Предприятие, перенос доработок из тестовой базы в рабочую, изменение расширений конфигурации, миграция базы на другой сервер или СУБД.
Дымовой тест имеет смысл и после чисто инфраструктурных работ: переезда сервера 1С, смены версии MS SQL или PostgreSQL, изменения настроек кластера. Формально конфигурация не менялась, но окружение — да, и это тоже источник сбоев.
Не нужен дымовой тест при изменениях, которые не затрагивают код и метаданные: добавлении пользователя, настройке прав, правке шаблона печатной формы через пользовательский макет. Здесь достаточно точечной проверки конкретного изменения.
Когда нужен дымовой тест
Что именно проверять: состав минимального сценария
Сценарий дымового теста строится вокруг критичных бизнес-операций конкретной организации. Универсального списка нет, но базовый каркас для большинства торгово-производственных конфигураций выглядит так: запуск базы в пользовательском режиме, открытие основных разделов, создание и проведение ключевых документов, формирование главных отчётов, проверка обменов и регламентных заданий.
Для базы с торговым учётом в список обычно входят: создание заказа покупателя, проведение реализации товаров, оформление поступления, формирование взаиморасчётов. Для бухгалтерии — проведение документов банка и кассы, формирование оборотно-сальдовой ведомости, проверка корректности заполнения счетов учёта. Для зарплатной конфигурации — расчёт начислений по тестовому сотруднику и формирование расчётного листка.
Важно проверять не только успешное выполнение операций, но и отсутствие ошибок в журнале регистрации. Форма может открыться визуально нормально, но при этом в журнале появятся ошибки фоновых процедур — это уже повод остановить запуск.
- 1Сделайте резервную копию рабочей базы и убедитесь, что она восстанавливается
- 2Примените обновление или доработку на копии базы, а не на рабочей
- 3Запустите базу в пользовательском режиме под учётной записью с полными правами
- 4Откройте основные разделы и ключевые формы: списки документов, справочники, рабочий стол
- 5Создайте и проведите по одному документу каждого критичного вида на тестовых данных
- 6Сформируйте 2–3 главных отчёта за реальный период
- 7Проверьте журнал регистрации на наличие ошибок за время теста
- 8Повторите запуск под учётной записью рядового пользователя с ограниченными правами
- 9Зафиксируйте результат и только после этого запланируйте обновление рабочей базы
Как проверить результат и отличить норму от проблемы
Критерий прохождения дымового теста — отсутствие критических ошибок при выполнении всех пунктов сценария. Критичными считаются ошибки, которые блокируют работу: база не запускается, документ не проводится, отчёт падает с исключением, обмен не выполняется. Некритичные замечания — например, изменившееся расположение кнопки на форме — фиксируются, но не останавливают запуск.
Отдельно проверяйте поведение под пользователями с ограниченными правами. Частая ситуация: под полными правами всё работает, а у менеджера с ролью «Продажи» форма документа не открывается из-за ошибки доступа к новому объекту метаданных. Такие ошибки выявляются только тестом под реальной ролью.
Обращайте внимание на время выполнения операций. Если после обновления отчёт, который формировался за секунды, стал строиться минутами, — это не критическая ошибка, но сигнал о проблеме производительности, который нужно зафиксировать до запуска пользователей.
Как проверить результат
База открывается в пользовательском режиме без сообщений об ошибках
Ошибки инициализации, требование монопольного режима, аварийное завершение
Документы создаются, проводятся, движения формируются
Исключения при проведении, пустые движения, ошибки заполнения
Отчёты формируются за рабочий период за приемлемое время
Падение с ошибкой, бесконечное формирование, пустой результат
Под ролью пользователя доступны нужные разделы и документы
Нарушение прав доступа, недоступные формы, скрытые команды
Нет новых ошибок за время теста
Ошибки фоновых заданий, обменов, обработчиков обновления
Типичные ошибки при дымовом тестировании
Самая распространённая ошибка — проведение теста сразу на рабочей базе в надежде, что «обновление типовое, ничего не сломается». Даже типовое обновление может конфликтовать с доработками, расширениями или нестандартными настройками. Тестировать нужно на копии, восстановленной из свежей резервной копии.
Вторая ошибка — тестирование только под администратором. Полные права маскируют проблемы доступа, и пользователи узнают о них уже в рабочем режиме. Третья типичная ошибка — проверка только запуска базы без выполнения реальных операций. База может запускаться идеально, но падать на проведении конкретного документа.
Ещё одна проблема — отсутствие письменного чек-листа. Без него каждый тест превращается в импровизацию: один раз проверили отчёты, другой раз забыли. Чек-лист должен быть зафиксирован и дополняться по мере появления новых критичных операций.
Автоматизация дымового теста
Если обновления происходят часто, ручной прогон чек-листа отнимает заметное время, и его имеет смысл автоматизировать. В экосистеме 1С для этого используются инструменты сценарного тестирования: Vanessa Automation для поведенческих тестов, встроенный механизм тестирования управляемых форм, а также внешние средства вроде TestComplete.
Автоматизировать в первую очередь стоит стабильные и часто повторяющиеся сценарии: запуск базы, открытие форм, проведение типовых документов. Сценарии, завязанные на меняющиеся данные или сложную аналитику, дешевле оставить ручными — поддержка таких автотестов обходится дороже, чем их периодический ручной прогон.
Для небольших внедрений с редкими обновлениями автоматизация дымового теста обычно не окупается: написание и поддержка сценариев требуют компетенций и времени. Здесь достаточно дисциплинированного ручного чек-листа.
Ручной или автоматизированный тест
Подходит при редких обновлениях и небольшом числе сценариев; не требует разработки, но зависит от внимательности исполнителя
Подходит при частых релизах и доработках; требует навыков написания сценариев и их поддержки
Подходят для комплексных стендов с интеграциями; высокая стоимость внедрения и лицензий
Ограничения дымового теста и что делать дальше
Дымовой тест не гарантирует корректность учёта. Он не проверяет точность расчёта себестоимости, правильность проводок, полноту данных в регламентированной отчётности. Все эти вопросы — зона ответственности регрессионного и приёмочного тестирования, которые выполняются после успешного дымового прогона.
Также дымовой тест не заменяет проверку обменов с внешними системами в реальном объёме. Тестовый обмен одним пакетом может пройти успешно, тогда как полная выгрузка выявит ошибки. Для критичных интеграций планируйте отдельную проверку на данных, близких к боевым.
Практическая схема выглядит так: дымовой тест на копии → при успехе обновление рабочей базы в нерабочее время → короткий контрольный прогон на рабочей базе → запуск пользователей. Такой порядок минимизирует и риск сбоев, и время простоя.
Храните чек-лист дымового теста рядом с планом обновления и отмечайте в нём дату, версию конфигурации и результат каждого пункта. Такой журнал быстро отвечает на вопрос «что именно проверяли перед запуском», когда проблема проявляется спустя несколько дней после обновления.
Частые вопросы о дымовом тесте в 1С
Чем дымовой тест отличается от регрессионного тестирования?
Дымовой тест проверяет только работоспособность системы в целом: запуск, открытие форм, проведение ключевых документов. Регрессионное тестирование глубоко проверяет, что ранее работавшая функциональность не сломалась, включая точность расчётов и граничные случаи. Дымовой тест — это фильтр перед регрессией, а не её замена.
Сколько времени должен занимать дымовой тест?
Ориентир — от 15 минут до часа. Если прогон занимает дольше, сценарий, скорее всего, перегружен и часть проверок стоит перенести в регрессионный контур. Слишком короткий тест (пара минут на запуск базы) недостаточен и не выявляет реальные проблемы.
Можно ли проводить дымовой тест на рабочей базе?
Можно только как финальный короткий контроль после уже выполненного теста на копии — например, проверить запуск и пару операций сразу после обновления. Основной прогон всегда выполняется на копии: иначе цена ошибки — остановка работы пользователей и порча данных.
Кто должен выполнять дымовой тест?
Техническую часть (обновление, запуск, журнал регистрации) выполняет администратор или разработчик 1С. Проверку бизнес-операций полезно поручить ключевому пользователю, который знает реальные сценарии работы: он быстрее заметит неочевидные отклонения в поведении документов и отчётов.
Нужно ли тестировать после установки обновления платформы, если конфигурация не менялась?
Да. Новая версия платформы может изменить поведение механизмов, от которых зависит конфигурация: работу СКД, фоновых заданий, веб-клиента. Дымовой тест в этом случае можно сократить до запуска, ключевых форм, отчётов и регламентных заданий, но полностью пропускать его не стоит.
Что важно запомнить
Дымовой тест 1С — быстрая проверка работоспособности системы после обновления или доработок: запуск базы, проведение ключевых документов, формирование отчётов, контроль журнала регистрации. Проводите его на копии базы по письменному чек-листу, проверяйте работу под реальными ролями пользователей и не запускайте рабочую базу при критических ошибках. Полное тестирование он не заменяет — только предшествует ему.