Методические указания по выполнению практических по мдк 02. 02

29
Лабораторная работа №21 «Тестирование интерфейса пользователя средствами 
инструментальной среды разработки» 
Цель работы. Получение практических навыков автоматической генерации тестов на 
основе формального описания. 
Теоретическая часть. 
Практически все программные системы предусматривают интерфейс с оператором. 
Практически всегда этот интерфейс – графический (GUI – Graphical User’s Interface). 
Соответственно, актуальна и задача тестирования создаваемого графического интерфейса. 
Вообще говоря, задача тестирования создаваемых программ возникла практически 
одновременно с самими программами. Известно, что эта задача очень трудоёмка как в смысле 
усилий по созданию достаточного количества тестов (отвечающих заданному критерию тестового 
покрытия), так и в смысле времени прогона всех этих тестов. Поэтому решение этой задачи 
стараются автоматизировать (в обоих смыслах). 
Для решения задачи тестирования программ с программным интерфейсом (API – Application 
Program Interface: вызовы методов или процедур, пересылки сообщений) известны подходы – 
методы и инструменты – хорошо зарекомендовавшие себя в индустрии создания программного 
обеспечения. Основа этих подходов следующая: создается формальная спецификация программы, 
и по этой спецификации генерируются как сами тесты, так и тестовые оракулы – программы, 
проверяющие правильность поведения тестируемой программы. Спецификации, как набор 
требований к создаваемой программе, существовали всегда, Ключевым словом здесь является 
формальная спецификация. Формальная спецификация – это спецификация в форме, допускающей 
её формальные же преобразования и обработку компьютером. Это позволяет анализировать набор 
требований с точки зрения их полноты, непротиворечивости и т.п. Для задачи автоматизации 
тестирования эта формальная запись должна также обеспечивать возможность описания 
формальной связи между понятиями, используемыми в спецификации, и сущностями языка 
реализации программы. 
Правильность функционирования системы определяется соответствием реального 
поведения системы эталонному поведению. Для того чтобы качественно определять это 
соответствие, нужно уметь формализовать эталонное поведение системы. Распространённым 
способом описания поведения системы является описание с помощью диаграмм UML (Unified 
Modeling Language). Стандарт UML предлагает использование трех видов диаграмм для описания 
графического интерфейса системы: 
 Диаграммы сценариев использования (Use Case). 
 Диаграммы конечных автоматов (State Chart). 
 Диаграммы действий (Activity). 
С помощью UML/Use Case diagram можно описывать на высоком уровне наборы сценариев 
использования, поддерживаемых системой. Данный подход имеет ряд преимуществ и недостатков 
по отношению к другим подходам, но существенным с точки зрения автоматизации генерации 
тестов является недостаточная формальная строгость описания. 
Широко распространено использование UML/State Chart diagram для спецификации 
поведения системы, и такой подход очень удобен с точки зрения генерации тестов. Но составление 
спецификации поведения современных систем с помощью конечных автоматов есть очень 
трудоёмкое занятие, так как число состояний системы очень велико. С ростом функциональности 
системы спецификация становится всё менее и менее наглядной. 
Перечисленные недостатки этих подходов к описанию поведения системы преодолеваются 
с помощью диаграмм действий (Activity). С одной стороны нотация UML/Activity diagram является 
более строгой, чем у сценариев использования, а с другой стороны предоставляет более широкие 
возможности по сравнению с диаграммами конечных автоматов. 
Для создания прототипа работающей версии данного подхода используется инструмент 
Rational Rose. В первую очередь для спецификации графического интерфейса пользователя при 
помощи диаграмм действий UML. 
Для прогона сгенерированных по диаграмме состояний тестов используется инструмент 
Rational Robot. Из возможностей инструмента в работе мы использовали следующие: 
1. 
Возможность выполнять тестовые воздействия, соответствующие переходам между 
состояниями в спецификации. 

30
2. 
Возможность проверять соответствие свойств объектов реальной системы и 
эталонных свойств, содержащихся в спецификации. Из тех возможностей, которые доступны с 
помощью этого инструмента, используется проверка следующих свойств объектов: 

Наличие и состояние окон (заголовок, активность, доступность, статус). 

Наличие и состояние таких объектов, как PushButton, CheckBox, RadioButton, List, 
Tree и др. (текст, доступность, размер). 

Значение буфера обмена. 

Наличие в оперативной памяти запущенных процессов. 

Существование файлов. 
Рис. 2 Общая схема генерации и прогона тестов 
Генератор строит по диаграмме состояний набор тестов. Условием окончания работы 
генератора является выполнение тестового покрытия. В данном случае в качестве покрытия было 
выбрано условие прохода по всем рёбрам графа состояний, то есть выполнения каждого доступного 
тестового воздействия из каждого достижимого состояния. 
Автоматическая генерация тестов по диаграммам действий имеет следующие преимущества 
перед остальными подходами к тестированию графического интерфейса: 
Генератор тестов есть программа (script), написанная на языке ‘Rational Rose Scripting 
language’ (расширение к языку Summit BasicScriptLanguage). В Rational Rose есть встроенный 
интерпретатор инструкций, написанных на этом языке, посредством которого можно обращаться 
ко всем объектам модели (диаграммы состояний). 

Спецификация автоматически интерпретируется (тем самым она 
проверяется и компилируется в набор тестов). 

Если какая-то функциональность системы изменилась, то диаграмму 
состояний достаточно изменить в соответствующем месте, и затем 
сгенерировать новый тестовый набор. Фактически, это снимает большую 

жүктеу/скачать 1.26 Mb.

Достарыңызбен бөлісу: