ПРОГРАММИРОВАНИЕ, 2010, No 5, с. 54-75
ТЕСТИРОВАНИЕ, ВЕРИФИКАЦИЯ И ВАЛИДАЦИЯ ПРОГРАММ
УДК 681.3.06
КОМПОНЕНТНАЯ АРХИТЕКТУРА СРЕДЫ ДЛЯ ТЕСТИРОВАНИЯ НА ОСНОВЕ МОДЕЛЕЙ
© 2010 г. В. В. Кулямин
Институт системного программирования РАН 109004 Москва, ул. Солженицына, 25 E-mail: kuliamin@ispras.ru Поступила в редакцию 21.01.2010 г.
В статье представлен подход к построению архитектуры инструментария для тестирования на основе моделей, использующего современные компонентные технологии. Одна из основных идей, лежащих в его основе - применение техник неинвазивной композиции, позволяющих с минимальными затратами интегрировать множество независимо разработанных компонентов в сложную систему и переконфигурировать ее, не изменяя кода компонентов. Представленный подход является одним из первых применений компонентных технологий для проектирования тестовых систем. Также описывается прототипная реализация предложенного подхода на базе свободно доступных библиотек и пример ее использования для построения тестов.
1. ВВЕДЕНИЕ
Рост количества и разнообразия задач, возлагаемых в современном мире на вычислительные системы, приводит к постоянному их усложнению и увеличению сложности всех видов деятельности, связанных с их построением и сопровождением. На решение проблем, связанных с этим ростом сложности, нацелены активно развивающиеся в последние десятилетия компонентные технологии [1, 2] построения вычислительных систем.
При их применении системы выстраиваются из независимых компонентов, каждый из которых решает узкий набор задач и взаимодействует с окружением только через четко определенный интерфейс, т.е. является модулем. Помимо этого, программные компонентные технологии облегчают интеграцию компонентов, автоматически выполняя связывание и запуск компонентов (часто на лету, без прерывания работы системы), помещенных в бинарном виде в рамки некоторой технологической инфраструктуры (компонентной среды). В результате компоненты могут создаваться и поддерживаться независимыми разработчиками, что снижает расходы на разработку и сопровождение сложных систем.
Компонентные технологии позволили значительно повысить сложность создаваемых систем, однако их развитие не сопровождается соответствующим прогрессом в технологиях контроля качества программного обеспечения (ПО). В связи с этим проблемы обеспечения качества компонентных систем, включающие проверку корректности их работы, лишь усугубляются с возрастанием сложности и ответственности решаемых ими задач.
Источником таких проблем служит чрезвычайно высокая трудоемкость проверки корректности систем при нелинейно зависящем от числа компонентов количестве возможных сценариев их взаимодействия и неявных зависимостей между ними. В свою очередь, эти трудности имеют следующие причины.
• Сложившаяся практика неполного и неточного описания интерфейсов компонентов приводит к возникновению множества неявных зависимостей между ними. Согласно Парнасу [3], одному из основоположников модульного подхода, полный интерфейс модуля должен задавать не только его синтаксическую структуру (имена операций, типы их параметров и результатов),
но и семантику (правила использования операций и ожидаемое поведение модуля). На практике же обычно фиксируют только синтаксис, семантика описывается, чаще всего не полностью и не однозначно, только для системных интерфейсов, поскольку с некорректным их использованием часто связаны высокие риски. Однако "менее рискованных" интерфейсов, смысл которых обычно не описывается совсем, гораздо больше, и суммарные расходы, связанные с ошибками в их работе, весьма значительны [4].
• Трудности интеграции средств верификации в процессы разработки ПО.
Такие средства по большей части являются "монолитными" инструментами или интегрированными решениями с большим количеством функций. Набор деятельностей по контролю качества ПО, связи между ними, а также поддерживаемые техники верификации задаются разработчиками инструментов и не могут быть существенно изменены или расширены. Однако процессы разработки ПО в разных организациях сильно различаются, поэтому все более востребованы модульные инструменты разработки, способные легко интегрироваться с другими инструментами и включать новые модули, реализующие передовые техники разработки и анализа ПО. Инструменты разработки сложных систем тоже должны быть компонентными и требовать минимума затрат на свое включение в разные технологические цепочки. Среди средств верификации такими свойствами пока обладают лишь инструменты модульного тестирования (unit testing) [5] (наиболее известен JUnit [6]), модульной поддержки более сложных видов верификации или тестирования на соответствие требованиям практически нет.
• Слабая поддержка многократного использования артефактов контроля качества — тестов, верифицированных утверждений, моделей и пр. Это особенно важно для компонентных технологий, где верификация одного компонента чаще всего имеет приемлемую стоимость, в ее ходе создается много вспомогательных артефактов, а ис-
пользовать их далее при проверке взаимодействующих компонентов или гораздо более дорогостоящем контроле качества систем, включающих проверенный компонент, уже не удается. Обеспечение многократного использования таких артефактов могло бы значительно снизить издержки верификации компонентного ПО.
Мотивацией данной работы является убежденность, что систематическое использование компонентных технологий при построении верифицирующих систем поможет справиться с проблемами, связанными с разрывом между сложностью современных систем и возможностями контроля их качества. Выход из сложившейся ситуации - создание компонентных технологий верификации программных и аппаратных систем, которые должны обеспечить независимую проверку качества отдельных компонентов в соответствии с требованиями к ним, а затем использовать получаемые при этом артефакты для более аккуратного контроля их интеграции и качества системы в целом, постепенно наращивая количество и сложность проверенных компонентов и подсистем. Эти технологии должны расширять существующие компонентные технологии разработки и задействовать элементы, уже знакомые разработчикам.
Гибкость технологии и возможность ее использования для решения разных задач во многом обуславливаются лежащей в ее основе архитектурой. Для компонентных технологий архитектурные решения еще более значимы, поскольку они непосредственно определяют систему правил создания, развития и добавления новых компонентов, их разновидности, шаблоны организации их взаимодействий, возможные конфигурации и т.д.
Одним из перспективных подходов к систематической проверке корректности сложных систем является тестирование на основе моделей, сочетающее строгость формальных методов и аккуратность выявления ошибок с гибкостью и практичностью обычного тестирования.
В данной работе представлены некоторые элементы компонентной технологии верификации, использующей методы тестирования на основе моделей и базирующейся на технологиях платформы Java, однако представляемая технология
пока находится в процессе создания. Основная же часть статьи посвящена ее архитектурному каркасу (framework), включающему инструментальные библиотеки, а также набор основных типов компонентов и правила их интеграции. Для тестирования на основе моделей подобная компонентная архитектура предлагается впервые, хотя ряд ее элементов заимствованы из наиболее передовых инструментов модульного тестирования.
Во втором разделе статьи рассматривается подход к тестированию на основе моделей, его требования к архитектуре поддерживающего инструментария и их имеющиеся реализации. Затем формулируются принципы компонентной разработки и представляются основные элементы предлагаемого архитектурного каркаса. Далее описан небольшой пример создания тестов с его помощью. Заключение статьи резюмирует ее содержание и обрисовывает направления дальнейшего развития изложенных идей.
2. ТЕСТИРОВАНИЕ НА ОСНОВЕ МОДЕЛЕЙ И ИНСТРУМЕНТЫ ТЕСТИРОВАНИЯ
Тестирование на основе моделей (model based testing) [7, 8] представляет собой подход к тестированию, в рамках которого тесты строятся вручную, автоматизированным образом или генерируются полностью автоматически на основе модели поведения тестируемой системы и модели ситуаций, связанных с ее работой.
• Модель поведения (behavior model) формализует требования к тестируемой системе, т.е. описывает, какие внешние воздействия на нее в каких ситуациях допустимы, и как она должна реагировать на эти воздействия.
Модель поведения служит основой для тестового оракула [9-11] - компонента, производящего оценку поведения системы во время тестирования.
Чаще всего при тестировании используются модели в виде автоматов разного вида: конечные или расширенные автоматы, системы переходов [7], Statecharts [12, 13], временные автоматы [14, 15] и т.д. Можно использовать другие разновидности моделей: контрактные спецификации в виде пред- и
постусловий операций, алгебраические спецификации в виде правил эквивалентности различных цепочек вызовов операций, трассовые модели, описывающие возможные цепочки воздействий и реакций системы.
• Модель ситуаций (situation model) формализует структуру возможных тестовых ситуаций, составляющими которых являются внешние воздействия и состояния самой системы и ее окружения, определяет различные классы ситуаций и их важность с точки зрения контроля качества. Обычно такая модель задает конечный набор классов эквивалентности ситуаций, подразумевая, что при тестировании достаточно проверить работу системы хотя бы в одной ситуации из каждого класса. Часто модель ситуаций описывает конечный набор элементарных событий, при этом каждый класс ситуаций соответствует некоторому множеству таких событий. Примером такого события может являться выполнение заданной инструкции в коде тестируемой системы. В более сложных случаях определяемые классы могут пересекаться, им могут приписываться веса, показывающие, насколько важно проверить одну из ситуаций такого класса.
Модель ситуаций используется для решения двух тесно связанных задач: определения кри
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.