Главная → Академия → Сценарии умного дома: режимы, состояния, приоритеты → Типы тестирования: модульное, интеграционное, сценарное

Типы тестирования: модульное, интеграционное, сценарное

Урок · Сценарии умного дома: режимы, состояния, приоритеты · 30 мин · theory

Введение в методологии тестирования

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

> 💡 Подсказка: Обнаружение и исправление ошибки на этапе стендовой разработки в среднем в 10 раз дешевле, чем после сдачи объекта заказчику. Затраты на выезд инженера, вскрытие чистовой отделки (например, для доступа к застрявшему реле), диагностику на работающем объекте и исправление проблемы в уже эксплуатируемой системе могут многократно превысить стоимость своевременного написания тестов.

Классификация типичных ошибок в умном доме

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

Пример:* Сценарий климат-контроля из-за состояния гонки (Race Condition) одновременно включает и теплый пол, и кондиционер на охлаждение; ночной режим активируется днем из-за неправильной обработки часовых поясов (UTC vs Local time) или неверного сохранения контекстных переменных (`flow.set` / `global.get` в Node-RED). Пример:* Контроллер отправляет команду кондиционеру по Modbus TCP, но порядок байт (Byte Swap) не совпадает; KNX-шлюз публикует топик в MQTT без установленного флага `Retain`, из-за чего Node-RED не получает актуальное состояние при перезагрузке; несоответствие форматов (передача строки `"true"` вместо логического `true` в JSON payload). Пример:* Обрыв или недостаточная терминация (отсутствие резистора 120 Ом) шины RS-485, дребезг контактов (bounce) дешевого физического выключателя, наводки на слаботочную линию от проложенного вплотную силового кабеля, падение напряжения на длинной ленте LED-освещения.

Пирамида тестирования для систем автоматизации

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

| Уровень тестирования | Объект тестирования (Контекст Умного дома) | Цель | Затраты машинного времени / Стоимость |

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

| Сценарное (End-to-End / E2E) | Вся система целиком: от нажатия физической кнопки до фактического щелчка реле контроллера. | Проверить, что итоговый пользовательский сценарий (UX) отрабатывает корректно в реальных или максимально приближенных условиях. | Выполняются минуты / Требуют оборудования (Высокая) |

| Интеграционное | Взаимодействие между программными модулями: Node-RED ↔ MQTT брокер ↔ Драйвер Устройства (например, zigbee2mqtt). | Проверить, что компоненты общаются по правильному протоколу, топики совпадают, а полезная нагрузка (Payload) парсится без ошибок. | Выполняются секунды / Базируются на виртуальных сервисах (Средняя) |

| Модульное (Unit) | Изолированный кусок логики: Отдельный узел `Function` в Node-RED, скрипт расчета ПИД-регулятора, подпоток (Subflow). | Доказать, что при определенном наборе входящих параметров (`msg.payload`) алгоритм ВСЕГДА выдает строго ожидаемый математический результат. | Выполняются миллисекунды / Пишутся быстро (Низкая) |

Основание пирамиды — это модульное тестирование (Unit Testing). Это самый многочисленный, быстрый и дешевый вид тестов, позволяющий отладить чистую логику до того, как она будет привязана к железу. Выше располагается интеграционное тестирование, которое проверяет связи между программными модулями и надежность транспорта сообщений. На самой вершине — сценарное (End-to-End) тестирование, которое имитирует реальные действия пользователя (через интерфейс дашборда или физические симуляторы нажатий) и проверяет всю цепочку целиком.

> ⚠️ Важное правило: Чем ниже уровень в пирамиде, тем быстрее система проходит проверку и тем проще локализовать причину ошибки (так как тестируемая область предельно узка). Строить проект только на сценарном тестировании («покликаем пультом и посмотрим, как работает») — это антипаттерн, ведущий к неподдерживаемому и хрупкому коду.

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

Модульное (юнит) тестирование в Node-RED

