Архитектура среды тестирования на основе моделей, построенная на базе компонентных технологий

Кулямин В. В.
Институт системного программирования РАН (ИСП РАН), Москва

Содержание

1. Введение

2. Тестирование на основе моделей и инструменты тестирования

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

Инструменты модульного тестирования

Инструменты тестирования на основе моделей

Итоги обзора существующих инструментов

3. Архитектурный каркас для тестирования на основе моделей

Виды компонентов и их интеграция

Реализация предложенного подхода

4. Пример построения теста

5. Заключение

Литература

Аннотация

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

1. Введение

Увеличение разнообразия и количества задач, возлагаемых в современном мире на вычислительные системы, приводит к постоянному росту их сложности и усложнению всех видов деятельности, связанных с их построением и сопровождением. На решение проблем, связанных с этим ростом сложности, нацелены активно развивающиеся в последние десятилетия компонентные технологии [1,2] построения как программных, так и аппаратных составляющих вычислительных систем.

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

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

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

• Сложившаяся практика неполного и неточного описания интерфейсов компонентов. Эти неточности и неполнота и приводят к возникновению множества трудноуловимых зависимостей между компонентами, проявляющихся при замене компонентов на их новые версии или на аналоги от других поставщиков. Дело в том, что полный интерфейс модуля, как он понимался в работах Парнаса [3], одного из основоположников модульного подхода к разработке ПО, должен задавать не только его синтаксическую структуру (имена реализуемых операций, типы их параметров и результатов, и соответствующие структуры данных), но и семантику (правила использования операций и ожидаемое в ответ поведение модуля). На практике же обычно ограничиваются только фиксацией синтаксиса, семантика описывается, да и то, чаще всего не полностью и не вполне однозначно, только для интерфейсов, входящих в системные библиотеки и имеющих достаточно долгую историю использования. С такими интерфейсами обычно связаны высокие риски и накладные расходы в случае несовместимости или некорректного взаимодействия компонентов, использующих их. Однако «менее рискованных» интерфейсов, для которых семантические требования не описываются совсем или фиксируются в виде одной фразы, указывающей их основную функциональность в нормальной ситуации, гораздо больше, и меньшие расходы, связанные с отдельными ошибками, в сумме дают очень значительную величину. В 2002 году годовые потери одной только экономики США от многочисленных ошибок в ПО были оценены в 60 миллиардов долларов [4].
• Трудности интеграции в технологические процессы разработки ПО средств верификации и тестирования на соответствие требованиям. Такие средства по большей части представлены в виде «монолитных» инструментов, реализующих большое число разнообразных функций, от оформления требований до создания отчетов о проведенном тестировании. Причем набор деятельностей, выполняемых в ходе контроля качества, связи между ними, а также поддерживаемые техники верификации и тестирования, определяются разработчиками инструмента и не могут быть изменены и расширены сколь-нибудь существенным образом. Более того, в последнее время многие компании, предоставляющие средства разработки ПО, предлагают интегрированные решения, охватывающие практически весь процесс разработки, причем включение в них посторонних, заранее не предусмотренных техник и средств невозможно, либо очень трудоемко. Вместе с тем, процессы разработки ПО в разных организациях сильно различаются, в связи с отличиями в создаваемых ими программах, в требованиях клиентов и способах взаимодействия с ними, в используемых бизнес-моделях и т.д. Поэтому все более востребованы инструменты разработки, имеющие модульную архитектуру, способные с минимальными накладными расходами интегрироваться с другими инструментами и включать модули, реализующие передовые, более эффективные техники выполнения отдельных видов деятельности по разработке ПО. Эти требования можно суммировать так: инструменты разработки сложных систем тоже должны быть компонентными и облегчать свое включение в разнообразные технологические цепочки. Среди средств верификации такими свойствами пока обладают лишь инструменты модульного тестирования (unit testing) [5], самым известным из которых является JUnit [6], модульных инструментов, поддерживающих более сложные виды верификации или тестирование на соответствие требованиям, практически нет.
• Отсутствие поддержки масштабного многократного использования возникающих в ходе контроля качества артефактов — тестов, верифицированных утверждений, моделей и пр. Эта проблема особенно важна именно для компонентных технологий, поскольку верификация одного компонента чаще всего имеет приемлемую стоимость, в ее ходе создаются многочисленные вспомогательные артефакты, а использовать их далее при проверке взаимодействующих компонентов или гораздо более дорогостоящем контроле качества систем, включающих проверенный компонент, уже не удается. Обеспечение многократного использования таких артефактов могло бы значительно снизить издержки верификации компонентного ПО.

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

• Предоставлять средства определения требуемых свойств отдельного компонента, включающих требования компонента к его окружению и его ответные обязательства, предоставляемые им службы и их характеристики.
• Давать возможность использовать те же средства для фиксации необходимых свойств подсистем, объединяющих в себе несколько компонентов (и других подсистем).
• Предоставлять инструментарий для независимой проверки компонентов и подсистем на соответствие требованиям к ним.
• Обеспечивать контроль взаимного соответствия взаимных требований и обязательств компонентов и подсистем при их интеграции и совместной работе.
• Позволять эффективно использовать результаты проверки отдельных компонентов и подсистем и наработанные в ее ходе материалы в виде формальных моделей, ограничений использования, верифицированных утверждений, тестов и т.п. в неизменном виде при контроле качества включающих их подсистем и систем.

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

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

В данной работе представлены некоторые элементы компонентной технологии верификации, использующей методы тестирования на основе моделей и базирующейся на компонентных технологиях платформы Java, однако представленная технология находится в процессе создания и в окончательном виде пока не сформирована. Основная же часть статьи посвящена архитектурному каркасу (framework) этой технологии, включающему ее инструментальные библиотеки, а также набор основных типов компонентов и правила их интеграции. Этот каркас может быть использован в несколько более широком контексте, чем сама технология, поэтому целесообразно иметь его отдельное описание.

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

Содержание Вперёд