CC BY
23
СПИСОК ЛИТЕРАТУРЫ
1. Microsoft Phoenix [Электронный ресурс] http:// connect.microsoft.com/Phoenix
2. ANTLR Parser Generator [Электронный ресурс] http://www.antlr.org
3. Aho, A.V. Compilers: Principles, Techniques & Tools [Текст]/Л.УЛ^, M.S.Lam, R.Sethi, J.D.Ullman; 2ed.-Addison-Wesley, 2007.
4. Muchnick, Steven S. Advanced Compiler Design & Implementation ^KCTySteven S. Muchnick.-Morgan Kaufmann Publishers, 1997
5. ECMA International [Электронный ресурс] http:// www.ecma-international.org/
УДК 004.415.5
Н.В. Воинов, В.П. Котляров
ПРИМЕНЕНИЕ МЕТОДА ЭВРИСТИК ДЛЯ СОЗДАНИЯ ОПТИМАЛЬНОГО НАБОРА ТЕСТОВЫХ СцЕНАРИЕВ
Стоимость исправления ошибок на фазах жизненного цикла создания программного продукта экспоненциально растет [1]. Фаза разработки требований и спецификаций наиболее эффективна для идентификации и исправления ошибок [2]. Следовательно, предотвращение ошибок в требованиях и обнаружение их на ранних этапах проекта сильно уменьшает объем корректировок продукта и, таким образом, сокращает общую стоимость разработки ПО.
Решением может служить подход тестирования на основе модели (model based testing). В голове разработчика и тестировщика всегда присутствует та или иная «модель» устройства программы, а также «модель» ее желаемого поведения, исходя из которой, в частности, составляются списки проверяемых свойств и создаются соответствующие тестовые примеры.
Модель - некоторое отражение структуры и поведения системы. Модель может описываться в терминах состояния системы, входных воздействий на нее, конечных состояний, потоков данных и потоков управления, возвращаемых системой результатов и т. д. Анализируя модель разрабатываемой системы, можно еще до этапа кодирования найти различного рода некорректности, неполноту, недетерминированное поведение (и, таким образом, избежать их в реализации), а также изучить возможные сценарии поведения, на основе которых можно получить тесты. Модель строится в виде формальных спецификаций на некотором формальном языке.
В случае систем крупного размера возникает проблема, связанная с комбинаторным взрывом числа состояний модели. Обычно состояние проверяемой модели включает большое количество переменных и процессов. Даже если число процессов конечно и переменные могут принимать только конечное число значений, общее число состояний может быть очень большим. Например, в системах, использующих параллелизм, число состояний моделей растет экспоненциально. В результате возникает необходимость оптимизации обхода формальной модели для последующей генерации тестовых сценариев. Кроме того, необходимо из множества возможных тестовых сценариев выбирать их некоторый оптимальный набор, который удовлетворяет определенному критерию покрытия требований.
В данной статье описан метод эвристик, позволяющий управлять ходом генерации тестовых сценариев (трасс) по формальной модели системы, представленной в виде базовых протоколов [3], а также сформулирован критерий покрытия требований, в соответствии с которым определяется оптимальный набор тестовых сценариев, по которым впоследствии будут генерироваться исполняемые тесты. Представлены результаты применения метода эвристик и оптимизации количества тестовых сценариев.
Базовые протоколы. Базовый протокол является формальной записью утверждения о некоторых событиях, которые должны произойти в про-
грамме, алгоритме, протоколе при выполнении определенных условий. Например, пусть имеется следующее требование к системе телефонии: «если система находится в состоянии busy, то после возврата трубки на базу она должна перейти в состояние idle». В данном утверждении можно выделить три составляющих: предусловие - «если система находится в состоянии busy»; процессная составляющая - «возврат трубки на базу» и постусловие - «система перейдет в состояние idle».
В общем случае базовый протокол является тройкой Хоара [4] и имеет следующий вид: а —-—> в, где а и в - предусловие и постусловие соответственно; ц - процессная составляющая базового протокола. Условия а и в задаются с помощью логических выражений некоторого базового языка и определяют условия на множестве состояний модели.
Разные базовые протоколы могут склеиваться по пред- и постусловиям, если состояние, описанное в постусловии одного базового протокола, совпадает с состоянием, описанным в предусловии другого. Таким образом, изолированно заданные поведенческие свойства образуют граф поведения модели, который и обходит верификатор.
Метод эвристик. Как было сказано выше, современные программные системы, особенно
в телекоммуникационной сфере, имеют очень большие размеры и сложную структуру и, как следствие, по формальным моделям, представляющим эти системы, практически невозможно вручную проанализировать все их поведение. Существуют инструменты верификации, которые в автоматическом режиме проверяют модели на корректность и могут по моделям генерировать некоторые сценарии их поведения (например, примеры тупиков в модели, недетерминированного поведения, зацикливания и т. д.). Однако для целей тестирования часто требуется по модели построить определенное количество сценариев, покрывающих конкретные функциональные требования, интересующие заказчика, чтобы в дальнейшем сгенерировать по ним тесты и исполнить их на готовой реализации системы. Метод эвристик позволяет пользователю задавать критерии покрытия, которые будут одновременно служить направлением поиска трасс для тестовых сценариев при обходе пространства поведения модели. Метод подразумевает наложение ограничений на размер тестового сценария, что дает возможность проверить его допустимость. Критерии покрытия формулируют дополнительные ограничения на поиск, отсекая ветви поведения модели, не удовлетворяющие тестовому сценарию.
Рис. 1. Схема работы метода эвристик
Рис. 2. Пример задания эвристик в системе VRS
Основная идея метода эвристик схематически представлена на рис. 1, где изображено дерево поведения модели, построенное на основании множества базовых протоколов, описывающих модель (вершины - состоянии модели, переходы -базовые протоколы).
Пользователь, зная, какие именно элементы дерева поведения модели (какие сигналы, изменения атрибутов и состояний и т. д.) должны быть включены в тестовый сценарий, чтобы соответствующее требование было покрыто, может указать определенные состояния и переходы, т. е. задать промежуточные точки (отмечены кружками), через которые осуществляется трассовая генерация. Таким образом, существенно ограничивается пространство поиска от одной промежуточной цели до другой, т. е. от одного события в тестовом сценарии до другого. При необходимости путь от начального события до конечного может быть уточнен дополнительными событиями, конкретизирующими путь в древе поведения (рис. 1).
Для реализации метода эвристик использовалась система верификации VRS (Verification of Requirement Specifications) [5]. VRS-технология была создана совместно Институтом кибернетики имени В.М. Глушкова НАН Украины и компанией Motorola для верификации функциональных поведенческих спецификаций, описанных с помощью базовых протоколов. Она проверяет модели, извлекаемые из базовых протоколов, на
недетерминированное поведение, достижимость определенных состояний, а также на полноту и непротиворечивость. После сеанса верификации составляется верификационный отчет с указанием ошибок, неточностей и несоответствий, найденных в процессе верификации. К отчету прилагаются полученные трассы, описывающие некорректные поведения системы.
В качестве промежуточных целей, которые обходит трассовый генератор VRS, использовались имена базовых протоколов. Последовательность базовых протоколов, достаточная для покрытия требования, называется «цепочкой». По каждой цепочке автоматически генерируется трасса, покрывающая определенное требование. На рис. 2 представлен пример задания эвристик (цепочек базовых протоколов) в одном из проектов VRS.
Использование метода эвристик позволяет значительно сократить время на генерацию тестовых сценариев, покрывающих определенный набор требований. В табл. 1 приведены результаты применения метода в трех крупных телекоммуникационных проектах. По результатам можно сделать вывод о том, что время, затрачиваемое верификатором на автоматическую проверку корректности модели и генерацию всех возможных сценариев поведения модели (3-я колонка) значительно превосходит время на генерацию с помощью метода эвристик конкретных тестовых сценариев, покрывающих требования.
Таблица 1
Результаты применения метода в телекоммуникационных проектах
Количество базовых протоколов в проекте Количество требований в проекте Время обхода всей модели верификатором и трассовым генератором, ч Количество цепочек базовых протоколов, покрывающих все требования Время генерации трасс с помощью метода эвристик, мин
60 107 16 110 4
124 148 35 30 9
497 57 50 223 18
Метод композиции состояний дерева поведения модели. Параллельно с методом эвристик значительное сокращение количества получаемых трасс достигается использованием композиции состояний дерева поведения модели. Смысл метода заключается в объединении некоторого числа состояний и переходов между ними в отдельный укрупненный элемент дерева - стаб («stub»), построении полного набора трасс внутри каждого стаба, а затем связывании множества стабов между собой небольшим числом трасс. Декомпозиция дерева поведения модели на множество стабов возможна различными способами, в частности, в соответствии с классификацией требований по функциональности. Такое разбиение фактически может быть определено структурой разделов исходной документации, которая используется при формализации требований. Другой подход заключается в декомпозиции поведенческого пространства по количеству связей, концентрируя в разных стабах состояния с большим числом связей и уменьшая число связей между стабами. В результате применения метода исключается экспоненциальный взрыв при переборе вариантов по разным стабам, при этом гарантируется покрытие всего множества поведений внутри каждого стаба.
Критерий покрытия требований и оптимизация набора тестовых сценариев. Для того чтобы определить, покрывается ли требование тестовым сценарием (или трассой VRS), необходимо сначала сформулировать критерий покрытия. Под критерием будем понимать последователь-
ность наблюдаемых причин и следствий некоторых событий («цепочку»), описывающих требование. Цепочка задается формулировкой всех ее элементов: начальных условий (причин), требуемых для выполнения определенной активности, самой активности и наблюдаемых результатов. Если цепочка встречается в трассе, это означает, что данная трасса покрывает соответствующее требование.
Для проверки покрытия требований в трассах используется матрица отслеживания (TRM -Traceability Matrix), в которую заносится информация обо всех требованиях в проекте. Матрица имеет пять колонок: «Identifier» - идентификатор требования; «Requirements» - текст требования; «Scenario of requirements» - непосредственно сама цепочка, т. е. последовательность наблюдаемых событий, которые должны произойти, чтобы требование выполнилось; «Scenario ID» - идентификатор цепочки; «Traceability» - последовательность базовых протоколов, содержащая цепочку событий в формализованном виде. Именно эта последовательность базовых протоколов ищется в трассах в процессе генерации. Если последовательность базовых протоколов, покрывающих требование, встречается в трассе, то данная трасса покрывает данное требование. Поиск покрытия осуществляется автоматически с помощью специального скрипта.
На рис. 3 приведен пример описания требования в матрице отслеживания и фрагмент трассы, покрывающей это требование (т. е. содержащей соответствующую цепочку базовых протоколов).
После нахождения множества трасс, покры-
Рис. 3. Описание требования в матрице отслеживания и фрагмент покрывающей его трассы
вающего все требования проекта, осуществляется его оптимизация. В найденном множестве трасс возможны ситуации, когда в одной трассе покрываются два или даже больше требований, потому что она содержит сразу несколько цепочек. В оптимальном наборе трассы с повторным покрытием требования исключены. Оптимизация выполняется автоматически с помощью скрипта. Например, если трасса 1 покрывает требования 1 и 2, трасса 2 - только требование 1, а трасса 3 -только требование 2, то трасса 3 исключается. На этом же этапе осуществляется автоматическая разметка требований в трассах, которая с помощью цветных маркеров показывает начало покрытия требования (первое событие цепочки), конец по-
крытия (последнее событие) и все промежуточные шаги цепочки покрытия. На рис. 4 приведен пример разметки покрытого требования в трассе.
Оптимизация набора трасс, покрывающих требования, позволяет сократить количество трасс, используемых в дальнейшем для генерации исполняемых тестов, без ущерба качеству покрытия требований, что, в свою очередь, сокращает общее время тестирования.
В табл. 2 приведены результаты оптимизации наборов трасс в тех же трех телекоммуникационных проектах.
Методы эвристик и оптимизации набора трасс, покрывающих требования, позволили
<
<
<
ПВЯ1С РЕОТОСМ.
ими*
[ПГСЭИЗГТ ГСИ»
|тав.л5 с«« <,«<1п>К|м
виххс штост.
[ПЯЗ'.ЕОПЕ К'.Ч» с пПМ1*|((
1«!и>Ш
*я$хс_гаотосоа.
>
>
>
<
<
|т|щ»_изст «ои «.«нчу**^,.*
(пшцгг ссзд с .'Л 1
[ПИЯ.Щ- «1» е.тТЯЯ1*Ш
лэлг.язз х»! 1
(п!па_со;п: с«« г.хтвешч
I
[пппцЕдт ссю с.-.гаыа-:»
а!»«»:
ищи* 1. и^тамлм
ВЬ51С_1'ГСгТОС1}1.
[ ЗХЦ 13» 1. 1В*<1 <{¿115 Т1глХ
-, I I
>
>
Рис. 4. Пример разметки покрытого требования в трассе
Таблица 2
Результаты оптимизации наборов трасс в телекоммуникационных проектах
Количество базовых протоколов в проекте Количество требований в проекте Количество полученных трасс, покрывающих все требования Оптимальный набор трасс
60 107 110 46
124 148 30 26
497 57 223 195
значительно сэкономить время и трудоемкость анализа формальных моделей разрабатываемых систем, а также разработку тестов, проверяющих
их функциональность. Преимущества описанных методов были доказаны в ходе их применения в ряде крупных телекоммуникационных проектов.
СПИСОК ЛИТЕРАТУРЫ
1. Boehm, B. Software Risk Management: Principles and Practices. [Текст]/В. Boehm//IEEE Computer Society Press.
2. Booch, Gr. Object-Oriented Analysis and Design with Applications. [Текст]/Gr. Booch//Addison-Wesley Professional; 2 ed.-Oct. 10, 1993.
3. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст]/А.А. Летичевский, Ю.В. Капитонова, A.A. Летичевский (мл.) [и др.]//Ки-бернетика и системный анализ.-2005.-№ 4.-С. 3-21.
4. Hoare, C.A.R. Communicating Sequential Processes. [TeKCT]/C.A.R. -Hoare Prentice Hall. London, 1985.
5. Letichevsky, A. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications. [TeKCT]/A. Letichevsky, J. Kapitonova, A. Letichevsky Jr. [et al.]//Proc of ISSRE04 Workshop on Integrated-reliability with Telecommunications and UML Languages (ISSRE04:WTTUL).-02 Nov 2004. -IRISA Rennes France.
УДК 004.415
P.C. Муханов, В.О. Сафонов
реализация и практическое применение системы
ASPECT.NET ДЛЯ АКАДЕМИЧЕСКОЙ ВЕРСИИ .NET
На сегодняшний день наиболее распространена методология объектно-ориентированного программирования (ООП). Менеджеры большинства новых проектов выбирают именно эту концепцию. Несмотря на эффективность подхода ООП, существуют проблемы, для которых нужна более совершенная методология. В современном мире промышленное производство программного обеспечения достигло таких масштабов и такой сложности, что с каждым днем все труднее и дороже обходятся его разработка, поддержка, отладка, добавление новой функциональности, докумен-
тирование, расширение и развитие. Сложность, присущая большинству современных программных систем, обусловлена четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; трудностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем [1].
Как в свое время на смену процедурному подходу пришло объектно-ориентированное про-
