Главная → Академия → Введение в протоколы автоматизации → Составление тест-плана для сдачи-приемки

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

Урок 4 · Введение в протоколы автоматизации · 30 мин · theory

Введение: Роль и ценность тест-плана

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

> ⚠️ Внимание: Пропуск этапа формального тестирования — одна из самых дорогостоящих ошибок в проекте. Любой дефект, обнаруженный заказчиком после подписания актов, наносит не только финансовый, но и репутационный ущерб. Затраты на выезд специалиста, диагностику и исправление проблемы на действующем объекте могут многократно превысить стоимость своевременного тестирования.

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

Ключевые риски "интуитивной" пусконаладки без формального тест-плана:

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

---

Анатомия тест-плана: структура и обязательные атрибуты

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

> 💡 Подсказка: Используйте облачные таблицы (Google Sheets, Notion, Microsoft 365) для ведения тест-плана. Это позволяет в реальном времени отслеживать прогресс, прикреплять скриншоты или фотографии, оставлять комментарии и совместно работать всей команде, включая менеджера проекта и, при необходимости, заказчика.

Рассмотрим обязательные разделы стандартного тест-плана:

1. Титульный лист

Это "лицо" документа. Он должен содержать всю идентификационную информацию:

2. Раздел "Предусловия"

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

3. Таблица тест-кейсов

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

| ID | Наименование проверки | Шаги для воспроизведения | Ожидаемый результат | Фактический результат | Статус (Пройден/Провален) | Примечания / ID Дефекта |

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

| HW-RELAY-01 | Вкл/Выкл освещения в гостиной с настенной кнопки | 1. Подойти к выключателю S-LIVING-01. 2. Однократно нажать клавишу. 3. Повторно нажать клавишу. | 1. При первом нажатии свет плавно включается. 2. При втором — плавно выключается. | | | |

| LOGIC-AWAY-01 | Тестирование сценария "Я ушел" | 1. Нажать и удержать на 3 сек. выключатель у входной двери. 2. Проверить группы освещения. 3. Проверить розетки. | 1. Все группы света выключаются. 2. Отключаемые розеточные группы обесточены. 3. На телефон приходит Push-уведомление. | | | |

| E2E-CLIM-01 | Изменение уставки температуры с панели iRidium | 1. Открыть экран "Климат" на панели. 2. Установить температуру на 25°C. 3. Проверить регистр Modbus-термостата. | 1. Уставка на панели сохраняется. 2. В Holding Register 101 устройства с ID=5 записывается значение 25. | | | |

4. Лист согласования и подписей

Финальный раздел, который формализует завершение испытаний.

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

---

Практика: Тест-кейсы для аппаратного уровня

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

> 🔗 Связанный материал: Данный раздел предполагает, что базовые проверки из уроков `COURSE-06-M09-L03` (Тестирование УЗО) и `COURSE-06-M09-L04` (Проверка работы реле под нагрузкой) уже успешно выполнены и задокументированы.

Ниже приведены примеры детализированных тест-кейсов для аппаратной части, построенной на контроллере HI-Core.

Тест-кейс 1: Проверка диммирования освещения

