Разработка Тест-плана сдачи объекта (пример на 30+ пунктов)

Введение в Тест-планы: Цели и Структура

ведение в Тест-планы: Цели и Структура

Завершающий этап любого проекта по автоматизации — это демонстрация его полной работоспособности заказчику и последующая сдача объекта. Интуитивная проверка «вроде всё работает» является признаком непрофессионального подхода и несет значительные риски как для исполнителя, так и для клиента. Чтобы формализовать и систематизировать этот процесс, используется Тест-план — ключевой документ, регламентирующий процедуру проверки системы перед вводом в эксплуатацию.

> ℹ️ Информация: Тест-план является неотъемлемой частью исполнительной документации, передаваемой заказчику. Он служит доказательством работоспособности системы и защищает инсталлятора от необоснованных претензий.

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

Ключевыми компонентами качественного тест-плана являются:

Область тестирования (Scope): Четкое определение того, какие подсистемы, функции и сценарии подлежат проверке. Например: «Тестирование подсистемы освещения во всех помещениях, включая диммирование и сценарное управление», «Проверка сценария безопасности ‘Протечка воды’». Область также определяет, что не тестируется (например, «Производительность стороннего медиасервера не входит в область тестирования»).

Ответственные: Указание лиц, ответственных за проведение тестов (инженер-инсталлятор, представитель заказчика) и за исправление выявленных дефектов.

Критерии успеха/провала (Acceptance Criteria): Однозначное описание того, при каких условиях тест считается пройденным (Pass), а при каких — проваленным (Fail).

Пример критерия успеха:* «При нажатии на кнопку ‘Я ушел’ в течение 5 секунд выключаются все группы света, кроме дежурной подсветки в коридоре, а на телефон владельца приходит push-уведомление».

Пример критерия провала:* «Группа света в гостиной не отреагировала на команду выключения» или «Уведомление не было доставлено».

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

Шаблон Тест-плана: Универсальный чек-лист на 30+ пунктов

Чтобы тест-план выполнял свою функцию юридического и технического щита инсталлятора, он должен охватывать все аспекты проекта. Ниже представлен готовый к внедрению шаблон из более чем 30 обязательных проверок, которые необходимо подтвердить со статусом Pass / Fail при передаче объекта.

Группа 1: Базовое оборудование, сеть и отказоустойчивость

Проверка наличия стабильного интернет-соединения и локальной сети в зоне серверной (пинг шлюзов).

Имитация перезагрузки сетевого роутера — автоматическое восстановление связи всеми контроллерами без ручного вмешательства (тайм-аут до 3-5 минут).

Проверка срабатывания ИБП: отключение вводного автомата 220В — контроллер продолжает работу, фиксируется время автономности работы ядра.

Отправка Push/Telegram-уведомления заказчику о факте пропадания сетевого питания 220В.

Восстановление питания 220В — проверка корректной загрузки всех служб (система не зависает в цикле).

Проверка уровней сигнала (RSSI) для всех беспроводных устройств (Zigbee/Z-Wave/Wi-Fi) — отсутствие зон с критически низким покрытием.

Антифлаппинг датчиков: Проверка работы фильтра дребезга на дискретных входах (герконы, кнопки). При многократном быстром замыкании/размыкании система не должна генерировать «шторм» уведомлений или команд (задержка фильтрации согласно M04).

Группа 2: Подсистема Освещения и Штор

Включение и выключение каждой группы света с привязанного настенного выключателя (задержка реакции < 300 мс).

Синхронизация статусов: при нажатии на физический выключатель состояние освещения мгновенно обновляется в мобильном приложении.

Проверка диммирования: плавное изменение яркости (от 5% до 100%) с настенных панелей и из приложения (без мерцания ламп).

Тест поведения реле после обрыва питания (Power-On State) — возврат групп освещения в нужное состояние (выключено или предыдущее).

Работа датчиков движения в проходных зонах: свет включается при входе человека.

Работа датчиков движения в связке с таймером: свет корректно выключается при отсутствии движения заданное время (например, 2 минуты).

Проверка управления шторами/жалюзи: плавное открытие/закрытие, остановка в промежуточном положении.

Корректная калибровка концевиков штор (полное закрытие не вызывает перегрева мотора, отображается статус 0% и 100%).

Группа 3: Климат (Отопление, Вентиляция, Кондиционирование)

Считывание и проверка показаний комнатных датчиков температуры во всех зонах измерения (отклонение не более ±1°C от эталонного термометра).

Проверка гистерезиса отопления: Установка целевой температуры и подтверждение того, что сервопривод не включается/выключается при колебаниях ±0.1-0.2°C вокруг уставки (проверка программного или аппаратного гистерезиса согласно M06).

Проверка реакции термостата: изменение целевой уставки влечет за собой открытие/закрытие сервоприводов радиаторов или теплого пола.

Управление теплым полом (включение/выключение) через приложение и локальный терморегулятор.

Взаимодействие кондиционера и окна: сработка сценария автоматического отключения кондиционера, если окно открыто дольше 3 минут (при наличии герконов).

