Ведение журнала тестирования

Урок 4 · Монтаж и пусконаладка контроллера · 10 мин · theory

Введение: Зачем вести журнал тестирования?

В профессиональной деятельности инженера по автоматизации действует непреложное правило: «Не записано — не сделано». Это означает, что любая выполненная работа, не имеющая документального подтверждения, считается невыполненной. Журнал тестирования (или Test Log) — это ключевой документ, который служит именно таким подтверждением для всех этапов пусконаладки системы. Он превращает хаотичную проверку функций в структурированный и воспроизводимый процесс.

> 💡 Подсказка: Начните вести журнал с самого первого теста. Это формирует полезную привычку и экономит время в будущем, когда не придется вспоминать, что и когда было протестировано.

Рассмотрим основные роли, которые выполняет журнал тестирования в жизненном цикле проекта:

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

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

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

Повышение качества и надежности. Сам процесс документирования заставляет инженера более вдумчиво подходить к тестированию. Вместо беглого "нажал кнопку — свет загорелся", вы должны четко описать ожидаемый результат (например, "Реле RL-03 щелкнуло, индикатор на контроллере загорелся, напряжение 230В появилось на клемме, лампа в коридоре включилась в течение 0.5с"). Такой подход позволяет выявлять не только полные отказы, но и неочевидные проблемы: медленное срабатывание, ложные сигналы, некорректную обратную связь. Систематическая фиксация и исправление таких мелких дефектов кардинально повышает итоговую надежность и комфорт использования системы умного дома.

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

---

Структура и обязательные поля журнала

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

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

> * Тестовый случай (Test Case): Формализованное описание шагов для проверки определенной функции или сценария, включая начальные условия, действия и ожидаемый результат.

> * Статус Pass/Fail: Бинарная оценка результата теста. 'Pass' (пройден) — фактический результат совпал с ожидаемым. 'Fail' (провален) — есть расхождения.

Ниже представлена таблица с описанием обязательных полей для каждой записи в журнале тестирования.

| Поле | Описание | Пример |

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

| ID Теста | Уникальный идентификатор тестового случая. Должен быть простым и последовательным. Обычно связан с планом тестирования, который мы рассматривали ранее. | `ST-001` (Smoke Test 1), `FT-LIGHT-012` (Functional Test, Lighting, 12) |

| Дата/Время | Точная дата и время проведения теста. Критически важно для отслеживания хронологии событий и анализа логов. | `2023-10-27 14:35` |

| Исполнитель | Имя или инициалы инженера, проводившего тест. Необходимо для координации в команде и понимания, к кому обращаться с вопросами. | `А. Иванов` |

| Описание | Краткое, но емкое описание проверяемой функции. Что именно мы тестируем? Какое устройство или сценарий? | `Сценарий 'Кнопка-Свет' для основного освещения в гостиной.` |

| Шаги для воспр. | (Опционально, но рекомендуется) Краткая последовательность действий для выполнения теста. | `1. Нажать кнопку SW-01. 2. Проверить включение света. 3. Нажать повторно.` |

| Ожидаемый результат | Самое важное поле. Конкретное, измеримое и недвусмысленное описание того, что должно произойти, если система работает корректно. | `При нажатии SW-01 реле RL-05 замыкается, свет включается. При повторном — выключается.` |

| Фактический результат | Честное и объективное описание того, что произошло на самом деле во время теста. | `Свет включился, но повторное нажатие не привело к выключению.` |

| Статус | Финальная оценка теста. Обычно используется выпадающий список: `Pass`, `Fail`, `Blocked` (не может быть выполнен), `Not Run` (не запускался). | `Fail` |

| Комментарии / ID | Поле для дополнительной информации. Для проваленных тестов здесь указывается причина, гипотеза, ссылка на ID сценария в Node-RED (`FLOW-AUTO-LIGHT-012`), ID тикета в баг-трекере или диагностические логи. | `Тест провален. Сценарий FLOW-LIGHT-012 отрабатывает только на включение. Проверить логику триггера.` |

Как правильно формулировать "Ожидаемый результат"

Это искусство, отличающее профессионала. Формулировка должна быть проверяемой.