В контексте платформы Умного дома и среды Node-RED, модулем (или юнитом) принято считать наименьшую логически неделимую часть потока обработки данных. Модуль должен быть полностью изолирован от физического оборудования (hardware). Это может быть:

Основная задача модульного теста — доказать, что изолированный юнит при получении на вход строго определенного сообщения (`msg`) выдает на выходе корректное, ожидаемое сообщение, либо правильно обрабатывает ошибку. Мы не проверяем, работает ли физическое физическое реле или датчик; мы проверяем только чистоту и правильность программной логики.

Базовые инструменты: ручное тестирование

Ключевыми инструментами для инициализации модульного тестирования «на лету» в Node-RED являются встроенные узлы `Inject` и `Debug`.

---

Практический пример: Тестирование функции преобразования температуры

> 💡 Сценарий: Датчик температуры, подключенный по протоколу Modbus RTU, отдает значение в виде целого числа (Integer), умноженного на 10. Например, регистр возвращает `255`, что физически означает `25.5 °C`.

> Нам необходимо написать узел `Function`, который: примет сырые данные, проведет валидацию, конвертирует значение и сформирует унифицированный JSON-объект согласно системному контракту сообщений.

Шаг 1: Конфигурация тестируемого узла `Function`

Напишем логику обработки, учитывая потенциальные краевые случаи.

// Имя узла: "Convert/Validate Modbus Temperature"


// Получаем сырое значение. Защищаемся от отсутствующего payload


const rawValue = msg.payload;



// 1. Строгая валидация: проверяем тип и физические границы (от -50.0 до +120.0 °C)


if (typeof rawValue !== 'number' || isNaN(rawValue)) {


    node.error("Type Error: Expected a number, got " + typeof rawValue, msg);


    node.status({fill:"red", shape:"ring", text:"Type error"});


    return null; // Прерываем поток


}



if (rawValue < -500 || rawValue > 1200) {


    node.error("Range Error: Value out of bounds (" + rawValue + ")", msg);


    node.status({fill:"red", shape:"dot", text:"Out of bounds: " + rawValue});


    return null; // Прерываем поток


}



// 2. Бизнес-логика (Преобразование)


const temperature = rawValue / 10.0;



// 3. Формирование исходящего сообщения по контракту (Data Contract)


msg.payload = {


    "value": temperature,


    "unit": "°C",


    "source": msg.topic || "modbus_default",


    "ts": Date.now()


};



// 4. Обновление статуса для диспетчера


node.status({fill:"green", shape:"dot", text: temperature.toFixed(1) + " °C"});



return msg;

Шаг 2: Формирование тест-плана и матрицы данных

Для обеспечения полноты проверки (coverage) мы создаем матрицу тест-кейсов, покрывающую позитивные (Happy Path) и негативные сценарии.

| № | Название теста | Настройки `Inject` (msg) | Ожидаемый результат (Assert) |

|---|---|---|---|

| 1 | Нормальное значение | `payload`: 255 (number)
`topic`: "sensor_1" | `msg.payload.value` === 25.5. Узел пропускает сообщение дальше. Статус зеленый. |

| 2 | Отрицательное значение | `payload`: -15 (number) | `msg.payload.value` === -1.5. Корректная работа с минусом. |

| 3 | Граничное значение (Edge) | `payload`: 1200 (number) | `msg.payload.value` === 120.0. Верхняя граница нормы. |

| 4 | Некорректный тип (String) | `payload`: "255" (string) | Сообщение не проходит на выход. Triggered `node.error` (Type Error). |

| 5 | Выход за границы (OOB) | `payload`: 5000 (number) | Сообщение не проходит на выход. Triggered `node.error` (Range Error). |

| 6 | Отсутствие данных (Null) | `payload`: не задан | Сообщение блокируется, ошибка типизации. |

---

Продвинутый уровень: Автоматизация модульных тестов