Доставка команд включения/переключения режимов (Cool/Heat/Fan) на внутренние блоки кондиционеров (по шине или IR-каналу).

Механизм вытяжки в санузлах: автоматическое включение вентилятора при превышении порога влажности (например, > 70%).

Группа 4: Безопасность и Инженерные тревоги

Протечка воды: замыкание контактов датчика протечки влажной губкой — мгновенное перекрытие вводных клапанов водоснабжения (КРАБы) во всех стояках.

Уведомления о протечке: отправка сирены, Push-сообщения и SMS (при наличии GSM-модуля) при сработке сценария воды.

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

Тест отвала датчика безопасности (Heartbeat/Offline): контроллер выдает ошибку потери связи с датчиком протечки или проникновения.

Проверка датчиков открытия окна/двери: актуальность статусов в приложении умного дома при смене положения створок.

Интеграция видеонаблюдения: проверка вывода RTSP/Onvif потоков с камер в интерфейс мобильного приложения умного дома.

Группа 5: Глобальные сценарии и UX-поведение (Override)

Мастер-сценарий «Я ушел»: выключены все группы освещения, отключены неуправляемые розетки, перекрыта вода, климат переведен в энергосберегающий режим, система поставлена на охрану.

Мастер-сценарий «Я пришел»: снятие с охраны, включение приветственного освещения, возврат климата в комфортный режим работы.

Ночной режим (сценарий «Сон»): при активации мастер-кнопкой в спальне гасится основной свет во всем доме, активируется дежурная подсветка (15-20% яркости) по датчикам движения в санузлах и коридорах.

Тестирование ручного перехвата (Override): если сценарий автоматизации выключил свет в комнате, ручное включение выключателя блокирует последующие команды сценариев (например, отключает таймер дежурного датчика) до следующего логического цикла.

Проверка таймеров/расписаний: корректная сработка имитации присутствия или открытия штор точно в заданное время с учетом часового пояса.

Пользовательский интерфейс: мобильное приложение (iOS/Android) отображается корректно на устройстве Заказчика, виджеты интуитивно понятны, отсутствуют не переведенные элементы, выданы и проверены права гостевого доступа (если предусмотрено ТЗ).

Роль тест-плана становится критически важной в процессе Приемо-сдаточных испытаний (ПСИ). Этот документ используется как пошаговая инструкция для совместной проверки системы инженером и заказчиком. По результатам прохождения всех пунктов чек-листа подписывается акт выполненных работ, который юридически подтверждает, что подрядчик выполнил свои обязательства в полном объеме и система соответствует заявленным требованиям. Наличие такого документа защищает инженера от будущих претензий в духе «а я думал, оно будет работать по-другому» и служит объективным доказательством качества проделанной работы. Создание такого документа строится поэтапно: от проверки базовых узлов до тестирования сложных связей и стрессовых нагрузок. Начнем с самого фундаментального уровня — тестирования отдельных подсистем.

Разработка чек-листа: Тестирование по подсистемам

азработка чек-листа: Тестирование по подсистемам

Основа любого комплексного тест-плана — это принцип декомпозиции. Вся сложная система автоматизации разбивается на более простые и понятные функциональные подсистемы, каждая из которых тестируется изолированно. Это позволяет локализовать проблемы на самом низком, аппаратном или базовом программном уровне, прежде чем переходить к проверке сложных сценариев.

> 💡 Подсказка: Для низкоуровневой проверки используйте узел `mqtt in` в Node-RED, подписанный на топики управления (`#`), или подключите узел `Debug` к выходам потоков, управляющих оборудованием. Это позволяет видеть реальные `msg.payload`, отправляемые на устройства, и сверять их с ожидаемыми командами. Например, для проверки KNX-диммера вы должны увидеть сообщение, похожее на:

{
    "on": true,
    "brightness": 75
}

Ниже приведен расширенный чек-лист из более чем 30 обязательных пунктов для сдачи объекта, сгруппированный по основным подсистемам, реализованным на платформе контроллера HI.

Тестирование подсистемы освещения

Эта секция должна покрывать каждую световую группу, управляемую контроллером.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| LT-01 | Включение/выключение (основная группа) | 1. C панели управления нажать кнопку "Вкл".
2. Нажать физический настенный выключатель.
3. Повторить для выключения. | Реле `RL-01` на контроллере щелкает, свет включается. Задержка реакции не более 0.5с. Синхронизация статуса в UI. |

| LT-02 | Диммирование (DALI) | 1. Через слайдер в UI установить 100%.
2. Установить яркость 10%.
3. Отправить MQTT команду `level=25`. | Подсветка плавно меняет яркость без мерцания до заданных значений. |

| LT-03 | Верификация адресации DALI | 1. В Node-RED инициировать команду сканирования.
2. Сверить полученные Short Addresses с проектом. | Контроллер HI успешно опрашивает шину DALI. Список адресов (`sa 0`, `sa 1`) совпадает с проектом. |

| LT-04 | Управление цветом RGB/RGBW | 1. В UI выбрать красный, затем синий цвет.
2. Установить белый (канал W). | Лента корректно меняет цвет, DMX/PWM каналы отрабатывают без искажений. |

