CC BY
49
УДК 004.415.53
А.О. Веселов, В.П. Котляров
АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ ПРОЕКТОВ В ОБЛАСТИ ТЕЛЕКОММУНИКАЦИЙ
Тестирование - неотъемлемый этап любого современного процесса промышленной разработки программного обеспечения. На сегодняшний день использование до 40 % ресурсов на тестирование не является чем-то необычным для компании, производящей программные продукты. Поэтому вопросы автоматизации и эффективности тестирования весьма актуальны.
В статье описываются этапы технологии, объединяющей верификацию, тестирование и генерацию кода с целью повышения качества продукта, уменьшения трудоемкости и сокращения стоимости. В основе предлагаемого подхода лежит идея переиспользования результатов, полученных на этапе верификации. Верификация позволяет не только повысить качество и формально доказать отсутствие ошибок в алгоритме, но и создает модель системы, подмножество путей дерева поведения которой может рассматриваться как тестовые сценарии. Число таких путей в индустриальных проектах огромно, поэтому требуются специальные фильтрующие техники для получения подходящего (оптимального) тестового набора. Этот подход применим не только для автоматизации создания функциональных тестов, но также и для автоматической проверки соответствия стандарту в том случае, если имеется формальная модель соответствующего стандарта.
На практике соответствие стандарту проверяется достаточно большим количеством тестов, создаваемых вручную. Предлагаемый подход позволяет избежать ручной работы за счет переиспользования результатов этапа верификации.
Статья раскрывает основные принципы автоматической генерации тестовых наборов на основе формальных спецификаций, представленных на языке базовых протоколов, при помощи инструмента верификации VRS [1, 2] и инструмента автоматизации тестирования TAT [3].
Общее описание технологии
Рассматриваемая технология обеспечивает частичную автоматизацию ручной работы в про-
цессе создания программного обеспечения, путем генерации кода из высокоуровневых моделей, и повышение качества продукта за счет интеграции верификации и тестирования.
Общий обзор технологии показан на рис. 1. Создание программного продукта начинается с интерпретации и формализации требований.
Шаг 1. Формализация. Инженеры создают модель системы в терминах базовых протоколов. Базовый протокол - это формальное описание некоторого действия, которое происходит в том случае, если система из некоторого определенного состояния (предусловия) переходит в новое состояние (постусловие). Другими словами, базовый протокол - это маленький «фрагмент поведения» системы. Базовые протоколы представляются в следующей нотации:
VX : а(X) ^(X) > ß(X),
где X - это список параметров протокола; а -предусловие; ß - постусловие; ц - действие; а, ц и ß могут зависеть от X. Это «тройка Хоара» [4].
Формализм базовых протоколов основывается на теории агентов и сред с инсерци-онной функцией [5]. Она была предложена А.А. Летичевским для создания поведенческих моделей систем, пригодных для верификации [6, 7]. Базовый протокол - это небольшая MSC диаграмма [9].
Два базовых протокола могут быть последовательно соединены, если постусловие одного эквивалентно предусловию второго. Комбинации соединений протоколов образуют дерево поведения. Каждый путь в таком дереве - это сценарий возможного поведения системы.
Формализация во многом ручной процесс, но и она в некоторой степени может быть автоматизирована или упрощена. Например, пользователь может проводить формализацию в терминах поведенческих сценариев (Use Case Maps (UCM) [8] или Message Sequence Charts (MSC) [9]) или UML [10] моделей. Существуют специальные инструменты для генерации базовых протоколов из UCM, MSC и UML.
Legend:
—► TAT —► VRS
—► Sdl2cpp .......► Manual
Requirements
Formalization......
_L
Basic protocols model
\ i
/
s
Verification
SDL MSC Tolerance
/ model \ \ scenarios range
Model code generation
Model in С++
Test suite eneration
Test suite in С++
Testing of a model
Lowering
Production basic protocols model
Generation of___
product
^ Trace generation
SDL model
MSC scenarios
Product code" generation
Test suite .generation
Product in Test suite
С++ < ► in С++
Tolerance range
Testing of a product
Рис. 1. Обзор технологии
Шаг 2. Верификация. На модели системы, представленной в терминах базовых протоколов, проверяются различные свойства при помощи VRS.
Набор базовых протоколов может быть интерпретирован как набор состояний и переходов, т. е. как автомат. Имея автомат, описывающий поведение системы, возможно сгенерировать код системы на целевом языке. Однако прямая генерация целевого кода не всегда эффективна, поэтому используется промежуточное представление. В качестве промежуточного языка выбран SDL (Spécification Description Language) [11] - простой
и достаточно известный язык описания автоматов. Наличие промежуточного языка делает отладку моделей более удобной.
Шаг 3. Преобразование проекта из базовых протоколов в SDL код. Соответствующее преобразование осуществляется автоматически.
Шаг 4. Генерация целевого исполняемого кода. Для генерации С++ используется инструмент Sdl2cpp, он интегрирован в общую технологическую цепочку. Sdl2cpp дополнительно генерирует конфигурационный XML файл для TAT (Test Automation Toolset) [3] с описанием тестового окружения. Таким образом, в случае использования Sdl2cpp вместе с TAT, конфигурирование тестового окружения происходит без участия пользователя (при этом пользователь решает задачи адаптации к целевой платформе путем корректировки автоматически заданных настроек).
После получения исполняемого кода и настройки тестового окружения становится возможным автоматическое тестирование и симуляция в реальном времени. На этом этапе достаточно удобна возможность пошаговой симуляции (например, в IBM Rational Suite [12]) с отслеживанием поведения системы в графическом режиме.
Шаг 5. Создание критерия тестового покрытия. Модель в терминах базовых протоколов -это дерево поведения с огромным числом возможных сценариев. Покрыть такое дерево тестами практически невозможно, поэтому требуется специальный критерий фильтрации.
В описываемой технологии используется критерий цепочек, который позволяет обеспечить покрытие функциональных требований с помощью относительно небольшого тестового набора. Критерий требует создания «цепочки» для каждого требования [13]. «Цепочка» - это последовательность ключевых воздействий и реакций тестируемой системы, соответствующих поведению, необходимому для проверки покрытия некоторого требования.
Создание цепочек - это процесс интерпретации требований, поэтому эта работа выполняется вручную. Процесс создания цепочек значительно упрощается и частично автоматизируется, если заказчик предоставляет требования в некоторой формальной нотации, например, в виде UCM или MSC.
Шаг 6. Генерация тестовых сценариев. VRS использует цепочки для «направленного» поиска
в дереве поведения модели тестируемой системы и генерирует трассы, если в модели удается найти путь с заданными в цепочках последовательностями событий. В результате появляется набор трасс (MSC), покрывающих функциональные требования.
Шаг 7. Из MSC сценариев происходит генерация исполняемого кода тестов и тестового окружения на целевую платформу. Здесь же осуществляется замена символических параметров MSC сценариев конкретными значениями, взятыми из областей их допустимых значений.
Шаг 8. Исполнение тестов из тестового цикла.
Шаг 9. Детализация. Верификация индустриальных проектов требует абстрагирования от некоторых деталей. Поэтому модель из базовых протоколов следует детализировать после верификации и перед генерацией кода продукта. Обычно требуется поддерживать две модели в рамках одного проекта: высокоуровневая модель для верификации, моделирования и симуляции и детализированная модель для генерации и тестирования кода продукта. Каждая модель требует свой собственный тестовый набор.
Обычно детализация подразумевает добавление пропущенных параметров сигналов, раскрытие функциональных «заглушек». Например, когда сложное поведение абстрагировано в одном сигнале. Детализация, так же как и формализация, является во многом ручной работой.
За детализацией модели следует генерация соответствующего ей кода целевого продукта. Для этого необходимо повторить шаги 3 и 4 для детализированной модели, а для генерации соответствующего тестового набора - шаги 6 и 7 (шаг 5 не обязателен, т. к. цепочки высокоуровневой модели подходят и для низкоуровневой).
Автоматизация тестирования
Четыре шага (5-8) описанной технологической цепочки относятся к получению и исполнению тестов.
Создание тестов начинается с интерпретации требований и формулирования критерия покрытия в терминах цепочек. Эти цепочки используются для направленного поиска в дереве поведения модели, и, как результат, из бесконечного набора поведений системы выбирается конечное число тестовых сценариев, покрывающих функциональ-
ные требования. Специальный скрипт используется для выбора минимального тестового набора из сгенерированных инструментом VRS трасс. Этот скрипт также размечает трассы (MSC), отмечая в них начало и конец проверки требования, а также события, заданные в цепочке.
VRS может работать в двух режимах. Первый режим - это обычная верификация (model checking), где все параметры имеют конкретные значения. Второй режим называется «символическим», т. к. параметры содержат символические значения, а область допустимых значений параметров вычисляется после применения каждого базового протокола. Таким образом, в случае «символического» режима существует дополнительный шаг - замена в MSC трассах символических параметров конкретными значениями, взятыми из области допустимых значений.
Одна диаграмма с символическими параметрами в действительности описывает набор эквивалентных поведений (одинаковая последовательность сигналов для любых значений параметров из допустимого диапазона). Принимая во внимание ограничения на параметры и зависимости между параметрами, из одной «символической» диаграммы можно сгенерировать несколько тестов.
Будем называть профилем один (из множества возможных) набор значений параметров для одной символической диаграммы. Обычно используются следующие профили:
«минимальный» профиль - все независимые параметры имеют минимальные (из области допустимых) значения;
«максимальный» профиль - все независимые параметры имеют максимальные (из области допустимых) значения;
«случайный» профиль - все независимые параметры имеют случайные (из области допустимых) значения;
«ошибочный» профиль - хотя бы один из параметров имеет значение, не попадающее в допустимую область. Тест с ошибочным профилем должен всегда заканчиваться фиксацией ошибки.
Для генерации тестового набора на целевом языке на основе MSC сценариев с подставленными значениями и файла с описанием окружения (в формате XML) используется TAT .
Генерация тестового набора состоит из нескольких основных шагов:
анализ конфигурационного XML файла и генерация кода тестового окружения, зависимого от настроек конфигурации;
генерация абстрактного тестового набора (Abstract Test Suite (ATS)) - представления тестового набора в виде системы состояний и переходов на языке tcl. ATS генерируется на основе набора MSC;
генерация целевого кода тестового набора на основе ATS.
TAT имеет достаточно гибкий механизм шаблонов генерации кода. При помощи шаблонов TAT может быть настроен на генерацию кода на любом целевом языке. В основном используется шаблон для генерации C++, но ряд других языков также поддерживается, включая Java SE, Java ME и TTCN-3.
Сгенерированный тестовый набор взаимодействует с тестируемой системой при помощи IP (TCP/UDP) или IPC (STRAM/DATAGRAM) со-кетов. В конфигурационном XML файле задается следующая информация:
тип используемых сокетов; код инициализации, исполняемый в начале каждого теста;
код, выполняемый в конце каждого теста; время ожидания входящих сообщений; код, отвечающий за распознавание сигналов; код сериализации/десериализации сообщений (генерируется автоматически при использовании Sdl2cpp);
описание инстанций MSC диаграмм и их интерфейсов (генерируется автоматически при использовании Sdl2cpp);
разделитель входящих сообщений (генерируется автоматически при использовании Sdl2cpp).
TAT и Sdl2cpp тесно интегрированы друг с другом. Sdl2cpp может не только генерировать целевой код из SDL, но также полностью настраивать TAT для тестирования этого кода. Наряду с автоматической поддерживается возможность ручной настройки. Конфигурация TAT хранится в двух файлах: первый генерируется Sdl2cpp, второй создается вручную. При наличии противоречащих настроек приоритет отдается второму файлу.
Результатом запуска сгенерированного тестового набора являются лог файлы, представленные в формате MSC и в текстовом формате. Специальный инструмент (Offline Test Results Analyzer (OTRA)) сравнивает исходные MSC диаграммы с
MSC-логами и создает суммарный тестовый отчет. Каждая запись в этом отчете - это ссылка на более подробное описание деталей сравнения и причин ошибки.
Предлагаемый подход автоматической генерации тестовых наборов на основе формальных спецификаций позволяет значительно сократить усилия и временные затраты на создание тестов. Естественно, он не может быть применен для проверки любого требования, т. к. иногда требования не могут быть выражены в терминах MSC диаграмм или последовательности ключевых событий. Для таких требований тесты приходится создавать вручную. Но на практике (особенно в области телекоммуникаций) большинство требований могут быть автоматически покрыты тестами в случае применения данной технологии.
Автоматизация создания функциональных тестов является не единственным преимуществом данного подхода, он также может быть применен для проверки на соответствие с определенным стандартом взаимодействия между тестируемой системой и окружением, что очень важно для телекоммуникационных проектов.
Автоматизация проверки соответствия стандартам
Процесс тестирования на совместимость и соответствие стандартам зачастую является достаточно долгим и трудоемким. Однако обойтись без него нельзя, т. к. стоимость выпуска продукции, не соответствующей стандартам, значительно превосходит затраты на тестирование.
Вопрос здесь может быть поставлен следующим образом: если имеется некоторая система, которая взаимодействует с тестовым окружением или другими системами, как определить, происходит ли это взаимодействие в соответствии с некоторым стандартом или нет. Другой важный вопрос - имеются ли противоречия в спецификации стандарта.
Предлагаемый подход проиллюстрирован архитектурной схемой (рис. 2), ориентированной на решение этих вопросов.
Шаг 1. Верификация, в рамках которой проверяется корректность стандарта. Верификация стандарта - это не простая задача. Формализация его спецификации - самая сложная часть этого шага, требующая серьезных усилий. К сожалению, формализация с большим трудом поддается полной автоматизации, т. к. это процесс
понимания и интерпретации требований. Однако верификация позволяет не только формально доказать отсутствие ошибок, но и помочь ответить на первый вопрос.
В случае использования нотации базовых протоколов, формализованная модель представляет собой набор состояний и переходов между ними, т. е. автомат. Этот автомат может быть использован как оракул процесса тестирования, если поместить его между тестируемой системой и тестовым окружением или между тестируемой системой и другими системами (которые соответствуют проверяемому стандарту).
Шаг 2. Генерация целевого кода для этого
Legend:
—► TAT —► Sdl2cpp —► VRS ........► Manual
Verification
Standard's specification
Formalization
Basic protocols model
Oracle code generation.
Oracle with sniffer in С++
Serialization /
"I
I deserialization code _i_L
Sniffing messages and, taking a decision about compliance to the standard
Test env
Serialization / deserialization
Trace generation
Production basic protocols model
Рис. 2. Схема проверки соответствия приложения стандарту
автомата и использование его совместно с агентом наблюдения за поведением исследуемой системы (в простейшем случае таким агентом может являться обычный сниффер пакетов). Для генерации целевого кода такого автомата возможно использование ядра TAT.
Обычно когда инструмент Sdl2cpp генерирует целевой код системы из SDL, он также генерирует функции сериализации и десериализации для каждого типа данных и для каждого сигнала, который может быть послан в окружение или получен из него. Эти функции используются для кодирования и декодирования сообщений как на стороне тестируемой системы, так и на стороне окружения, генерируемого при помощи TAT. Другими словами, Sdl2cpp автоматически настраивает TAT и предоставляет ему API для кодирования и декодирования сигналов. Это делает обмен сообщениями «прозрачным» для пользователя, работающего на уровне абстракции сигналов и не беспокоящегося о том, что в действительности пересылается по сокетам. При этом поддерживается возможность наблюдения за сообщениями на уровне сокетов. Аналогичная идея применима и для оракула, который также, в свою очередь, нуждается в средстве сопоставления сообщений сокетов с высокоуровневыми сигналами.
Таким образом, оракул, проверяющий соответствие системы стандарту, будет состоять из следующих частей (рис. 3):
автомат, сгенерированный инструментами TAT на основе модели стандарта, представленной в терминах базовых протоколов;
код десериализации сообщений, сгенерированный Sdl2cpp;
агент наблюдения за поведением системы. Шаг 3. Тестирование. На этом шаге система и окружение взаимодействуют в обычном режиме (при помощи обмена сообщениями через сокеты), и единственным отличием является наличие оракула, который при помощи агента наблюдения за поведением перехватывает сигналы, декодирует их и принимает решение о соответствии стандарту.
Решение о соответствии стандарту принимается по следующему алгоритму.
1. Оракул перехватывает сообщение и пытается декодировать его. Если сообщение не удается декодировать, то оно не соответствует стандарту.
2. Если сообщение успешно декодировано, оракул проверяет наличие перехода из текуще-
Conformance oracle
<— ■Deserialization
State machine, code, generated
generated by by Sdl2cpp a
TAT on base ---------1_
standard's Agent for i
model in terms behavior
of basic observation
protocols (sniffer)
Рис. 3. Оракул
SUT
ад а
•в
«
о H
Test environment
го состояния, где условием перехода является получение данного сигнала. Если такого перехода не существует, то система не соответствует стандарту.
3. Оракул проверяет параметры сигнала. Если значения параметров находятся в области допустимых значений, оракул производит переход на следующее состояние и ожидает прихода следующего сигнала, в противном случае - система не удовлетворяет стандарту.
Уверенность в том, что система соответствует стандарту, растет в зависимости от количества запущенных тестов при включенном оракуле.
Разработанный подход к автоматизации тестирования был успешно применен в нескольких достаточно крупных проектах в области телекоммуникации.
Наибольшая эффективность, измеряемая сокращением трудоемкости и сроками сдачи продукта, достигается в случае применения этого подхода как части описанной общей технологии.
Предлагаемый подход к проверке системы на соответствие стандартам, перспективен, несмотря на сложность формализации стандартов, и позволяет значительно повысить качество программного продукта.
СПИСОК ЛИТЕРАТУРЫ
1. Drobintsev, P.D. Integrirovannaia tehnologia obespechenia kachestva programmnih produktov s pomoshiu verifikacii i testirovania [Текст]ЯШ. Drobintsev// Kand. dis., SPbGPU.-2006.-238 p.
2. Letichevsky, A. Basic protocols, message sequence charts, and the verification of requirements specifications [Текст]/А. Letichevsky, J. Kapitonova, Jr.A. Letichevsky [et al.]//Computer Networks: The International Journal of Computer and Telecommunications Networking.-Dec. 2005.-Vol .49-№ 5.-P. 661-675
3. Веселов, А.О. Автоматизация тестирования телекоммуникационных приложений [Текст]/А.О. Веселов, А.С. Иванов, Б.В. Тютин, В.П. Котляров//Научно-технические ведомости СПбГПУ-2009.-№ 3.
4. Hoare, C.A.R. Communicating sequential processes [Текст]/С.А.К Hoare. -Prentice Hall, London, 1985.
5. Letichevsky, A.A. Insertion Programming [Текст]/ A.A. Letichevsky, J.V. Kapitonova, V.A. Volkov [et al.]// Cybernetics and Systems Analysis.-Jan. 2003.-Vol. 39.-Iss. 1.-P. 16-26.
6. Letichevsky, A.A. System Specification with Basic Protocols [Текст]/А.А. Letichevsky, J.V. Kapitonova,
V.A. Volkov [et al.]//Cybemetics and Systems Analysis.-Jul. 2005.-Vol. 41.-Iss. 4.-P. 479-493.
7. Baranov, S. Leveraging UML to deliver correct telecom applications in UML for Real: Design of Embedded Real-Time Systems [Текст]/?. Baranov, C. Jervis, V. Kotlyarov [et al.]; by L.Lavagno, G. Martin, B. Selic (editors). -Kluwer Academic Publishers, 2003. P. 323-342,
8. Recommendation ITU-T Z.151. [Электронный ресурс] User requirements notation (URN), 11/2008.
9. ITU Recommendation Z.120. [Электронный ресурс] Message Sequence Charts (MSC), 11/99.
10. OMG Unified Modeling Language. [Электронный ресурс] http://www.omg.org/spec/UML/2.2/
11. ITU-T Recommendation Z.100. [Электронный ресурс] CCITT Specification and Description Language (SDL), 03/93.
12. IBM Rational SDL Suite [Электронный ресурс] http://www-01.ibm.com/software/awdtools/sdlsuite/
13. Воинов, Н.В. Верификация и автоматизация тестирования UML проектов [Текст]/Н.В. Воинов, В.П. Котляров//Научно-технические ведомости СПбГПУ- 2009.-№ 3.
