Тестирование систем с асинхронным интерфейсом на платформе языка C
Процесс тестирования систем с асинхронным интерфейсом при помощи набора инструментов CTesK максимально унифицирован с процессом тестирования синхронных систем. Тестирование асинхронных систем также разбивается на три этапа, инструментальная поддержка которых построена по аналогичным принципам.
На этапе разработки тестового набора осуществляется проектирование и разработка автоматизированного тестового набора на основе унифицированной архитектуры асинхронного теста. Эта архитектура предоставляет базовые решения, в рамках которых происходит построение тестового набора для каждой конкретной целевой системы.
Первым шагом при разработке тестового набора для системы с асинхронным интерфейсом является выделение набора интерфейсных операций. Интерфейсные операции представляют собой атомарные взаимодействия с целевой системой. Для асинхронных систем такие взаимодействия разделяются на два вида: взаимодействия, инициируемые окружением целевой системы, и взаимодействия, инициируемые самой целевой системой. Анализ требований к целевой системе, ее документации и других документов с целью выделения набора интерфейсных операций и их классификации является существенно неформальным процессом и поэтому его автоматизация не осуществляется.
На втором шаге разработки тестового набора происходит формализация требований к целевой системе посредством построения асинхронной модели требований. Описание модели требований выполняется в виде предусловий и постусловий интерфейсных операций, выделенных на предыдущем шаге. В качестве нотации для записи предусловий и постусловий используются спецификационные функции SEC. Но так как спецификационные функции предназначены для описания требований к взаимодействиям, инициируемым окружением целевой системы, то для тестирования систем с асинхронным интерфейсом в спецификационное расширение языка C добавлен дополнительный вид функций, называемых функциями-отложенными реакциями.
Функции-отложенные реакции имеют очень много общего со спецификационными функциями.
Зависимости между отдельными взаимодействиями задаются при помощи каналов и временных меток. Дальнейшее построение асинхронной модели поведения осуществляется регистратором взаимодействий, реализованном в виде библиотечного компонента тестовой системы.
Процесс регистрации взаимодействий различается в зависимости от того, кто является инициатором этого взаимодействия: целевая система или ее окружение. Если инициатором взаимодействия является окружение, а во время тестирования - это тестовая система, то взаимодействие происходит по следующей схеме. Тестовая система вызывает спецификационную функцию, которая, в свою очередь, вызывает связанную с ней медиаторную функцию, а медиаторная функция уже выполняет необходимые действия для организации взаимодействия. После завершения взаимодействия оно автоматически регистрируется без специальных указаний со стороны разработчика тестового набора. При этом разработчик может полностью управлять процессом регистрации: он может указать, к какому каналу отнести текущее взаимодействие, какую временную метку ему присвоить или вообще отключить автоматическую регистрацию.
В случае, когда инициатором взаимодействия является целевая система, механизм посредством которого осуществляется взаимодействие, зависит от особенностей ее реализации. Только разработчик теста, имеющий информацию об этих особенностях, может указать тестовой системе, какие взаимодействия, инициированные целевой системой, имели место в процессе тестирования. Компонент, реализующий данную функциональность, называется в унифицированной архитектуре асинхронного теста кетчером. Реализация кетчера разрабатывается для каждой целевой системы индивидуально. Кетчер никак не выделяется синтаксически и представляет собой обычный код на языке C, использующий для регистрации взаимодействий одну из функций, принадлежащих интерфейсу регистратора взаимодействий. Канал и временная метка каждого взаимодействия указываются явно при его регистрации.
Еще одним компонентом унифицированной архитектуры асинхронного теста, разрабатываемым на третьем шаге, является медиатор состояния, который определяет правила обновления модельного состояния.
В случае тестирования асинхронных систем этот шаг практически ничем не отличается от синхронного случая. Асинхронные метрики покрытия определяются так же, как и синхронные: посредством специальных именованных блоков в теле спецификационных функций.
На пятом шаге разрабатываются тестовые сценарии. Чтобы определить тестовый сценарий в SEC необходимо указать механизм построения тестового сценария и исходные данные, необходимые для этого механизма. Для систем с синхронным интерфейсом в системе тестирования CTesK реализован единственный механизм построения тестовых сценариев - механизм dfsm. В качестве исходных данных механизма dfsm выступают
- функция инициализации тестового сценария;
- функция завершения тестового сценария;
- функция вычисления вершины графа сценария;
- набор сценарных функций, задающих множество дуг графа сценария.
Для поддержки асинхронного стационарного тестирования в набор исходных данных для механизма dfsm были добавлены три дополнительных элемента:
- функция сохранения модельного состояния;
- функция восстановления модельного состояния;
- функция проверки стационарности текущего модельного состояния.
Назначение всех прежних элементов осталось без изменений, поэтому разработка асинхронных тестовых сценариев не вызывает проблем у пользователей, знакомых с разработкой синхронных тестовых сценариев. Единственное существенное изменение коснулось семантики вызова спецификационных функций: если при синхронном тестировании такой вызов ведет к немедленному обновлению модельного состояния, синхронизирующем его с состоянием реализации, то при асинхронном тестировании модельное состояние остается неизменным вплоть до завершения очередного цикла работы сценарной функции.
Дополнительные исходные данные представляют собой обычные функции языка C. Функция сохранения модельного состояния читает значения переменных модельного состояния и сохраняет их в объекте спецификационного типа, возвращаемого из функции. Функция восстановления модельного состояния получает объект спецификационного типа, созданный ранее функцией сохранения, и восстанавливает значения переменных модельного состояния такими, какими они были на момент вызова функции сохранения.