| LT-05 | Проверка Fade Time (плавность) | 1. Отправить команду включения с параметром fade=5s. | Световая группа плавно разгорается ровно за 5 секунд. |

| LT-06 | Датчик движения (базовая логика) | 1. Пройти в зоне видимости датчика.
2. Покинуть зону и подождать таймаут (напр., 1 мин). | Свет включается при обнаружении движения и выключается ровно через заданный таймаут. |

| LT-07 | Проходные выключатели | 1. Включить свет с выключателя А.
2. Выключить с выключателя Б. | Группа корректно переключает состояние; статус в Node-RED обновляется при каждом нажатии. |

| LT-08 | Фоллбэк (потеря связи с сервером) | 1. Отключить физически контроллер.
2. Нажать кнопку на KNX-выключателе. | Выключатель управляет светом напрямую через ассоциированные групповые адреса (если предусмотрено топологией). |

Тестирование подсистемы климат-контроля

Проверка управления отоплением, вентиляцией и кондиционированием (HVAC).

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| CL-01 | Управление радиатором (термостат) | 1. Установить уставку на 2°C выше текущей.
2. Установить на 2°C ниже текущей. | Контроллер открывает/закрывает клапан сервопривода. Статус ШИМ (PWM) или реле виден в Node-RED. |

| CL-02 | Управление фанкойлом (Modbus) | 1. Выбрать "Охлаждение" и скорость "Средняя".
2. Проверить регистр скрости на устройстве. | Фанкойл охлаждает, вентилятор на средней скорости. Регистр содержит ожидаемое значение (например, `2`). |

| CL-03 | Чтение телеметрии температур | 1. Сравнить показания 1-Wire датчика с эталонным термометром. | Отклонение не более ±0.5°C. Данные в топиках `telemetry/...` обновляются по настроенному интервалу. |

| CL-04 | Электрический теплый пол | 1. Включить нагрев теплого пола.
2. Имитировать нагрев датчика пола (опустить его в тепло). | Реле замыкается, пол греется. При достижении нужной температуры реле отключается. |

| CL-05 | Защита от перегрева (пол) | 1. Задать уставку ограничения температуры стяжки 30°C. | Пол отключается независимо от температуры воздуха в комнате при достижении стяжкой 30°C. |

| CL-06 | Управление вентиляцией (0-10V) | 1. Установить скорость вентиляции на 50% через UI. | На модуле AI/AO напряжение составляет ~5V, приток воздуха работает на 50% мощности. |

| CL-07 | Реакция на уровень CO2 | 1. Подышать на датчик CO2 (повысить свыше 1000 ppm). | Автоматически активируется повышенная скорость вентиляции; приходит уведомление. |

| CL-08 | Управление увлажнителем | 1. Установить целевую влажность 45%. При текущей < 45% проверить статус. | Реле/розетка увлажнителя включается. После достижения влажности в 45% + гистерезис — отключается. |

| CL-09 | Переключение Сезонности (Зима/Лето) | 1. В UI переключить режим системы на "Лето". | Теплые полы отключаются, доступен только режим кондиционирования, уставки сдвигаются на летний профиль. |

Тестирование приводов (шторы, ворота, клапаны)

Проверка всех моторизированных элементов.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| DR-01 | Открытие/закрытие штор | 1. Нажать "Открыть", дождаться конца.
2. Нажать "Закрыть". | Шторы доходят до крайних положений и отключаются по концевикам; контроллер снимает питание с реле после истечения таймаута движения. |

| DR-02 | Частичное открытие | 1. Установить шторы в положение 50% (или нажать "Стоп" на середине). | Привод останавливает движение точно по центру окна. |

| DR-03 | Угловое управление ламелями жалюзи | 1. Изменить угол наклона ламелей (tilt) на 45 градусов. | Ламели поворачиваются на заданный угол без движения самого полотна вверх/вниз. |

| DR-04 | Перекрытие вводных кранов воды | 1. Нажать кнопку "Перекрыть ГВС/ХВС". | Реле активируется на нужное время. Краны физически закрываются. В UI статус "Вода перекрыта". |

| DR-05 | Гаражные ворота (импульс) | 1. Отправить команду "Открыть ворота". | Реле замыкается на короткий импульс (0.5 - 1с) и размыкается (сухой контакт). Ворота начинают движение. |

Тестирование систем безопасности и датчиков

Критический блок работы с событиями, требующими немедленной реакции платформы.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| SEC-01 | Датчик протечки воды | 1. Намочить контакты датчика протечки под раковиной. | Мгновенно отрабатывает сценарий: перекрытие кранов воды (DR-04), пуш-уведомление в Telegram/App, сирена. |

| SEC-02 | Снятие аварии протечки | 1. Насухо вытереть датчик протечки.
2. Сбросить тревогу в UI. | До ручного сброса КХВ/КГВС остаются закрытыми. После сброса возвращается возможность управления кранами. |

| SEC-03 | Датчик дыма (интеграция) | 1. Нажать тестовую кнопку на пожарном извещателе. | В платформу приходит сигнал пожарной тревоги. Вентиляция выключается (CL-06), свет во всем доме включается на 100% (LT-01). |

