Разработка плана Smoke Test

Урок 3 · Монтаж и пусконаладка контроллера · 15 мин · theory

Что такое план Smoke Test и его назначение

> 💡 Подсказка: Хорошо составленный и согласованный план тестирования экономит до 50% времени на этапе пусконаладки и является главным инструментом для сдачи объекта заказчику.

План Smoke Test — это структурированный документ, который описывает набор последовательных проверок (тест-кейсов), направленных на подтверждение базовой работоспособности системы автоматизации после монтажа и первичной настройки. Его основная цель — быстро, эффективно и системно убедиться, что "дым не идет", то есть наиболее критичные и фундаментальные функции системы работают корректно.

Ключевое отличие плана от отдельных тестовых сценариев, которые мы рассматривали в предыдущих уроках, заключается в комплексности и упорядоченности. Если отдельный сценарий, например, «Кнопка-Свет», проверяет лишь узкий участок логики, то план Smoke Test представляет собой упорядоченный набор таких сценариев, который охватывает всю систему целиком. Он связывает отдельные проверки в единый процесс пусконаладки, гарантируя, что ни один важный аспект не будет пропущен.

Важность плана для инженера-инсталлятора невозможно переоценить. Он выполняет несколько критически важных функций:

Сокращение времени на объекте: Вместо хаотичных проверок "по памяти" вы следуете четкому алгоритму. Это исключает лишние перемещения по объекту, повторные тесты и позволяет сфокусироваться на решении реальных проблем, а не на попытках вспомнить, «что еще нужно было проверить».

Предотвращение пропусков: Человеческий фактор — одна из главных причин ошибок. В суете пусконаладочных работ легко забыть проверить работу датчика в дальнем углу или одну из световых групп. План служит чек-листом, который гарантирует 100% покрытие базового функционала.

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

Аргумент при сдаче объекта: План, заполненный результатами тестов (Pass/Fail), является неотъемлемой частью Исполнительной документации. Это формальное подтверждение для заказчика, что система работает в соответствии с заявленными требованиями. Он позволяет наглядно продемонстрировать работоспособность каждого элемента и сценария.

Для разработки качественного плана необходимы следующие исходные данные, которые формируются на этапе проектирования:

Функциональная спецификация (ФС): Документ, описывающий логику работы системы. Из него мы берем информацию о том, как* система должна себя вести (например, "при обнаружении движения в коридоре свет включается на 5 минут"). Проектная документация: Схемы щитов, планы расположения оборудования, схемы подключений. Отсюда мы получаем информацию о том, какое оборудование установлено и где* оно находится.

Кабельный журнал: Таблица, связывающая каждый кабель с его начальной и конечной точкой. Помогает идентифицировать, какой физический вход/выход контроллера за что отвечает.
Список установленного оборудования: Перечень всех устройств с их моделями и адресами (IP, Modbus ID и т.д.).

Изучив эти документы, инженер получает полное представление о системе и может приступить к структурированию проверок.

---

Структура и ведение документа

> ℹ️ Информация: В материалах к курсу приложен шаблон плана Smoke Test в формате .xlsx. Рекомендуем использовать его как основу для ваших проектов.

План Smoke Test — это официальный документ, и его структура должна быть четкой, понятной и стандартизированной. Наиболее удобным форматом для его ведения являются электронные таблицы (например, Microsoft Excel или Google Sheets), так как они позволяют легко фильтровать данные, отслеживать статус и предоставлять к ним совместный доступ.

Рекомендуемая структура документа выглядит следующим образом:

Титульный лист:

* Наименование проекта: Например, "Система автоматизации коттеджа в КП 'Сосновый Бор'".

* Адрес объекта: Полный адрес.

* Дата проведения теста: Дата начала и окончания тестирования.

* Версия документа: Например, `v1.0` (начальная), `v1.1` (после внесения правок).

* Исполнители: ФИО и должности инженеров, проводящих тест.

* Представитель заказчика: Место для подписи (при необходимости).

Чек-лист предварительных проверок:

Этот раздел выносится вперед, так как без выполнения этих пунктов дальнейшее тестирование бессмысленно. Он включает проверку базовой инфраструктуры, как было рассмотрено в курсе `COURSE-02`.