Ручное нажатие кнопок `Inject` работает для простых задач, но при масштабировании Умного дома тесты необходимо автоматизировать. Вместо того чтобы проверять значения в `Debug` глазами, мы строим поток валидации (Test Runner).

> ⚠️ Важно: Для профессиональной разработки в Node-RED рекомендуются сторонние узлы (например, `node-red-contrib-node-tester` или использование `Catch` узлов для перехвата ошибок типизации). Однако базовую автоматизацию можно реализовать нативных узлах.

Сценарий автоматизированного теста (Test Harness):

Мы собираем массив тестовых данных в одном узле, прогоняем их через тестируемую функцию по очереди, а на выходе ставим `Function` со скриптом-ассертом (проверкой утверждений).

Схема автоматизированного тестового потока: 
[Inject: Run All Tests] 

       |


       v


[Function: Test Data Matrix] --(Подача mock-сообщений по очереди)-->


       |


       v


[Function: Convert/Validate (Тестируемый юнит)]


       |


       v


[Function: Assert Expected vs Actual] --> [Debug: Test Results (Pass/Fail)]
Код узла `Test Data Matrix`: 
// Отправляем серию сообщений для автоматической проверки

const testCases = [


    { payload: 255, expected: 25.5, desc: "Positive integer" },


    { payload: -10, expected: -1.0, desc: "Negative integer" }


];



testCases.forEach(test => {


    node.send([ { payload: test.payload, _testDesc: test.desc, _expected: test.expected } ]);


});


return null;
Код узла `Assert expected vs Actual`: 
// Автоматическая сверка результата

if (msg.payload.value === msg._expected) {


    msg.payload = `✅ PASS: ${msg._testDesc}`;


} else {


    msg.payload = `❌ FAIL: ${msg._testDesc}. Expected ${msg._expected}, got ${msg.payload.value}`;


}


return msg;

Итоги модульного тестирования