| SEC-04 | Герконы на окнах | 1. Открыть окно в спальне. | Статус в Node-RED меняется на `opened`. Если в комнате работает кондиционер, он переводится в режим ожидания (экономия э/э). |

| SEC-05 | Работа датчика освещенности | 1. Закрыть датчик освещенности непрозрачным чехлом. | Показания люксметра падают до 0-10 lx. Если включен сценарий "Вечер", автоматически зашториваются окна. |

Тестирование ядра системы, сети и UI

Проверка "живучести", стабильности инфраструктуры и пользовательского интерфейса.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| SYS-01 | Синхронизация статусов UI (Обратная связь) | 1. Включить свет с физической кнопки. Открыть Dashboard / Apple Home. | Статус выключателя в приложении мгновенно (до 1 сек) меняется на "Включено". |

| SYS-02 | Доступность платформы без интернета | 1. Выдернуть WAN кабель из роутера.
2. Управлять домом через локальный Wi-Fi с телефона. | Все подсистемы работают корректно. Локальный Node-RED Dashboard и MQTT сервер перехватывают команды без задержек. |

| SYS-03 | Резервное питание (ИБП) | 1. Отключить рубильник общего питания. | Дом переходит на ИБП. Контроллер HI не перезагружается. В логах фиксируется событие "Питание от батареи". Дополнительно проверяется отключение мощных нагрузок. |

| SYS-04 | Корректный старт после блэкаута | 1. Отключить всё питание дома, включая низковольтное. Включить обратно. | Контроллер HI загружается (проверяем uptime). Шлюзы и шины инициируются, оборудование не зависает в цикле перезагрузки. |

| SYS-05 | Журналирование и логи (Node-RED) | 1. Отвесить ошибку в скриптах/API намерено (например, неверный URL). | Ошибка записывается в системные логи Linux или Debug-панель Node-RED с корректным timestamp. |

| SYS-06 | Обработка потери связи устройств шины RS-485 | 1. Отключить кабель Modbus от одного модуля реле. | Панель управления помечает устройства этого модуля как "Offline" (покраснение кнопки/статус-бара). Важно исключить фантомные срабатывания. |

| SYS-07 | Тестирование QoS в MQTT | 1. Отправить команду управления с качеством обслуживания QoS 1 на топик света. | Гарантированная доставка команды даже при кратковременном сетевом шторме, подтверждение `PUBACK` получено. |

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

Разработка чек-листа: Тестирование сценарное и интеграционное

азработка чек-листа: Тестирование сценарное и интеграционное

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

> 💡 Связанный материал: Логика построения комплексных сценариев с использованием состояний и конечных автоматов (State Machine), а также иерархия триггеров для управления приоритетами, подробно рассматривается в модуле COURSE-07-M04. Данный урок фокусируется на методологии их тестирования.

Сценарное тестирование моделирует реальные жизненные ситуации и проверяет, как система на них реагирует.

Пример 1: Сценарий «Я ушел»

Этот сценарий переводит дом в режим энергосбережения и охраны.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| SCN-01 | Активация режима "Я ушел" | 1. Нажать физическую кнопку "Ушел" у входной двери.
2. Убедиться, что в `flow.context` переменная "presence_mode" установлена в "away". | 1. Свет: Все группы света гаснут.
2. Розетки: Некритичные группы розеток (например, медиа, утюг) отключаются.
3. Климат: Уставки температуры на всех термостатах переводятся в эконом-режим (+18°C).
4. Безопасность: Через 60 секунд (время на выход) система встает на охрану (активируются датчики движения и открытия).
5. Уведомление: На телефон владельца приходит push-уведомление "Активирован режим 'Отсутствие'". |

| SCN-02 | Возвращение домой | 1. Снять систему с охраны через мобильное приложение (геофенсинг) или вводом кода на панели. | 1. Система снимается с охраны.
2. Свет: Включается свет в прихожей.
3. Климат: Уставки температуры возвращаются в комфортный режим.
4. Безопасность: Датчики движения перестают отправлять тревожные уведомления. |

Пример 2: Сценарий «Кино»

Этот сценарий создает комфортную атмосферу для просмотра фильмов.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| SCN-03 | Активация режима "Кино" | 1. Нажать кнопку "Кино" на планшете управления или дать голосовую команду. | 1. Шторы: Шторы в гостиной полностью закрываются.
2. Свет: Основной свет плавно гаснет (диммирование до 0% за 5 секунд).
3. Подсветка: Декоративная подсветка за телевизором включается на 15% яркости, цвет - теплый белый.
4. Медиа: Контроллер отправляет команду по IP на включение AV-ресивера. |

Пример 3: Сценарий «Протечка воды»

Это пример критически важного сценария безопасности. Его тестирование должно быть особенно тщательным. Требования безопасности выступают высшим приоритетом (override-режимом) над любой пользовательской логикой.

| ID теста | Название | Шаги для проверки | Ожидаемый результат |

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

