CC BY
19
5. Ukkonen, E. Sweepline the Music! Lecture Notes in Computer Science [Text] / E. Ukkonen, K. Lemstrom, V. Makinen // Comp. Sci. in Perspective (Ottmann Festschrift); Ed. R. Klein [et al.]. -2003. -P. 330-342.
6. Typke, R. Using transportation distances for measuring melodic similarity [Электронный ресурс] / R. Typke [et al.] // In Proc. of the International Conf. on Music Information Retrieval (ISMIR). -2003. -Режим доступа: http://ismir2003.ismir.net
7. Madsen, S.T. A complexity-based approach to melody track identification in midi files [Электронный ресурс] / S.T. Madsen, G. Widmer // In Proc. of the International Workshop on Artificial Intelligence and Music (MUSIC-AI 2007) held in conjunction with the 20th International Joint Conf. on Artificial Intelligence
(IJCAI 2007). -2007. -Режим доступа: http://www.ofai. at/~soren.madsen/pub/music-ai07.pdf
8. Uitdenbogerd, A.I. Manipulation of music for melody matching [Text] / A. L. Uitdenbogerd, J. Zobel // In Proc. of the 6th ACM international Conf. on Multimedia. -ACM NY, 1998. -P. 235-240.
9. Madsen, S.T. Automatic reduction of midi files preserving relevant musical content [Text] / S.T. Madsen, R. Typke, G. Widmer // In Proc. of the 6th International Workshop on Adaptive Multimedia Retrieval (AMR'08). -Springer-Verlag. -2008. -P. 89-99.
10. Kuznetsov, A. Searching for Music: From Melodies in Mind to the Resources on the Web [Text] / A. Kuznetsov, E. Pyshkin // In Proc. of the 13th International Conf. on Humans and Computers (HC-2010), University of Aizu Press, 2010. -P. 152-158.
УДК 004.415
В.П. Котляров
критерии покрытия требований в тестовых сценариях, сгенерированных из поведенческих моделей приложений
Ключевая проблема современного тестирования - проверка соответствия семантики реализованного программного продукта семантике, заданной заказчиком в требованиях. Суть проблемы в том, что набор тестов, проверяющий выполнение требований, не гарантирует проверку их семантики. В статье, в отличие от традиционных критериев [9], предложен критерий, позволяющий согласовать с заказчиком и проверить при тестировании семантику требований.
Формализация требований
В современной проектной документации формулировка требований задается либо конструктивно, когда из текста требования на естественном языке удается реконструировать процедуру контроля или сценарий проверки выполнения данного требования, либо неконструктивно, когда заданное в требовании свойство не содержит пояснения способа его проверки.
Поведенческие требования при наличии заданного сценария проверки являются конструктивно заданными и допускают для проверки реализуемости использование верификации или
тестирования. Неповеденческие требования часто задаются неконструктивно, что заставляет в процессе формализации привлекать дополнительную информацию, позволяющую реконструировать сценарий их проверки, т. е. привести неконструктивную форму задания требования к конструктивной.
Процедура или сценарий проверки некоторого требования заключается в задании перечислимого упорядоченного набора событий, фиксация которого в процессе исполнения приложения будет для заказчика критерием выполнимости соответствующего требования. Подобную последовательность событий в дальнейшем изложении будем называть критериальной последовательностью или цепочкой [1]. Каждому требованию может быть сопоставлена одна или несколько критериальных цепочек. Отслеживая в поведенческом сценарии системы факт выполнения критериальной цепочки, можно утверждать, что соответствующее требование в анализируемой системе удовлетворено.
Специальная структура данных (Traceability Matrix) на рис. 1 проектирует исходные требова-
А ВС D E
1 ID Identifier Requirements Scenario of Requirements Traceability
2 1 1639 When tie CCGW is ready to send the conventional channe out-of-seroce CP message to the ZC to lake the channel out of service, it shall send s proper STOP i:W message to the BS before it stops sending the link maiagement packets Note Tus is wien an actrve call is in irogress Transmission of STOP IMBE nessaqt is optonal 1) Rece*» CChstinefOovvn 2) Send CisStopBS 3) stop Ink 4) Send DhanneOutOfServiceRsquest 1639 rChanrelDownl
Рис. 1. Требование, цепочка (сценарий) и имя соответствующего ВР, кодирующего цепочку
ния (колонка Requirements) на критериальные цепочки (колонка Scenario for the Requirement). Каждая цепочка содержит события, выполнимость которых необходима для покрытия требования. В процессе формализации этот сценарий кодируется базовым протоколом (BP) [2] rChannelDownl (Колонка Traceability).
Базовый протокол кодирует минимальный наблюдаемый шаг поведения системы. BP - это аналог тройки Хоара, содержащий предусловие, постусловие и процесс (наблюдаемое действие, последовательность действий). Пред- и постусловия описывают подмножество состояний системы перед и после действий процесса, заключающегося в посылке сигналов или изменении значений переменных приложения. BP могут содержать символьные или конкретные значения параметров, причем для символьных задается диапазон возможных значений. BP может относиться к одному или нескольким требованиям, равно как и несколько BP или несколько цепочек BP могут относиться к одному требованию.
Множество BP составляет модель требований. Объединяя непротиворечивые пред- и постусловия различных BP, можно построить сценарии или трассы, позволяющие наглядно отображать возможные поведения проектируемой системы. Трассы, использующие символьные параметры, называются символическими. Корректность варианта поведения, фиксируемого конкретной или символической трассой, доказывается верификатором [3].
Совокупность трасс, покрывающая все цепочки всех требований, формирует модель требований разрабатываемого приложения. Эта модель может использоваться для генерации полного набора тестов, проверяющего функциональное покрытие всех конструктивно заданных требований.
Формализация архитектурной модели
Формальная модель требований на основе BP обладает серьезным недостатком: она со-
держит все возможные трассы, которые можно построить из BP. Даже для индустриальных проектов среднего размера это обстоятельство приводит к взрыву числа вариантов, которые следует учитывать при анализе. В то же время в приложениях важны не все поведенческие трассы, а только те, которые можно будет использовать для реализации функциональности, заданной требованиями [4].
Модель, отображающую реализацию функциональности, называют архитектурной. Она часто задается в нотации Use Case диаграмм (UCM [5]). UCM диаграммы (рис. 2) изображают причинно-следственные связи событий (Responsibilities) на путях от начальной точки (Start point) до конечной точки (End point). Каждое событие (Responsibility) на пути UCM диаграммы может быть закодировано BP. Путь может разветвляться в точках альтернатив (OrFork) или точках распараллеливания (AndFork), ветви могут соединяться в точках (OrJoin и AndJoin) и если необходимо -синхронизироваться. В путях могут использоваться таймеры (Timer) и поддиаграммы (Stub). Последовательность событий, описывающих поведение системы, задается набором взаимодействующих между собой диаграмм.
На сегодняшний день UCM представляет наиболее высокоуровневое описание проектируемой системы, сохраняющее при этом все сценарии поведения, она понятна и проста [11]. Высокоуровневое описание можно многократно детализировать, добиваясь ясности и корректности описания архитектуры системы.
Эта форма описания позволяет представителю заказчика участвовать в принятии решений на уровне архитектуры проекта, в текущем контроле проекта, в отслеживании расхождений семантики постановки задачи и ее реализации.
Критерии поведенческих сценариев
Критерии покрытия требований в тестовых сценариях генерируются из поведенческих моде-
Рис. 2. Представление поведения системы и взаимодействий между ее компонентами с помощью UCM
лей приложений. В данной статье как и в [10] используются архитектурные ИСМ модели.
Поскольку для событий иСМ диаграммы возможно однозначное отображение через ВР, критерием выполнения отдельных требований могут служить согласованные с заказчиком цепочки из ВР, содержащие последовательности активностей и состояний, подлежащих проверке в процессе тестирования.
Функциональным критерием стопроцентного выполнения требований на программный продукт служит покрытие всех цепочек на множестве всех исходных формализованных требований. Частным функциональным критерием качества является покрытие всех цепочек на фиксированном заранее подмножестве требований [1]. При этом детальность цепочек может различаться в зависимости от целей ее использования для верификации или тестирования.
Для целей верификации цепочкам достаточно описывать лишь наблюдаемую (измеряемую) часть функциональности, т. е. описывать последовательности событий и состояний в поведении системы, гарантирующих покрытие требования, но не обязательно следующих непосредственно друг за другом. Трассы, генерируемые в этом случае, могут не учитывать некоторые промежуточные события и состояния, не используемые при оценке покрытия.
Для целей тестирования в цепочке необходимо воспроизвести детальную последовательность событий, связанную с взаимодействием тестируемой системы с окружением, другими словами, учесть события обмена внешними сигналами, прерываниями (например, от таймеров)
и т. д. Трассы, генерируемые для целей тестирования, должны кроме воспроизведения поведения, необходимого для реализации некоторой функциональности, содержать полную последовательность событий и состояний, связанных с коммуникацией с окружением.
Таким образом, если в цепочке порядок поведения приложения (в виде последовательности ВР) задан частично, то в генерируемой для целей тестирования трассе необходимо полностью воссоздать этот порядок.
Рассмотрим структурные критерии тестирования поведения, использование которых совместно с функциональными обеспечивает необходимый уровень качества на этапах интеграционного и системного тестирования.
Структурные критерии связаны с покрытием определенных путей исходных ИСМ диаграмм генерируемыми трассами (тестовыми сценариями). Можно выделить структурные критерии базовых протоколов и цепочек.
По критерию базовых протоколов [6, 7] итоговый набор трасс состоит из трасс, покрывающих все базовые протоколы, т. е. каждый базовый протокол встречается, по крайней мере, один раз в трассах. Однако такой критерий достаточно слаб. Он соответствует известному критерию С0, который заключается в покрытии всех операторов тестируемой программы, по крайней мере, один раз в ходе исполнения тестового цикла. Данный критерий гарантирует покрытие всех функциональных требований только в случае, если каждое требование покрывается одним базовым протоколом. Однако критерий не гарантирует покрытие всех ИСМ путей, поскольку не учитывается тот
Рис. 3. UCM диаграмма верхнего уровня с элементом Stub1
факт, что несколько трасс могут содержать один и тот же базовый протокол. В результате в итоговом наборе трасс может присутствовать только одна из трасс, содержащих этот базовый протокол, соответственно другие пути, заданные UCM диаграммой, будут потеряны.
Например, если требуется покрыть требование, представленное элементом 6 на рис. 3, используя критерий базовых протоколов, то совсем не важно, по какому пути следует достичь элемента 6 из начального состояния 0. Достаточно только одной из трех трасс (1-2-3-6, 1-4-6 или 1-5-6), в то время как две другие не будут рассматриваться и будут потеряны. В результате два пути на UCM диаграмме не будут покрыты.
В случае использования критерия цепочек будут заданы все пути, содержащие цепочки базовых протоколов, ведущие к элементу 6. Критерий цепочек гарантирует присутствие соответствующих событий в итоговой трассе именно в той последовательности, которая необходима для покрытия требования.
По критерию цепочек итоговый набор трасс содержит трассы, покрывающие все цепочки из BP для всех требований. В этом случае ограничение на соответствие каждого требования одному BP снимается: каждое требование может быть представлено цепочкой BP, и покрытие требования означает, что все BP и соответствующие события произойдут в итоговой трассе в точно таком же порядке. Данный критерий соответствует известному критерию путей C2 («все пути потока управления программы должны быть покрыты»), ограниченному набором путей, учитывающих только важные для заказчика сценарии поведения тестируемого приложения. Без данного ограничения применение критерия в промышленных проектах становится бесполезным из-за экспоненциального взрыва числа возможных путей поведения.
Например, на рис. 3 трассы 1-2-3-6-8-9-10, 1-4-6-8-9-10 и 1-5-6-8-9-10, построенные по UCM
диаграмме, гарантируют покрытие не только базовых протоколов BP6 (6 на рисунке), BP8 (9) и BP9 (10), но также задают пути, на которых выполняются важные события, необходимые для покрытия соответствующих требований: элемент Stub1 (8) и базовые протоколы BP2 (2), BP3 (3), BP4 (4), BP5 (5).
Если цепочка для требования содержит альтернативу (например, 1-2-3-6, 1-4-6, 1-5-6, описываемую тремя цепочками), то необходимо сгенерировать три трассы для покрытия альтернативных цепочек. Если трассы, покрывающие альтернативные цепочки, не зависят от этой альтернативы, то трасса для некоторых тестов может быть укорочена путем удаления повторяющегося поведения. Например, набор трасс 1-2-3-6-8-9-10, 1-4-6-8-9-10 и 1-5-6-8-9-10 может быть заменен набором 1-4-6-8-9-10, 1-2-3-6 и 1-5-6.
Если трассы содержат абстрактные фрагменты с описанием поведения, заданного с помощью элемента Stub (например, Stub1 (8) на рис. 3), то трассы, представляющие поведение внутри элемента Stub, могут быть получены отдельно и
Stubl EndPant2 S7 Ь S3
Рис. 4. UCM диаграмма элемента Stub1
затем добавлены в итоговую трассу с детальным поведением.
Например, ИСМ диаграмма элемента Stub1 представлена на рис. 4. Поведение элемента описывается следующими трассами: S1-S2-S6-S7, S1-S3-S6-S7, S1-S4-S6-S7, S1-S5-S6-S7, а также идентичным набором трасс, оканчивающихся элементом S8 вместо последовательности элементов S6-S7. При подстановке детального поведения Stub1 в трассу, описывающую полное поведение системы, вход в Stub1 соединяется с элементом S1, выход S7 - с элементом 9, выход S8 - с элементом 7 на рис. 3.
Критерий цепочек - достаточно сильный критерий, т. к. из полного набора сгенерированных трасс выбираются лишь те, которые содержат определенные критериальные цепочки событий и состояний в определенной последовательности.
Итоговый набор выбранных трасс минимизируется и в результате содержит вхождение каждой цепочки в трассы по крайней мере один раз. Минимизированный набор трасс покрывает все требования на программный продукт. По этому набору осуществляется кодогенерация тестов.
Однако возможны ситуации, когда пользователю (тестировщику) необходимы определенные трассы, не вошедшие в итоговый набор. Существуют две причины такого непопадания:
трасса может присутствовать в полном наборе сгенерированных трасс, но исключаться из минимального набора, покрывающего все цепочки. Для исправления ситуации должны быть до-
бавлены дополнительные условия (события или состояния), т. е. измененные или дополнительные цепочки, чтобы сделать эту трассу отличной от других и, таким образом, добавить в минимальный набор трасс;
трасса не может быть представлена ни одним из путей на ИСМ диаграмме, т. к. на диаграмме отсутствуют необходимые дополнительные сценарии поведения. Обычно эти дополнительные пути состоят из тех же событий, что и начальные пути, но относятся к другим состояниям системы, что и создает различия. Различия, как правило, вызываются разными режимами функционирования системы, что приводит к уточнению спецификации в виде ИСМ диаграммы, и соответственно, к добавлению новых цепочек.
Описанный подход применен при тестировании индустриальных проектов, использующих VRS/TAT технологию верификации и тестирования [8], где показал существенную экономию трудоемкости на этапах формализации, генерации тестов и анализа тестовых циклов.
Использование критерия цепочек для оценки покрытия функциональных требований на систему сгенерированными тестовыми сценариями обеспечивает надежный базис при тестировании промышленных систем, гарантирующий высокое качество реализации по отношению к исходным спецификациям.
Работа поддержана грантом РФФИ 11-07-90412-Укр_ф_а.
СПИСОК ЛИТЕРАТУРЫ
1. Баранов, С.Н. Индустриальная технология автоматизации тестирования мобильных устройств на основе верификационных поведенческих моделей проектных спецификаций требований [Текст] / С.Н. Баранов, В.П. Котляров, А.А. Летичевский // Космос, астрономия и программирование. Лавровские чтения. -СПб.: Изд-во СПбГУ, 2008. -С. 134-145.
2. Letichevsky, A.A. Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications [Text] / A.A. Letichevsky, J.V. Kapitonova, V.P. Kotlyarov, O.O. Letichevsky [et al.] // Proc. of ISSRE04 Workshop on Integrated -reliability with Telecommunications and UML Languages. -IRISA Rennes France. -2 Nov. 2004.
3. Baranov, S. An Industrial Technology of Test Automation Based on Verified Behavioral Models of Requirement Specification for Telecommunication Applications [Text] / S. Baranov, V. Kotlyarov, A.
Letichevsky // Proc. IEEE Eurocon. -SPb, 18-23 May 2009. -8p.
4. Baranov, S. Implementation of an integrated verification and testing technology in telecommunication project [Text] / S. Baranov, V. Kotlyarov, A. Letichevsky // Proc. IEEE Russia Northwest Section, 110 Anniversary of Radio Invention Conf. -SPb, 2005. -11 p.
5. Recommendation ITU-T Z.151 User requirements notation (URN) - Language definition [Электронный ресурс] / Nov. 2008. -190 p.
6. Летичевский, А.А. Спецификация систем с помощью базовых протоколов [Текст] / А.А. Летичевский, Ю.В. Капитонова, В.А. Волков [и др.] // Кибернетика и системный анализ. -2005. -№ 4. -С. 3-21.
7. Baranov, S. Tools For Requirements Capturing Based on the Technology of Basic Protocols [Text]/ S. Baranov, J. Kapitonova, A. Letichevsky [et al.] // Proc. of SPb. IEEE Chapters. -2005. -P. 92-97.
8. Котляров, В.П. Автоматизация проектирования программного продукта под контролем заказчика [Текст] / В.П. Котляров, П.Д. Дробинцев // Ершовская конф. по информатике. Тр. рабочего семинара Наукоемкое программирование, 27 июня - 1 июля 2011. -Академгородок, Новосибирск. —С.124—131.
9. Carel, M. C0, C1 and C2 Coverage [Электронный ресурс] / M. Carel // Режим доступа: http://dev-logger.
blogspotcom/2008/06/c0-c1-and-c2-coverage.html
10. Amyot, D. Generation of Test Purposes from Use Case Maps [Text] / D. Amyot, M. Weiss, L. Logrippo // Computer Networks. - 2005. -№ 49 (5). -P. 643-660.
11. Hassine, J. Use Case Maps as a property specification language [Text] / J. Hassine, J. Rilling, R. Dssouli // Software and Systems Mod. -2009. -№ 8 (2). -P. 205-220.
УДК 004.056.53
С.А. Нестеров
методика построения и оптимизации комплекса средств защиты на основе результатов анализа рисков
В настоящее время большое распространение получил подход к построению комплексов средств защиты информационных систем (ИС), основанный на анализе и управлении рисками. Подобный подход позволяет рассматривать затрачиваемые на обеспечение безопасности средства и ресурсы как инвестиции в снижение рисков, связанных с информационной безопасностью (ИБ), и, в конечном счете, - в увеличение стабильности работы предприятия. Это позволяет в дальнейшем использовать общепринятые экономические показатели для оценки их эффективности.
Широко известен ряд методик проведения анализа рисков. Однако на практике их применение затрудняется сложностью получения требуемых достоверных оценок частот реализации различных угроз. Кроме того, большинство современных методик и основанных на них программных продуктов не рассматривают технические вопросы, связанные с совместной работой средств и механизмов защиты в той «внешней среде», которую формирует защищаемая ИС. Поэтому, несмотря на то что проведение подобного анализа позволит оценить риски, выбор конкретного набора средств защиты является отдельной задачей, один из подходов к решению которой описывается в данной статье.
Примеры методик анализа рисков
По типу используемой оценки существующие методики анализа рисков можно разделить на три группы:
использующие оценку риска на качественном уровне (например, по шкале «высокий», «средний», «низкий») — к таким методикам, в частности, относится Facilitated Risk Analysis Process (FRAP);
количественные (риск оценивается через числовое значение, например размер ожидаемых годовых потерь) — к этому классу относится методика RiskWatch;
использующие смешанные оценки (такой подход применяется в CRAMM, методике Майкрософт и т. д.).
Для примера рассмотрим методику анализа рисков, реализованную в системе RiskWatch [1]. Эффект от внедрения средств защиты количественно описывается с помощью показателя ROI (Return on Investment), характеризующего отдачу от сделанных инвестиций за определенный период времени. Рассчитывается он по формуле:
ROI = £ NPV(Benefits,) - £ NPV(Costs,), (1) i i где Costsi — затраты на внедрение и поддержание i-й меры защиты; Benefits. — оценка той пользы (т. е. ожидаемого снижения потерь), которую приносит внедрение данной меры защиты; NPV (Net Present Value) — функция, приводящая значения аргумента к ценам на один момент времени (учитывающая поправки на инфляцию и т. д.).
Для вычисления показателя Benefits необходимо ввести количественную оценку риска, и разница оценок до и после внедрения средств защиты даст искомое значение. Если рассматривать