Выполнение модульных тестов — это первый эшелон защиты логики умного дома от сбоев. Проводя модульные тесты мы:

  • Гарантируем детерминированность: узел ведет себя предсказуемо при любых (даже мусорных) входных данных.
  • Ускоряем отладку: ошибка локализуется в конкретном узле до того, как сообщение попадет в сложную сеть сценариев.
  • Формируем контракт: жестко фиксируем, в каком виде данные отправляются на следующий уровень системы.

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

    Интеграционное тестирование: проверка связей

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

    > ⚠️ Внимание: При интеграции асинхронных систем, таких как KNX и MQTT, всегда учитывайте возможные задержки и "гонки состояний" (race conditions). Например, команда от сценария на включение света может прийти раньше, чем от выключателя на стене придет сообщение о его текущем состоянии. Используйте механизмы подтверждения (ACK) и периодической синхронизации состояний (Status Request), как было рассмотрено в уроках по архитектуре.

    Ключевые параметры проверки (что именно мы тестируем)

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

    * Отрабатывается ли конвертация типов: например, KNX DPT 1.001 (1 бит) в MQTT JSON payload `{"state": true}`.

    * Соблюдается ли порядок байт (Endianness) в Modbus: читаются ли 32-битные числа (Float/UInt32) в правильном регистре (Big-endian vs Little-endian, `ABCD` или `CDAB`).

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

    Пошаговый план проведения интеграционного теста

    Чтобы тестирование было управляемым, двигайтесь по следующему алгоритму:

  • Изоляция: Временно отключите глобальные сценарии (автоматизации), чтобы они не генерировали побочный трафик. Мы тестируем только связь "Устройство А -> Брокер -> Устройство Б".
  • Генерация воздействия на источнике: Вызовите событие.
  • Трекинг транзита: Проверьте шину/брокер с помощью сниффера на наличие правильного сообщения.
  • Проверка реакции на приемнике: Убедитесь, что исполнительное устройство приняло команду корректно.
    • Типичные примеры интеграционных тестов на платформе HI:
  • Прямая связь (KNX -> MQTT):

    • Действие:* Нажать физическую кнопку KNX на стене.

    Проверка транзита:* Убедиться, что шлюз обработал телеграмму (Group Address `1/1/10`).

    Ожидаемый результат:* Проверить, что в MQTT Explorer в соответствующем топике (`hi/office/light/main/state`) появилось сообщение с правильной структурой и QoS:

        {
    

          "state": "ON",
    

          "brightness": 100,
    

          "linkquality": 98
    

        }

  • Обратная связь с масштабированием (MQTT -> Modbus RTU):

    • Действие:* Опубликовать тестовое сообщение в топик `hi/office/climate/setpoint/set` с payload `{"value": 24.5}`.

    Ожидаемый результат:* Логика контроллера (например, в Node-RED) должна умножить значение на 10. С помощью логов порта RS-485 убедиться, что в нужный Holding Register (например, `40012`) термостата было записано целочисленное значение `245`.

  • Асинхронная запись (1-Wire -> MySQL):

    • Действие:* Изменить температуру на датчике DS18B20 (универсальный вход контроллера).

    Ожидаемый результат:* Показания считываются раз в 10 секунд, парсятся контроллером и успешно выполняют SQL-запрос `INSERT` в таблицу `telemetry` в локальной базе данных MySQL. В таблице корректно формируется `timestamp`.

    Инструментарий для диагностики

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

    > 💡 Итог шага: Как только вы убедились, что данные без искажений доходят от датчика до логического ядра (Брокера/БД), а команды из ядра за доли секунды отрабатываются реле и термостатами, интеграционный слой можно считать надежным. Только после успешного подтверждения всех связей (интерфейсов) имеет смысл переходить к проверке комплексной логики работы всего здания.

    Практикум: тест интеграции KNX и MQTT

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

    Задача: При нажатии на клавишу KNX-выключателя (групповой адрес `1/1/1`), которая управляет основным светом в гостиной, в MQTT-топик `hi/LIVING_ROOM/light/main/state` должно публиковаться стандартизированное сообщение о новом состоянии.

    Шаг 1: Конфигурация узлов в Node-RED

    Для этой задачи нам понадобится палитра `node-red-contrib-knx-ultimate`. Поток будет состоять из трех основных узлов, которые реализуют паттерн «Сборщик -> Трансформатор -> Отправитель».

    [KNX Device: Wall Switch] --> [Function: Format to JSON] --> [MQTT Out: Publish State]
    1. Узел `knx-ultimate` (режим Device):

    > 💡 Важно: Этот узел будет выдавать на выходе объект сообщения, где `msg.payload` содержит аппаратно-распакованное значение (булево `true` или `false`).

    2. Узел `Function` ("Format to JSON"):

    На этом этапе мы приводим "сырые" данные к формату нашего контракта сообщений.

        // Защита от пустых телеграмм (например, Read Requests без данных)

        if (msg.payload === undefined || msg.payload === null) {
    

            node.warn("Получен пустой payload от KNX для GA 1/1/1");
    

            return null; // Прерываем поток
    

        }
    


        // Жесткое приведение к boolean для страховки
    

        const switchState = Boolean(msg.payload);
    


        // Формируем стандартный объект состояния по контракту нашего проекта
    

        msg.payload = {
    

            "on": switchState,
    

            "source": "knx",
    

            "ga": "1/1/1", // Добавляем доп. информацию для трассировки
    

            "timestamp": Date.now()
    

        };
    


        // Для обратной совместимости систем, слушающих простые топики,
    

        // можно параллельно отправлять строку "ON"/"OFF", но в нашей 
    

        // архитектуре мы используем стандартизированный JSON.
    


        return msg;

    3. Узел `MQTT Out`:

    Здесь мы публикуем сформированный JSON в брокер.

    Шаг 2: Выполнение теста и проверка

    Перед выполнением интеграционного теста необходимо подготовить среду мониторинга.

    Чек-лист тест-плана:
  • Разверните (Deploy) поток в Node-RED и убедитесь, что под узлами KNX и MQTT горят зеленые индикаторы `connected`.
  • Откройте программу-сниффер MQTT Explorer и подключитесь к вашему брокеру (с правами чтения нужных топиков).
  • В дереве топиков найдите и подпишитесь на ветку `hi/LIVING_ROOM/light/main/#`.
  • Стимуляция события: физически нажмите на клавишу KNX-выключателя на стене (либо отправьте телеграмму на адрес `1/1/1` через ETS Group Monitor, если физического стенда нет под рукой).
  • Наблюдение: В MQTT Explorer в топике `hi/LIVING_ROOM/light/main/state` должно мгновенно (задержка <50 мс) появиться сообщение. Кликните на него, чтобы посмотреть `payload`.
  • Сравнение результата с ожидаемым. `Payload` должен быть валидным JSON-объектом, строго соответствующим контракту:

    •     {
    

          "on": true,
    

          "source": "knx",
    

          "ga": "1/1/1",
    

          "timestamp": 1677611281000
    

        }

  • Проверка сброса состояния: Нажмите на клавишу еще раз. `Payload` должен обновиться, и значение поля `"on"` измениться на `false`.

    • Шаг 3: Edge-cases и диагностика

    В реальной практике интеграционные тесты часто падают с первого раза. Если вы не видите нужного результата в MQTT Explorer, выполните следующие проверки отказоустойчивости (edge-cases):

    Проверьте KNX/IP Router (если есть). Возможно, его таблица фильтрации (Filter Table) блокирует прохождение телеграмм `1/1/1` между линиями. Используйте Dummy-устройства в ETS для проброса адресов. Узел `MQTT Out` по умолчанию может некорректно сериализовать специфические объекты. Убедитесь, что галочка «Format: JSON» не вступает в конфликт с уже сформированным JSON-объектом внутри функции (в коде выше мы задали просто объект, Node-RED сериализует его автоматически). Настройка выключателя в ETS может быть выставлена в режим отправки состояния (Status) и команды (Command) по одному групповому адресу. Разделите их (`1/1/1` — команда, `1/4/1` — статус) и перенастройте Node-RED на прослушивание статусной группы.

    > ⚠️ Вывод по практикуму: Успешное прохождение этого теста валидирует работоспособность связки «физическая кнопка -> KNX-шина -> IP-шлюз -> программный брокер сообщений -> MQTT». Настроив один такой шаблон, вы можете легко масштабировать тест на сотни устройств, меняя лишь групповые адреса и суффиксы MQTT-топиков.

    Сценарное (E2E) тестирование: проверка пользовательских историй

    Сценарное тестирование, или End-to-End (E2E) тестирование — это вершина пирамиды. Оно проверяет не отдельные функции и не связи между протоколами, а всю бизнес-логику системы с точки зрения конечного пользователя. В основе E2E-тестов лежат пользовательские истории — короткие описания функциональности с позиции пользователя, например: "Как жилец, я хочу, чтобы при уходе из дома весь свет выключался, а климат переходил в экономный режим, чтобы экономить электроэнергию".

    В рамках E2E сигнал проходит полный путь: от физического взаимодействия (нажатие кнопки или срабатывание датчика) через брокер сообщений в ядро логики (Node-RED), а затем обратно к исполнительным устройствам различных стандартов (KNX, DALI, Modbus) и интерфейсам (мобильное приложение, дашборд).

    > 💡 Связанный материал: Подробно о создании комплексных сценариев и управлении состояниями см. в уроке "Сценарный слой: режимы, сцены и приоритеты".

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

    Чек-лист подготовки к E2E-тестированию

    Прежде чем приступать к прохождению сценариев, убедитесь, что система находится в состоянии готовности:

    Документирование тестов: структура Тест-кейса

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

  • ID и название сценария (уникальный идентификатор для ссылок).
  • Предусловия (исходное состояние всей системы, без которого тест не имеет смысла).
  • Последовательность действий (Шаги).
  • Ожидаемый результат (включает как видимый эффект, так и системные триггеры/телеметрию).
  • Фактический результат (заполняется инженером: соответствует / не соответствует ожиданиям).
  • Статус (Пройден / Не пройден / Заблокирован).

    • Пример тест-кейса: Сценарий "Я ухожу" (Позитивный сценарий)

    ID: TC-01 Название: Проверка сценария "Я ухожу" (Master Off) Предусловия:
  • Глобальный стейт объекта: режим "Дома" (`payload.mode = "home"`).
  • Включен свет в гостиной (KNX, Групповой Адрес `1/1/10` = 1).
  • Розетки на кухне включены (Реле контроллера Wiren Board, топик `/devices/wb-mr6c_1/controls/K1` = 1).
  • Климат-контроль в режиме "Комфорт" (уставка +23°C, Modbus, регистр `40100`).
  • Система охраны снята (модуль Ajax интегрирован по UART/MQTT).
  • Входная дверь закрыта (геркон замкнут).

    • | Шаг | Действие | Ожидаемый результат (Физика + Софт) | ФК | Статус |

    | --- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -- | ------ |

    | 1 | Нажать и удерживать 2 секунды кнопку "Уход" на панели у входной двери. | 1. Подсветка кнопки мигает синим (визуальный фидбек).
    2. Топик `home/modes/system` меняет значение на `"away"`.
    3. В логах Node-RED: "Mode changed to Away". | | |

    | 2 | Проверить статус освещения по всей квартире. | 1. Свет в гостиной и других зонах выключился (ГА `1/1/10` получил `0`).
    2. Статусы в UI интерфейсе обновились на выключенные в течение 500мс. | | |

    | 3 | Проверить неотключаемые и отключаемые розетки. | 1. Реле `K1` на кухне выключилось (светодиод погас).
    2. Неотключаемая розетка холодильника (Реле `K2`) осталась под напряжением.
    3. Топик `/devices/wb-mr6c_1/controls/K1` = 0. | | |

    | 4 | Проверить уставку на панели кондиционера. | Уставка температуры автоматически изменилась на +18°C (состояние "Eco/Эконом", регистр `40100` = 180). | | |

    | 5 | Физически открыть, выйти и закрыть входную дверь. | 1. Через 60 секунд (время на выход) система охраны поставлена.
    2. Светодиод на панели охраны сменил цвет на красный.
    3. Датчики движения перешли в режим "Тревога по движению". | | |

    | 6 | Проверить системные уведомления. | На телефон владельца (Telegram / Push) пришло уведомление:
    "Объект поставлен на охрану. Режим 'Я ухожу' активирован." Дашборд в приложении заблокирован для управления светом. | | |

    Тестирование исключений и ручного контроля (UX / Override)

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

    Для проверки UX/Override и отказоустойчивости добавляются дополнительные тестовые сценарии:

    Действие:* Инициировать режим "Я ухожу", когда геркон на окне в спальне разомкнут.

    Ожидание:* Охрана не встает на общий периметр полностью. Владелец моментально получает Push-уведомление или голосовое сообщение от колонки "Внимание, открыто окно в спальне". Сценарий Master-Off (выключение розеток) выполняется независимо от статуса охраны.

    Действие:* Сразу после активации "Я ухожу" (в течение 60 секунд на выход), пользователь нажимает кнопку включения света в прихожей.

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

    Действие:* Имитация отключения (отсоединение кабеля связи) модуля кондиционеров перед запуском сценария.

    Ожидание:* Сбой одного компонента (Graceful Degradation) не обрушает весь скрипт. Свет и розетки отключаются, охрана ставится. В логах Node-RED фиксируется таймаут (timeout error) по Modbus, а владельцу отправляется сервисный отчет: "Режим активирован частично. Ошибка связи с климатом".

    Методика проведения E2E тестирования требует педантичности: инженер последовательно выполняет шаги как из позитивных, так и из негативных тест-кейсов, фиксируя результат. Использование комплексного подхода (оценка физического результата + чтение сырых данных MQTT + проверка пользовательского интерфейса) — единственный способ гарантировать, что жилец получит надежный и предсказуемый Умный дом.

    Тест-план сдачи объекта: Чек-лист из 30+ пунктов

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

    1. Базовые сети и оборудование

  • [ ] Локальная сеть: роутер и коммутаторы стабильны, контроллеру и шлюзам присвоены статические IP-адреса.
  • [ ] Ядро логики: контроллер пингуется, доступен по SSH, веб-интерфейс Node-RED загружается без визуальных ошибок.
  • [ ] Брокер сообщений: MQTT-брокер стабильно принимает сообщения и вещает новые (проверено через MQTT Explorer).
  • [ ] Проводные шины: RS-485 (Modbus) работает без CRC-ошибок и тайм-аутов связи.
  • [ ] Радиосеть: ячеистая сеть Zigbee/Z-Wave маршрутизируется корректно, LQI датчиков на периферии не ниже 50.

    • 2. Датчики и входы

  • [ ] Движение/Присутствие: датчики мгновенно фиксируют появление человека и отключаются по заданному таймауту (без залипаний).
  • [ ] Контроль доступа: герконы на дверях/окнах мгновенно передают статус Открыто/Закрыто в брокер.
  • [ ] Кнопочные панели: физические выключатели на стенах безошибочно генерируют события (одинарное, двойное, долгое нажатие).
  • [ ] Микроклимат: датчики температуры и влажности откалиброваны, разброс относительно эталона в пределах нормы.
  • [ ] Качество воздуха: датчики CO2 передают корректные и регулярно обновляемые значения ppm.

    • 3. Освещение и исполнительные устройства

  • [ ] Свет on/off: релейные группы обычного света включаются/выключаются с нулевой задержкой.
  • [ ] Диммирование: DALI/KNX светильники плавно меняют яркость от 1% до 100%, не мерцают на низких значениях.
  • [ ] Декоративный свет: LED-ленты (RGB/RGBW) правильно отображают цвета и температуру белого.
  • [ ] Моторизация: шторы, жалюзи или рулонные ворота полностью открываются и закрываются, предельные концевики настроены.
  • [ ] Силовые линии: розетки отключаемых групп стабильно обесточиваются по команде и через сценарий "Отпуск / Я ушел".

    • 4. Климат и ресурсоснабжение

  • [ ] Теплые полы: сервоприводы гребенок или реле срабатывают при установке целевой температуры выше текущей.
  • [ ] Радиаторы: управление водяными клапанами отрабатывает алгоритм ПИД-регулятора на поддержание уставки.
  • [ ] Кондиционирование: шлюз климата корректно переключает режимы (Охлаждение, Обогрев, Авто), скорость вентилятора и уставку.
  • [ ] Вентиляция: приточная система реагирует на превышение порога CO2, а вытяжки санузлов — по таймеру или влажности.
  • [ ] Учет ресурсов: данные со счетчиков ХВС/ГВС и электричества корректно транслируются на дашборд.

    • 5. Безопасность и защитные сценарии

  • [ ] Защита от протечки (ОЖИДАЕМАЯ АВАРИЯ): при срабатывании датчика мгновенно перекрываются краны подачи воды.
  • [ ] Пожарная тревога: датчики дыма/CO активируют оповещение и автоматически останавливают приточную вентиляцию.
  • [ ] Сценарии охраны: при режиме "Я ушел" встают на охрану требуемые зоны, датчики движения переключаются в режим тревоги.
  • [ ] Отказоустойчивость питания: ИБП корректно держит нагрузку контроллера и роутера при имитации пропажи питания 220В.
  • [ ] Safe-state: при потере связи с контроллером критичные устройства (обогреватели, насосы) переходят в безопасное отключенное состояние.

    • 6. Интерфейсы и пользовательский опыт

  • [ ] Локальный UI: дашборд (Apple HomeKit, Home Assistant или кастомный UI) загружается в локальной сети (без интернета).
  • [ ] Удаленный доступ: приложение полноценно управляет домом при переключении смартфона на сотовую сеть (LTE).
  • [ ] Голосовое управление: интеграция с ассистентом (Алиса/Siri) протестирована базовыми командами ("Включи свет", "Сделай теплее").
  • [ ] Уведомления: Push-уведомления или сообщения в Telegram прилетают быстро и содержат точную причину.
  • [ ] Audit Trail: система ведет структурированный журнал событий (пользователь, время, действие).

    • ---

    Методология проведения «учений» (имитация аварий на объекте)

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

    Данный этап осуществляется до заезда жильцов, но на этапе полной готовности железа.

    Процедура симуляции критических кейсов

  • Учебная протечка

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

    Мониторинг:* Шаровые краны ввода воды обязаны перекрыться за 3-5 секунд. При наличии циркуляционных насосов/бойлера они должны обесточиться. Владелец обязан получить точный Push ("Авария: Протечка в гостевом санузле").

    Восстановление:* Насухо вытереть датчик, нажать программную или аппаратную кнопку "Сброс аварии", удостовериться в автоматическом открытии кранов.

  • Отказ канала связи (Network Outage)

    • Действие:* Извлечь оптический/Ethernet кабель провайдера из роутера.

    Мониторинг:* Локальные подсистемы умного дома обязаны продолжить работу в штатном режиме. Выключатели реагируют на нажатия, автоматика поддержания температуры функционирует. Должен работать доступ к локальному дашборду через Wi-Fi. Голосовое управление может отключиться, но не должно блокировать скрипты.

    Восстановление:* Подключение кабеля; проверка автоматического восстановления облачных интеграций.

  • Сбой главного электропитания 220В

    • Действие:* Выключить общий вводной автомат в электрощите.

    Мониторинг:* Контроллер автоматики и роутер мгновенно переходят на питание от ИБП. Сеть умного дома не перезагружается. В Telegram приходит тревожное сообщение: "Отключено основное питание 220В. Работа от резервных батарей".

    Восстановление:* Включение автомата. Мощные потребители должны включаться каскадно, чтобы не вызывать пиковых перегрузок. Реле света должны загрузиться в корректное Power-On State (не устраивая "дискотеку").

  • Аппаратный сбой шины (Hardware Fault)

    • Действие:* Имитация отвала устройства: физическое отключение кабеля RS-485 или обесточивание блока реле в щите.

    Мониторинг:* Node-RED / центральная логика должны зафиксировать обрыв связи по времени (Timeout). В журнале появляется запись ошибки. Логика системы не должна "зависать" или генерировать бесконечный цикл команд восстановления, перегружая CPU.

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

    Итоги и документирование результатов

    Мы рассмотрели уровни тестирования, каждый из которых играет незаменимую роль в создании надежной системы автоматизации:

    Документирование дефектов (Bug Reports)

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

    Пример:* 1. Выставить `input_select.home_mode` в состояние `Уход`. 2. Подождать 5 секунд (задержка автоматизации). Пример:* На топик `climate/living_room/set` должен уйти payload `{"preset": "eco", "temp": 18}`. Термостат в гостиной переключается. Пример:* Узел `Call Service` выдает ошибку `API Error`. В payload отправляется только `{"preset": "eco"}`, обязательный параметр `temp` возвращает `undefined`. * Экспорт `msg` из узла `Debug` (в формате JSON).

    * Логи из Home Assistant (`home-assistant.log`) или системного журнала (journalctl).

    * Скриншоты проблемного участка флоу.

    > 💡 Совет: Чем лучше описана ошибка и чем больше технических "следов" (payload, логи) прикреплено к отчету, тем быстрее разработчик сможет локализовать неверную логику маршрутизации или некорректно заданную переменную.

    Подготовка артефактов тестирования

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

    К ним относятся:

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