| SCN-04 | Симуляция протечки в санузле | 1. Замкнуть контакты датчика протечки `WS-01` (например, влажной салфеткой). | 1. Реакция (в течение 2 секунд): Контроллер HI немедленно активирует реле, управляющие электроприводами на вводных кранах ХВС и ГВС. Краны закрываются.
2. Оповещение (в течение 10 секунд): На все зарегистрированные устройства владельцев отправляется push-уведомление "ТРЕВОГА! Зафиксирована протечка воды в санузле!".
3. Индикация: На панели управления и, возможно, локально (сирена) включается сигнал тревоги.
4. Логирование: В системный журнал (MySQL `audit_log`) записывается событие с точным временем и источником тревоги (`WS-01`). |

Шаблон Тест-плана: Расширенный интеграционный чек-лист (30+ пунктов)

Ниже представлен детализированный шаблон интеграционного чек-листа для сдачи объекта заказчику (User Acceptance Testing - UAT). Шаблон охватывает проверку макро-сценариев, межсистемных зависимостей, пользовательского override-поведения и аппаратных лимитов.

Раздел 1: Мастер-сценарии и режимы присутствия

• [ ] 1. "Я ушел": Активация режима гасит 100% групп рабочего и декоративного освещения без задержек.
• [ ] 2. "Я ушел": Отключаются контакторы некритичных/потенциально опасных розеток (утюг, обогреватель, ТВ).
• [ ] 3. "Я ушел": Уставки всех климатических зон переводятся в режим энергосбережения (+18°C).
• [ ] 4. "Я ушел": Автоматически закрываются все шторы/жалюзи на 1-м этаже.
• [ ] 5. "Я ушел": Через 60 секунд (задержка на выход) активируется охрана периметра и датчики движения.
• [ ] 6. "Я пришел": Система корректно снимается с охраны (по PIN-коду, ключу или геозоне смартфона).
• [ ] 7. "Я пришел": Восстанавливается питание розеточных групп.
• [ ] 8. "Я пришел": Климат возвращается в комфортный режим (+22°C), если сейчас активный период дня.
• [ ] 9. "Ночь": Плавно выключается весь основной свет, не затрагивая дежурную ночную подсветку.
• [ ] 10. "Ночь": Активируется DND-режим (блокируются звуковые push-уведомления и ответы голосовых колонок).
• [ ] 11. "Уборка" (Override): При активации везде включается 100% свет, игнорируя таймеры авто-отключения от датчиков движения.

Раздел 2: Безопасность и управление критическими приоритетами

• [ ] 12. Протечка: Замыкание контактов любого датчика мгновенно (≤ 2 сек) перекрывает краны на стояках.
• [ ] 13. Протечка (Override): Уведомление доставляется на смартфон с критическим приоритетом (обходится беззвучный режим iOS/Android).
• [ ] 14. Протечка (Связь): После высыхания контактов краны не открываются автоматически — требуется явная ручная команда сброса ошибки.
• [ ] 15. Пожарная тревога: Сработка датчика дыма принудительно отключает приточную вентиляцию (предотвращение распространения дыма).
• [ ] 16. Пожарная тревога: Система открывает электронные замки входной двери/ворот для беспрепятственной эвакуации.
• [ ] 17. Охранная тревога: Обнаружение движения в режиме "Вне дома" активирует сирену и пугающий алгоритм (мигание всем светом).
• [ ] 18. Охранная тревога (Медиа): Фиксация вторжения параллельно создает снапшоты с камер и отправляет их в Telegram/email.

Раздел 3: Интеграция Климата, Вентиляции и Окон

• [ ] 19. Открытое окно: Открытие створки (датчик геркона) приостанавливает работу кондиционера и радиатора в данной комнате через 30-60 сек.
• [ ] 20. Закрытое окно: После закрытия окна оборудование возвращается к предыдущему расписанию и уставкам.
• [ ] 21. Защита от конфликтов: При работе кондиционера на охлаждение система аппаратно запрещает активацию теплого пола, радиатора или подачу теплоносителя.
• [ ] 22. Гистерезис и ПИД-регуляция: Теплый пол выключается строго при превышении уставки на +0.5°C и возобновляет обогрев при падении на -0.5°C.
• [ ] 23. Вентиляция: Повышение концентрации CO2 свыше уставки (например, >1000 ppm) плавно увеличивает скорость приточной установки.
• [ ] 24. Сезонный режим: Перевод системы

Негативное и стресс-тестирование

егативное и стресс-тестирование

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

> ⚠️ Внимание: Стресс-тестирование может привести к временной неработоспособности системы. Проводите его в согласованное с заказчиком время, в идеале — в нерабочие часы. Всегда имейте план по быстрой перезагрузке контроллера HI и сетевого оборудования.

Негативное тестирование

Цель негативного тестирования — проверить реакцию системы на сбои оборудования, потерю связи и некорректные команды. Система не должна «падать» или входить в непредсказуемое состояние.

Примеры тест-кейсов:

• NT-01: Обрыв связи с Modbus-устройством.

1. Шаги: Физически отключить кабель шины RS-485 от модуля фанкойла.

