Как доказать, что система работает
Какие испытания отличают демонстрацию от работающей системы?
Прототип сопровождается повторяемой проверкой, которая позволяет отличить улучшение от регрессии и воспроизвести результат демонстрации.
Один удачный голосовой запрос показывает только один удачный запрос. Нам нужны повторяемые проверки обычных действий, нагрузочных пиков и отказов: перезагрузка, дубликат, устаревшее измерение, полный диск, повреждённое обновление.
Фиксируем не только среднее время, но и редкие задержки, ресурсные пределы и условия опыта. Для моделей отдельно проверяем перенос в новые ситуации и цену ошибок. Ноль ошибок в небольшой выборке не является доказательством нулевого риска.
Тесты делятся на расчётные, программные, аппаратные и сквозные. Модель подтверждает поведение на заданных предположениях. Unit-тест проверяет функцию. HIL соединяет реальное устройство и управляемый сценарий. Только совместное испытание показывает, что питание, радио, протокол, Core и физический выход работают вместе.
Измерение задержек#
На клиенте фиксируются начало команды и получение результата по одним монотонным часам. Это даёт полный RTT. На станции отдельно измеряются очередь, проверка, транзакция и передача. На устройстве — время до изменения выхода. Внешний логический анализатор может наблюдать диагностические GPIO обеих сторон, если они доступны в одном безопасном стенде.
Не следует выдавать RTT за одностороннюю задержку или измерять только быстрые успешные команды. В отчёт входят ошибки, тайм-ауты, p50/p95/p99 и худшие случаи. Выборка должна включать старт, длительную работу, массовое переподключение и конкурентные задачи.
Предлагаемые цели, а не полученные результаты#
| Проверка | Исходная цель стенда | Условия и оговорки |
|---|---|---|
| Команда → подтверждение постоянно доступного узла | p95 до 100 мс, p99 до 250 мс | Исправная локальная сеть, без механически медленного процесса |
| Внутренняя обработка Core | p95 до 5 мс без обязательной fsync | Отдельно измеряется надёжное принятие |
| Голос после конца фразы | Подобрать целевой порог по тестам моделей | Зависит от STT и endpointing; не обещается заранее |
| Нагрузка ядра | 100 устройств, 10 клиентов, 100 событий/с | Синтетический запас, не требование Wi-Fi к одному радио |
| Длительная устойчивость | Несколько суток непрерывного стенда | С повторениями сети, записи и голоса |
Это начальные инженерные ориентиры. Если плохая задержка вызвана неправильной семантикой подтверждения или неограниченной очередью, её не исправляют покупкой более быстрого CPU. Если ограничение честно физическое — например, длительное интегрирование датчика, — меняется профиль измерения, а не только код.
Матрица отказов#
| Воздействие | Ожидаемое поведение | Что фиксируется |
|---|---|---|
| Интернет выключен | Локальные команды и правила работают | Нет внешних обязательных запросов |
| Роутер выключен | Кнопка и локальная безопасность работают | Время восстановления связи |
| Перезапуск узла | Новый boot_id, корректный snapshot | Нет ложного повторного действия |
| Потеря ответа | UNKNOWN или последующая сверка | Тот же command_id при повторе |
| Датчик завис | Канал недоступен, другие живы | Тайм-аут и восстановление драйвера |
| Диск почти заполнен | Сокращается необязательная история | Критичная конфигурация сохраняется |
| Speech-worker убит | Управление не останавливается | Перезапуск без утечки ресурсов |
| Старый сертификат / чужой ключ | Отказ с понятной причиной | Нет fallback на небезопасный режим |
Для сетевого стенда Linux netem позволяет вводить задержки, потери, дублирование и изменение порядка там, где это применимо к тестируемому пути. Он не заменяет реальный радиоэфир, но делает часть отказов воспроизводимой. [85]
Парсеры, конкурентность и свойства#
Для KQIP нужны fuzz-тесты на длины, вложенность, неизвестные поля и повреждённые кадры. Cargo-fuzz помогает запускать такие испытания. Для небольших конкурентных примитивов Loom позволяет исследовать разные варианты выполнения. Эти инструменты находят классы ошибок, но не являются сертификатом отсутствия уязвимостей. [95][86]
Проверяются последовательности, а не только одиночный set: известный ID не меняет выход после ручного вмешательства; срок запрещает новое действие, но не чтение истории; старый snapshot не заменяет новый; UNKNOWN не равен EMPTY; автоматизация не нарушает ManualOverride. Каждый успешный counterexample превращается в постоянный регрессионный тест.
Электрические измерения#
Сначала измеряются питание и сигналы, затем сетевое поведение. Для реле проверяются стартовый импульс, ток катушки, выброс на ключе и контактная операция. Для I²C — уровни, фронты и ошибки при подключении второго сенсора. Для UART — правильная скорость, framing и реакция на неполный кадр.
Для датчиков сохраняются raw и опорные условия. Для вентиляции — температура комнаты и реальные обороты. Тест с грязным фильтром не должен создавать опасную пылевую среду; используется контролируемое изменение сопротивления под наблюдением.
Реальные пользователи и эксплуатация#
Второй человек подключает узел и выполняет восстановление по инструкции. Вопросы и места остановки записываются, а не компенсируются устной подсказкой автора. Через несколько дней проверяется, удобно ли увидеть причину включения и отключить правило, которое мешает работе.
Минимальный пакет результата#
Для каждого теста сохранить commit, hardware_rev, конфигурацию, исходные данные, критерий, результат и ссылку на лог. Снимок экрана с надписью «успешно» без условий не является достаточным инженерным доказательством.
Полезность управления оценивается по результату в комнате. Качество текста и точность модели измеряются отдельно и связываются с физическим результатом через испытание всего контура.
Три сравнения#
Сначала проверяем отдельный компонент: ошибку температуры, распознавание фразы, качество оценки присутствия. Затем проверяем контур: достижение цели, задержку, число переключений, соблюдение ручного режима. Наконец — эксплуатацию: восстановление, потерю канала, ресурсный пик и перенос размещения.
Для каждого AI-кандидата есть разумный не-AI эталон. Если классификатор выигрывает среднюю точность, но чаще гасит свет при неподвижном человеке, он не проходит допуск по выбранной цене ошибки. Низкая ошибка одношагового прогноза также не гарантирует хорошую длинную траекторию — это различие существенно для идентификации моделей управления. [111]
Матрица обязательных эпизодов#
| Условие | Проверяемое поведение |
|---|---|
| Неподвижный человек | Нет вывода о пустоте только по отсутствию PIR |
| Пустая комната, помеха | Ложные свидетельства не превращаются в безусловную уверенность |
| Датчик закрыт/перенесён | Модель не считает старую калибровку доказанно действующей |
| Потеря пакетов и часов | Пропуски и неопределённое время явно отражены |
| Ручной OFF во время плана | Старое предложение не отменяет ручное действие |
| Обрыв нагрузки | Подтверждение выхода не объявляет физическую цель достигнутой |
| AI-worker завис | Базовый контроль и доступная локальная кнопка сохраняются |
| Модель обновлена/откачена | Восстанавливается совместимый комплект данных и преобразований |
Вероятности и покрытие#
Вероятностный прогноз оцениваем и по точности, и по покрытию интервалов. Не проверяем только средний показатель по смеси лёгких и трудных режимов. Отдельно смотрим на перенос, пропуски и смену датчика.
Адаптивные conformal-методы исследуют поддержание покрытия при изменении распределения. [129] Их статистический смысл зависит от постановки и не является гарантией безопасности каждого отдельного физического действия. Для опасного последствия недостаточно поместить рядом с моделью слово «калиброванная».
Ноль ошибок — не нулевой риск#
При условии независимых одинаково распределённых испытаний и нуле ошибок в попытках односторонняя 95-процентная верхняя граница вероятности ошибки равна . Для это около 0,99%. Это расчётная иллюстрация: соседние секунды одной записи не дают 300 независимых эпизодов.
Поэтому фиксируем объём и разнообразие тестов, а не только красивый процент. Для проекта на раннем этапе важнее открытое описание ещё не испытанных режимов, чем псевдоточная оценка «надёжность 99,999%».
Инструменты испытания#
Начальный симулятор света работает без тяжёлых зависимостей. Для дальнейших тепловых процессов можно изучить FMI для обмена моделями и BOPTEST для сопоставления контроллеров на моделях зданий. [139] [140] Перенос такой симуляции в свой кабинет требует сопоставления измерений и параметров.
Property-based тесты проверяют инварианты контрактов; fuzzing — парсеры и границы ресурсов; повтор журналов — последовательности отказов. Аппаратный стенд добавляет питание, электрические уровни и физическую нагрузку. Назначение этих уровней различается: успешный fuzzing не подтверждает, что реле подключено правильно.
Перед допуском модели проверяют цену ошибок, отказ от решения и устойчивость замкнутого контура. Средний результат benchmark дополняет эти проверки, но не определяет допуск самостоятельно.
Результат, который можно повторить#
К каждому испытанию прикладываются конфигурация, версии, исходные данные, последовательность действий и критерий успеха. Для оборудования добавляются ревизии плат, схема соединений и условия среды; для моделей — хеш артефакта, разбиение эпизодов и способ исполнения.
Так неудача становится полезной. Вместо «иногда выключается свет» получается воспроизводимая история: при таком состоянии, такой очереди и таком обрыве старая команда прошла проверку. Исправление сопровождается тестом на эту историю и проверкой, что обычный сценарий не изменился неожиданно.
Измерительные границы и стартовые цели#
| Проверка | Начальная цель / выборка | Что не следует из PASS |
|---|---|---|
| Команда доступному узлу | 1000 попыток на условие; p95 ≤100 мс, p99 ≤250 мс, все тайм-ауты учтены | Не доказывает скорость обнаружения входа |
| Физический вход → свет | Отдельная разметка момента входа, детектора и выхода | Нельзя вычесть часы двух плат без привязки |
| Долговечное ACCEPTED | Клиентский запрос → commit → ответ, включая fsync | 5 мс чистого Core не заменяют эту метрику |
| Soak | 72 ч; 0 необъяснённых reboot; нет монотонного роста FD/очередей | Не доказывает многолетнюю надёжность |
| Потеря питания / MCU | 50 управляемых циклов на тестовом стенде, затем анализ reset и выхода | Не подтверждает все источники и партии |
| RU/EN push-to-talk | 300–500 отдельных фраз на язык; 500 негативов; отдельный тестовый набор | Нельзя объявить нулевую вероятность ошибки |
| Тепло / радио | 2 ч после установления; закрытый корпус, заданная комната и Wi-Fi | RSSI сам по себе не является критерием качества |
p99 на тысяче попыток опирается примерно на десять крайних случаев и требует интервала неопределённости, а не только красивой цифры. Ошибки, отмены и тайм-ауты входят в знаменатель. Если не было ни одного ложного действия на 500 независимых негативах, верхняя односторонняя 95% граница всё ещё около 0,6%. Коррелированные записи уменьшают информативность числа опытов.
Точность температуры сравнивается с эталоном известной неопределённости в нескольких установившихся точках; цель ±0,3 °C относится только к согласованному измерению при достаточном эталоне, не к любой точке комнаты. Присутствие проверяется неподвижным сидением 30 минут, помехами и потерей каналов. Для PIR-only ожидаемый результат — отсутствие необоснованного OFF.
Регрессии, без которых E0 не получает исполнительный допуск#
Обязательны: A/потеря ACK/кнопка/повтор; тот же ID с другим телом; повтор после вытеснения кэша; reboot между GPIO и результатом; первая доставка после срока; suspend H0 на 10 минут; UTC ±1 год; новый план при MANUAL_HOLD; поздний ACK после OFF; старый backup после переноса; отзыв при открытой сессии; диск заполнен; AI-worker завис; радар пропал. Каждый опыт сохраняет трассу и итоговое состояние, а не только PASS.