CC BY
29
СПИСОК ЛИТЕРАТУРЫ
1. Костюхин К.А. Отладка систем реального времени: Обзор. М.: НИИСИ РАН, 20()3. (http:// citforum.univ.kiev.ua/program ming/d igest/ rtsdebug.shtml).
2. Авербух BJI., Байдалин А.Ю., Исмагилов Д.Р., Казанцев А.Ю. Трехмерные методики визуализации программного обеспечения параллельных и распределенных вычислений // Параллельные вычислительные технологии (ПаВТ'2008): Труды Междунар. науч. конф., Санкт-Петербург, 28 января — 1 февраля 2008 г. Челябинск: Йзд-во ЮУрГУ, 2008. С. 283-288. (Электрон, издание; УДК 004.75).
3. http://www.vampir.eu/
4. Мапаков Д.В. Анатиз параллельных визуальных технологий // Вычислительные технологии. Т. 12. № 1. 2007. С. 45-60.
5. Байдалин А.Ю., Гусева Е.М., Даеннчева A.A., Исмагилов Д.Р., Казанцев А.Ю., Манаков Д.В. Разработка средств визуализации для системы параллельного программирования DVM // Проблемы теоретической и прикладной математики: Труды 34-й Регион, молодежной
конф., Екатеринбург, 27—31 января 2003 г. (http://www.cv.imm.uran.ru/uploads/ www_cv_imm_uran_ru/basic_upload/3495/Baj-Kung03.htm).
6. Гусева М., Минаев Д., Ткаченко Р. Визуальные средства создания, отладки и анализа программ для параллельных вычислений / ННГУ им. Н.И. Лобачевского// (http://www.itlab.unn.ru/ file.php?id=332).
7. Авербух В.Л. Специализированные системы научной визуализации // Труды Междунар. конф. Снежинск: РФЯЦ-ВНИИТФ, 2005. (http://www.cv.imm.uran.ru/uploads/ www_cv_imm_uran_ru/basic_upload/3474/so.pdf).
8. http://company.gettvimages.com/ (royalty-free images).
9. Brown M.H., Hershberger J. Color and Sound in Algorithm Animation // Computer. Vol. 25. № 12. 1992. P. 52-63. (doi:10.1109/2.179117).
10. Pollack and M. Ben-Ari. Selecting a visualization system // Third Program Visualization Workshop. 2004. P. 134—140. (http:// www.dcs.warwick.ac.uk/pvw04/pl9.pdf).
УДК 681.3
А.О. Веселов, A.C. Иванов, В.П. Котляров, Б.В. Тютин
АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ ТЕЛЕКОММУНИКАЦИОННЫХ
ПРИЛОЖЕНИЙ
Телекоммуникационный сектор сегодня — один из наиболее бурно развивающихся секторов в области, связанной с разработкой качественного программного обеспечения. И здесь все большее внимание уделяется усовершенствованию методов тестирования.
Решение проблемы повышения качества программного продукта и эффективности тестирования возможно через использование методов автоматической генерации тестов и компактной нотации формального задания тестовых наборов. Немаловажен и фактор читабельности тестовых алгоритмов, достигаемый за счет визуализации формальных описаний.
В данной статье предлагается подход к тестированию телекоммуникационных си-
стем, реализованный в инструментальной системе в автоматизации тестирования TAT (Test Automation Toolset) [I]. TAT обеспечивает автоматическую трансляцию спецификаций. заданных в форме MSC-диаграмм (Message Sequence Charts), в исполняемый целевой код тестов и его последующий прогон. Эта трансляция контролируется специальными инструментами, позволяющими ввести дополнительную синхронизацию, раскрыть недетерминизм и т. д.
Технологическая цепочка TAT. Система представляет собой набор инструментов автоматизации тестирования, объединенных в технологической цепочке (рис. I). Каждый из этих инструментов отвечает за определенные преобразования входных дан-
I
Конференция "Технологии Microsoft в теории и практике программирования"
MSC
XML config
TAT
1
Test-suite in target
Compilation
Execution
a
a
Verdict
Рис. I. Технологическая цепочка TAT
пых, изначально заданных в формате диаграмм MSC. Модульность построения системы допускает как самостоятельное использование отдельных ее подсистем, так и их произвольные комбинации, диктуемые проектной необходимостью.
В состав системы автоматизации тестирования TAT входят следующие инструменты: макропрепроцессор, генератор абстрактных тестов, шаблоны генерации кода, модуль автоматического анализа результатов.
Рассмотрим подробнее функциональность основных модулей.
Макропрепроцессор (МПП) — осуществляет подстановку значений макроподстановок, раскрытие параметризованных ссылок и циклов, вычисление условных выражений. На вход макропроцессора поступают MSC с описанными макроподстановками в формате XML. на выходе получается набор простых MSC, содержащих константы вместо символьных имен. Макропрепроцессор может использоваться в режиме подсчета числа возможных комбинаций макроподстановок и показа их значений. Этот режим помогает задать правило выбора конкретных комбинаций.
Генератор абстрактных тестов (ГAT) — главный модуль TAT. Он принимает на вход MSC-сценарии. описание типов данных в формате XML, взаимодействующих объектов и используемые сообщения, а на выходе создает абстрактный тестовый набор (АТН). Преобразование АТН в тесты на целевом языке осуществляется при помощи кодогенерирующего шаблона. Генератор абстрактных тестов может производить вычисление временной спецификации. Важное свойство ГАТ — выполнение проверки входных описаний с точки зрения коррект-
ности получения исполнимого кода. Проверяется направление посылки сообщения, количество параметров сообщений и их типы.
Шаблоны генерации кода (ШГТ) — используются для генерации целевого кода на основе абстрактного тестового набора, полученного при помощи ГАТ. В шаблоне должна содержаться реализация вызываемых в АТН процедур. Последовательность вызовов процедур в АТН имеет линейную структуру. Каждый вызов отвечает за некоторое событие, описываемое на MSC-ди-аграмме. Все параметры события переносятся в АТН в виде параметров процедур. Таким образом, процесс кодогенерации представляет собой последовательную выгрузку блоков целевого кода, соответствующих определенному событию, в выходные файлы. Модификация внутренних параметров блока производится относительно входных параметров вызываемой процедуры в АТН.
Модуль автоматического анализа результатов — предназначен для анализа результатов тестирования путем сравнения лог-файлов в формате MSC с исходными диаграммами. В результате работы данного модуля автоматически генерируется отчет о тестировании.
TAT позволяет получать тесты уже на ранних стадиях разработки программного обеспечения. Начиная со стадии анализа требований и проектирования, они могут разрабатываться, отлаживаться и совершенствоваться параллельно с реализацией программного продукта.
Разработчик тестов создает тестовые сценарии, используя MSC-редактор. Далее тестовые сценарии при помощи модулей TAT автоматически превращаются в абстрактный тестовый набор на языке Tel.
На следующем шаге необходимо воспользоваться шаблоном генерации целевого кода. Соответственно его задача состоит в преобразовании абстрактного тестового набора с языка Tel в целевой код. Использование кодогенерируюшего шаблона позволяет максимально гибко подходить к созданию автоматизированного тестового набора при использовании TAT. На данном этапе существует необходимость корреляции разработки и использования шаблона с дизайном MSC-сценариев тестового набора. Необходимо учитывать подход и степень детализации, принятые при проектировании диаграмм.
В заключение создания тестового набора необходимо провести его конфигурирование и настройку на взаимодействие с конкретной тестируемой системой. Методика выполнения данного шага в значительной степени зависит от предположений и решений, которые были приняты при проектировании MSC-диаграмм и создании шаблона генерации целевого кода тестового окружения.
В это время разработчик приложения реализует целевое приложение. В случае необходимости модификация и расширение тестового набора совершаются простым изменением и дополнением MSC-диаграмм.
Конфигурирование проекта. Настройка тестового окружения на работу с конкретной тестируемой системой осуществляется при помощи редактирования конфигурационного XML-файла. При этом от пользователя требуется задать ряд обших параметров окружения, таких, как список инстанций, набор сигналов и т. д. Помимо общих параметров также должны быть описаны правила, позволяющие соотнести передаваемые через сеть сообщения с сигна-
лами MSC-диаграмм. В общем случае это делается при помощи вставок целевого кода в соответствующие разделы конфигурационного файла. Для типовых задач эта процедура может быть упрощена за счет использования готовых библиотечных решений.
В ситуации, когда ни одно из библиотечных решений не применимо и требуется специальная настройка окружения, последняя может быть произведена пользователем с помощью редактирования конфигурационного файла. В этом случае пользователь может самостоятельно вставлять в соответствующие разделы XML-файла код на целевом языке, отвечающий за формирование отправляемых и распознавание принимаемых сигналов.
Код тестового окружения разделен на три части (рис. 2):
MSC-зависимый код — генерируется инструментами TAT на основе MSC диаграмм. Представляет собой реализованную в целевом языке систему состояний и переходов. Состояния интерпретируются как события на MSC диаграмме (например, посылка или прием сигнала):
проектно-зависимый код — генерируется инструментами TAT на основе информации, заданной в конфигурационном файле (например, IP-адреса, порты взаимодействующих инстанций, функция распознавания входящих сигналов и т. д.);
ядро шаблона генерации кода — эта часть кода инвариантна как относительно MSC-диаграмм, так и относительно конфигурационного файла и остается неизменной для любого проекта, в котором данный язык целевой (например, к такому коду относятся функции работы с очередью входящих сообщений)
MSC-зависимыи код
Проектно-зависимый код, генерируется на основе XML
Ядро шаблона генерации кода
/у/
Тестовое '
окружение Д.'
- ч
^а Тестируемая
система
_
Рис. 2. Взаимодействие с окружением
Конференция "Технологии Microsoft в теории и практике программирования"
Как это показано на рис. 2. конфигурированию при помощи XML файла подлежит именно проектно-зависимая часть кода тестового окружения.
Чтобы избавить пользователя от необходимости редактирования конфигурационного XML-файла, в дальнейшем предполагается создать графический интерфейс, при помощи которого пользователь мог бы задавать все необходимые настройки более удобным способом.
Анализ результатов тестирования. В качестве основного формата log-файлов выбран формат MSC-диаграмм, которые отражают в удобном графическом представлении наблюдаемое поведение приложения при тестировании.
Если прогон теста завершился с ошибкой, на выходе появляется MSC-диаграмма, описывающая сценарий взаимодействия с тестируемой системой до возникновения ошибки. На основании такой диаграммы может быть сгенерирован тест, автоматически приводящий тестируемую систему в состояние, предшествующее фиксации ошибки, что значительно упрощает анализ ее причин.
Для облегчения процедуры поиска причин ошибок в диаграмму могут быть вставлены специальные маркеры остановки, благодаря которым исполнение теста может быть временно приостановлено с целью анализа текущего состояния тестируемого приложения.
При помощи модуля автомагического анализа результатов осуществляется возможность генерации выходного отчета, содержащего наряду с протоколами выполнения тестов статистику тестового прогона (цикла) в формате HTML-документа. Данная статистика содержит информацию о количестве запушенных и успешно пройденных тестов, а также сводную таблицу по всем тестам с краткими сведениями о каждом из них. В таблице имеются ссылки на автоматически сгенерированный HTML-документ, содержащий детальную информацию как об исходной диаграмме, так и о MSC-Iog-файле. а также отмеченные красным цветом несовпадения.
Кроме того, имеется возможность получать протоколы выполнения тестов (log-фай-
лы) не только в виде МБС, но и в определенном пользователем формате. Это свойство реализуется путем расширения входного языка конфигурационного ХМЕ-файла, через который задается формат выводимого в ^-файл сообщения для каждого из возможных событий МБС-диаграммы.
Разработка планов тестовых экспериментов и подготовка данных. В будущих версиях инструмента запланирована реализация возможности использования в диаграммах символьных параметров, непосредственные значения которых будут задаваться (читаться из внешних файлов) в момент исполнения соответствующего теста. Преимущество такого подхода в том, что пользователь сможет задавать несколько различных комбинаций значений, что позволит без редактирования диаграмм проверять одни и те же сценарии на разных наборах входных данных. Задавать конкретные значения подстановок можно, например, в табличной форме.
Методика классификации ошибок на ошибки приложения и ошибки тестов. Классификация ошибок может быть проведена на основе анализа адекватности модели (в данном случае — МБС-диаграммы), из которой был получен тест, и ее соответствия требованиям. Если модель адекватно интерпретирует требования, то непрошедший тест говорит о том. что найдена ошибка в коде тестируемой системы, в противном случае — ошибка в сценарии теста.
Если требование сформулировано нечетко или возможна его двоякая интерпретация, то его необходимо детализировать, после чего следует вернуться к вопросу об адекватности модели.
Итак, предложенный подход к генерации тестов обладает существенными преимуществами: он гибок, эффективен с точки зрения времени и затрат, позволяет разрабатывать тестовые сценарии в графическом виде, способствует увеличению покрытия пространства дефектов. Но все равно ручная разработка тестовых сценариев остается как проблема в решении задачи полной автоматизации тестирования путем совместного использования методов верификации
и тестирования. Например, используя такой инструмент верификации, как VRS [2|. можно автоматически создавать модель поведения тестируемой системы в виде машины состояний. VRS обходит эту модель и в результате создает дерево поведения. Каждый путь в этом дереве — поведенческий сценарий тестируемой системы. Следовательно, такой путь можно использовать для генерации тестов на целевую платформу. Подобных путей, как правило, огромное множество, поэтому проблема выбора оптимального числа тестов, позволяющего проверить всю функциональность программного продукта на основе выбранного критерия покрытия требований, очень актуальна. Методика оптимального выбора трасс для генерации тестового набора изложена в работе [3].
Совместное использование верификатора (VRS) и тестового генератора (TAT) показало высокую эффективность. Технология VRS/TAT использовалась при решении
задач промышленной разработки телекоммуникационных систем, программного обеспечения мобильных телефонов и встроенных систем. В данных проектах достигалась существенная экономия трудозатрат, а количество найденных ошибок было сравнимо (и во многих случаях даже превышало) с аналогичным показателем для ручного тестирования.
Применение технологической цепочки в реальных проектах позволило сократить время на разработку тестового набора на 30 %, что существенным образом повлияло на стоимость разработки.
Что касается телекоммуникационных проектов, диаграммы MSC — это наиболее часто используемый в этой области и весьма удобный способ описания протокола взаимодействия тестируемых приложений. Зачастую сами требования здесь формируются в виде MSC-диаграмм. что в случае использования TAT сводит затраты на формирование тестового набора к минимуму.
СПИСОК ЛИТЕРАТУРЫ
1. TAT User's Manual. Motorola. 2007.
2. Baranov S., Kotlyarov V., Letichevsky A., Drobintsev P. The technology of Automation Verification and Testing in Industrial Projects // Proc. of St. Petersburg IEEE Chapter. International Conference, May 18—21. St. Petersburg, Russia. 2005. P. 81-86.
3. Баранов С.Н., Котляров В.П., Летичевский АЛ.
Индустриальная технология автоматизации тестирования телекоммуникационных приложений на основе верифицированных поведенческих моделей спецификаций требований // Космос, астрономия и программирование: Тезисы Междунар. науч. конф., Санкт-Петербург. 20-22 мая, 2008 г. С. 134-145.
УДК 681.3
Г.Н. Черкесов, В. В. Чуркин
ПРОГРАММА РАСЧЕТА ПОКАЗАТЕЛЯ НАДЕЖНОСТИ СИСТЕМЫ С ПРЯМЫМ ВКЛЮЧЕНИЕМ КОМПЛЕКТА ЗИП В МОДЕЛЬ НАДЕЖНОСТИ
При проектировании и эксплуатации технических комплексов большое внимание уделяется их надежности. Это связано с повышением важности и сложности решаемых с помощью этих комплексов задач. Под надежностью объекта понимают свойство объекта сохранять во времени в установлен-
ных пределах значения всех параметров, характеризующих его способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования.
Вместе с тем в настоящее время известно достаточно большое количество различ-