❌ Плохо: "Свет должен включиться".
✅ Хорошо: "При получении MQTT-сообщения `{"command": "ON"}` в топик `office/light1/set`, реле `RL-01` замыкается, на его NO-клемме появляется напряжение ~230В, и узел `Status` в Node-RED отображает статус 'ON'."

Примеры "хороших" и "плохих" комментариев

При провале теста комментарий — это первый шаг к его исправлению.

❌ Плохо: "Не работает." (Неинформативно, бесполезно).
❌ Плохо: "Опять эта проблема со светом." (Эмоционально, но неконструктивно).
✅ Хорошо: "`Fail`. Датчик `MOTION-HALL-01` отправляет сообщение, `debug` показывает `msg.payload.value: true`. Однако сценарий `SCN-LIGHT-034` не активирует реле `RL-08`. Подозрение на неверную настройку `msg.topic` на выходе из датчика. См. скриншот в папке `Project/Logs/2023-10-27/`."

Правильно структурированный журнал становится не просто списком проверок, а полноценной базой знаний по проекту.

---

Практика: Создание шаблона журнала в Google Sheets / Excel

Электронные таблицы, такие как Google Sheets или Microsoft Excel, являются идеальным инструменком для ведения журнала тестирования. Они доступны, просты в использовании и предоставляют все необходимые функции. Google Sheets предпочтительнее для командной работы благодаря простоте совместного доступа.

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

Выполним пошаговую настройку шаблона.

Создание таблицы и столбцов:

* Откройте Google Sheets (sheets.google.com) и создайте новую таблицу.

* Дайте ей осмысленное имя, например, `Журнал тестирования - Проект "Коттедж на Лесной"`

* В первой строке создайте заголовки для столбцов, которые мы обсуждали в предыдущем разделе: `ID Теста`, `Дата/Время`, `Исполнитель`, `Описание`, `Шаги для воспр.`, `Ожидаемый результат`, `Фактический результат`, `Статус`, `Комментарии / ID`.

* Заморозьте первую строку, чтобы заголовки всегда были видны при прокрутке: `Вид` -> `Закрепить` -> `1 строку`.

Использование выпадающих списков для стандартизации:

* Чтобы избежать опечаток и разночтений в статусах (`failed`, `провален`, `минус`), создадим стандартизированный список.

* Выделите столбец `H` (Статус), нажав на его заголовок.

* Перейдите в меню `Данные` -> `Настроить проверку данных`.

* В поле `Правила` выберите `Значение из диапазона`.

* В качестве диапазона укажите `Pass,Fail,Blocked,Not Run`. Обязательно выберите опцию `Показывать раскрывающийся список в ячейке`.

* Нажмите `Готово`. Теперь в каждой ячейке столбца "Статус" появится удобный выпадающий список.

Применение условного форматирования для наглядности:

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

* Выделите всю таблицу (Ctrl+A) или диапазон ячеек, где будут данные.

* Перейдите в меню `Формат` -> `Условное форматирование`.

* В появившейся панели справа нажмите `Добавить правило`.

* В разделе `Форматировать ячейки` выберите `Ваша формула` и введите `=$H2="Fail"`, где `H` - это буква вашего столбца "Статус", а `2` - первая строка с данными.

* В `Стиле форматирования` выберите заливку светло-красным цветом.

* Нажмите `Готово`.

* Аналогичным образом создайте еще одно правило для статуса `Pass` с формулой `=$H2="Pass"` и заливкой светло-зеленым цветом.

* Теперь строки с проваленными тестами будут автоматически подсвечиваться красным, а с успешными — зеленым.

Настройка общего доступа (для Google Sheets):

* Нажмите большую синюю кнопку `Настройки доступа` в правом верхнем углу.

* Введите email-адреса членов вашей команды.

* Присвойте им права `Редактор`, чтобы они могли добавлять и изменять записи.

* Скопируйте ссылку и отправьте ее команде. Теперь все инженеры на объекте могут работать с одним и тем же документом в реальном времени, даже с мобильных устройств.

