Тестовые сценарии для компонентов
Особенности разработки тестовых сценариев UniTesK для TinyOS вытекают из уже упоминавшихся особенностей TinyOS и nesC:
- разделение исполнения на синхронное и асинхронное;
- взаимодействие по нескольким интерфейсам;
- наличие расщеплённых операций;
- наличие взаимодействия с аппаратурой.
Если целевой компонент не вызывает другие компоненты для обработки запроса, то разработка тестового сценария или сценарного метода для такой операции ничем не отличается от тестирования обычного метода в UniTesK. Если целевой компонент для выполнения запроса обращается к окружению, то для тестирования необходимо подготовить соответствующие заглушки, имитирующие ответы от окружения. Задача заглушек — передавать в тестируемый компонент различные значения изменяемых параметров и возвращаемых значений.
Поскольку для тестирования представляет интерес проверка поведения целевого компонента при различных ответах окружения, в тестовом сценарии необходимо уметь перебирать ответы окружения. Наиболее естественно для этой задачи подходит использование в сценарных методах UniTesK итераторов и “stable”-переменных. На рисунке 7 схематично изображён сценарный метод, реализующий предложенный приём.bool scenario test_with_stubs() { iterate( /* перебор аргументов запроса */ ){ iterate( /* перебор ответов окружения */ ) { /* передаём тестовому агенту ответы окружения */ setup_env( ... ); /* Вызываем целевую операцию */ call_target_operation( /* аргументы */ ); } } return true; }
Рисунок 7. Пример перебора параметров запроса и ответов окружения
Методы разработки тестовых сценариев для компонентов, взаимодействующих с аппаратурой, не отличаются от уже рассмотренных приёмов. Тестовый сценарий перебирает параметры запроса и значения, которые должна получить реализация от аппаратуры. Вопрос доставки значений аппаратуры выходит за рамки разработки тестового сценария, и будет рассмотрен в разделе про медиаторы.
Тестирование асинхронного кода
При тестировании асинхронного кода необходимо создавать тестовые ситуации, в которых выполнение целевой функции прерывается, причём для систематического тестирования необходимо, чтобы можно было управлять тем, в каком месте исполнение будет прервано.
Для реализации управляемого прерывания исполнения целевой процедуры мы предлагаем следующее:
- Инструментировать код целевого метода: при инструментировании в код внедряются заглушки; когда исполнение доходит до заглушки, исполнение целевой функции может быть прервано.
- В тестовый сценарий задаётся, в каких заглушках целевая функция будет прервана при прогоне теста, и какие функции прервут исполнение.
Во время написания статьи в симуляторе TinyOS прерывание исполнения не поддерживалось. Предложенный подход к симуляции асинхронного исполнения функций может позволить протестировать поведение функции при прерываниях даже в условиях фактически непрерываемого исполнения.
Как правило, асинхронное поведение в TinyOS наблюдается в функциях, которые вызываются из обработчиков прерываний. Для достоверного тестирования асинхронного поведения на аппаратуре необходимо удалить источники прерываний, в цепочке обработки которых встречается целевая функция. Вместо аппаратных прерываний необходимо организовать программные прерывания, что можно сделать аналогично симулятору — через инструментирование кода. В этом случае тестовый сценарий определяет, в каких точках исполнения целевой функции необходимо прерывать исполнение, и настраивает заглушки.
Оценка затрат ресурсов на тестирование асинхронного поведения при помощи инструментирования кода:
- дополнительный код: число вставок * размер вставки + размер диспетчера (здесь диспетчер означает компонент, который эмулирует асинхронное поведение); размер вставки — несколько инструкций, размер диспетчера до 1 Кб;
- расходы на данные: число вставок * размер даных вставки; размер данных для отдельной вставки можно оценить как несколько байт на отдельную вставку.
Как показывают оценки, предложенный подход к тестированию асинхронного поведения возможно реализовать на типовых устройствах для TinyOS.
Предложенный подход к тестированию асинхронного выполнения ПО пока не применялся на практике.