2. Ожидаемый результат: В интерфейсе Node-RED узел `modbus-read` отображает статус "ошибка" или "таймаут". На панели управления виджет, отображающий состояние фанкойла, меняет статус на "Недоступен" или "Ошибка связи". Конечный автомат (State Machine) управления климатом переходит в безопасное состояние (например, `Error`). Система не зависает, остальные потоки продолжают работать. После восстановления кабеля связь восстанавливается автоматически в течение 1 минуты.

• NT-02: Отправка некорректной команды.

1. Шаги: С помощью утилиты `mosquitto_pub` отправить в MQTT-топик `hi/office/light1/set` сообщение `{"command": "DIM", "level": 50}` для недиммируемой группы света, которая управляется простым реле.

2. Ожидаемый результат: Поток в Node-RED, обрабатывающий этот топик, должен отфильтровать или отбросить некорректную команду. Узел `Catch` на этой вкладке должен зафиксировать ошибку (например, "Invalid command for this device"). Реле не должно срабатывать. Система не должна генерировать критических ошибок.

• NT-03: Пропадание питания на оконечном устройстве.

1. Шаги: Отключить питание 24V от датчика движения.

2. Ожидаемый результат: Если датчик имеет функцию контроля (heartbeat), система через заданный промежуток времени должна зафиксировать его пропажу и уведомить администратора. Сценарии, зависящие от этого датчика, должны перейти в безопасный режим (например, свет в этой зоне переключается в ручное управление).

Стресс-тестирование

Цель стресс-тестирования — проверить производительность и стабильность контроллера HI и всей системы под высокой нагрузкой. Это помогает выявить утечки памяти, "гонки состояний" и узкие места в сети.

Примеры тест-кейсов:

• ST-01: "Флуд" MQTT-сообщениями.

1. Шаги: Написать простой скрипт на Bash, который отправляет 10 сообщений в секунду в течение 5 минут в один из топиков, обрабатываемых Node-RED.

        #!/bin.bash

        for i in {1..3000}; do
          mosquitto_pub -h localhost -t 'test/stress' -m "Message $i"
          sleep 0.1
        done
        

2. Ожидаемый результат: Подключиться к контроллеру по SSH и запустить утилиту `htop`. Загрузка CPU может кратковременно подниматься, но не должна постоянно держаться на уровне 100%. Потребление памяти процессом Node-RED не должно монотонно расти (признак утечки памяти). Панель управления (Dashboard) должна оставаться отзывчивой.

• ST-02: Одновременная активация множества сценариев.

1. Шаги: Попросить 2-3 человек одновременно с разных устройств (планшеты, телефоны) активировать разные сценарии: один включает «Кино», другой — «Я ушел», третий — меняет режимы климата.

2. Ожидаемый результат: Система должна корректно обработать все команды с учетом иерархии триггеров и приоритетов. Например, если сценарий "Протечка" имеет наивысший приоритет, он должен выполниться, даже если в тот же момент был запущен сценарий "Кино". Не должно возникать конфликтов, когда одно реле пытается одновременно включиться и выключиться.

Шаблон Тест-плана сдачи объекта (35 пунктов)

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

Инфраструктура и базовые проверки

Проверка стабильности питания контроллера HI и сетевого оборудования (роутер, коммутаторы).

Пинг и доступность всех IP-устройств в сети «Умного дома».

Проверка качества связи и уровня сигнала беспроводных устройств (Zigbee/Wi-Fi).

Опрос всех Modbus-устройств (отсутствие ошибок CRC и таймаутов).

Проверка автозапуска сервисов (Node-RED, MQTT) после перезагрузки контроллера по питанию.

Освещение

Включение/выключение всех групп релейного света с физических выключателей замыканием контактов.

Плавная регулировка (диммирование) поддерживаемых групп света без видимого мерцания.

Корректность работы RGB/RGBW-лент (выбор цвета, изменение температуры белого).

Синхронизация статусов света в интерфейсе при управлении с физических кнопок (отсутствие задержек более 1 секунды).

Отсутствие ложных срабатываний света ("призрачные нажатия") из-за наводок на кабельных линиях.

Климат

Корректность показаний всех датчиков температуры, влажности и качества воздуха в интерфейсе.

Открытие/закрытие сервоприводов радиаторов отопления по команде с контроллера.

Переключение скоростей и режимов работы фанкойлов/кондиционеров (через шлюзы или ИК).

Управление электрическими теплыми полами (работа реле и получение обратной связи от датчиков пола).

Переход зоны климата в безопасный/ждущий режим при срабатывании оконного геркона (блокировка охлаждения).

Шторы, автоматика и безопасность

Открытие/закрытие штор и жалюзи до концевых выключателей позиционирования (корректный процент открытия).

Срабатывание датчиков движения/присутствия и корректная индикация события в системе.

Срабатывание датчиков физической протечки (замыкание контактов водой).

Проверка работы датчиков дыма и локальной пожарной сигнализации (если интегрирована).

Корректная отработка сирены и пуш-уведомлений в Telegram/приложение при имитации тревоги.

Ручное управление (Override) и приоритеты

Блокировка автоматического таймера выключения света при явном ручном включении (Override датчика движения).