ID: `HW-DIM-01` Наименование: Проверка плавности диммирования и отсутствия мерцания. Предусловия: Группа света подключена к выходу DALI-шлюза. Шаги для воспроизведения:
  • С помощью отладочного интерфейса Node-RED (или панели управления) отправить команду на установку яркости 1%.
  • Визуально оценить работу светильника.
  • Последовательно установить яркость 10%, 50%, 99%, 100%.
  • Отправить команду на выключение (яркость 0%).
    • Ожидаемый результат: Статус: Пройден / Провален. Примечание: В случае провала указать, на каком уровне яркости наблюдается мерцание.

    Тест-кейс 2: Верификация обратной связи от реле

    ID: `HW-RELAY-FB-01` Наименование: Проверка соответствия физического состояния реле и его статуса в системе. Предусловия: Реле `RL-05` контроллера подключено к MQTT-брокеру. Топик для команд: `hi-core/control/RL05/on`, топик для статуса: `hi-core/status/RL05`. Шаги для воспроизведения:
  • Подписаться на топик `hi-core/status/RL05` с помощью MQTT-клиента (например, MQTT Explorer).
  • Опубликовать сообщение `1` в топик `hi-core/control/RL05/on`.
  • Зафиксировать щелчок реле и измерить напряжение на его выходе.
  • Проверить сообщение, пришедшее в топик `hi-core/status/RL05`.
  • Опубликовать сообщение `0` в топик `hi-core/control/RL05/on`.
  • Зафиксировать щелчок реле и отсутствие напряжения.
  • Проверить сообщение в топике статуса.
    • Ожидаемый результат:

    Тест-кейс 3: Проверка Modbus-устройства (счетчик электроэнергии)

    ID: `HW-MODBUS-01` Наименование: Чтение текущих показаний с Modbus-счетчика. Предусловия: Счетчик с ID=15 подключен к шине RS-485. В Node-RED настроен узел `Modbus-Read`. Шаги для воспроизведения:
  • Включить мощную нагрузку, подключенную через счетчик (например, электрочайник).
  • В Node-RED активировать узел `Modbus-Read`, настроенный на чтение Holding Register-а, отвечающего за мгновенную мощность (например, адрес 40012).
  • Проанализировать `msg.payload` на выходе узла в окне `Debug`.
  • Выключить нагрузку.
  • Повторно активировать узел `Modbus-Read`.
    • Ожидаемый результат: 
    // Пример msg.payload от узла Modbus-Read при успешном чтении

    {
    

      "payload": [2150],
    

      "buffer": "",
    

      "_msgid": "c3a4e5f6.123456"
    

    }

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

    ---

    Практика: Тестирование логики и сценариев в Node-RED

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

    Имитация входных сигналов с помощью узла `Inject`

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

    Пример: Тестирование реакции на датчик движения.

    Предположим, сценарий включения света в коридоре должен срабатывать на сообщение от датчика движения, которое приходит из MQTT-топика `sensors/corridor/motion`.

  • Отсоедините ветку потока, идущую от узла `mqtt in`.
  • На её место временно подключите узел `Inject`.
  • Настройте узел `Inject` для отправки JSON-объекта, имитирующего сработку датчика.
    • {

        "payload": {
    

            "value": true,
    

            "source": "motion-sensor-corridor-1",
    

            "ts": 1678886400000,
    

            "meta": {
    

                "battery_level": 98
    

            }
    

        },
    

        "topic": "telemetry/corridor/motion"
    

    }
  • Нажмите на кнопку узла `Inject`. Это действие полностью эквивалентно сработке реального датчика. Теперь вы можете наблюдать, как система отрабатывает логику: включает свет, запускает таймер на выключение и т.д.

    • Тест-кейс для сложного сценария: "Я ушел"

    ID: `LOGIC-SCN-AWAY-01` Наименование: Комплексная проверка сценария "Я ушел" / "Мастер-выключатель". Предусловия: Сценарий реализован в Node-RED и запускается по длительному (3 сек) нажатию на выключатель у входной двери. Шаги для воспроизведения:
  • Включить свет в гостиной, на кухне и в спальне. Включить телевизор в розетку, управляемую реле.
  • С помощью узла `Inject` сымитировать сообщение о длительном нажатии.
  • Наблюдать за выходами узлов `Debug`, подключенных к исполнительным веткам потока.
  • Проверить физическое состояние оборудования.
  • Проверить получение Push-уведомления на тестовом смартфоне.
    • Ожидаемый результат:

    Проверка энергонезависимости логики (Context Storage)

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

    > ℹ️ Информация: Платформа HI-Core позволяет настроить сохранение контекста (`context storage`) в энергонезависимую память (встроенный EEPROM, файловая система на SD-карте или база данных MySQL). Этот тест проверяет, что данная функция настроена и работает корректно.

    ID: `LOGIC-PERSIST-01` Наименование: Проверка сохранения состояния конечного автомата (FSM) климат-контроля после перезагрузки. Предусловия: Логика климата реализована как конечный автомат, текущее состояние (`heating`, `cooling`, `off`) хранится в `flow.climate_state`. Шаги для воспроизведения:
  • С помощью панели управления перевести климат-контроль в режим "Нагрев" (`heating`).
  • В редакторе Node-RED, на вкладке "Context Data", убедиться, что `flow.climate_state` имеет значение `"heating"`.
  • Физически перезагрузить контроллер (командой `sudo reboot` через SSH или кратковременным отключением питания).
  • Дождаться полной загрузки контроллера и Node-RED.
  • Снова открыть вкладку "Context Data" и проверить значение `flow.climate_state`.
    • Ожидаемый результат:

    Использование узлов `Inject` и `Debug`, а также целенаправленное тестирование сохранения контекста, позволяет провести глубокую и всестороннюю проверку всей логики автоматизации еще до того, как ее начнет использовать конечный пользователь.

    ---

    Сквозное тестирование: Пользовательский интерфейс iRidium

    После того как мы по отдельности проверили аппаратный уровень и логику в Node-RED, наступает финальный и самый важный для заказчика этап — сквозное тестирование (End-to-End или E2E).

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

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

    Этот вид тестирования имитирует реальный пользовательский опыт и помогает выявить проблемы на стыках различных подсистем (iRidium <-> MQTT <-> Node-RED <-> Контроллер HI-Core <-> Оборудование).

    Пример сквозного тест-кейса для iRidium

    ID: `E2E-FLOORHEAT-01` Наименование: Управление теплым полом в ванной комнате с планшета. Предусловия: Планшет с запущенным проектом iRidium подключен к Wi-Fi сети объекта. Теплый пол подключен через реле `RL-10` контроллера. Шаги для воспроизведения:
  • Взять в руки планшет и перейти на экран "Ванная комната". Убедиться, что иконка теплого пола находится в неактивном состоянии (например, серого цвета).
  • Нажать на иконку "Теплый пол".
  • Слушаем: Прислушаться к щелчку реле `RL-10` в электрощите.
  • Смотрим: Убедиться, что иконка теплого пола на планшете изменила свой цвет на активный (например, оранжевый) и, возможно, отобразила текущую температуру.
  • Подождать 30 секунд.
  • Повторно нажать на иконку "Теплый пол" на планшете.
  • Прислушаться к повторному щелчку реле `RL-10`.
  • Убедиться, что иконка на планшете вернулась в неактивное состояние.
    • Ожидаемый результат:

    Тестирование на разных платформах

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

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

    Особое внимание следует уделить сложным, нестандартным элементам, которые часто реализуются с помощью скриптов на стороне визуализации (в iRidium это JavaScript).

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

    ---

    Регрессионное тестирование и финализация

    В процессе пусконаладки и демонстрации системы заказчику практически неизбежно возникают правки. "А давайте сделаем, чтобы вот эта кнопка включала свет не на 100%, а на 70%", "Можем добавить в сценарий 'Я ушел' еще и закрытие штор?". Каждое такое изменение, даже самое незначительное, несет в себе риск — оно может нарушить то, что уже работало. Для борьбы с этим риском существует регрессионное тестирование.

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

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

    Это не полное повторение всех тестов, а выборочная проверка наиболее важных и взаимосвязанных частей.

    Определение "области влияния"

    Перед тем как начать регресс-тест, важно мысленно оценить "область влияния" внесенного изменения.

    Обязательный набор регресс-тестов

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

  • Сценарий "Мастер-выключатель" ("Я ушел"/"Я пришел"): Это самый комплексный сценарий, затрагивающий множество подсистем. Его корректная работа — признак общей стабильности.
  • Система безопасности: Тестирование сработки всех датчиков (протечки, дыма, открытия) и корректной реакции системы (перекрытие воды, отправка уведомлений). Компромиссы здесь недопустимы.
  • Климат-контроль: Проверка базовых режимов работы. Заказчик очень быстро заметит, если в доме станет слишком холодно или жарко.
  • Управление основными группами света и шторами: Проверка реакции на команды с наиболее часто используемых выключателей и панелей.

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

    Финализация и подписание акта

    После того как все функциональные, сквозные и регрессионные тесты пройдены, наступает финальный этап:

  • Заполняются все пустые поля в таблице тест-плана: "Фактический результат", "Статус".
  • Если были найдены и исправлены дефекты, в примечаниях ставятся ссылки на записи в баг-трекере или просто отметка "Исправлено в версии v1.1".
  • Итоговый документ распечатывается в двух экземплярах.
  • В ходе финальной встречи с заказчиком происходит демонстрация ключевых пунктов тест-плана.
  • После успешной демонстрации обе стороны подписывают "Лист согласования".

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

    Что дальше?

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