ГлавнаяАкадемияСценарии умного дома: режимы, состояния, приоритеты → Шаг 4: Разработка тест-плана и проведение само-тестирования

Шаг 4: Разработка тест-плана и проведение само-тестирования

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

Введение в тестирование на реальном объекте

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

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

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

> 📋 Ключевые понятия:

> * Приемо-сдаточные испытания (Acceptance Testing): Проверка системы конечным пользователем (заказчиком) или инженером на самом объекте. Цель — доказать, что система выполняет все требования ТЗ при работе с реальной физической средой.

> * Стресс-тестирование и учения (Stress Testing / Drills): Имитация реальных аварийных ситуаций (затопление, задымление, потеря связи) для проверки надежности защитных механизмов системы и скорости их реакции в полевых условиях.

> * Пусконаладочные работы (ПНР): Комплекс мероприятий по настройке установленного оборудования и проверке его интеграции в общую программную логику Node-RED перед финальной сдачей.

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

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

---

Разработка программы испытаний: структура и документирование

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

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

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

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

| ACC-001 | Переход в режим "Комфорт" | 1. Убедиться, что никого нет (состояние "Отсутствие"). 2. Нажать физическую мастер-кнопку у входа. | Система переходит в состояние `comfort`. Активируются реальные группы света в прихожей. Включается питание аудиосистемы. | | |

| ACC-002 | Игнорирование команд при аварии | 1. Инициировать состояние "Авария" (см. учения). 2. Попытаться включить розетки через настенную панель. | Питание на розетки не подается. Настенная панель сигнализирует красным индикатором. В журнале — игнорирование команды. | | |

| DRL-001 | Срабатывание датчика протечки | 1. Установить состояние "Комфорт". 2. Замкнуть контакты датчика под раковиной влажной салфеткой. | Система переходит в `emergency_leak`. Физические клапаны ХВС и ГВС закрываются (визуальный контроль). Отправляется Telegram-уведомление. | | |

> 🔗 Связанный материал:

> Для разработки исчерпывающего плана ПСИ поднимите исходное техническое задание (ТЗ) заказчика. Каждый пункт ТЗ и каждое требование к безопасности должны быть покрыты минимум одним физическим тестом из программы испытаний.

Методология сценариев приемочных испытаний

  • Пользовательские сценарии (User Journey Scenarios): Проверяют ежедневное штатное использование системы реальным человеком.
  • * Источник: Сценарии жизни (Утро, Вечер, Уход из дома), описанные в ТЗ.

    * Пример: `(ID: ACC-005)` Проверка сценария "Ночной режим".

    * Шаги: 1. Дождаться наступления вечера или сымитировать освещенность. 2. Нажать клавишу "Спокойной ночи" у кровати.

    * Ожидаемый результат: Основной свет гаснет, шторы физически закрываются. Активируется ночная подсветка по датчикам движения на минимальной яркости.

  • Стресс-тесты оборудования (Hardware Stress Tests): Проверяют реакцию системы на нештатные физические состояния устройств: отключение питания, потерю сети, дребезг контактов.
  • * Источник: Логика резервирования и обработки ошибок.

    * Пример: `(ID: ACC-006)` Проверка реакции на пропажу связи с контроллером Zigbee.

    * Шаги: 1. Установить состояние "Комфорт". 2. Физически извлечь Zigbee-координатор из USB-порта.

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

    Акт ПСИ является "живым" документом до момента подписания. Он заполняется инженером вместе с заказчиком на объекте и становится главным юридическим подтверждением выполненных работ.

    ---

    Практика: Приемо-сдаточные испытания всего объекта

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

    Отслеживание реальных сигналов от оборудования

    Теперь мы не симулируем сообщения узлом `Inject`, а слушаем эфир. Мы инициируем физическое действие и смотрим, как оно отражается в цифровой среде умного дома, соблюдая "Контракт сообщения".

  • Настройка мониторинга: Подключитесь к MQTT-брокеру объекта. Используйте узлы `MQTT in` с базовой фильтрацией или внешний клиент (например, MQTT Explorer), чтобы видеть сырые данные от датчиков.
  • Формирование событий: Взаимодействуйте с реальным миром: пройдитесь перед датчиком движения, подышите на датчик качества воздуха, включите увлажнитель руками.
  • > 💡 Подсказка: Организуйте рабочее место сборщика на объекте так, чтобы видеть интерфейс Node-RED (дашборд или дебаг) с планшета, находясь непосредственно рядом с тестируемым оборудованием (например, сидя в котельной рядом с коллектором).

    Примеры логов `msg.payload` при реальных испытаниях

    1. Учения: Датчик протечки (физическое воздействие)

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

    {
    

    "value": true,

    "source": "sensor-leak-bathroom-1",

    "ts": 1678886400000,

    "meta": {

    "room": "bathroom",

    "type": "leak_sensor",

    "battery": 87,

    "linkquality": 105

    }

    }

    2. Проверка работы с климатом: Датчик CO2

    Вы собираете несколько человек в непроветриваемом помещении или используете баллончик из набора тестировщика.

    {
    

    "value": 1150,

    "source": "sensor-co2-bedroom",

    "ts": 1678886500000,

    "unit": "ppm",

    "temperature": 24.5

    }

    * Физический контроль: После превышения порога в 1000 ppm убедитесь, что вытяжная установка реально включилась (слышен шум двигателей).

    * Граничный контроль: Проветрите помещение до падения CO2 ниже гистерезиса (например, 800 ppm) и убедитесь, что приточная установка сбросила обороты.

    3. Тестирование сложных команд через реальные панели

    Заказчик нажимает кнопку "Кино" на физическом KNX-выключателе или Zigbee-пульте.

        {
    

    "payload": {

    "state": "ON",

    "brightness": 30,

    "transition": 5

    },

    "topic": "zigbee2mqtt/light_livingroom_main/set"

    }

    Техника поэтапной сдачи (по зонам)

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

  • Разделите объект на логические зоны (Котельная, Гостиная, Мастер-спальня).
  • Фокусируйте внимание заказчика только на одной зоне за раз, тестируя сначала освещение, затем климат, затем безопасность.
  • Такой подход исключает рассеивание внимания заказчика и снижает шанс пропустить баг "на стыке" оборудования в соседних помещениях.
  • ---

    Практика: Проведение "учений" и имитация аварий (Стресс-тесты)

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

    Основным инструментом на этом этапе становится журнал событий, сопоставленный с вашими визуальными наблюдениями за инженерными системами объекта.

    > ⚠️ Внимание:

    > Во время учений (особенно проверок протечек и коротких замыканий) убедитесь, что на объекте нет ценных вещей, которые могут пострадать в случае сбоя логики, или что система продублирована аппаратными защитами.

    Техника отработки стресс-сценариев и приоритетов

    Задача — последовательно сымитировать аварийные физические события и наблюдать за реакцией автоматики.

    Пример сквозного тест-кейса учений (ID: DRILL-001):
  • Начальная точка: Убедитесь, что система находится в состоянии полного покоя `away` (Отсутствие), физический замок закрыт.
  • * Проверка: В журнале последняя запись о состоянии — `state_changed: away`.

  • Шаг 1: Возвращение домой. Вы физически открываете дверь умным замком или кодом.
  • * Действие: Замок присылает событие разблокировки, отрабатывает триггер на `comfort`.

    * Проверка: В журнале запись `state_changed: comfort`. Вы слышите голосовое приветствие колонки, видите включившийся стартовый свет.

  • Шаг 2: Активация специфического режима. Вы ложитесь на диван и просите Алису включить кино.
  • * Действие: Произносите реальную голосовую команду. Алиса дает команду в интеграцию.

    * Проверка: В журнале запись `state_changed: cinema`. Шторы физически задвигаются с характерным звуком моторов.

  • Шаг 3: Аварийная ситуация (Тест приоритета!). Вы берете чашку с водой и выливаете ее на датчик протечки под радиатором.
  • * Действие: Датчик погружается в воду.

    * Проверка:

    * В журнале немедленно появилась запись `state_changed: emergency_leak`.

    * Вы слышите звук сервоприводов клапанов Нептун перекрывающих стояки.

    * Все опасные розетки обесточиваются (слышны щелчки реле в щите).

    * На ваш телефон синхронно приходит push-уведомление с фото от камеры.

  • Шаг 4: Попытка выхода из аварии до устранения. Вы подходите к выключателю и упорно пытаетесь включить свет/розетки, пока вода все еще на контактах датчика.
  • * Действие: Физическое нажатие кнопок на настенной панели.

    * Проверка:

    * Освещение может игнорировать команды или включаться только в безопасных зонах.

    * Розетки не включаются ни при каких обстоятельствах. В журнале фиксируется аппаратная блокировка: `command_ignored: set_state (reason: emergency_active)`. Это доказывает, что ваша система держит физический приоритет аварии.

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

    ---

    Итоги и лучшие практики приемо-сдаточных испытаний

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

    Давайте подведем итоги ключевых концепций:

    Теперь введем еще два важных понятия для дальнейшей эксплуатации:

    > 📋 Ключевые понятия:

    > * Регулярные учения (Maintenance Drills): Представьте, что за год контакты датчиков могли окислиться, а батарейки сесть. Сдача объекта — это не конец. Вы должны согласовать с заказчиком (или проводить самостоятельно, если берете объект на поддержку) регулярные, ежегодные "учения" по имитации протечек и пожаров для поддержания боеготовности системы.

    > * Исполнительная документация (As-built Documentation): Это весь пакет схем, графов состояний, логов ПСИ и бэкапов Node-RED, который фиксирует срез полностью работающей системы на момент подписания акта сдачи. Без нее полноценная техническая поддержка невозможна.

    Что дальше

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