Написать статью меня побудило прочтение статьи с похожим названием, недавнее посещение Embedded World и опыт разработки в этой области.
Почему-то, когда говорят о тестировании применительно к встраиваемым системам, почти всегда имеют в виду платформу, позволяющую «отрезать» эту самую встраиваемую систему, чтобы протестировать написанный код «независимо от аппаратной платформы».
Конечно, подход имеет свое место, и с его помощью можно многое проверить и найти, но.
Вот пример простой системы: микроконтроллер и инфракрасный датчик температуры, подключенный к нему по I2C. Как мы будем тестировать? Что здесь можно виртуализировать, чтобы тест не потерял всякий смысл? Что, если весь код по сути сводится к инициализации периферийных устройств контроллера I2C и реализации протокола связи с самим датчиком? А также блокировка доступа к ресурсу в случае многозадачной среды.
На мой взгляд, для нормального тестирования нужно иметь возможность считать значение температуры с датчика, и каким-то образом получить данные извне о реальной температуре окружающей среды и/или объекта, на который указывает датчик.
И сравните их.
Те.
для обычного «сквозного» тестирования, на мой взгляд, без реальной платы с контроллером и датчиком, а также «внешнего» интерфейса связи не обойтись.
В самом крайнем случае, мы Можно предположить, что температура в помещении, где работают люди, будет находиться в пределах 18-30 градусов, и проверить полученное значение, попадает ли оно в этот интервал.
Но если вам нужно проверить точность, то без тепловизионной камеры, увы, не обойтись.
Пример из жизни: нам как-то приходилось работать с микросхемой ADG2128 — коммутационной матрицей 8х12, управляемой по I2C. А у чипа, как оказалось, был недокументированный глюк — его I2C-часть «будила» чип не только тогда, когда он получал свой адрес в начале пакета, но и всякий раз, когда его адрес обнаруживался на шине.
Даже в середине выступления.
I2C предназначен для подключения нескольких устройств.
И вот - на этой же шине висит связь с другим устройством, и в середине общения проскакивает байт с адресом этого ADG, он просыпается и начинает выдавать свои данные на шину.
В общем, это был интересный баг, и его исправление тоже было костылем весьма своеобразным, хотя в конце концов оно работает. Итак, как же можно было «отловить» такой или подобный глюк с помощью подхода тестирования без наличия самой встроенной системы с «живым» чипом на ней? Еще пара примеров из жизни встраиваемых систем: после добавления очередной функции у контроллера заканчивается память.
Добавление новой функциональности приводит к гонкам или тупикам.
Альтернативно, к аналогичным последствиям приводят неверные, но все же возможные в реальности действия пользователя из серии «подключиться к устройству не так/не так/не в том месте/не в то время».
Или отправьте на устройство неправильную конфигурацию.
Либо само устройство при определенной конфигурации начнет потреблять ток больше, чем может обеспечить USB. Либо при подключении устройства к ноутбуку, работающему от аккумулятора, в розетке не будет связи между «землей» и «землей» — и измерение окажется поразительно неточным из-за ошибки в спроектированной схеме.
.
На мой взгляд, нормальное, "полноценное" тестирование будет возможно только в виде разработки другого устройства, настоящего, "аппаратного", которое будет эмулировать все необходимые эффекты на нашем тестируемом устройстве, плюс наш тестовый фреймворк должен иметь возможность управлять нашим тестируемым устройством и устройством моделирования ударов.
Когда мы разрабатывали DSLAM (телекоммуникационное устройство с широким Ethernet на одном конце и 32/64/128 DSL-модемами на другом), испытательный стенд выглядел примерно так: 64 модема, подключенные к 64 портам генератора трафика L2/L3. и Uplink подключен к другому порту.
Тестовый скрипт настроил DSLAM, генераторы трафика, запустил трафик и проверил результаты.
Когда мы разрабатывали многоканальный прикладной осциллограф, испытательное устройство выглядело так: коробка с 4 независимыми выходами, подключенными к входам тестируемого осциллографа, каждый выход мог имитировать все датчики, поддерживаемые осциллографом (например, датчик тока).
зажим или датчик давления), а также выводить значения, которые бы выдавал реальный датчик.
Сценарий тестирования – задайте на выходах комбинацию датчиков и сгенерированные значения, настройте тестируемое устройство (задайте датчик, диапазон и т. д.), измерьте их с тестируемым устройством и сравните со сгенерированными.
Все это было интегрировано в CI-систему — текущий билд был собран и загружен в устройство, после чего началось описанное выше тестирование.
Системы использовались как на этапе разработки для регрессионного тестирования, так и на этапе производства для тестирования нового устройства перед отправкой его в эксплуатацию.
Несомненно, такой подход дорогой — но при длительном и сложном многофункциональном проекте альтернативы ему, мне кажется, нет. А без него — прямая дорога к «смертельному циклу тестирования» (Увеличение необходимого количества «ручных» тестов по мере добавления новых функций, как следствие — даже самое простое изменение в коде невозможно внести быстро: 1 час на изменение/исправление ошибок и неделя ручного регрессионного тестирования, ага.
Про неделю – это не шутка, увы.
) Сейчас делаем саму систему тестирования в виде более-менее универсальной модульной системы, посмотрим, понадобится ли она еще кому-нибудь.
Теги: #встроенные системы #тестирование #программирование #программирование микроконтроллеров #тестирование ИТ-систем
-
Использование Gps В Ubuntu
19 Oct, 24 -
Первая Мышь, «Оптимизированная Для Mmog»
19 Oct, 24
