Опыт динамического тестирования и анализа моделей технических систем реального времени

В.В. Макаров,
с.н.с, к.т.н., доц.,makarov@ipu.ru,
ИПУ РАН, г. Москва,
 А.М. Денисов,
студ.,
Т.С. Клименко,
студ.,
МИФИ, г. Москва

Аннотация

Рассматривается тестирование ПО с использованием анимации UML-моделей Такое исполнение UML-моделей в режиме анимации называют динамической отладкой. Исследуются процессы тестирования на программных моделях технических устройств для С++ и Java 2.0, которые получены из UML-моделей. Верифицированность таких систем оказывается выше, чем для систем, для которых проведено только статическое тестирование. Рассматриваются анимированные UML-диаграммы конечных автоматов и диаграммы последовательностей. При выполнении такой программы среда разработки отражает изменение состояния приложения на соответствующей диаграмме. Рассматривается быстрое прототипирование системы, как метод тестирования. Такое дополнительное тестирование важно для создания встраиваемых систем и систем реального времени.

 

Abstract

Software testing with use of animation of UML-models is considered. Execution of UML-models in an animation mode is dynamic debugging. Processes of testing on program models of technical devices for C ++ and Java 2.0 which are received from UML-models are investigated. Verifies such systems are above, than for static testing systems only. Animated UML-diagrams of Finite State Machine and the Sequence Diagrams are considered. The development framework reflects change of a condition of the application program in the corresponding diagram during program run. Fast prototyping of system, as a testing method is considered. Additional testing is important for creation of real time systems and embedded systems.

Введение

При разработке программного обеспечения часто приходится сталкиваться с одной из двух проблем: либо качество разработанного продукта много ниже самых минимальных разумных требований, либо затраты на тестирование превосходят все разумные пределы. К сожалению, бывает и так, что обе проблемы существуют одновременно. Денег на тестирование истрачено много, а качества достичь не удалось [1].

Тестирование на уровне модели

Важную роль в создании программных систем играет тестирование. Однако тестирование не может гарантировать  соответствие системы заданным свойствам. Повышение сложности программных систем привело к тому, что тестирование не позволяет полностью изучить поведение систем во всех возможных режимах функционирования. Для сложных систем невозможно с разумными затратами временных и других ресурсов воссоздать все возможные комбинации входных и операционных данных. Поэтому тестирование лишь повышает доверие к системе. Изучать поведение системы позволяет динамический анализ и верификация системы [2,3]. При верификации систем кроме тестирования выполняют различные работы, которые относят к статическому и динамическому анализу. Статический анализ – это исследование характеристик программного обеспечения путем изучения исходных текстов без реального выполнения кода. Динамический анализ - исследование характеристик программного обеспечения в ходе исполнения программы.

В среде разработки Rational Rhapsody (использовались версии 7.5.3 и 7.6) поддерживается уникальный механизм анимации  UML-моделей и реальное выполнение сгенерированной программы с графическим интерфейсом. Механизм анимации для UML-диаграмм реализуется следующим образом. При генерации кода указывается необходимость создания анимированной версии приложения, а так же параметры для связи с инструментальной средой разработки по TCP/IP. В этом случае поведенческий код, реализующий диаграммы конечных автоматов (State Machine Diagram) и диаграммы последовательностей (Sequence Diagram) вставляются соответствующие инструкции. При запуске программы она устанавливает TCP-соединение с Rhapsody и во время выполнения сообщает среде разработки своё текущее состояние. Среда разработки отражает изменение состояния приложения на соответствующей диаграмме. Исполнение UML-моделей в режиме анимации называют динамической отладкой.

Можно использовать и традиционные подходы к отладке модели – выполнять действия пошагово, расставлять точки останова и т.п. Кроме того, действия программиста можно записать в виде сценариев для автоматизированного выполнения.

В системе разработки можно подключить два дополнительных компонента повышающих степень автоматизации тестирования – Test Conductor и Automatic Test Generator (ATG). Последняя компонента обеспечивает автоматическое генерирование тестов для UML-моделей полученных с помощью Rhapsody с генерацией исходного исполняемого кода на C++. ATG анализирует модель и исходный код и генерирует тестовые векторы, которые могут быть использованы для окончательного тестирования. Генерируются тестовые векторы для того, чтобы достигнуть всех состояний на диаграмме, пройти все переходы, все операции и события реактивных классов  (классы, имеющие диаграммы поведения) в тестируемой  модели. ATG генерирует тестовые вектора, покрывающие C++ код [4,5].

Рассмотрим пример тестирования модели секундомера. Работа модели созданной, что очень важно, по UML-диаграммам, описывается предельно просто. Пользователь нажимает на кнопку, и секундомер запускается. Пользователь снова нажимает на кнопку – секундомер останавливается и показывает время (секунды и минуты), прошедшее от первого нажатия на кнопку до второго. Разработанная модель простого секундомера включает в себя 4 класса, 2 диаграммы классов, 2 диаграммы состояний, 2 диаграммы последовательностей, простой интерфейс. При относительной простоте модели, наличию нескольких диаграмм объем сгенерированного кода имеет внушительные размеры – 2900 строк.

Модель секундомера содержит следующие классы (рис. 1):

Button – кнопка;

StopWatch – секундомер;

Display – класс, благодаря которому секундомер отображается на экране;

Power – класс, отвечающий за контроль включения/выключения секундомера.

 

рис. 1 Классы программы

