Программирование для встроенных систем - статьи

       

Тестовые сценарии для компонентов


Особенности разработки тестовых сценариев UniTesK для TinyOS вытекают из уже упоминавшихся особенностей TinyOS и nesC:

  • разделение исполнения на синхронное и асинхронное;
  • взаимодействие по нескольким интерфейсам;
  • наличие расщеплённых операций;
  • наличие взаимодействия с аппаратурой.

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

Поскольку для тестирования представляет интерес проверка поведения целевого компонента при различных ответах окружения, в тестовом сценарии необходимо уметь перебирать ответы окружения. Наиболее естественно для этой задачи подходит использование в сценарных методах UniTesK итераторов и “stable”-переменных. На рисунке 7 схематично изображён сценарный метод, реализующий предложенный приём.bool scenario test_with_stubs() { iterate( /* перебор аргументов запроса */ ){ iterate( /* перебор ответов окружения */ ) { /* передаём тестовому агенту ответы окружения */ setup_env( ... ); /* Вызываем целевую операцию */ call_target_operation( /* аргументы */ ); } } return true; }

Рисунок 7. Пример перебора параметров запроса и ответов окружения

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

Тестирование асинхронного кода

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


Для реализации управляемого прерывания исполнения целевой процедуры мы предлагаем следующее:

  1. Инструментировать код целевого метода: при инструментировании в код внедряются заглушки; когда исполнение доходит до заглушки, исполнение целевой функции может быть прервано.


  2. В тестовый сценарий задаётся, в каких заглушках целевая функция будет прервана при прогоне теста, и какие функции прервут исполнение.


Во время написания статьи в симуляторе TinyOS прерывание исполнения не поддерживалось. Предложенный подход к симуляции асинхронного исполнения функций может позволить протестировать поведение функции при прерываниях даже в условиях фактически непрерываемого исполнения.

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

Оценка затрат ресурсов на тестирование асинхронного поведения при помощи инструментирования кода:
  • дополнительный код: число вставок * размер вставки + размер диспетчера (здесь диспетчер означает компонент, который эмулирует асинхронное поведение); размер вставки — несколько инструкций, размер диспетчера до 1 Кб;


  • расходы на данные: число вставок * размер даных вставки; размер данных для отдельной вставки можно оценить как несколько байт на отдельную вставку.


Как показывают оценки, предложенный подход к тестированию асинхронного поведения возможно реализовать на типовых устройствах для TinyOS.

Предложенный подход к тестированию асинхронного выполнения ПО пока не применялся на практике.


Содержание раздела