* [ ] Питание 230В на контроллер подано, автомат защиты включен.

* [ ] Питание 24В для датчиков и периферии присутствует, блок питания работает в штатном режиме.

* [ ] Контроллер загрузился, сетевое подключение Ethernet активно (link горит).

* [ ] Доступ к контроллеру по SSH есть, сервис `hi-core.service` запущен и активен.

* [ ] Напряжение на шинах данных (RS-485, DALI) находится в пределах нормы.

Таблица Тест-Кейсов:

Это ядро всего документа. Каждая строка в таблице — это один тест-кейс, то есть атомарная проверка одной функции.

| :--- | :------------- | :------------------- | :---------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------- | :-------------------------- | :----------------------------------------- |

| L-01 | Гостиная | `RL-01`, `SW-LR-01` | Краткое нажатие на клавишу 1 панели `SW-LR-01`. | Реле `RL-01` щелкает, включается основная группа света. В MQTT приходит сообщение `{"state":"ON"}`. | Pass | - |

| L-02 | Гостиная | `RL-01`, `SW-LR-01` | Повторное краткое нажатие на клавишу 1 панели `SW-LR-01`. | Реле `RL-01` щелкает, выключается основная группа света. В MQTT приходит сообщение `{"state":"OFF"}`. | Pass | - |

Разбор полей таблицы:

* ID: Уникальный идентификатор теста (L-освещение, M-движение, T-телеметрия).

* Зона/Помещение: Физическое расположение для удобной группировки.

* Оборудование: Проектные ID устройств, участвующих в тесте.

* Тестовый сценарий: Четкое описание действия, которое должен выполнить инженер.

* Ожидаемый результат: Недвусмысленное описание того, что должно произойти. Это главный критерий успеха.

* Фактический результат: Статус `Pass` (пройдено) или `Fail` (не пройдено).

* Примечания: Детальное описание проблемы (для `Fail`), номер версии ПО, время срабатывания или любая другая полезная информация.

Итоги:

Краткая сводка по результатам тестирования:

* Всего тест-кейсов: 150

* Прошло (Pass): 145

* Не прошло (Fail): 5

* Общий статус: `Требуются доработки по пунктам M-01, M-02, C-05, C-06, S-11.`

Принципы ведения документа:

Версионирование: Всегда работайте с последней версией плана. Если в ходе ПНР требуется изменить логику, создается новая версия документа (например, `v1.1`), а в примечаниях указывается причина изменения. Это помогает отслеживать эволюцию проекта.
Совместная работа: Используйте облачные инструменты (Google Sheets), если над объектом работает несколько инженеров. Это позволяет видеть прогресс в реальном времени и избегать дублирования работы.

---

Шаг 1. Инвентаризация системы и декомпозиция

Первый практический шаг в создании плана — это инвентаризация и декомпозиция системы. Задача этого этапа — составить полный и структурированный перечень всего, что подлежит тестированию. Без этого шага план будет неполным, и вы рискуете упустить важные элементы.

Процесс инвентаризации заключается в систематическом "чтении" проектной документации и выписывании всех конечных устройств и их функций.

Принцип декомпозиции

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

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

Пример: Этаж 1 -> Гостиная, Кухня, Коридор, Санузел. Этаж 2 -> Спальня 1, Спальня 2, Кабинет.*

Функциональный признак: Разделение системы по подсистемам.

Пример: Освещение, Управление розетками, Климат-контроль (отопление и кондиционирование), Управление шторами/жалюзи, Безопасность (датчики протечки, дыма), Сбор телеметрии (счетчики, датчики).*

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

Сопоставление физического и логического уровней

Самая важная часть инвентаризации — это создание "карты" системы, которая связывает физические устройства с их логическими представлениями в программном обеспечении контроллера (в нашем случае, в Node-RED). Инженер на объекте взаимодействует с физикой (нажимает кнопку, машет рукой перед датчиком), но проверка результата зачастую происходит на логическом уровне (проверка сообщения в MQTT, статуса в логе).

Эта карта создается на основе кабельного журнала, схем и настроек проекта в Node-RED.

Пример таблицы сопоставления для одной зоны ("Гостиная"):

| :---------------------- | :----------- | :---------------------------- | :------------------------------------------------------------ | :---------------------------- |

