Автор: Ренато Руджеро (Renato Ruggiero)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование программного обеспечения как можно раньше в цикле разработки – это широко признанная лучшая практика: чем раньше обнаружен дефект, тем дешевле его исправить. В этом заключается суть подхода со сдвигом влево (shift-left).

Но когда речь идёт о встроенных системах, таких как системы, используемые в промышленности, Интернете вещей (IoT) или автомобильных приложениях, слово «рано» приобретает особое значение. Представьте, что вы можете тестировать программное обеспечение вашего электронного блока управления (ECU) сразу после того, как устройство становится доступным, даже если среда, с которой оно будет взаимодействовать, например автомобиль, производственная линия или облачный сервис, ещё не готова.

Именно здесь на помощь приходит тестирование hardware-in-the-loop (HIL). HIL-тестирование — это метод тестирования в реальном времени, при котором встроенное программное обеспечение работает на целевом аппаратном обеспечении и взаимодействует с имитируемой средой, воспроизводящей реальные сигналы и поведение. Это позволяет выполнять валидацию на уровне системы ещё до появления физических прототипов.

Понимание HIL-тестирования

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

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

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

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

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

Преимущества HIL-тестирования

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

HIL-тестирование не только способствует раннему обнаружению расхождений на уровне системы, но и хорошо сочетается с практиками непрерывной интеграции. Можно ежедневно запускать регрессионные тесты, оценивающие влияние последних изменений кода. Большинство современных HIL-платформ, коммерческих или основанных на компонентах с открытым исходным кодом, можно эффективно интегрировать с популярными решениями CI / CD.

Навыки, лежащие в основе автоматизации тестирования, разработки регрессионных тестов и анализа сбоев, остаются одинаковыми в разных областях тестирования. Независимо от того, запускаете ли вы тесты против API или HIL-системы, вы всё равно задаёте вопрос: «Что может пойти не так?» Вы разрабатываете продуманные тесты, интерпретируете сбои и переносите качество вверх по течению. В некотором смысле HIL-конфигурации делают на уровне системы то же, что моки и стабы делают на уровне модулей: они имитируют компоненты реального мира, чтобы тестировать поведение устройства в контролируемой среде. Но вместо имитации функции или вызова сервиса вы имитируете реальные сигналы, физические интерфейсы и взаимодействие всей системы.

Стоимость HIL-тестирования и способы её снижения

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

Так как же предотвратить превращение одной HIL-системы в узкое место, ограничивающее возможности тестирования всей команды?

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

Эти виртуальные среды могут имитировать само встроенное устройство (иногда это называют software-in-the-loop, или SIL). В зависимости от потребностей тестирования они могут включать виртуализированный полный программный стек: операционную систему, интерфейсы controller area network (CAN) или Ethernet, а также цифровые и аналоговые входы и выходы. Симуляции передают сигналы в виртуализированный ECU и от него, позволяя системе проверять, как она ведёт себя в реалистичных условиях, и всё это со стандартного ноутбука.

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

Инструменты с открытым исходным кодом делают HIL-тестирование широко доступным

Рост сообществ, работающих над демократизацией HIL-тестирования с помощью инструментов и фреймворков с открытым исходным кодом – очень перспективная тенденция. Эти экосистемы быстро расширяются, предоставляя экономичные платформы, которые поддерживают автоматизацию тестирования и практики CI / CD, а также позволяют взаимодействовать с реальным аппаратным обеспечением.

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

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

Подводя итог

Вот основные моменты, которые мы рассмотрели:

• HIL-тестирование позволяет выполнять валидацию на уровне системы в имитируемой среде ещё до того, как станут доступны такие компоненты реального мира, как автомобили, облачные сервисы или промышленное оборудование
• Вы можете безопасным и воспроизводимым способом имитировать граничные случаи, отказы и опасные условия, поддерживая инъекцию отказов и проверку безопасности
• Гибридная стратегия тестирования, сочетающая HIL и виртуализированные решения, помогает оптимизировать ограниченные ресурсы и уменьшить узкие места в тестировании
• Современные HIL-системы могут интегрироваться в конвейеры CI / CD, делая ежедневное регрессионное тестирование и автоматизацию возможными даже для встроенных систем
• Инструменты HIL-тестирования с открытым исходным кодом набирают популярность, делая HIL-тестирование доступным для команд и организаций разного размера и с разными бюджетами

Если вы работаете со встроенным программным обеспечением, будь то в промышленной автоматизации, IoT или любой другой области, стоит пересмотреть, какое место тестирование на уровне системы занимает в вашей стратегии Agile-разработки. Начните с оценки того, какие части вашего текущего процесса можно перенести на более ранний этап цикла и могут ли HIL или виртуализированные среды помочь вам обнаруживать проблемы до того, как они попадут в реальный мир.

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

Обсудить в форуме