Ваш шаблон готов. Сохраните пустую версию этого файла как `Шаблон_Журнала_Тестирования.xlsx` для использования в будущих проектах.

---

Пример: Логирование результатов smoke-теста 'Кнопка-Свет'

Рассмотрим, как заполнять созданный нами журнал на примере базового smoke-теста, который мы создавали в уроке `COURSE-03-M07-L02: Создание простого сценария: 'Кнопка-Свет'`.

Заполнение журнала для успешного теста

Сценарий: Вы настроили flow `FLOW-LIGHT-001`, который по нажатию настенного выключателя, подключенного к универсальному входу `UI-01`, включает реле `RL-01`, управляющее светом в прихожей.

Ваша запись в журнале будет выглядеть так:

Заполнение журнала для проваленного теста

Сценарий: Через некоторое время вы добавили в этот же flow логику диммирования по долгому нажатию. После этого вы повторно запускаете исходный smoke-тест и обнаруживаете проблему.

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

| `ST-001.1` | `2023-10-27 18:25` | `В. Петров` | Регрессионный тест: 'Кнопка-Свет' для прихожей. | При коротком нажатии выключателя `SW-ENTRANCE-01` (вход `UI-01`) реле `RL-01` замыкается, свет включается. | Свет не включился. Реле `RL-01` не изменило состояние. | `Fail` | Вероятно, регрессия после добавления логики диммирования в `FLOW-LIGHT-001`. `Debug` узел не показывает сообщения на выходе из `function` ноды-триггера. |

Как прикрепить диагностический лог

Ключ к быстрому решению проблемы — это качественная диагностическая информация. Предположим, вы поставили `debug` узел на выходе из узла, который обрабатывает нажатие кнопки, и получили следующий вывод в панели отладки Node-RED при проваленном тесте:

{
  "payload": 0,
  "topic": "input/ui-01",
  "_msgid": "a1b2c3d4.5e4f32",
  // ... другие свойства
}

Вы можете скопировать этот JSON и вставить его прямо в ячейку "Комментарии" (или в комментарий к ячейке в Google Sheets):

Комментарий: `Fail. Сценарий FLOW-LIGHT-001. Похоже, узел-триггер ожидает boolean 'true', а получает numeric '0' от узла входа. Лог msg объекта: {"payload": 0, "topic": "input/ui-01", ...}`

Такая запись мгновенно дает другому инженеру (или вам самим на следующее утро) точное понимание, где искать корень проблемы. Это экономит десятки минут, а иногда и часы на диагностику. Указание ID сценария (`FLOW-LIGHT-001`) позволяет сразу открыть нужный поток в Node-RED и приступить к исправлению.

---

Расширенное логирование: сбор диагностической информации

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

Настройка узла 'debug' для полного анализа

Стандартно узел `debug` выводит только `msg.payload`. Этого часто бывает мало, так как важная информация может содержаться в `msg.topic` или других свойствах объекта `msg`.

Дважды кликните по узлу `debug`, который вы хотите использовать для диагностики.

В поле `Вывод` (`Output`) измените значение с `msg.payload` на `полный объект msg` (`complete msg object`).

Нажмите `Готово` и `Развернуть`.

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

// Пример вывода полного объекта msg
{
    "payload": {
        "value": 22.5,
        "source": "temp-sensor-office-1",
        "ts": 1678886400000,
        "unit": "°C"
    },
    "topic": "telemetry/sensor/temperature",
    "qos": 1,
    "retain": false,
    "_msgid": "b9c8d7e6.f5a4b3"
}

Копирование пути к свойству

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

Найдите в панели отладки сообщение, которое хотите проанализировать.

Раскройте его до нужного вам свойства (например, `payload.value`).

Наведите курсор на имя свойства (`value`). Справа появятся несколько иконок.

Нажмите на иконку, похожую на ``, с всплывающей подсказкой `Скопировать путь`.

В ваш буфер обмена скопируется полный путь к этому свойству, например, `payload.value`. Это незаменимо при написании кода в узлах `function` или настройке узла `switch`, так как исключает опечатки.

Прикрепление артефактов к журналу