Создав такую таблицу для всего объекта, вы получаете мощнейший инструмент. Теперь, формулируя тест-кейс, вы можете точно указать не только "нажать на кнопку", но и "проверить, что на входе UI-01 произошло событие" или "убедиться, что в топик `hi/commands/relays/1/set` была отправлена команда". Эта карта фактически является переводом с "языка заказчика" ("хочу, чтобы свет включался") на "язык инженера" ("событие на входе N должно вызывать отправку команды на выход M").

---

Шаг 2. Формулирование тест-кейсов

> ⚠️ Внимание: Избегайте размытых формулировок. Тест-кейс 'Проверить свет' — плохой. Тест-кейс 'Краткое нажатие на физическую клавишу `SW-LR-01-KEY1` должно вызывать отправку в MQTT-топик `hi/commands/relays/1/set` сообщения `ON`, что приводит к включению световой группы `L-LR-MAIN`' — хороший, так как он однозначен, проверяем и содержит критерии успеха.

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

Хороший тест-кейс всегда отвечает на три вопроса:

Что делаем? (Действие)

Что должно произойти? (Ожидаемый результат)

Как мы это проверим? (Метод верификации)

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

Пример 1: Формулирование тест-кейса для сценария 'Кнопка-Свет'

🔗 Связанный материал: Логика этого сценария подробно рассмотрена в уроке `COURSE-03-M07-L02`.

Предположим, у нас есть кнопка в гостиной, которая управляет основной группой света.

Действие: Краткое нажатие на клавишу №1 панели `SW-LR-01`.
Ожидаемый результат:

1. Происходит физическое включение света (визуально виден свет, слышен щелчок реле).

2. В интерфейсе Node-RED узел, управляющий реле `RL-01`, отображает статус `ON`.

3. В MQTT-брокере в топик `hi/devices/RL-01/state` публикуется сообщение о смене состояния.

Метод верификации: Визуальный осмотр, проверка статуса в Node-RED, прослушивание MQTT-топика.

Запись в таблице плана Smoke Test будет выглядеть так:

| :--- | :------- | :------------------ | :--------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- |

| L-01 | Гостиная | `RL-01`, `SW-LR-01` | Краткое нажатие на клавишу 1 панели `SW-LR-01` (свет выключен). | 1. Свет в группе `RL-01` включается.
2. В топик `hi/state/living_room/light_main` приходит сообщение с `payload` `{"value": true}`. |

Пример `msg.payload` для проверки:

{
  "value": true,
  "source": "relay-output-1",
  "ts": 1678886400000,
  "meta": {
    "triggered_by": "SW-LR-01"
  }
}

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

Пример 2: Формулирование тест-кейса для сценария 'Датчик движения-Свет'

🔗 Связанный материал: Этот сценарий мы реализовывали в уроке `COURSE-03-M07-L03`.

Теперь рассмотрим более сложный сценарий с датчиком движения в коридоре.

Действие: Войти в зону действия датчика движения `MS-HW-01`.
Ожидаемый результат:

1. Свет в коридоре (`RL-HW-01`) включается не более чем через 1 секунду после обнаружения движения.

2. Дополнительная проверка: После выхода из зоны действия датчика и отсутствия повторных срабатываний свет автоматически выключается через 3 минуты.

Метод верификации: Визуальный осмотр, использование секундомера.

Запись в таблице будет состоять уже из двух связанных тест-кейсов:

| :--- | :------ | :------------------ | :---------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------- |

| M-06 | Коридор | `RL-HW-01`, `MS-HW-01` | Дождаться выключения света по таймеру после срабатывания `M-05`. | Свет выключается ровно через 3 минуты (180 сек) после последнего зафиксированного движения. Отклонение не более ±5 сек. |

Важность описания метода проверки нельзя недооценивать. Если ожидаемый результат — "данные появились в базе MySQL", то и инструментом проверки будет SQL-клиент. Если "пришло уведомление в Telegram", то проверять нужно соответствующий чат. Чем точнее описан ожидаемый результат и способ его проверки, тем меньше споров и недопонимания возникнет на этапе сдачи объекта.

---

Шаг 3. Приоритизация и последовательность тестов