Выбираем класс StopWatch и нажимаем на «Create TestArchitecture» в контекстном меню, чтобы создать тестовую архитектуру. Автоматически создается Test Conext Diagram «TCon_StopWatch». Автоматически созданная архитектура также отображается в браузере. Созданы:

·         Новая конфигурация в «TPkg_StopWatch_Comp» (рис.2), описывающая тестовые компоненты и  объекты SUT (System Under Test) и их взаимосвязь во время работы тест-кейсов.

·         Новый тестовый компонент. Тестовый контекст. (Тестовое окружение, в котором запускаются  тест-кейсы)

Тестовое окружение состоит из трех классов (рис. 2)

TCon_StopWatch ;

«TC_at_pIn_of_StopWatch» - реализует необходимые связи  для  «IKey» и поэтому может быть связан с «pIn» портом класса, который обеспечивает эти связи;

«TC_at_pOut_of_StopWatch» - реализует необходимые связи для «IDisplay» и поэтому может быть связан с «pOut» портом этого класса секундомера.

 

рис. 2. Автоматически созданная тестовая архитектура, отображенная в браузере

Создание тест-кейсов. Диаграмма последовательности

Чтобы создать диаграмму последовательности для тест-кейса, мы должны создать тестовый сценарий, реализованный как диаграмма последовательности, и связать его с тест-кейсом.

Для этого в браузере выбираем в контекстном  меню «TCon_StopWach» «Create SD TestCase…». Переименовываем для удобства сгенерированный тест-кейс в «tc_check_init» и тестовый сценарий в «CheckInit».

Далее добавляем тестовый профиль: Add newàTestingProfileàTestObjective. Пусть тест-кейс должен проверить, что «REQ_Init» действительно выполняется в программе «StopWatch». Выбираем «REQ_Init» в открывшемся окне. Теперь наш тест и «REQ_Init» связаны (рис. 3)

 

рис.3 Связь объекта и теста

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

рис.4 Диаграмма последовательности теста

Параметр m равен числу минут, прошедших с момента включения отсчета секундомера, параметр s равен числу секунд (значение < 60), прошедших с момента запуска секундомера, параметр b показывает, включен ли секундомер (Если b = true, то включен, false - выключен).

Теперь запускаем  тест. Для этого выбираем «Execute TestCase» в контекстном меню. При запуске теста IBM Rational Rhapsody автоматически сравнивает, соответствует ли реакция программы заданной тестировщиком диаграмме. Если не соответствует – тест не пройден.

В браузере открывается окно, в котором показано, успешно ли пройден тест (рис.5)

 

рис.5  Отображение успешности прохождения теста

Тест не пройден. Чтобы понять причины ошибки, TestConductor  создает диаграмму последовательности, на которой указана ошибка (рис.6).

рис.6 Отображение автоматически выявленных ошибок

На скриншоте стрелка, соответствующая событию evShow, выделена красным, и написано «Check of in value of argument b failed» («Проверка значения аргумента b привела к ошибке»).

Изменяем в тесте значение аргумента b на false (рис. 7), снова запускаем тестирование.

 

рис. 7 Новая диаграмма последовательности теста

Теперь тест пройден успешно (рис.8)

 

рис.8 Отображение успешного прохождения теста

Тестирование модели с использованием прототипа интерфейса GUI

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

 

                      

рис.9 Вариант интерфейса с кириллицей без связей с событиями приложения и латиницей

Необходимо связать элементы интерфейса с событиями. Тестируем приложение – при первом нажатии кнопки приложение запускается, а при повторном останавливается. Наблюдаем останов модели секундомера на 25 секунде (рис.10).

рис.10 Функционирование интерфейса приложения и контроль за ним через консоль оператора

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

Заключение

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

Далее были рассмотрены анимационные модели, основанные на диаграммах последовательности. Необходимо отметить плюс данных анимационных моделей, что полученные анимационные модели в результате работы системы сохраняются, и их можно просматривать и анализировать  уже после работы системы, они сохраняются в проекте разработки, в отличие от анимационных моделей, основанных на диаграмме состояний. Еще одним плюсом данной анимационной модели является то, что на ней отображаются помимо всех действий, предписанных диаграммой последовательности, все состояния экземпляров классов, которые принимают они во время работы, а также методы, которые выполняют экземпляры, генерируемые ими события и сообщения, предписанные диаграммой состояний, во время перехода в различные состояния. Анимационные модели обоих видов являются еще одним средством, облегчающим  процесс создания качественного и надёжного ПО. Ясно, что код, который получается при генерации по разработанной модели в режиме анимации, более избыточен по сравнению с режимом без анимации. Код с анимацией разработчик использует только на этапе отладки и верификации программного обеспечения, а не для использования в целевой системе.

Литература

1.   Новичков А., Костиков А. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational. (Электронный ресурс)/ Новичков А., Костиков А. Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational.-Режим доступа: http://citforum.ru/SE/testing/automation_1/index.shtml, свободный.

2.   Douglass B. P. Real-Time UML Workshop for Embedded Systems. – Oxford, UK, Elsevier Inc., 2007. p.408.

3.   Зыль С.Н. Проектирование, разработка и анализ программного обеспечения систем реального времени. – СПб.: БХВ-Петербург, 2010. 336с.

4.   Rhapsody Automatic Test Generation (Rhapsody ATG). User Guide. Release 3.2. Telelogic, Massachusetts, 95p.

5.   Зыль С.Н. Java реального времени уже реальность. (Электронный ресурс)/С.Н.Зыль-электрон.текстовые дан.-Режим доступа: http://www.swd.ru/index.php3?pid=877, свободный.