Иногда текста недостаточно. Скриншот потока Node-RED с подсвеченной проблемной зоной или график из дашборда могут сказать больше тысячи слов.

Для Google Sheets:

1. Сделайте скриншот.

2. Загрузите его на Google Drive в папку проекта.

3. Получите ссылку на файл.

4. Вставьте эту ссылку в ячейку "Комментарии" вашего журнала.

Текстовые логи: Длинные логи из `debug` или консоли лучше не вставлять напрямую в ячейку. Создайте текстовый файл (`error_ST-005.log`), поместите его в ту же папку на Google Drive и дайте ссылку на него.

Использование системных логов Linux

Некоторые проблемы происходят на более низком уровне, чем логика Node-RED. Например, отказ COM-порта для Modbus, проблемы с сетью или сбой самого сервиса Node-RED. В таких случаях на помощь приходит командная строка Linux контроллера.

> ℹ️ Информация: Доступ к командной строке контроллера HI осуществляется по протоколу SSH. Вам понадобится SSH-клиент (например, PuTTY для Windows или встроенный терминал в macOS/Linux).

Основной инструмент для просмотра системных логов — утилита `journalctl`.

Просмотр логов сервиса Node-RED в реальном времени: Эта команда покажет все, что Node-RED пишет в системный журнал, в момент происходящего. Идеально для отладки проблем с запуском или падением сервиса.

sudo journalctl -u nodered -f

* `-u nodered`: фильтровать логи только для сервиса `nodered`.

* `-f`: следовать за логом (`follow`), т.е. выводить новые записи по мере их появления.

Просмотр логов за определенный период: Если проблема произошла некоторое время назад, можно отфильтровать логи по времени.

# Показать логи за последние 10 минут sudo journalctl -u nodered --since "10 minutes ago" # Показать логи с конкретного времени sudo journalctl -u nodered --since "2023-10-27 18:20:00"

Поиск по логам: Если вы ищете конкретную ошибку, например, связанную с `modbus`.

sudo journalctl -u nodered | grep -i "modbus"

Фрагменты этих логов, содержащие ошибки (`ERROR`, `failed`, `timeout`), являются бесценной диагностической информацией, которую следует копировать и прикреплять к соответствующей записи `Fail` в вашем журнале тестирования.

---

Итоги и лучшие практики

Подведем итог. Ведение журнала тестирования — это не дополнительная нагрузка, а неотъемлемая часть профессионального подхода к пусконаладке систем автоматизации.

> 🔗 Связанный материал: Принципы, заложенные в этом уроке, напрямую связаны с разработкой Плана Smoke Test (`COURSE-03-M07-L04`), который определяет, что тестировать, в то время как журнал отвечает на вопрос, как это было протестировано.

Ключевые выводы и лучшие практики:

Журнал — это "живой" документ. Он создается в начале пусконаладочных работ и постоянно обновляется вплоть до момента сдачи объекта. Каждое изменение в системе, каждый новый тест или повторная проверка должны находить в нем отражение.
Постоянство и аккуратность — залог успеха. Самый лучший шаблон бесполезен, если его заполнять от случая к случаю. Выработайте привычку фиксировать результат сразу после проведения теста, пока детали свежи в памяти.
Журнал — основа для финальной отчетности. На базе заполненного журнала тестирования формируется Акт сдачи-приемки работ и "паспорт объекта" — итоговый документ, описывающий состав и проверенную функциональность системы, который передается заказчику.
Думайте о будущем. Подробные комментарии к `Fail` тестам сегодня — это сэкономленные часы работы завтра. Диагностическая информация, прикрепленная к записи, поможет быстро восстановить контекст проблемы даже спустя несколько недель.

Что дальше?

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

В будущих, более продвинутых курсах (уровня Advanced (automation) и Integrator (integration)), мы рассмотрим, как можно частично автоматизировать процесс тестирования. Например, создавать специальные потоки в Node-RED, которые будут автоматически прогонять тесты по расписанию, проверять отклики устройств и отправлять результаты в базу данных или Google Sheet через API, формируя отчет без участия человека. Но основа для этого — это понимание ручного процесса, которое вы получили сегодня.