> 🔗 Связанный материал: Данный подход к последовательности опирается на методику поэтапного запуска оборудования, рассмотренную в уроке `COURSE-02-M04-L02 'Порядок включения и проверки питания'`.

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

Правильная последовательность и приоритизация тестов строятся на нескольких принципах.

Логическая последовательность "от фундамента к функциям"

Тестирование должно идти от низкого уровня к высокому, от простого к сложному. Это позволяет на каждом шаге опираться на уже проверенный и работающий функционал.

Уровень 0: Питание и сеть. Это предварительный чек-лист, который мы уже обсуждали. Проверяется наличие питания 230В/24В и базовое сетевое подключение контроллера.

Уровень 1: Шины данных и интерфейсы. На этом этапе проверяется работоспособность самих каналов связи, без привязки к логике.

RS-485: Проверяется, что контроллер может опросить любое* устройство на шине и получить от него корректный ответ (не `timeout` или `CRC error`).

* DALI: Запускается поиск устройств на шине DALI, проверяется, что все светильники найдены и им присвоены адреса.

* 1-Wire: Проверяется, что контроллер видит все подключенные датчики температуры.

Уровень 2: Прямое управление исполнительными устройствами. Проверяется возможность управлять каждым устройством напрямую, в обход сложной логики. Например, из интерфейса Node-RED (с помощью узла `Inject`) принудительно включить и выключить каждое реле. Это подтверждает, что силовая часть и подключения выполнены верно.

Уровень 3: Простые сценарии. Тестируются базовые связки "вход-выход", такие как "Кнопка-Свет" или "Геркон-Уведомление".

Уровень 4: Сложные сценарии. На последнем этапе проверяются комплексные алгоритмы: климат-контроль (взаимодействие датчиков температуры, отопления и кондиционирования), сценарии по расписанию, логика работы "мастер-кнопки" и т.д.

Приоритизация по критичности

Внутри каждого уровня тесты следует приоритизировать по их важности для конечного пользователя и безопасности.

Высокий приоритет: Системы, отвечающие за безопасность и жизнеобеспечение.

* Срабатывание датчиков протечки и автоматическое перекрытие воды.

* Срабатывание датчиков дыма.

* Управление основными группами света.

* Работа ключевых настенных выключателей.

Средний приоритет: Системы, отвечающие за основной комфорт.

* Управление климатом.

* Управление шторами.

* Сценарии "Я ушел" / "Я пришел".

Низкий приоритет: Дополнительные и сервисные функции.

* Управление декоративной подсветкой.

* Сбор некритичной телеметрии (например, потребление энергии второстепенными приборами).

* Голосовое управление.

Группировка по физическому расположению

Для оптимизации работы на объекте сгруппируйте тесты в плане по помещениям. Это позволит инженеру, придя в одну комнату (например, в гостиную), последовательно выполнить все тесты, относящиеся к ней (свет, шторы, климат, розетки), и только после этого переходить в следующую. Такой подход минимизирует "беготню" по объекту и значительно экономит время.

Итоговая последовательность в плане тестирования будет выглядеть как комбинация всех трех принципов: сначала выполняются все тесты Уровня 1; затем тесты Уровня 2, сгруппированные по комнатам; затем тесты Уровня 3, сгруппированные по комнатам и отсортированные по критичности, и так далее.

---

Резюме и следующие шаги

В этом уроке мы детально разобрали процесс создания одного из важнейших документов для инженера-инсталлятора — плана Smoke Test.

Мы выяснили, что план Smoke Test — это не формальность для отчетности, а мощный рабочий инструмент, который систематизирует процесс пусконаладки, экономит время и служит гарантией качества выполненных работ.

Процесс его разработки состоит из трех ключевых шагов:

Инвентаризация и декомпозиция: Создание полного перечня тестируемых систем и их сопоставление с логическими адресами в проекте.

Формулирование тест-кейсов: Преобразование функциональных требований в конкретные, проверяемые и однозначные тестовые сценарии с четко описанными ожидаемыми результатами.

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

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

В следующем уроке мы перейдем от теории к практике: научимся выполнять дымовое тестирование непосредственно на объекте, используя наш разработанный план, а также правильно фиксировать результаты и оформлять отчет о найденных проблемах.