Дымовые тесты в 1С: что это и зачем они нужны

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

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

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

Что именно проверяют в дымовом тесте 1С

Состав дымового теста зависит от конфигурации и специфики учёта, но есть типовой минимум, который подходит большинству баз. Его цель — покрыть самые массовые и критичные сценарии работы пользователей.

Базовый набор проверок обычно включает:

• запуск базы в пользовательском режиме без ошибок инициализации;
• открытие основных форм списков: документы, справочники «Номенклатура», «Контрагенты»;
• создание, заполнение и проведение 2–3 ключевых видов документов (например, реализация, поступление, платёжное поручение);
• формирование главных отчётов: оборотно-сальдовая ведомость, отчёт по продажам, взаиморасчёты;
• проверка работы обменов, если они есть: с сайтом, банком, другими базами;
• печать хотя бы одной печатной формы.

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

Чем дымовой тест отличается от других видов тестирования

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

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

Как провести дымовой тест вручную

Ручной дымовой тест — самый доступный вариант, который не требует никаких инструментов, кроме самой 1С и заранее составленного списка проверок. Он подходит для небольших баз, где обновления выполняются нечасто и объём доработок невелик.

1. 1
   Сделайте резервную копию базы до начала любых изменений — это обязательное условие
2. 2
   Выполните обновление или перенос доработок в тестовую копию базы
3. 3
   Запустите базу в режиме Предприятие под учётной записью с полными правами
4. 4
   Пройдите по чек-листу: откройте основные формы, создайте и проведите ключевые документы, сформируйте главные отчёты
5. 5
   Проверьте работу обменов и регламентных заданий, если они используются
6. 6
   Зафиксируйте результат по каждому пункту: работает / ошибка с описанием
7. 7
   При отсутствии критических ошибок повторите проверку в рабочей базе после обновления

Ключевой момент — заранее написанный чек-лист. Без него проверка превращается в хаотичное «покликать и посмотреть», при котором легко забыть важный сценарий. Чек-лист составляют один раз и дополняют по мере появления новых доработок и обнаруженных инцидентов.

Результат каждой проверки фиксируйте письменно. Если тест не пройден, запись вида «при проведении реализации ошибка: поле объекта не обнаружено (ХХХ)» сэкономит разработчику часы на воспроизведение проблемы.

Автоматизация дымовых тестов

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

Наиболее распространённые подходы в экосистеме 1С:

• Vanessa Automation — открытый инструмент сценарного тестирования, где поведение описывается сценариями на языке Gherkin (например, «Когда я создаю документ Реализация, Тогда документ проводится без ошибок»). Подходит для команд, готовых поддерживать библиотеку сценариев;
• Тестирование конфигурации средствами платформы — проверка конфигурации в конфигураторе (синтаксический контроль, проверка логической целостности) как первый автоматический фильтр перед запуском;
• Сценарные тесты через TestClient — механизм платформы, позволяющий программно управлять клиентским приложением: открывать формы, заполнять данные, нажимать кнопки;
• Автоматические процедуры обновления — при обновлении через механизмы БСП часть проверок (выполнение обработчиков обновления, отложенных обновлений) контролируется штатно.

Автоматизация окупается, когда одни и те же сценарии прогоняются регулярно. Разовую доработку дешевле проверить вручную, чем писать и поддерживать автотест.

Как понять, что дымовой тест пройден

Критерии прохождения должны быть определены заранее, иначе оценка результата превратится в субъективное «вроде всё нормально». Для каждого пункта чек-листа нужен понятный признак успеха.

Контрольные точки

Как проверить результат

Запуск базы

Норма

База открывается, нет сообщений о незавершённых обработчиках обновления

Тревожный признак

Ошибки при входе, зависшие отложенные обновления, требование монопольного режима

Проведение документов

Норма

Документ создаётся, заполняется и проводится без сообщений об ошибках

Тревожный признак

Ошибка «поле объекта не обнаружено», падение при записи, недоступность кнопок

Отчёты

Норма

Отчёт формируется за приемлемое время, данные выводятся

Тревожный признак

Ошибка компоновки, пустой результат при наличии данных в базе

Обмены

Норма

Обмен выполняется, в журнале регистрации нет ошибок сеанса

Тревожный признак

Ошибки подключения, сообщения об изменении структуры данных

Расширения

Норма

Расширения применены, их функции доступны

Тревожный признак

Расширение отключено с диагностикой несовместимости

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

Типичные ошибки при организации дымовых тестов

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

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

Когда дымового теста недостаточно

Дымовой тест — не универсальная защита. Есть ситуации, где поверхностной проверки мало и требуется более глубокое тестирование или дополнительные меры.

Полноценное регрессионное тестирование нужно, когда: обновление затрагивает несколько релизов сразу; изменялись подсистемы учёта (проводки, расчёт себестоимости, НДС); доработка меняет обмены с другими системами; переносились данные между конфигурациями. В этих случаях ошибки чаще скрыты в логике расчётов, а не в доступности форм.

Маршрут решения

Как выбрать действие

Небольшая доработка, не затрагивающая учётные механизмыДостаточно ручного дымового теста по чек-листу на копии базы

Обновление типовой конфигурации на очередной релизДымовой тест плюс контроль выполнения обработчиков обновления и сверка ключевых отчётов до и после

Изменены алгоритмы расчёта, проводки, обменыДымовой тест как первый фильтр, затем регрессионная проверка затронутых подсистем на копии с реальными данными

Обновлений много и они регулярныеИнвестируйте в автоматизацию сценариев дымового теста, чтобы сократить время каждого цикла

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

Самый ценный источник сценариев для дымового теста — реальные инциденты. Каждый раз, когда после обновления что-то ломалось в рабочей базе, добавляйте этот случай в чек-лист. Через несколько циклов получится компактный набор проверок, точно покрывающий уязвимые места именно вашей конфигурации.

Частые вопросы о дымовых тестах в 1С

Сколько времени должен занимать дымовой тест?

Ориентир — от 10–15 минут для небольшой базы с коротким чек-листом до 30–60 минут для крупной конфигурации с обменами и расширениями. Если проверка занимает больше часа, это уже не дымовой тест, а сокращённое регрессионное тестирование — стоит разделить список на быстрый минимум и расширенный набор.

Можно ли проводить дымовой тест сразу в рабочей базе?

Можно только как финальный этап после успешной проверки копии, и только те пункты, которые не создают лишних данных: открытие форм, формирование отчётов, проверка доступности функций. Создание и проведение тестовых документов в рабочей базе недопустимо — они попадут в учёт и отчётность.

Что проверять в первую очередь, если времени совсем мало?

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

Нужен ли дымовой тест при установке расширения?

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

Чем автоматизировать дымовые тесты без бюджета на платные инструменты?

Основные инструменты бесплатны: механизм TestClient встроен в платформу, Vanessa Automation распространяется открыто, а проверку конфигурации и выполнение обработчиков обновления можно запускать пакетными командами конфигуратора. Основные затраты — время на написание и поддержку сценариев, а не лицензии.

Дымовой тест пройден, но пользователи нашли ошибку. Что не так?

Это нормальная ситуация: дымовой тест по определению не ищет все ошибки, а только критические. Разберите инцидент: если ошибка критичная и могла быть обнаружена быстрой проверкой — добавьте соответствующий сценарий в чек-лист. Если она скрыта в глубокой логике расчёта — значит, для таких изменений нужен уровень регрессионного тестирования.