Содержание к диссертации
Введение
1. Анализ методов и средств автоматизации тестирования реактивных систем 7
1 1 Современная базовая терминология и опреділение задачи тестирования 7
12 Автоматизация тьсгирования 9
13 Анализмуатехнологиидоямобильныхус1роисгв 16
1 4 средства автоматизации тьсттоования для java программных интерфейсов и приложений 20
15 Современные байт-код анализаторы 29
16 Сравнительный анализсредствавтоматизациитестировация 33
17 Выводы 39
2 Модель взаимодействия тестируемой системы и тестового окружения .41
2 1 Рьактивнаясистгма как объькт тьсгирования 41
2 2 Представление тестируемой системы итестовогоокружения в видр системы временных переходов 43
2 3 Расширение системы временных переходов 47
2 4 Обобщенная формулировка модели 52
2 5 Постановка задачи на разработку технологии автоматизации тестирования 53
2 6 Выводы 55
3 Концепция технологии автоматизации тестирования 56
3 1 Технолоі ическая цепочка и сценарий ее использования 57
3 2 Модули ядра технолоі ии ав гоматизации тестирования 61
3 3 Структура абстрактных тестовых наборов (атн) 65
3 4 Язык спецификации требовании тьстируемой системы 66
3 5 Структура компоньнга сопряжения интерфгисов 68
3 6 Выводы 75
4 Комплекс методик технологии автоматизации тестирования 77
4 1 метОдика разработки тестовых сценариев 78
4 2 Методика ie нерации трасс и абстрактных тестов 83
4 3 Методика управления балансом выбора обоыценных сценариев и линейных трасс 91
4 4 Методика создания шаблона ifhepauhh целевого кода тестовых наборов 97
4 5 Методика встраивания тестовых агентов 103
4 6 Выводы 110
5 Практическое применение разработанной технологии автоматизации тестирования 112
5 1 Обобщенная cxfma применения технолоі ии 112
5 2 Применение технологии для тес іирования java api 114
5 3 Пpиmehfhиe^fxhoлoгиидляtecrиpobahияпoльзobatfлбckиxjavaпpилoжeiiии(miditt) 118
5 4 Применение технологии для тестирования системных java приложении (corfi ет) 121
5 5 Анализ результатов применения технологии 125
5 6 Выводы 134
Заключение 136
Литература
- Автоматизация тьсгирования
- Расширение системы временных переходов
- Структура абстрактных тестовых наборов (атн)
- Методика управления балансом выбора обоыценных сценариев и линейных трасс
Введение к работе
1.1 Актуальность работы. В рамках технологии производства программного обеспечения (ПО) важное значение имеет организация процессов тестирования, которые во многом определяют длительность, трудоемкость цикла разработки и качество ПО
Возрастающая сложность ПО встроенных систем требует от соответствующих инструментальных средств:
поддержки процессов тестирования, начиная с ранних этапов разработки;
использования формальных спецификаций для ясного представления поведения тестируемой системы, а также проверки требований на непротиворечивость;
поддержки автоматической генерации тестов;
организации тестирования на разных этапах разработки с обеспечением преемственности (переиспользования) уже полученных результатов и наработок;
поддержки тестирования в реальном окружении.
В связи с этим, при постоянном сокращении сроков разработки ПО и увеличении его сложности необходимо создание методик и инструментальных средств, которые позволили бы автоматизировать процесс тестирования.
Анализ предметной области показал, что в настоящее время широкое распространение имеют различные нотации для формального представления требований к тестируемой системе: UML, MSC, VDM-SL, Murq>, Alloy, T-VEC LF, LOTOS, Esterel, SCR, которые основаны на использовании таких известных моделей программ как сети Петри (Петри), конечные автоматы (Мили, Мура), темпоральные логики (Приора), алгебры параллельных процессов (Милнера, Хоара, Бергстры и Клоппа), традиционные системы (Д. Парка). Существующий инструментарий, основанный на их использовании, TVG (от T-VEC Technologies), Rational Rose Test Realtime (от Rational), Rhapsody TestConductor (от I-Logix), UniTesK (ИСП PAH), GOTCHA-TCBEAN (от AGED1S), MulSaw (от MIT), JUnit (от RoleModel Software) не удовлетворяет требованиям современного процесса производства ПО в области разработки встроенных Java программных интерфейсов и приложений, например, для мобильных телефонов, что является следствием следующих причин:
трудоемко параметрическое описание взаимодействия процессов тестируемой системы и тестового окружения, а также функционалов контроля значений параметров этих процессов;
отсутствуют подходы платформо-независимой интеграции тестовых наборов и тестируемого Java приложения;
затруднено получение эффективного настраиваемого вида целевого кода тестов.
В диссертации автором разработана технология создания специализированных систем автоматизированного тестирования с помощью адаптивной генерации тестовых наборов и их интеграции с тестируемым приложением. Применение предлагаемой технологии позволяет существенно сократить длительность и трудоемкость цикла разработки, что и определяет актуальность диссертационной работы. Результаты анали:.а области исследования позволили сформулировать цели и задачи исследования и определить его структуру.
1.2 Цели и задачи диссертационной работы. Целью диссертационной работы
является разработка комплекса методик и инструментальных средств технологии созданая
систем автоматизированного тестирования реактивных программных приложений
мобильных Java телефонов, обеспечивающих сокращение трудозатрат и времени фазы
тестирования при отсутствии регрессии качества. Для достижения цели в работе решены
следующие задачи.
разработка требований к технологии автоматизации тестирования ПО мобильных телефонов на основе проведенного анализа существующих методов и средств автоматизации тестирования;
разработка модели взаимодействия тестируемого объекта и окружения на баїе аппарата реактивных систем;
создание методик разработки параметризованных тестовых сценариев, адаптивней генерации целевого кода тестов и их интеграции с тестируемой системой;
создание программного инструментария, обеспечивающего: 1) адаптивную генерацию целевого кода тестовых сценариев по формальному описанию; 2) встраивание тестовых агентов в тестируемую систему для сопряжения с тестовым окружением;
проверка работоспособности предложенных методик и инструментальных средств на 8 реальных проектах для 4 моделей мобильных телефонов.
Разработка и результаты решения этих задач выносятся на защиту.
-
Предметом исследования являются методы и инструментарий автоматизации тестирования встроенных Java программных интерфейсов и приложений.
-
Методы исследования. В диссертации используется теория реактивных систем и конечных автоматов, аппарат формальных спецификаций, концепция абстрактных тестовых сценариев. В коде применялись стандарты Message Sequence Charts (MSC), ANSI С и Java. Основными критериями являлись универсальность, адаптивность и простота автономного использования разрабатываемой технологии автоматизации тестирования, а также возможность интеграции с существующими инструментальными средствами. В основу исследований положен системный подход.
-
Обоснованность и достоверность полученных результатов обусловлена корректным использованием теории реактивных систем и конечных автоматов, аппарата формальных спецификаций; совпадением результатов по достижению качества программного обеспечения, полученных различными методами; положительными результатами использования предложенных методов и средств в реальных проектах и положительным опытом эксплуатации программного обеспечения, тестирование которого осуществлялось с использованием предложенных методик.
-
Научные результаты и их новизна: в диссертации разработаны методологические основы технологии создания систем автоматизированного тестирования. Суть этих результатов сводится к следующему.
-
Разработана модель взаимодействия тестируемой системы и тестового окружения на основе модели реактивных систем в виде системы временных переходов, расширенная средствами статической и динамической параметризации. Модель положена в основу функционирования систем автоматизированного тестирования и учитывает функциональность средств проверки параметров событий и сопряжения интерфейсов.
-
На базе стандарта MSC создана методика формализации требований к тестируемой системе посредством применения параметризованных, инвариантных тестовых сценариев, для последующего их автоматизированного преобразования в платформо-независимое представление.
-
Разработана методика генерации платформо-независимого абстрактного тестового набора в виде трасс и обобщенных сценариев для обеспечения возможности генерации целевого кода тестов на заданную платформу с помощью адаптируемого шаблона;
-
Предложена методика управления балансом выбора обобщенных сценариев и линейных трасс в совокупном тестовом наборе для удовлетворения ограничениям доступной памяти и времени выполнения тестового цикла;
-
Разработана методика создания шаблонов адаптивной генерации кода, позволяющая преобразовать платформо-независимое представление тестовых сценариев в платформо-зависимый целевой код тестов путем интерпретации команд абстрактного теста.
-
Предложена методика встраивания тестовых агентов в Java приложения для сопряжения интерфейсов тестируемой системы и тестового окружения, что позволило обеспечить эмуляцию тестовых воздействий и контроль откликов.
1.7 Практическая значимость работы. На базе полученных научных результатов
разработан комплекс программных средств, предназначенных для автоматизации
тестирования Java программных интерфейсов и приложений для мобильных телефонов.
Программный комплекс использован в компании Motorola в 8 профаммных проектах в
таких областях как: разработка Java программных интерфейсов (JSRs) и базового приемочного (Sanity) тестирования, а также при разработке пользовательских (MIDlet) и системных (CORElet) Java приложений. Созданная технология внедрена в проекте по разработке аппарата оповещения о статусе систем контроля в ОАО "Интелтех" и проекте "Исследование применения мобильных технологий в задаче отслеживания движения поездов" в ЗАО "Северо-Западная лаборатория Лтд". Созданные комплекс методик и программные средства являются универсальными и могут быть использованы для автоматизации тестирования Java программных интерфейсов и приложений различной направленности. Применение разработанной технологии автоматизации тестирования позволяет в среднем сократить время фазы тестирования в 2,5 раза.
-
Апробация работы. Основные результаты и выводы диссертации докладывались на следующих международных научных конференциях: "IEEE Russia Northwest Section, 110 Anniversary of Radio Invention conference" (СПб., 2005 г.); "2006 IEEE Tenth International Symposium on Consumer Electronics" (СПб., 2006 г.); Motorola Technology Day (Spb 2005, 2006); конференциях "Технологии Microsoft в теории и практике программирования" 2002, 2004, 2005 и 2006 гг.; конференциях XXIX-2001 г, ХХХ-2002Г, ХХХП-2004г, XXXII1-2005 г, недели науки СПбГПУ. По материалам диссертации опубликовано 8 печатных работ, в том числе статья в издании из списка ВАК, где достаточно полно изложены основные результаты работы.
-
Внедрение. Разработанная технология автоматизации тестирования внедрена в ЗАО "Северо-Западная лаборатория", НПО "Интелтех", ЗАО "Моторола" и использована при разработке учебно-методического комплекса СПбГПУ по курсу "Автоматизация тестирования Java на мобильных телефонах" на кафедре "Информационных и управляющих систем". Практическое использование представляемых на защиту результатов подтверждено соответствующими актами о внедрении.
1.10 Структура и объем работы. Работа содержит введение, 5 глав, заключение
и 5 приложений. Объем работы 145 страниц текста, количество иллюстраций 80, список
использованной литературы содержит 95 наименований.
Автоматизация тьсгирования
При разработке ПО можно ставить две взаимосвязанные задачи обеспечения его качества, тесно связанные с тестированием [7]. - оценка достигнутого уровня качества, - достижение некоторого предопределенного уровня качества
В соответствии с традиционным подходом [8], численно уровень качества ПО оценивается количеством дефектов на 1000 сірок кода При этом можно рассматривать как нормированные строки кода на языке программирования, приведенные к ассемблерному аналогу (KAELOC - KiloAssembler Equivalent Line of Code), так и ненормированные (KLOC - KiloLine of Code для используемого языка программирования)
Ошибкой является различие между вычисленным, обозреваемым или измеренным значением или условием и действительным (полученным экспериментально), специфицированным или теоретически корректным значением или условием [9]
Под дефектом понимается - ошибка, привнесенная на некоторой фазе разработки ПО, но выявленная на последующих фазах, - ошибка, проявившаяся на стороне заказчика (пост-релизный дефект)
С точки зрения заказчика продукта второе определение более актуально, і е соответствует его представлению о дефекте Пост-релизные дефекты вьіявляюіся во время эксплуатации на стороне заказчика. Количество выявленных дефектов зависит от способа эксплуатации. Метрика качества в виде количества пост-релизных дефектов, отнесенного к объему кода - характеризует плотность оставшихся ошибок в коде Практически, она несет в себе информацию о достигнутом качестве. Можно утверждать, что задачей обеспечения качества является минимизация этой метрики [8]. j Y post \ Vpost-rK-y-), (1) где Мроп - количество пост-релизных дефектов, выявленных заказчиком, V -объемПОвКАЕШС, F - интегральная функция нормального распределения; crpmt - "плотность" пост-релизных дефектов в коде. Величина арш носит вероятностный характер. В соответствии с классической моделью предполагается, что дефекты распределены в ПО равномерно, а вероятность их обнаружения описывается нормальным законом распределения. Величина crpost задает доверительный интервал вероятности не встретить ошибку на 1К нормированных строк кода и потому может быть выражена в терминах нормального закона распределения как: 0 /»«=Л 0-, (2) где а - параметр нормального закона распределения (среднеквадратическое отклонение), п - граница доверительного интервала
Оценка плотности ошибок в соответствии с данной метрикой может быть получена путем сбора статистики о результатах эксплуатации выпущенных продуктов Такая метрика может быть получена только в результате анализа разработанного кода, те в ре ультате тестирования Тестирование, с одной стороны, позволяет определить достигнутый уровень качества (первая задача обеспечения качества), с другой стороны повысить уровень качества за счет выявления и исправления ошибок Пост-релизный уровень качества характеризует то качество, которое удалось достигнуть на фазе тестирования за счет выявления и устранения ошибок (тестирование и исправление)
Необходимо отметить, что в результате любого (сколь угодно поверхностного) тестирования и исправления ошибок фактический уровень пост-релизного качества повышается Это утверждение непосредственно вытекает из і ого факта, что фактическое количество дефектов, заключенное в коде ПО фиксировано для каждого конкретного продукта и при последующей корректировке кода уменьшается.
Только правильно построенный процесс тестирования может служить целям повышения качества программного продукта Под правильным процессом подразумевается комплекс организационно-технических мер, приводящих к наиболее эффективному тестированию. В настоящей работе рассматриваются чисто технические аспекты фазы процесса тестирования
Одной из глобальных проблем процесса тестирования является вопрос о том, когда следует закончить тестирование программы, поскольку не представляется возможным определить, сколько еще ошибок содержится в программе В [10] предлагается три группы критериев для завершения тестирования:
- критерии, основанные на использовании определенной методологии проектирования тестов Тестирование завершается, когда по критерию (критериям) тестирования достигается заранее заданный процент покрытия и тесты для определенного критерия (критериев) заканчиваются без нахождения ошибок в программе. Данные критерии завершения полезны на соответствующих фазах тестирования
- критерии, в основу которых положен принцип завершения тестирования при нахождении в процессе тестирования зафиксированного "экспертами до начала работ количества ошибок, например, на основе данных о разработке других программ соответствующего класса Длительность тестирования, а тем самым и всей разработки, непосредственно зависит от допустимого количества не выявленных ошибок, при котором разработку можно считать завершенной.
- критерии, для применения которых требуется в процессе проведения тестирования строить временную диаграмму фиксации ошибок. Анализируя форму кривой, можно определить, следует ли продолжать проверку на данной фазе или закончить ее и перейти к следующей
Результаты экспериментов по разработке и прогону тестов ложатся на так называемую S-образную кривую (Рис 1) зависимости количества выявленных дефектов от объема разработанных тестов (или времени) На оси абсцисс откладывается объем написанных тестов, который также можно понимать и как время Критерием окончания фазы тестирования является достижение "насыщения" S-образной кривой, означающее достижение необходимого уровня качества [12]
Расширение системы временных переходов
Спецификацию поведения реактивной системы удобно формализовать в виде некоторого набора последовательностей подачи входных воздействий на тестируемую систему из окружения и получения откликов тестируемой сисіемьі обратно в тесювое окружение Таким набором задаются правила поведения тестируемой системы, те. представляются переходы системы по входным воздействиям из состояния в состояние При этом возникает необходимость учета временных ограничений на возможность подачи различных воздействий и, аналогично, возможность получения своевременных откликов в заданные интервалы времени На Рис. 6 изображена система временных переходов взаимодействующих объектов
Таким образом, представление тестируемой реактивной системы в виде системы временных переходов является весьма наглядным. Аналитически модель реактивной системы в виде системы временных переходов выражается следующим кортежем [79]: Sr = (X, Z, Т, Є, L, U), (6) где, X -множество переменных над областью определения D; с \Х - D] - множество состояний системы; 0 є I - множество начальных состояний; Т с { - I) - множество переходов; L,U - множества нижних и верхних границ интервалов временных задержек срабатывания активизированных переходов г є Т: L = {/г,гєТ}, U = {иг, т єТ}, 0 /r ит, lr,uTe R.
С позиций тестирования проверка корректности работы системы согласно заданной спецификации есть установление эквивалентности поведения реализации относительно заданной модели поведения. В свою очередь спецификация динамического поведения реактивной системы представляет собой описание правил подачи входных воздействий и ожидаемых откликов. Соответственно, такую спецификацию возможно формализовать в виде системы временных переходов. В данном случае такая модель может служить не для анализа и верификации свойств смоделированной системы, а для генерации последовательностей входных сигналов, и ожидаемых откликов, т.е. тестовых сценариев.
Таким образом, мы получаем две сущности, которые возможно задать с помощью одной модели. Это непосредственно тестируемая система и поведение тесового окружения. В итоге процесс тестирования реактивной системы можно представить в виде функционирования композиции двух систем переходов. Первая описывает спецификацию на тестируемую систему и по своей сути является тестовым сценарием. Вторая есть непосредственная реализация системы, обращенная к тестовому окружению заданным набором интерфейсов.
В соотвеїсгвии с подходом тестирования методом "черною ящика" внутреннее строение тестируемой системы неизвестно. В качестве накладываемых оіраничений на процессы обмена событиями достаточно описать временные интервалы на входные и выходные интерфейсы Работа с подаваемыми на входные интерфейсы значениями скрыта внутри "черного ящика". Однако для описания тестовою сценария одних временных ограничений недостаточно. На стороне тестового окружения необходимо формировать сигналы, которые будут поданы на соответствующие входные интерфейсы Также необходимо формировать модели выходных сигналов, которые должны быть проверены на соответствие с реальными сигналами, посылаемыми тестируемой системой в окружение посредством выходных интерфейсов
На Рис. 7 показано обобщенное представление модели тестового сценария. Состояния А и В необходимо определить как некоторые глобальные наблюдаемые состояния Каждое такое состояние содержит в себе множество простых состояний, между которыми осуществляются переходы по соответствующим сигналам, и которые непосредственно определяют состояние тестового сценария в данный момент времени. В состоянии А производится формирование сигналов согласно заданной спецификации для используемого интерфейса Каждому переходу соответствует единственный сигнал с заданным набором значений переменных
Также в этом состоянии осуществляется проверка временных ограничений на возможность посылки сигнала в тестируемую систему в данный момент времени В состоянии В происходит ожидание отклика системы В качестве критерия окончания ожидания используется глобальный тайм-аут В случае если ответ от системы не последует в течение времени возможного ожидания Т 1оЪ, система переходит в состояние обработки ошибки Это сосюяние может использоваться как терминальное для заданного тестового сценария или как промежуточное в случае продолжения сценария путем перехода в состояние А, если эго допускается спецификацией тестируемой системы В случае получения окружением сигнала от выходного интерфейса тестируемой системы до истечения глобального тайм-аута Tglob производится проверка данного сигнала на соответствие спецификации В случае установления валидности ответного сигнала срабатывает переход из состояния В в состояние А. В этом состоит процесс проверки работы тестируемой системы Условия срабатывания перехода можно описать следующим образом - сигнал получен с ожидаемого выходного интерфейса тестируемой системы; - множество значений параметров сигнала выходного интерфейса, полученного от тестируемой системы, совпадает с множеством ожидаемых значений, заданных в формальной спецификации; - время получения сигнала выходного интерфейса удовлетворяет множеству временных ограничений, заданных в формальной спецификации
Структура абстрактных тестовых наборов (атн)
Предлагаемая структура является выходом ГАТ и призвана обеспечить платформо-независимое представления тестов. В качестве основы для AIH выбран язык Tel [84].
Анализ предметной области показал, что на данный момент для применения технологии автоматизации тестирования представляются актуальными три структуры А1Н: - непосредственная (полная копия исходной MSC), - поведенческий граф (активное включение), - система временных переходов (пассивное включение)
Самой простой формой АГН является первая При использовании ГАТ в режиме повторения структуры MSC каждой конструкции MSC сценария ставится в соответствие конструкция АТН Фактически производится тривиальное преобразование MSC в эквивалентный формат Эта форма АТН создает проблемы при генерации кода на алгоритмических языках, так как не все конструкции MSC отображаются на их структуру. Например, оператор alt (альтернативные участки) соответствует условному оператору, а оператор par (параллельное выполнение участков) не имеет аналогов в привычных нам языках типа С и Java В то же время для языков, поддерживают параллелизм (VIIDL, Verilog и другие), прямое отображение MSC на них вполне возможно.
Граф поведения - это форма АТН, ориентированная на активное подключение тестового агента к тестируемой системе. При этом тестовый код в процессе выполнения обращается к тестируемой системе, получает реакцию на свои действия и в зависимости от реакции выбирает дальнейший маршрут по графу
Система переходов - форма АТН предназначена для пассивного подключения к тестируемой системе При этом активной сущностью является не тестовый код, как в предыдущем случае, а тестируемая система или внешний источник синхронизации События, происходящие в тестируемой системе, вызывают переходы тестового агента из состояния в состояние Пассивная форма A III (сисіема переходов) в общем случае "полезнее", чем активная (граф поведения) Если тестируемая система по своей природе является пассивной (это характерно, например, для библиотек функций), то тестовый агент может быть как активным, так и пассивным (в случае пассивного тестового агента должен присутствовать внешний источник синхронизации и управления, обеспечивающий функционирование всей системы) Если же тестируется активная система, то тестовый агент может быть только пассивным, так как поток управления один Здесь активное включение неприемлемо.
Базовые команды, используемые в АТН и конструкции в MSC, которые их порождают, приведены в Приложении 5 Помимо базовых команд, определяющих поведение теста, существуют управляющие команды, определяющие типы данных, параметры сообщений, начало и завершение текущего тестового сценария
Язык спецификации требований тестируемой системы
Концептуальная постановка вопроса разработки технологии автоматизации тестирования вызывает необходимость расширения стандартной базовой нотации формального графического языка спецификаций MSC. Основными способами расширения определены следующие: - использование макроподстановок, - расширенные MSC, - типизация элементов сценария взаимодействия.
Подходы, разработанные в данном пункте, обеспечивают создание платформо-независимого инвариантного описания тестовых сценариев, и позволят описывать входные данные, которые будут использованы при генерации целевого кода тестов и тестового окружения Методики использования расширений приведены в Главе 4.
Предложенные и применяемые в настоящей работе макросредства имеют современный аналог - препроцессор языка С (директива #defme) Предложенные макроподстановки являются базой для разработки параметризированных тестовых сценариев В то время как стандарты MSC96 и MSC2000 не позволяют описывать данные и алгоритмы, макро расширения MSC позволяют обойти эту проблему Макроподстановками различных типов создается возможность задавать множесіва значений параметров сигналов, условия их выполнения и использовать в качестве параметров циклов Кроме того макроподстановки позволяют автоматически размножить число однотипных процессов на диаграмме при использовании их в имени процесса Реализованы следующие типы макроподстановок LIST - і операция значении по списку; NLIST - числовой список, COND - условные списки, DERIVE - вычисление пользовательской функции, FUNCTION -вычисление функции в зависимоеш от значений параметров, заданных на MSC
Интерпретация парамегров сообщении как строковых констант позволяет гибко задавать множества данных различных типов, не прибегая к явной типизации Обрабатываются макроподстановки макро процессором, результатом работы которого является набор MCS диаграмм содержащих полный перебор значений заданных макросов Определения макроподстановок задаются в пользовательской конфигурации
В ходе исследования предметной области установлено, чго в целях компактного представления тестов и поддержки существующего редактора Telelogic MSC-Editor [25], в грамматику стандарта MSC2000 были внесены изменения, которые позволили:
1. Для каждой процесса на MSC диаграмме задавать масштаб времени, относительно которого будет, производится расчет временных составляющих спецификации собыгий.
2. Для любого события задавать интервал времени, когда оно должно происходить Возможные точки отсчета интервала. - от начала диаграммы (абсолютное время), - от предыдущего события процесса (относительное время), - относительно некоторой заданной базы (временная метка)
3 Сопоставлять событиям на MSC диаграмме логическое условие их существования в зависимости от значения макроподстановки (статически проверяемое условие), либо использовать логическое выражение с переменными, значения которых будут определены в процессе исполнения теста (динамически проверяемое условие)
4 Описывать переменные со сложными составными типами данных (массивы, структуры), значения которых могут меняться и которые можно использовать в процессе непосредственного исполнения тестового сценария
5 Осуществлять условное разрешение альтернативною поведения за счет использования специального элемента на диаграмме с комментариями аналогично конструкции IF в языках программирования
Методика управления балансом выбора обоыценных сценариев и линейных трасс
Методика управления балансом выбора обобщенных сценариев и линейных трасс предназначена для регулирования объема занимаемой памяти и времени, необходимого для прогона тестового набора, путем баланса обобщенных сценариев и функционально эквивалентного множества линейных трасс, составляющих данный тестовый набор
В рамках рассматриваемой области применения предложенной технологии для автоматизации тестирования встроенных Java приложений мобильных устройств существуют строї ие ограничения на объем используемой оперативной памяти Спецификой Java-технолоі ии является работа исключительно внутри "кучи" (Java-Heap) - выделенного ограниченного объема памяти для исполнения приложений При этом классы тестируемого приложения подгружаются в "кучу" из файловой системы мобильного устройства перед исполнением. Также существуют ограничения на размер, занимаемый приложением на файловой системе Ограничения на оперативную память и файловую систему не имеют четкого стандарта, но зависят от модели конкретного устройства и определяются в рамках конфигурации всей платформы мобильного устройства в зависимости от объема имеющихся ресурсов При этом приложения, разрабатываемые для конкретного типа мобильного устройства, используют значительный объем предоставляемых ресурсов для непосредственного обеспечения собственной функциональности. В результате существенное значение при применении предложенной технологии имеет объем ресурсов, потребляемый тестирующей функциональностью
Как было показано в п. 4 2, методика генерации трасс и абстрактных тестов позволяет раскрывать нелинейное поведение на исходной MSC диаграмме в набор линейных трасс, либо сохранять нелинейность в виде обобщенного сценария, коїда выбор конкретного пуги осуществляется в процессе исполнения теста Оценим затраты памяти для двух подходов
За единицу используемой памяти примем объем генерируемого целевого кода теста для описания одного события на MSC диаграмме. Тогда объем памяти, используемый для обобщенных сценариев, предложено оценивать по следующей метрике:
На MSC диаграмме (1) присутствует единственная альтернатива (4) смешанного типа. Очевидно, что при этом обобщенный сценарий (2) и множество генерируемых трасс (3) будут занимать одинаковую память. Таким образом, можно утверждать следующее: MEMSC MEMTR (23)
Рассмотрим альтернативы (4,5) MSC диаграммы (1) на Рис. 39. Для первой альтернативы (4) видно, что по воздействию на тестируемое приложение сигналом А в тестовое окружение в качестве отклика может быть получен как сигнал Е, так и сигнал G. Соответственно проход по одной из ветвей альтернативы может быть никогда не покрыт. На примере второй альтернативы (5) существует выбор либо ожидать прихода сигнала J от тестируемого приложения, либо послать в него сигнал I из тестового окружения. Возможен вариант, что сигнал J не будет когда-либо послан и эта ветвь альтернативы останется не протестированной. Таким образом, представленный сценарий не обеспечивает полного покрытия заданной спецификации. При этом набор генерируемых трасс включает в себя все пути сценария и тем самым обеспечивает проход по всем путям заданной спецификации и гарантирует полное покрытие. Это актуально, например, когда тестируемое приложение на запрос тестового окружения возвращает два сигнала, но необходимо обеспечить различную реакцию на каждый из них. Однако, можно представить ситуацию, когда проход по той или другой ветви альтернативы зависит от истории выполнения теста, и в этом случае не каждая трасса может быть актуальной. Это означает, что исходная спецификация на MSC диаграмме неполна. Тогда необходимо определить и описать на диаграмме необходимые условия прохода по различным ветвям альтернатив. Рассмотрим пример, приведенный на Рис. 41, на котором показана возможность задания необходимых условий с использованием переменных для покрытия ветвей альтернатив.