Автоматический сброс режима Override по истечении длительного таймера бездействия (например, через 4 часа).

Перехват управления климатом с настенного термостата (смена состояний в State Machine Node-RED).

Абсолютный приоритет аппаратных мастер-выключателей над программными расписаниями.

Блокировка локальных автоматизаций при активном глобальном режиме "Никого нет дома".

Сценарии и режимы

Отработка сценария "Я ушел": выключение всего света, медиа, перевод климата в Эко-режим.

Отработка сценария "Кинотеатр": закрытие блэкаут-штор, приглушение света, включение AV-оборудования и проектора.

Отработка сценария "Удобное утро": плавное (fade-in) включение света, открытие портьер на 50%, запуск подогрева пола.

Защитный сценарий "Протечка": автоматическое перекрытие вводных клапанов воды, рассылка уведомлений, отключение опасных розеток на полу (высший системный приоритет).

Сценарий "Вечеринка": блокировка отключения света по датчикам движения в гостиной и прихожей.

Негативные и стресс-тесты

Физическое отключение шины RS-485 или Zigbee-координатора: фиксация ошибки и переход статусов в состояние "Недоступно".

Имитация пропадания интернета: проверка работоспособности локального управления со смартфонов (внутри Wi-Fi сети).

Отключение контроллера HI от сети: локальное управление с физических выключателей со встроенной логикой продолжает работать.

Flood-тест MQTT (спам командами): стабильная работа Node-RED без залипания и 100% загрузки CPU.

Восстановление исходных (или безопасно-выключенных) состояний после имитации полного black-out (кратковременное отключение вводных автоматов 220В на всем объекте).

Пройдя все этапы — от базовых подсистем до стрессовых нагрузок — мы собираем исчерпывающую картину состояния объекта. Теперь все эти разрозненные проверки необходимо свести в единый, удобный для работы и отчетности финальный документ.

Шаблон Тест-плана и подведение итогов

аблон Тест-плана и подведение итогов

Собрав все вышеописанные тест-кейсы, мы можем сформировать единый итоговый документ. Для удобства его лучше всего вести в электронных таблицах (Google Sheets, Excel), где легко фильтровать, сортировать и отмечать статусы. Этот документ служит финальным чек-листом во время приемо-сдаточных испытаний.

Структура и шаблон документа

Ниже приведен пример того, как могут выглядеть записи в таблице. Обратите внимание, что каждый тест имеет уникальный идентификатор (ID), что сильно упрощает дальнейшее ведение баг-репортов.

| ID | Название теста | Подсистема | Шаги для проверки | Ожидаемый результат | Факт. результат | Статус | Комментарий |

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

| LT-01 | Вкл/выкл света в гостиной (основная группа) | Освещение | 1. Нажать кнопку "Вкл" на UI.
2. Нажать физический выключатель. | Свет включается и выключается без задержки. | Заполняется | Pass / Fail | |

| CL-02 | Управление фанкойлом (Modbus) | Климат | 1. Выбрать режим "Охлаждение".
2. Установить скорость "Средняя". | Фанкойл запускается в нужном режиме. Значение регистра `40102` равно `2`. | Заполняется | Pass / Fail | |

| SCN-04 | Сценарий "Протечка воды" | Безопасность | Замкнуть контакты датчика `WS-01`. | Краны перекрываются < 2с. Push-уведомление приходит < 10с. | Заполняется | Pass / Fail | |

| NT-01 | Обрыв связи с Modbus-устройством | Отказоуст-ть | Отключить кабель RS-485 от фанкойла. | На UI статус "Ошибка связи". Остальная система работает. Связь восстанавливается после подключения кабеля. | Заполняется | Pass / Fail | Тест провален. Связь не восстановилась. |

Полный чек-лист тестирования объекта (36 пунктов)

Для проведения полноценной сдачи объекта мы подготовили подробный список из более чем 30 базовых проверок, который вы можете использовать для формирования строк вашего Тест-плана.

Подсистема: Освещение (Lighting)

Включение и выключение каждой отдельной световой группы с настенного выключателя (задержка не более 100-200 мс).

Включение и выключение каждой группы света через пользовательский интерфейс (UI) приложения.

Физическое диммирование света (удержание кнопки выключателя — плавное изменение яркости от 0% до 100% и обратно).

Диммирование света через UI (перемещение ползунка слайдера без «дребезга» и скачков).

Тестирование датчиков движения/присутствия: автоматическое включение света при входе в зону мониторинга.

Отработка таймаута присутствия: корректное отключение света (или переход в дежурный режим 10%) после выхода человека из зоны.

Управление RGB/RGBW-лентами: изменение цвета (Color Picker) и цветовой температуры (CCT - от теплого к холодному) в интерфейсе.

Проверка отсутствия мерцания (фликера) при выставлении яркости диммируемых светодиодных ламп на 1–5%.

Подсистема: Климат (Climate)

Включение каждого контура теплого пола, проверка срабатывания соответствующего реле и фактического нагрева поверхности.

Работа термостата: автоматическое отключение теплого пола или радиатора по достижении целевой температуры (уставки).

