Составление тест-плана для сдачи-приемки
Введение: Роль и ценность тест-плана
На заключительном этапе пусконаладки инженер сталкивается с самой ответственной задачей — демонстрацией работоспособности системы заказчику и подписанием акта сдачи-приемки. Процесс, который кажется простым на первый взгляд ("просто показать, что все работает"), на деле является зоной повышенного риска. Ошибки, пропущенные на этом этапе, могут привести к серьезным репутационным и финансовым потерям.
> ⚠️ Внимание: Пропуск этапа формального тестирования — одна из самых дорогостоящих ошибок в проекте. Любой дефект, обнаруженный заказчиком после подписания актов, наносит не только финансовый, но и репутационный ущерб. Затраты на выезд специалиста, диагностику и исправление проблемы на действующем объекте могут многократно превысить стоимость своевременного тестирования.
Тест-план — это формальный документ, который структурированно описывает весь объем проверок, необходимых для подтверждения полного соответствия системы автоматизации проектным требованиям. Это не просто список "что проверить", а методология верификации, которая обеспечивает полноту и воспроизводимость тестирования.Ключевые риски "интуитивной" пусконаладки без формального тест-плана:
- Пропущенные дефекты: Человеческий фактор неизбежен. Без структурированного чек-листа легко забыть проверить редко используемые сценарии, работу аварийных систем или поведение логики при пограничных условиях (например, работа климат-контроля при резком скачке температуры).
- Недовольство заказчика: Неструктурированная демонстрация выглядит непрофессионально. Заказчик может чувствовать, что его "водят за нос", показывая только то, что гарантированно работает. Четкий тест-план, согласованный заранее, снимает это напряжение и выстраивает доверительные отношения.
- Юридические последствия: В случае возникновения споров именно подписанный обеими сторонами тест-план с результатами проверок становится главным аргументом. Он доказывает, что на момент сдачи система функционировала корректно и в полном объеме.
- Экономическая неэффективность: Классическое правило разработки гласит, что стоимость исправления ошибки растет экспоненциально с каждым этапом проекта. Ошибка, найденная на этапе тестирования, обходится в 10 раз дешевле, чем та же ошибка, найденная заказчиком в процессе эксплуатации. Тест-план — это инвестиция в снижение будущих издержек.
Таким образом, тест-план является не бюрократической формальностью, а важнейшим инструментом управления качеством, управления рисками и выстраивания профессиональных отношений с клиентом. Он превращает хаотичную проверку в предсказуемый инженерный процесс и служит надежным основанием для успешного завершения проекта.
---
Анатомия тест-плана: структура и обязательные атрибуты
Качественный тест-план должен быть не просто списком, а полноценным документом, понятным как инженеру, так и представителю заказчика. Его структура должна быть логичной, а каждый элемент — информативным.
> 💡 Подсказка: Используйте облачные таблицы (Google Sheets, Notion, Microsoft 365) для ведения тест-плана. Это позволяет в реальном времени отслеживать прогресс, прикреплять скриншоты или фотографии, оставлять комментарии и совместно работать всей команде, включая менеджера проекта и, при необходимости, заказчика.
Рассмотрим обязательные разделы стандартного тест-плана:
1. Титульный лист
Это "лицо" документа. Он должен содержать всю идентификационную информацию:
- Наименование документа: Тест-план приемо-сдаточных испытаний
- Проект: Например, "Система автоматизации коттеджа"
- Адрес объекта: г. Москва, ул. Центральная, д. 10
- Дата составления: 20.10.2023
- Версия документа: v1.0 (важно для отслеживания изменений)
- Исполнитель: Инженер-интегратор Иванов И.И.
- Представитель заказчика: Петров П.П.
- ID урока (для внутренних нужд): COURSE-06-M09-L05
2. Раздел "Предусловия"
Перед началом тестирования необходимо убедиться, что система находится в исходном состоянии, готовом к проверке. Этот раздел предотвращает ситуации, когда тесты проваливаются из-за невыполненных базовых условий.
- Все монтажные работы завершены.
- Электрощит собран, проверен и находится под напряжением.
- Все устройства защиты (АВ, УЗО, Диф. автоматы) включены.
- Контроллер HI-Core загружен и доступен по сети.
- Программное обеспечение (Node-RED, MQTT-брокер) запущено.
- На контроллер загружена проектная версия конфигурации сценариев (указать версию или дату).
- Все оконечные устройства (датчики, приводы) подключены и получают питание.
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-шлюза. Шаги для воспроизведения:- Светильник включается на минимально возможную яркость.
- Изменение яркости происходит плавно, без видимых скачков.
- На всех уровнях яркости отсутствует видимое мерцание (стробоскопический эффект).
- При установке 100% светильник выходит на полную мощность.
- При установке 0% полностью гаснет.
Тест-кейс 2: Верификация обратной связи от реле
ID: `HW-RELAY-FB-01` Наименование: Проверка соответствия физического состояния реле и его статуса в системе. Предусловия: Реле `RL-05` контроллера подключено к MQTT-брокеру. Топик для команд: `hi-core/control/RL05/on`, топик для статуса: `hi-core/status/RL05`. Шаги для воспроизведения:- После отправки `1` на выходе реле появляется напряжение ~230В. В топик статуса приходит сообщение `1`.
- После отправки `0` напряжение на выходе реле пропадает. В топик статуса приходит сообщение `0`.
- Задержка между командой и изменением статуса в MQTT не превышает 500 мс.
Тест-кейс 3: Проверка Modbus-устройства (счетчик электроэнергии)
ID: `HW-MODBUS-01` Наименование: Чтение текущих показаний с Modbus-счетчика. Предусловия: Счетчик с ID=15 подключен к шине RS-485. В Node-RED настроен узел `Modbus-Read`. Шаги для воспроизведения:- При включенной нагрузке узел `Modbus-Read` возвращает массив с ненулевым значением, близким к паспортной мощности чайника (например, `[2150]`).
- Статус узла в Node-RED — зеленый, `active`.
- При выключенной нагрузке узел возвращает значение, близкое к нулю (например, `[5]`).
- Ошибки `Timeout` или `CRC Error` отсутствуют.
// Пример msg.payload от узла Modbus-Read при успешном чтении
{
"payload": [2150],
"buffer": "",
"_msgid": "c3a4e5f6.123456"
}
Эти тесты покрывают основные аппаратные взаимодействия и гарантируют, что "железо" работает предсказуемо и готово к выполнению сложных сценариев.
---
Практика: Тестирование логики и сценариев в Node-RED
После того как мы убедились в исправности аппаратного уровня, наступает время для проверки "мозга" системы — логических сценариев, реализованных в среде Node-RED. Основная задача здесь — убедиться, что контроллер корректно реагирует на события и управляет оборудованием в соответствии с заложенными алгоритмами.
Имитация входных сигналов с помощью узла `Inject`
Самый мощный инструмент для тестирования логики — узел `Inject`. Он позволяет вручную инициировать поток, отправляя в него сообщение `msg` точно такой же структуры, какое пришло бы от реального датчика или кнопки. Это позволяет тестировать сценарии без необходимости физически бегать по объекту и нажимать на все выключатели.
Пример: Тестирование реакции на датчик движения.Предположим, сценарий включения света в коридоре должен срабатывать на сообщение от датчика движения, которое приходит из MQTT-топика `sensors/corridor/motion`.
{
"payload": {
"value": true,
"source": "motion-sensor-corridor-1",
"ts": 1678886400000,
"meta": {
"battery_level": 98
}
},
"topic": "telemetry/corridor/motion"
}
Тест-кейс для сложного сценария: "Я ушел"
ID: `LOGIC-SCN-AWAY-01` Наименование: Комплексная проверка сценария "Я ушел" / "Мастер-выключатель". Предусловия: Сценарий реализован в Node-RED и запускается по длительному (3 сек) нажатию на выключатель у входной двери. Шаги для воспроизведения:- Реле освещения гостиной, кухни и спальни выключаются (в `Debug` приходят сообщения с `payload: false` на соответствующие выходы).
- Реле розетки телевизора выключается.
- Реле неотключаемых групп (например, холодильник) остаются включенными.
- На выход, ведущий к отправке уведомления, приходит сообщение с текстом "Режим 'Никого нет дома' активирован".
- На телефон приходит соответствующее Push-уведомление.
Проверка энергонезависимости логики (Context Storage)
Критически важный тест — проверка сохранения состояний системы после перезагрузки контроллера. Если состояния хранятся только в оперативной памяти, то после сбоя питания система "забудет" все: какой сценарий был активен, какая уставка была у термостата и т.д.
> ℹ️ Информация: Платформа HI-Core позволяет настроить сохранение контекста (`context storage`) в энергонезависимую память (встроенный EEPROM, файловая система на SD-карте или база данных MySQL). Этот тест проверяет, что данная функция настроена и работает корректно.
ID: `LOGIC-PERSIST-01` Наименование: Проверка сохранения состояния конечного автомата (FSM) климат-контроля после перезагрузки. Предусловия: Логика климата реализована как конечный автомат, текущее состояние (`heating`, `cooling`, `off`) хранится в `flow.climate_state`. Шаги для воспроизведения:- После перезагрузки контроллера переменная `flow.climate_state` сохранила свое значение и равна `"heating"`.
- Система климат-контроля автоматически продолжила работу в режиме нагрева, не требуя повторной команды от пользователя.
Использование узлов `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` контроллера. Шаги для воспроизведения:- Все действия пользователя в интерфейсе приводят к предсказуемой и быстрой реакции оборудования (щелчок реле в течение <1 секунды).
- Обратная связь в интерфейсе iRidium обновляется корректно и своевременно, отражая реальное состояние оборудования.
- Система адекватно реагирует на повторные нажатия, без "залипаний" или неверной логики.
Тестирование на разных платформах
Современные системы визуализации, такие как iRidium, позволяют запускать один и тот же проект на разных устройствах. Крайне важно проверить работоспособность на всех целевых платформах, которые будет использовать заказчик.
- iOS (iPhone/iPad): Проверить, что верстка интерфейса не "поехала" на экранах с разным разрешением. Убедиться в корректной работе жестов (свайпы, долгое нажатие).
- Android (смартфоны/планшеты): Аналогично iOS, проверить верстку и отзывчивость. Обратить внимание на поведение при сворачивании и разворачивании приложения.
- Windows (стационарные панели): Проверить работу в полноэкранном режиме, реакцию на касания, если панель сенсорная.
Проверка кастомных элементов интерфейса
Особое внимание следует уделить сложным, нестандартным элементам, которые часто реализуются с помощью скриптов на стороне визуализации (в iRidium это JavaScript).
- Всплывающие окна (Pop-ups): Проверить, что pop-up для управления RGB-лентой корректно открывается, позволяет выбрать цвет, и этот цвет применяется к ленте. Проверить, что pop-up корректно закрывается.
- Динамические элементы: Если в интерфейсе есть виджет погоды или график энергопотребления, нужно убедиться, что они получают данные и корректно их отображают.
- Авторизация и профили: Если система поддерживает разные профили пользователей (администратор, гость), необходимо проверить переключение между ними и убедиться, что права доступа работают корректно (гость не может изменять важные настройки).
Сквозное тестирование — это "генеральная репетиция" перед сдачей объекта. Успешное прохождение всех E2E тест-кейсов дает высокую уверенность в том, что заказчик получит стабильную, удобную и надежную систему.
---
Регрессионное тестирование и финализация
В процессе пусконаладки и демонстрации системы заказчику практически неизбежно возникают правки. "А давайте сделаем, чтобы вот эта кнопка включала свет не на 100%, а на 70%", "Можем добавить в сценарий 'Я ушел' еще и закрытие штор?". Каждое такое изменение, даже самое незначительное, несет в себе риск — оно может нарушить то, что уже работало. Для борьбы с этим риском существует регрессионное тестирование.
📋 Ключевые понятия:
Регрессионное тестирование — это вид тестирования, направленный на обнаружение ошибок в уже протестированных участках системы после внесения изменений. Его главная цель — убедиться, что новые правки не "сломали" существующий функционал.Это не полное повторение всех тестов, а выборочная проверка наиболее важных и взаимосвязанных частей.
Определение "области влияния"
Перед тем как начать регресс-тест, важно мысленно оценить "область влияния" внесенного изменения.
- Изменение: В сценарий климат-контроля добавили учет данных с датчика открытия окна (если окно открыто — выключить отопление).
- Прямое влияние: Необходимо заново протестировать все режимы работы климат-контроля (нагрев, охлаждение, авто).
- Косвенное влияние: Сценарий "Я ушел" переводит климат в эконом-режим. Нужно проверить, не конфликтует ли новая логика с этим сценарием. А что если уйти, оставив окно открытым? Система должна отработать корректно.
- Вывод: После изменения логики климата нужно провести регрессионное тестирование не только самого климата, но и всех макро-сценариев, которые им управляют.
Обязательный набор регресс-тестов
Перед каждой демонстрацией системы заказчику или перед финальной сдачей после внесения правок, инженер обязан провести сокращенный регресс-тест "критической" функциональности.
Прохождение этого минимального набора регресс-тестов занимает 15-30 минут, но может сэкономить часы работы и сохранить репутацию в случае, если что-то пошло не так после "небольшой правки".
Финализация и подписание акта
После того как все функциональные, сквозные и регрессионные тесты пройдены, наступает финальный этап:
С этого момента заполненный и подписанный тест-план становится официальным документом, подтверждающим выполнение работ. Это формальное завершение одного из самых ответственных этапов проекта и основа для дальнейшего гарантийного обслуживания.
Что дальше?
В следующем уроке мы рассмотрим процесс создания исполнительной документации — финального пакета документов, который передается заказчику вместе с рабочей системой. Он включает в себя не только тест-план, но и схемы, инструкции и другие важные артефакты, необходимые для грамотной эксплуатации и обслуживания системы в будущем.