CC BY
18
2. Гадаснн В.А. Ушаков И.А. Надежность сложных информационно-управляющих систем. М.: Сов.радио, 1975.
3. Гадаснн В.Л. Интерполяционный метод оценки характеристик надежности ретрансляционных сетей с однородной структурой // АиТ. 1979.№8. С. 172-179.
4. Гадаснн В.А. Методы расчета структурной надежности сетей сложной конфигурации. М.: "Знание", 1984. С. 3-53.
5. Романовский В.И. Дискретные цепи Маркова. М.-Л.: Гостехиздат, 1949.
Тихомиров В.А., Котляров В.П.
Верификация программного обеспечения при интеграции
новой функциональности в существующую систему
Введение
На сегодняшний день, в связи с постоянным увеличением объема и сложности разрабатываемых систем, процесс интеграции новых компонент в уже существующую версию программного продукта становится ключевым. Это связано с тем, что процесс разработки компоненты проводится часто независимо от других компонент, и от того, как будет проводиться интеграция компонентов, зависит работоспособность всей системы. Целью интеграционного тестирования системы, расширенной новой функциональностью, является проверка того, как новый модуль согласуется с остальной частью программного продукта (с остальными модулями продукта).
Использование при интеграционном тестировании проверки на моделях (model checking) — известного подхода к верификации и тестированию программных систем — затруднено по причине отсутствия средств настройки на локальную задачу — тестирование "стыка" система / новая компонента. Если формальной модели системы нет. то ради тестирования стыка нужно потратить много усилий для их создания. Если модели системы и новой компоненты есть, то из них нужно выделить часть, которая необходима в рамках данной задачи. При этом предполагается, что система и компонента протестированы по отдельности. Это можно делать путем изменения процесса верификации, а можно создать новую модель.
Рассмотрим, каким образом можно изменить процесс верификации. При верификации компоненты отдельно от системы вызов системных функций (то есть функций, внешних для компоненты) не может быть проверен. Но если системе
верификации предоставить дополнительную информацию о системе (как реализованы соответствующие системные функции), то процесс интеграционной верификации будет проведен при верификации компоненты автоматически. Такой подход требует наличия полной спецификации компоненты, что в случае большого объема функциональности требует значительный объем ресурсов для полной верификации. Если компонента уже была протестирована, часть работы по верификации дублируется.
Рассмотрим другой подход к тестированию "стыка" —создание модели. В нее необходимо включить спецификации только тех участков кода системы и интегрируемой компоненты, которые отвечают за взаимодействие и создавая таким образом частичные модели (partial specifications) системы и компоненты. Последний вариант более выигрышный, потому что не требует наличия полных моделей системы и компоненты. Именно такой подход предлагается в данной статье. Несмотря на большое количество исследований в области частичных спецификаций (обзоры можно найти в работах [1,2, 3]), до сих пор эта идея не использовалась для интеграционного тестирования ПО.
Наш подход использует в качестве языка построения моделей базовые протоколы Летичевского [4]. Этот формализм создан в Институте Кибернетики НАН Украины и предназначен для формализации поведенческих аспектов программных систем. В качестве формы записи базовых протоколов мы вслед за [5] используем MSC-диаграммы [4]. Эти диаграммы являются языком описания поведения системы в виде последовательности событий и хорошо согласуются с парадигмой базовых
протоколов. В качестве инструментальных технологий предложено использовать систему верификации VRS [5] и систему тестирования ТА Г [6]. которые разработаны специально для базовых протоколов Летичевского.
В статье представлена схема и описание самого подхода, а также приводится пример, в котором в телекоммуникационную систему добавляется компонента, отвечающая за реализацию сервиса коротких сообщений (Short Message Service — SMS).
1. Частичные спецификации
При создании и использовании полной модели программного продукта возникают следующие трудности:
— создание такой модели требует больших трудозатрат;
— полные модели очень объемны:
— анализ и обработка модели требуют больших трудозатрат.
Построение и анализ моделей только для фрагментов программного продукта во многом решает описанные трудности. Такой подход носит название частичных спецификаций (partial specifications). Этот подход используется многими исследователями в различных областях программной инженерии (подробные обзоры содержатся в работах [1, 2. 3]). В статье приводится краткий анализ основных работ последних лет.
В [7] рассматривается ситуация, когда необходимо построить модель по требованиям к программной системе для последующего проведения тестирования. Для каждого требования строится своя спецификация на основе логики первого порядка. На выходе создается набор частичных спецификаций, каждая из которых соответствует определенному требованию. Разработка таких частичных спецификаций требует меньших трудозатрат по сравнению с полной спецификацией системы, поскольку не тратятся ресурсы на детальное описание связей между требованиями. Такая же идея лежит в основе использования базовых протоколов, используемых в данной статье как средство создания моделей ПО.
В [8] рассматривается способ задания конечного автомата с помощью частичных спецификаций. Описывается метод, позволяющий на основе частичных спецификаций обнаружить недостижимые или дублированные состояния автомата. После применения этого метода
становится возможным упростить конечный автомат и обнаружить возможные ошибки в его описании.
В [9] с помощью частичных спецификаций, описывающих конечный автомат, решается задача получения тестов, проверяющих интересующую область функциональности автомата. Традиционно сложно достижимые состояния автомата являются проблемным участком тестирования. В статье показано, как с помощью частичных спецификаций протестировать сложнодостижимые состояния с заданным функциональным покрытием.
В работе норвежских ученых [2] для объектно-ориентированной системы предлагается создавать формальные спецификации для каждого из объектов в отдельности. Построение таких спецификаций для любого объекта аналогично процессу создания.частичных спецификаций всей системы, то есть может проводиться независимо от других объектов. Такой подход является актуальным в современном процессе разработки распределенных систем, когда разработкой многочисленных модулей и компонент системы занимаются разные команды инженеров. В работе приводится методика объединения частичных спецификаций для получения полной спецификации системы, которая впоследствии может быть подвержена верификации и тестированию. Похожие принципы заложены в объектно-ориентированный язык программирования £7//е/', где при задании методов классов описываются пред- и постусловия, задаются инварианты класса.
Тестирование взаимодействия системы с другими модулями на основе частичных спецификаций рассматривается в статье [10]. Для исследуемой системы строится диаграмма внешних вызовов. Затем среди различных цепочек вызовов выделяются наиболее частые и для них строятся спецификации, основанные на исходном коде системы. При верификации и тестировании построенные частичные спецификации позволяют сфокусироваться на наиболее вероятных сценариях поведения системы. Однако при таком подходе цепочки вызовов, которые не были включены в выборку. вообще не подвергаются верификации, что на практике отрицательно сказывается на качестве продукта.
1 http://www.Eiffel.com
Выделяется работа японских ученых [11], в которой описывается методика построения частичных спецификаций программных компонентов. образующих целостную систему. По результатам исследования кода функциональность компоненты разделяется на два типа: с локальной и внешней областью действия. Фрагмент функциональности считается внешним, если ответственен за взаимодействие с другими компонентами: содержит вызовы их функций, использует глобальные переменные, доступные другим модулям. В противном случае он является локальным. После построения набора спецификаций становится возможным проводить тестирование внешнего взаимодействия отдельно от тестирования локальной функциональности компонента. Однако в статье основной акцент сделан на теоретические аспекты разделения функциональности, при этом практическое применение для реальных проектов не рассматривается.
2. Описание метода
Предложенный в данной статье метод представляет собой следующую последовательность основных шагов.
Шаг№1. Идентификация интерфейса взаимодействия.
Шаг №2. Идентификация регионов взаимодействующего кода.
Шаг №3. Построение модели.
Шаг №4. Верификация и тестирование.
Общая схема метода представлена на рис. 1.
Рассмотрим пошаговый процесс реализации метода.
Шаг№1. Идентификация интерфейса взаимодействия.
Все начинается с определения интерфейса взаимодействия. Артефакты компоненты, используемые системой, и артефакты системы, используемые компонентой, по сути, составляют интерфейс взаимодействия. Под артефактом понимается любая программная сущность, например функция, переменная или класс. Если доступен исходный код компоненты и системы, то артефакты, как правило, объявлены соответствующим образом (в отдельной секции программы или с использованием ключевого слова языка программирования). В случае, если исходный код недоступен, для некоторых языков программирования, возможно использование декомпиляторов. Формат записи интерфейса может, любым, при этом, наряду с именем артефакта и его описанием полезно описывать ограничения, накладываемые на артефакт.Например, с помощью формального языка зафиксировать тот факт, что функция вызывается в компоненте только с отрицательными параметрами. Добавление такой информации позволяет уже на данном шаге
Зона тестирования
Область системы, отвечающая за взаимодействие. Регионы этой области будут формализованы
КОМПОНЕНТА
Область компоненты, отвечающая за взаимодействие. Регионы этой области будут формализованы
Рис. 1. Схема метода
обнаружить ошибки. Результатом шага является построенный интерфейс взаимодействия компоненты и системы.
Шаг№2. Идентификация регионов взаимодействующего кода.
Для каждого артефакта интерфейса взаимодействия определяется область кода, в которой он реализован (для системных артефактов — в системе, для компонентных артефактов — в компоненте). Такие области назовем внутренними регионами. Поиск внутреннего региона сводится либо к поиску реализации (в случае функции или класса), либо к поиску инициализации и объявления (в случае переменной).
Под внешним регионом будем понимать область кода компоненты или системы, которая определяет параметры вызова внешней функции (изменения переменной или использования класса) и параметры, которые изменяются после внешнего вызова. Например, компонента в своем коде вызывает функцию системы с некоторым параметром. Внешним регионом вызова функции системы будет считаться то место в коде компоненты, которое определяет значение параметра перед вызовом функции системы, и те артефакты компоненты, которые изменяются после ее вызова.
Определение регионов осуществляется с помощью построенного на предыдущем шаге интерфейса взаимодействия. Поиск внешнего региона осуществляется следующим образом: если исходный код доступен, то производится поиск точек вызова функциональности системы из компоненты (или вызов функциональности компоненты из системы) в соответствии с построенным интерфейсом. Затем определяется окружение обнаруженной точки вызова. Чем более детально будет описаны внешних регионов и реализация для внутренних регионов, тем более будет точна спецификация интерфейса взаимодействия и результаты верификации.
На данном шаге удобно использовать автоматизированные кодоанализаторы (например. К1ос\Уогк2). Рассмотрим применение такого подхода на примере Юоскогк. При создании нового проекта в К1оскогк, содержащего компонент и систему, становятся видны все связи между ними. Каждой связи соответствует использование внешней функциональности с некоторыми параметрами. Отслеживание этих параметров в области вызова и реализации поз-
3 http://www.klocwork.com
воляет построить соответствующие регионы.
В случае, если код недоступен, в ряде случаев возможно использовать декомпиляцию кода.
Шаг №3. Построение модели.
На основе полученных регионов взаимодействующего кода системы и компоненты строится модель взаимодействия. Каждый регион подвергается формализации отдельно от других регионов в терминах базовых протоколов. В результате получаем набор спецификаций, соответствующий взаимодействующим регионам системы и компоненты. В случае внешнего региона спецификация описывает состояние компоненты или системы до вызова внешней функциональности, ее непосредственный вызов и состояние после внешнего вызова. Спецификация внутреннего региона описывает реализацию системной или компонентной функции. Таким образом, модель состоит из двух наборов спецификаций — формализованные регионы взаимодействующего кода системы и компоненты. Результат шага — построенная модель взаимодействия в терминах базовых протоколов.
Шаг №4. Верификация и тестирование.
На данном шаге построенная модель подвергается верификации и тестированию (например, используется система УЯЗ/ТАТ). Другими словами, проверяется соответствие спецификаций окружения внешних вызовов (внешние регионы) и реализации внешних артефактов (внутренние регионы). На данном шаге осуществляется контроль синтаксиса базовых протоколов, контроль связанности базовых протоколов друг с другом и генерация тестовых трасс. Полученные тестовые трассы являются готовыми сценариями, обеспечивающими полное функциональное покрытие выделенных регионов. Трассы можно использовать в качестве тестовых процедур в ручном тестировании или для генерации автоматических тестов для конкретной платформы, например используя технологию ТА Т. Если в процессе верификации и тестирования были найдены критические ошибки, то исходная система подвергается переработке и процесс повторяется, начиная с первого шага. Критерий критичности ошибок в каждом проекте свой. Например, в случае прототипа допускаются ошибки, не мешающие демонстрации основной функциональности. После данного шага принимается решение об исправлении ошибок или готовности продукта.
3. Пример
Данный метод апробирован на индустриальном проекте, в котором в качестве системы выступало ПО мобильного устройства, а в качестве компоненты диспетчер сообщений, обеспечивающий отправку, прием и хранение различных типов сообщений. Итак, рассмотрим применение предлагаемого метода на примере отправки SA/S-сообщений. В качестве новой компоненты выступает набор классов, отвечающих за 5Л/5-сервис. Методы этих классов используют функции, которые реализованы в системных модулях.
Для отправки 5'Л/5-сообщения необходимо инициализировать адрес, по которому будет, осуществляется отправка — открыть соединение. Рассмотрим пример реализации открытия соединения, описанный в компоненте.
Class Connection { ореп( ); close ( );
}
function open (port) { if (port >=0) {
S YS_OpenLow Level (port); //вызов функции системы
status = OPENED; //соединение
открыто
} else throw DataException;
)
Если значение порта (port) отрицательное, то функция open завершается (бросается исключение DataException). Системная функция SYS_OpenLowLevel обеспечивает установление соединения на низком уровне. После вызова метода SYS_Open Low Level соединение считается открытым (status = OPENED).
Рассмотрим применение метода по шагам.
Шаг №1. Идентификация интерфейса взаимодействия.
Компонента использует функцию системы SYS_OpenLowLevel. При этом система не использует функции компоненты, поэтому интерфейс взаимодействия ограничивается одной функцией.
Шаг №2. Идентификация регионов взаимодействующего кода.
Внешним регионом для 5 YSjOpenLowLevel является область кода функции open, где фильтруются значения номера порта. Внутренним регионом является область кода в системе, где эта функция реализована. Ниже представлена реализация данной функции:
function SYS_OpenLowLevel(port) {if (port <= 0) TERMINATE_PROGRAM; else SYS_ H WO PEN: }
Шаг №3. Построение модели.
Для формализации внешнего региона необходимо рассмотреть только случай неотрицательного значения порта (в случае отрицательного значения вызов внешней функции не производится).
На рис. 2 представлена спецификация на языке MSC, описывающая внешний регион компоненты.
Рассмотрим спецификацию детально. На рис 2. показано взаимодействие двух сущностей — Connection (соответствует классу Connection) и Sj'.v/cwlСистема). Предусловие PRE требует, чтобы соединение было в состоянии "закрыто". Постусловие POST показывает состояние соединения после вызова SYS_OpenLowLevel. В соответствии с реализацией соединение должно открыться (STA TUS = = OPENED). Событие 5 YSjOpenLow Level соответствует вызову функции S YSjOpenLow Level. В качестве параметра события выступает макрос #nonnegative_¡H>rts, который принимает множество неотрицательных значений.
При формализации внутреннего региона системной функции SYS_OpenLowLevel рассмотрим случай, когда порт равен нулю. MSC-диаграмма для этого случая представлена на рис. 3.
При реализации шага 3 система верификации для построенной модели обнаружила ошибку (см. рис. 2 и рис. 3). Когда значение порта нулевое, компонента вызывает системную функцию S YS _Ореп Low Level, которая терминирует выполнение программы при нулевом значении порта согласно ее спецификации. Ошибки можно было бы избежать, добавив проверку на ноль в компоненту (вместо "if (port >= 0)" написать "if (port > 0)").
Шаг №4 после построения спецификаций взаимодействия относится к технической части метода и не представляет практического интереса после того, как спецификации построены.
Заключение
В рамках данной статьи предложена методика тестирования взаимодействия компоненты и системы. Кроме того, методика также позволяет обеспечить тестирование взаимодействия нескольких компонент или нескольких систем.
Connection
System
PRE
Connection (closed)
ЭУЭ OpenLowLeve1
#nonnegative_ports POST
Connection (opened)
Рис.2. Внешний регион
Connect ion
System
PRE
Connection (closed)
S YS OpenLoTirLeve 1
0 г TERMINATE
■ж
POST
Connection (closed)
Рис. 3. Внутренний регион
Предлагаемый подход автоматизирует тестовый процесс и гарантирует полное покрытие функциональности при генерировании тестов. Данная методика апробирована на нескольких индустриальных проектах по разработке встроенного программного обеспечения. Предварительные оценки трудоемкости на примерах проектов среднего размера (около 100 требований) подтвердили его эффективность: цикл
тестирования был сокращен на 3 человека-месяца по сравнению с обычным тестированием. Кроме того, были найдены дополнительные ошибки. В настоящее время метод применяется в больших индустриальных проектах.
В дальнейшем планируется расширить функциональность системы верификации для проведения интеграционных проверок на основе предложенного метода. Теорети-
ческая составляющая основа верификатора построена и проходит апробацию в больших индустриальных проектах разработки ПО. Также планируется определить формат и способы составления словарей внешних вызовов функциональности компоненты и системы. Формализация словарей упростит
многие шаги метода и позволит проводить верификацию уже на первых этапах разработки программного продукта. Разработка указанных улучшений предоставит возможность полной автоматизации интеграционного тестирования, обеспечивая заданное тестовое покрытие.
СПИСОК ЛИТЕРАТУРЫ
1. Easterbrook, S„ Callahan. J. 1997. Formal Methods for Verification and Validation of partial specifications: A Case Study. Virginia University symposium, vol. 1, 1997. 26-37.
2. Johnsen, E. B., Owe, O. 2002. Composition and Refinement for Partial Object Specifications. Parallel and Distributed Processing Symposium, 2002,210-217.
3. Hendrix, J., Clavel, M., Meseguer, J. 2005. A Sufficient Completeness Reasoning Tool for Partial Specifications. Proceedings of the 16h International Conference on Rewriting. LNCS, vol. 3467. 2005. May 31. Springer. 165-174.
4. Letichevsky, A.A., Kapitonova, J.K. 2004 Basic Protocols, Message Sequence Charts, and the Verification of Requirements Specifications. Proceedings of International Workshop. WITUL. 2004, 30-38.
5. Baranov, S.N., Kotlvarov, V.P., Letichevsky, A.A. 2005. The technology of automation verification and testing in industrial projects. IEEE Russia Northwest Section. The International Scientific Conference "110 Anniversary of Radio Invention" Saint Petersburg. 2005. 12-34.
6. Kotlvarov, V.P., Golubev, A.A., Karpov, A.N.
2006. Testing Automation for system core kJava applications. Consumer Electronics, 2006, 1-4.
7. Falcone, Y., Fernandez, J.C., Mourner, L., Richier ea. 2007. A Compositional Testing Framework Driven by Partial Specifications. TestCom FATES. 2007, 107-122.
8. Petrenko, A., Yevtushenko, N. 2005. Testing from Partial Deterministic FSM Specifications. IEEE Trans. Computers, vol.54. No. 9. 2005. 1154-1165.
9. Petrenko, A., Yevtushenko, N. 2000. On Test Derivation from Partial Specifications. Procedings of IFIP Joint International Conference Formal Description Techniques, 2000, 85-102.
10. Acharya, M., Xie, T., Pei. J. ea. 2007. Mining API patterns as partial orders from source code: from usage scenarios to specifications. Proceedings of SIGSOFT Seminar. 2007, 25-34.
11. Aoshima, T., Yonezaki, N. 2000. An Efficient Tableau-Based Verification Method with Partial Evaluation for Reactive System Specifications. Proceedings of EJC Conference. 2000. 363-374.
Мезенцева О. С., Алексеев А. И.
Применение аппарата пороговых схем и модулярной
арифметики для повышения производительности распределенных вычислительных систем
Распределенные вычислительные системы, основанные на широко используемом в задачах криптографии аппарате пороговых схем, имеют ряд отличительных особенностей. Основными преимуществами таких систем являются высокая устойчивость к потере связи между участниками и возможность проверки информации, поступа-
ющей от каждого узла. Малая чувствительность к выходу одного или нескольких участ ников из процесса вычислений следует из избыточности хранимых данных, однако для распределенных систем, подверженных частой потере связи с вычислительными узлами, такой подход представляется оправданным. Так, в [1] освещается