Отработка сервоприводов радиаторов на гребенке (полное открытие при запросе тепла, полное закрытие при остановке).

Включение кондиционера/фанкойла на базовое охлаждение через шлюз (Modbus / KNX / инфракрасный бластер).

Смена скорости вращения вентилятора фанкойла (Low, Mid, High, Auto) и проверка реакции железа.

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

Автоматическая логика «нагрев/охлаждение»: смена уставки (Set Point) через UI и проверка того, что система верно запрашивает тепло или холод в зависимости от дельты температур.

Подсистема: Моторизация и шторы (Blinds/Motors)

Полное открытие и закрытие всех приводов штор, жалюзи или рольставней с выделенных кнопок.

Функция "Стоп": остановка движения шторы в промежуточном положении как с выключателя, так и из приложения.

Позиционирование в процентах (через UI/override): отправка команды открыть штору ровно на 50% и проверка точности исполнения.

Подсистема: Безопасность и контроль доступа (Security)

Имитация протечки (замыкание контактов датчика влажной салфеткой): немедленное перекрытие электроприводов крана (ХВС и ГВС).

Корректность оповещения о протечке: Push-уведомление в приложение, сообщение в Telegram/СМС, звуковой сигнал сирены.

Управление замком/домофоном: открытие калитки или электромеханического замка входной двери из приложения.

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

Контроль периметра: сработка герконов на дверях и открывающихся окнах (корректное изменение статусов в UI).

Блокировка климата при проветривании (опционально): отключение кондиционера при открытом более 2 минут окне.

Сценарии и комплексная автоматизация (Scenarios)

Тест сценария «Я ушел» (Мастер-кнопка при выходе): выключается весь свет, останавливается музыка, закрываются шторы на 1 этаже, теплые полы переходят в Эко-режим, ставится охрана.

Тест сценария «Я пришел» (в дневное время): снятие с охраны, открытие базовых штор, возврат климата в Комфорт-режим.

Тест приветственного сценария (в ночное время): включение приглушенной подсветки в прихожей и коридоре по датчику присутствия.

Тест сценария «Кино»: приглушение основного света на 15%, закрытие штор Blackout, опускание моторизованного экрана проектора.

Режим имитации присутствия («Отпуск»): автоматическое рандомное включение/выключение света в 2–3 помещениях в заданный интервал времени (например, с 19:30 до 23:00).

Проверка приоритета конфликтующих систем (Override/Safety bounds): попытка запустить сценарий максимального охлаждения одновременно со сценарием быстрого прогрева помещения (система должна выдать ошибку или подавить действие более низкого приоритета).

Стресс-тесты, отказоустойчивость и UI (Stress/Resilience/UX)

Полное отключение питания центрального контроллера. Проверка запуска и автоматического подключения всех шин (после возобновления питания) через 1-3 минуты. Все реле должны сохранять правильное состояние (Safe state).

Ошибки интерфейса связи: физическое отключение кабеля RS-485 от одного подчинённого устройства. Остальная часть гирлянды должна продолжить работать без лагов. В приложении UI должен отобразить "Устройство недоступно".

Самовосстановление сети: возврат кабеля RS-485 на место. Устройство должно корректно продолжить опрос без необходимости перезапуска сервисов.

Спам-тест ("Тест кота/ребенка"): многократное быстрое нажатие (15-20 раз) на кнопку выключателя или иконку в приложении. Система не должна зависать, контроллер должен обработать буфер или проигнорировать спам.

Работа без интернета: отключение внешнего кабеля провайдера от роутера. Приложение должно подключаться локально (по Wi-Fi) и управлять устройствами без задержек.

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

Ведение журнала дефектов

Для каждого теста со статусом `Fail` необходимо заводить запись в отдельном документе — журнале дефектов (Bug Report). Это позволяет систематизировать работу над ошибками. Запись должна содержать:

• ID теста, который провалился.
• Подробное описание проблемы («Что произошло?»).
• Шаги для воспроизведения дефекта.
• Информация об окружении (версия прошивки контроллера, модель устройства, версия приложения на смартфоне).
• Приоритет (Критический, Высокий, Средний, Низкий).
• Ответственный за исправление.
• Текущий статус (Открыт, В работе, Исправлен).

> ⚠️ Важно: после перевода дефекта в статус "Исправлен", необходимо обязательно провести регрессионное тестирование (повторить исходный тест и убедиться, что внесенные в программный код изменения не сломали другие функции, которые раньше работали исправно).

Тест-план — это не статичный документ, созданный один раз. Это «живой» инструмент, который может и должен дополняться в ходе пусконаладки и последующей эксплуатации системы. Если заказчик просит добавить новую функцию, для нее должен быть разработан соответствующий набор тестов, который добавляется в общий план.

Подводя итог, можно утверждать: системный подход к тестированию (от базовых устройств к подсистемам, через сценарии и к стресс-тестам) полностью исключает пропуск логических и программных ошибок. Совместное прохождение этого набора из 30+ пунктов формирует доверие заказчика и гарантирует, что сданный объект будет функционировать предсказуемо и стабильно.

Что дальше

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