Содержание к диссертации
Введение
1 Обзор возможностей технологии java для мобильных устройств и анализ современных подходов автоматизации тестирования 10
1.1 JAVA технология для мобильных устройств 10
1.1.1 Особенности kJava Виртуальных Машин (КУМ) 13
1.1.2 Обзор особенностей МЮР-профайла. Пользовательское приложение MIDlet 14
1.1.3 Обзор особенностей DoJa-профайла. Пользовательское приложение i-appli. 16
1.1.4 Системные kJava приложения-CORElet 17
1.1.5 Java байт-код. Анализ современных байт-код анализаторов 20
1.2 Формальные методы в разработке по 22
1.3 Автоматизация тестирования 25
1.3.1 Использование агентов для автоматизации тестирования и мониторинга 27
1.4 Анализ средств автоматизации тестирования JAVA me 30
1.4.1 Анализ средств автоматизации тестирования Java ME без использования агентов 30
1.4.1.1 J2ME Unit Testing Framework 30
1.4.2 Анализ средств автоматизации тестирования Java ME на основе агентов 32
1.4.2.1 ТСК 32
1.4.2.2 Java Device Test Harness 34
1.4.2.3 Communology MTE 36
1.4.2.4 Mobile Complete LiveTest 37
1.4.2.5 PTF 38
1.4.2.6 FlexAuto 40
1.5 Анализ систем автоматизации тестирования на основе генерации тестовых сценариев 41
1.5.1 Test Vector Generation System 41
1.5.2 MulSaw 42
1.5.3 GOTCHA-TCBEAN. 43
1.5.4 AsmL Test Tool 45
1.5.5 UniTesK. 46
1.5.6 VRS/TAT. 48
1.6 Сравнительный анализ систем автоматизации тестирования 50
1.7 Выводы 55
2 Методика встраиваемых агентов для автоматизации тестирования и мониторинга встроенных java систем 57
2.1 Реактивные системы 57
2.1.1 Понятие реактивной системы 57
2.1.2 Описание реактивной системы как объекта тестирования 60
2.2 Представление java систем в виде реактивных моделей 61
2.2.1 Реактивная модель Java ME приложения 61
2.2.2 Реактивная модель KVM 64
2.2.3 Реактивная модель окружения Java платформы 66
2.2.4 Интегрированная модель взаимодействия компонентов мобильного устройства 68
2.3 Методика встраиваемых агентов 71
2.3.1 Модель универсального встраиваемого агента 72
2.3.2 Методика встраивания агентов для Java ME приложений. 75
2.3.3 Методика встраивания агентов на уровне окружения 78
2.3.4 Обобщенная формулировка методики 80
2.4 Проверка корректности моделей 81
2.5 Выводы 84
3 Концепция реализации комплекса методик встраивания агентов 86
3.1 Концепция реализации методики для тестирования встроенных java me приложений 86
3.1.1 Концепция разработки классов-оболочек и перехвата управления потока исполнения приложения 87
3.1.2 Концепция тестирования системных Java ME приложений. 91
3.1.2.1 Методика встраивания агентов в K.VM 91
3.1.2.2 Реализация методики встраивания агентов в KVM 93
3.1.3 Обобщенная концепция интеграции тестового набора, агента и тестируемого приложения 95
3.1.4 Анализ и модификация байт-кода для встраивания агентов в Java приложения 96
3.1.4.1 Алгоритм работы байт-код анализатора 97
3.1.4.2 Безопасность алгоритма работы байт-код анализатора 100
3.2 Концепция реализации методики для тестирования системного платформенного по 102
3.2.1 Методика встраивания пассивного агента на уровне окружения 102
3.2.2 Методика встраивания активного агента на уровне окружения 103
3.2.3 Реализация методики встраивания агентов на уровне окружения 106
3.3 Методика выбора альтернатив на основе контрольных сумм 108
3.4 Выводы 112
4 Реализация технологии автоматизации тестирования на основе разработанных методик 113
4.1 Технологическая цепочка из
4.2 Архитектура системы 117
4.2.1 Модуль тестирования пользовательских МЮР-приложений и API. 118
4.2.2 Модуль тестирования системных и DoJa приложений 119
4.2.3 Модуль тестирования системных платформенных приложений 120
4.2.4 Пользовательская система для настройки и подготовки тестовых сценариев 120
4.3 Выводы 122
5 Результаты применения разработанных методов и технологии автоматизации тестирования 123
5.1 Применение методики встраиваемых агентов для автоматизации тестирования java 123
5.1.1 Анализ результатов применения технологии автоматизации тестирования Java ME приложений 126
5.2 Применение методики встраивания native-агентов для автоматизации тестирования мобильных платформ 132
5.2.1 Анализ результатов применения технологии автоматизации тестирования мобильных платформ 133
5.3 Сравнительный анализ результатов применения методик встраивания агентов с системой автоматизации ptf 137
5.4 Выводы 139
Заключение 141
Литература
- Системные kJava приложения-CORElet
- Представление java систем в виде реактивных моделей
- Обобщенная концепция интеграции тестового набора, агента и тестируемого приложения
- Модуль тестирования системных и DoJa приложений
Введение к работе
1.1 Актуальность работы В процессе разработки программного обеспечения (ПО) важную роль играет автоматизация тестирования совместной работы разных типов приложений вычислительных систем Трудозатраты по интеграции указанных типов тестирования определяют длительность цикла разработки и качество ПО
С развитием Java технологии для встроенных вычислительных систем существенно возросли требования к сложности, качеству и трудоемкости разработки приложений, объединяющих платформенные и Java компоненты Основные свойства технологий автоматизации тестирования, поддерживающих такое применение, следующие
использование формальных спецификаций на ранних этапах разработки,
поддержка автоматической генерации кода тестов в соответствии с особенностями целевой платформы,
возможность наблюдения внутреннего поведения тестируемой системы посредством генерации воздействий и обработки откликов,
- автоматизированный прогон тестовых циклов, сбор и анализ результатов,
гибкая настройка и адаптация к новым версиям программных платформ
Перечисленные свойства подтверждают необходимость создания методик и
инструментальных средств технологии автоматизации тестирования встроенных систем, поддерживающих тестирование свойств совместного функционирования платформенных и Java компонентов Анализ предметной области проведен по двум основным направлениям анализ существующего инструментария для автоматической генерации кода тестов из формальных описаний, анализ существующих методов и средств, обеспечивающих возможность автоматизации тестирования встроенных Java систем на этапах прогона тестов, сбора и анализа результатов
Анализ существующего инструментария для автоматической генерации кода тестов из формальных описаний TVG, MuISaw, GOTCHA-TCBEAN, AsmL Test Tool, UniTesK, VRS/TAT - показал актуальность использования для этих целей инструмента VRS/TAT, удовлетворяющего требованиям современного процесса разработки ПО встроенных вычислительных систем, включающих в себя платформенные и Java компоненты Преимущества выбранного инструмента возможность гибкой настройки целевого языка кода тестов, автоматическая генерация оптимального набора тестовых сценариев по формальным описаниям требований и генерация кода тестов для соответствующей платформы Java ME, что не поддерживается в других рассмотренных промышленных средствах автоматизации тестирования
Анализ существующих методов и средств автоматизации тестирования встроенных Java систем на этапах выполнения тестов, сбора и анализа результатов показал, что в настоящее время в исследуемой предметной области используются технологии внедрения агентов, позволяющих наблюдать поведение тестируемой системы (ТСК, Java Device Test Harness, Communology MTE, Mobile Complete Live Test, PTF, FlexAuto) Выявленные недостатки не позволили использовать их для решения поставленной в работе задачи по следующим причинам узкая специализированная направленность рассмотренных средств не обеспечивает гибкой настройки на платформу, отсутствие средств, поддерживающих тестирование платформенных и Java приложений, и их взаимодействий, избыточная трудоемкость расширения тестовых наборов, включенных в рассмотренные средства, невозможность свободной интеграции с системами генерации кода тестов для искомой платформы
На основе анализа работ В И Городецкого, В Б Тарасова, Р Брукса, Н Дженнингса и других авторов по проектированию агентов сделаны выводы о перспективности использования агентов для обеспечения возможности наблюдения и управления на программном уровне, и о необходимости адаптации существующих подходов к разработке агентов, исходя из специфики исследуемых встроенных систем
В диссертационной работе автором разработаны методики создания и внедрения программных агентов в прикладное и системное ПО встроенных Java систем Применение предлагаемых методик для автоматизации этапов выполнения тестов, сбора и анализа результатов совместно с системой VRS/TAT для генерации кода тестов по формальным спецификациям позволяет создать технологию автоматизации тестирования платформенных и Java приложений Технология, созданная на базе предложенных методик, позволяет в несколько раз сократить длительность и трудоемкость процесса тестирования при отсутствии регрессии качества, что и определяет актуальность диссертационной работы Результаты анализа предметной области позволили сформулировать цели и задачи исследования и определить его структуру
1 2 Цели и задачи диссертационной работы
Целью диссертационной работы является разработка комплекса методик встраивания адаптивных программных агентов, позволяющих осуществлять наблюдение и управление внутренним поведением тестируемой системы для обеспечения автоматизации этапов прогона тестов, сбора и анализа результатов, сокращающей трудозатраты и время фазы тестирования Агенты должны обеспечивать наблюдаемость поведения прикладного и системного ПО, а также их взаимодействий, поддерживать возможность гибкой адаптации к целевой платформе Методики должны обеспечивать
возможность создания технологии автоматизации тестирования с использованием средств автоматической кодогенерации по формальным описаниям В поддержку технологии должны быть разработаны настраиваемые на платформу Java ME инструментальные средства В рамках достижения цели в работе решены следующие задачи
разработка требований к встраиваемым программным агентам на основе проведенного анализа существующих методов и средств автоматизации тестирования,
создание поведенческих моделей основных архитектурных компонентов встроенных Java систем и модели универсального агента, инвариантных относительно платформы,
разработка обобщенной методики встраивания агентов на основе предложенных моделей,
доказательство корректности разработанных моделей, их функционирования и взаимодействия с использованием инструментов автоматической верификации,
разработка концепции программной реализации и адаптации к целевой платформе методик встраивания агентов в прикладное и системное ПО на уровне основных архитектурных компонентов вычислительных систем, обеспечивающих управление и наблюдаемость поведения платформенных и Java приложений, и их взаимодействий,
создание программного инструментария, обеспечивающего настройку и интеграцию агентов с тестируемой системой,
- проверка работоспособности и эффективности предложенных методик и
инструментальных средств в 6 проектах для двух различных архитектур
встроенных мобильных платформ
1 3 Предметом исследования являются методы, средства и программный инструментарий автоматизации тестирования и мониторинга поведения встроенных мобильных платформ
1.4 Методы исследования В диссертации использованы результаты теории реактивных и транзитивных систем, конечных автоматов и базовых протоколов, аппарат формальных спецификаций, концепция объектно-ориентированных моделей Основными критериями являлись универсальность, технологичность, простота использования и адаптации разработанных методик, а также возможность интеграции с существующими средствами автоматической генерации кода тестов Применялись стандарты UML, MSC, ANSI С и Java В основу исследований положен системный подход
1.5 Обоснованность и достоверность полученных результатов обеспечена корректным использованием теорий реактивных и транзитивных систем, конечных автоматов и базовых протоколов, использованием строгого аппарата формальных спецификаций, положительными итогами использования разработанных методик и программных средств в реальных проектах, совпадением результатов по достижению качества ПО, полученных различными методами
1 6 Научные результаты и их новизна На защиту выносятся следующие научные результаты работы
-
Модели архитектурных компонентов встроенных Java систем и модель универсального агента в виде реактивных систем переходов
-
Обобщенная методика встраивания агентов, разработанная на основе моделей
-
Доказательство корректности функционирования и безопасности встраивания агентов с точки зрения сохранения логики работы межкомпонентных интерфейсов на основе верификации моделей и их взаимодействий
-
Специализированные методики встраивания агентов, позволяющие обеспечить наблюдение и управление в различных задачах тестирования и мониторинга методика встраивания агентов на уровне Java ME приложений, методика встраивания агентов на уровне kJava виртуальной машины (KVM), методика встраивания агентов на уровне платформенного окружения
-
Алгоритм анализа и модификации байт-кода Java ME приложения, обеспечивающий возможность наблюдения за внутренним поведением тестируемого приложения и генерации воздействий встроенным агентом
-
Методика для ускорения выбора путей ветвления тестовых сценариев на основе выбора альтернатив с помощью сигнатур
1.7 Практическая значимость работы. На базе полученных научных результатов разработан комплекс программных средств, использующий методики встраивания агентов для автоматизации тестирования прикладного и системного ПО, и их взаимодействий Программный комплекс использован в компании Motorola в 6 программных проектах для двух различных платформенных архитектур в таких областях как разработка Java ME приложений (MIDlet, i-appli, CORElet), сертификационное и компонентное тестирование встроенных Java платформ Созданные методики и программные средства являются универсальными и могут быть использованы для автоматизации тестирования и мониторинга прикладного и системного ПО любых современных платформенных архитектур встроенных вычислительных систем Применение технологии автоматизации тестирования на базе методик встраивания агентов позволяет в среднем сократить время
фазы прогона тестов, сбора и анализа результатов в 6 раз по сравнению с ручным подходом и в 1,7 раза по сравнению с существующими подходами автоматизации
1.8 Апробация работы Основные результаты и выводы диссертации докладывались на следующих международных научных конференциях «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 в теории и практике программирования» 2004, 2005 и 2006 гг, конференциях XXXTI-2004 г, ХХХШ 2005 г, XXXIV-2006 г педели науки СПбГПУ По материалам диссертации опубликовано 6 печатных работ, в том числе одна статья в издании, входящем в список рекомендованных изданий ВАК
1 9 Внедрение Методики встраивания агентов для исследуемых вычислительных систем и технология автоматизации тестирования, разработанная на их базе, внедрены в ЗАО «Северо-Западная Лаборатория Лтд », ОАО «Интелтех», ЗАО «Моторола ЗАО» и использовались при разработке учебно-методического комплекса СПбГПУ по курсу «Технология индустриального программирования» на кафедре ИУС Практическое использование представляемых на защиту результатов подтверждено соответствующими актами о внедрении
1 10 Структура и объем работы. Работа содержит введение, 5 глав, заключение и 5 приложений Объем работы 150 страниц, количество иллюстраций 69, список использованной литературы состоит из 112 наименований
Системные kJava приложения-CORElet
В данной главе приведен обзор и анализ Java технологии для встроенных вычислительных систем. Рассмотрены различные типы и особенности Java приложений и Java виртуальных машин встроенных вычислительных систем. В условиях ограниченных ресурсов (память, вычислительная мощность устройств), Java технология обеспечивает их эффективное использование и разработку сложных программных проектов. Тем не менее, в рамках Java технологии отсутствуют эффективные методы программного управления и наблюдения за поведением приложений, что не позволяет автоматизировать тестирование Java ПО.
Приведен обзор использования формальных спецификаций для увеличения эффективности процесса разработки ПО. В главе вводится понятие автоматизации тестирования, проведен анализ существующих подходов к автоматизации тестирования в исследуемой предметной области. Анализ проведен по двум направлениям:
Анализ существующего инструментария для автоматической генерации кода тестов из формальных описаний, применимого к исследуемой предметной области. Анализ существующих методов и средств, обеспечивающих возможность автоматизации прогона тестов, сбора и анализа результатов.
На основе проведенного анализа сделан вывод о необходимости создания методик, обеспечивающих автоматизацию прогона, сбора и анализа результатов для поддержки технологии автоматизации тестирования не только прикладного, но и системного ПО встроенных вычислительных систем.
Java технология для мобильных устройств В настоящее время технология Java широко применяется в области беспроводных устройств и мобильных телефонов. Для них разработан специальный класс Java технологии - Java ME (MicroEdition).
Термин Java ME отражает попытку Sun Microsystems перевести язык программирования Java на устройства с ограничениями по ресурсам. Мобильный телефон, который не обладает большими вычислительными мощностями; памятью, а тем более мощностями рабочих станций, не может выполнять задачи такой же функциональности, как высокопроизводительные сервера и рабочие станции.
Идея платформы Java ME заключается в применении языка программирования Java к устройствам с ограниченными ресурсами с целью получить максимальную функциональность на основе универсального подхода к программированию приложений. В результате обеспечивается широко используемый в данной области применений базовый набор функций и специализированных классов.
Платформа Java ME разбита на конфигурации, профайлы и дополнительные пакеты. Конфигурации - это спецификации, которые определяют виртуальную машину (KVM- kJava Virtual Machine) и набор базовых классов библиотек. Библиотеки предоставляют набор необходимых АРІ для программирования устройств конкретных классов. Они обеспечивают базовую функциональность для определенного круга устройств, обладающих схожими характеристиками, такими как доступ к сети или файловой системе. Конфигурация, например, может быть спроектирована даже для устройств с объемом памяти менее 512 Кб. На данный момент имеется две конфигурации Java ME: Connected Device Configuration (CDC)[1] и Connected Limited Device Configuration (CLDC)[2].
Профайлы дополняют конфигурацию специфичными API, необходимыми для создания исполнимой среды конкретной категории устройств. Профайл - это набор высокоуровневых интерфейсов, которые определяют модель жизненного цикла приложения, пользовательский интерфейс, доступ к специфическим функциям устройства. Наиболее широко распространенный пример - это соединение конфигурации CLDC с Mobile Information Device Profile (MIDP) (рис. 1) - дающее полноценную исполняемую среду Java для мобильных телефонов и устройств со схожими характеристиками.
Дополнительные пакеты расширяют платформу Java ME путем добавления новой функциональности к технологическому стеку, который уже включает в себя CLDC и соответствующий профайл. Примеры таких дополнительных Java ME API - это АРІ для доступа к базам данных, обмену беспроводными сообщениями, 3D графике или WEB сервисам. Поскольку дополнительные пакеты имеют модульную архитектуру, разработчики могут не включать лишние пакеты в свои устройства.
Также важной частью ПО мобильного устройства, кроме Java ME приложений, профайлов, конфигураций и виртуальной машины, являются платформенные (так называемые, «native») приложения (например, вызов и прием звонков, телефонная книга, календарь и др.). Взаимодействие, совместная работа и интеграция элементов Java ME платформы с native-приложениями обеспечивает полную функциональность устройства. MIDP приложения
Взаимоотношения между Java ME конфигурациями, профайлами и дополнительными пакетами представлены на рис. 2, из которого видно, что Java ME имеет две базовых конфигурации. Первая - Connected Limited Device Configuration (CLDC). Это конфигурация предназначена для небольших беспроводных устройств, таких как мобильные телефоны и компыотеры-наладонники (PDA). Mobile Information Device Profile (MIDP), который базируется на CLDC, был первым законченным профайлом и, таким образом, первой законченной Java ME средой разработки приложений.
Другая базовая конфигурация - Connected Device Configuration (CDC). Эта конфигурация предназначена для больших устройств (в терминах потребления памяти и процессорной мощности) с постоянным сетевым соединением. Компьютерная приставка к телевизору, терминалы доступа в Internet - типичные примеры CDC устройств, кроме того, мобильные устройства high-end класса также попадают в эту категорию.
Кроме упомянутых базовых профайлов, стандартизированных фирмой Sun, существует также профайлы, разработанные другими производителями, в частности NTT DoCoMo профайл, получивший название DoJa (DoCoMo Java) [3].
Представление java систем в виде реактивных моделей
Поведение реактивной системы представляется множеством всех возможных вычислений ее системы переходов. Системы переходов применимы и при спецификации параллельных дискретных систем, так как параллельная композиция систем переходов также является некоторой новой системой переходов. Ее функционирование может быть представлено уже ее множеством вычислений. Часто наряду с обычными (линейными) вычислениями используют деревья вычислений [84]. Такое представление поведения параллельных процессов нагляднее и эффективнее, поскольку позволяет проследить пути развития каждого отдельного процесса.
Разработанные на основе модели системы переходов алгоритмы верификации ([85][86]) позволяют исследовать свойства реактивной системы с точностью до порядка наступления событий в системе, что дает возможность анализа качественных свойств поведения. Порядком наступления событий в реактивной системе называется относительный порядок следования переходов в ее вычислении.
Кроме того, в реактивных системах реального времени необходимо учитывать конкретные моменты времени наступления событий, а также время выполнения отдельных операций (в состояниях). Для ввода времени в вычислительную модель реактивной системы обычно используют два подхода: 1. Первый заключается в учете длительности нахождения в каждом дискретном состоянии. Реализуется введением задержек срабатывания переходов в системе переходов. 2. Второй заключается в отслеживании моментов наступления событий. Реализуется с помощью модели таймированного автомата или системы временных переходов. Системой временных переходов называется тройка [80]: где S - система переходов (2.1), a L, U - множества нижних и верхних границ интервалов временных задержек срабатывания активизированных переходов Т Є Т:
В случае одного последовательного наблюдателя, поведение системы временных переходов представляется последовательностью событий двух типов: событие изменения времени при неизменном состоянии и последующего за ним одного или нескольких событий изменения состояний при фиксированном времени [75].
Рассмотрим реактивную систему с точки зрения процесса тестирования. С этой точки зрения реактивная система может быть описана конечным множеством интерфейсов, доступных из тестового окружения [87].
Интерфейсы можно разбить на входные и выходные: Входной интерфейс - интерфейс для воздействий окружения на тестируемую систему. Будем называть его управляющим интерфейсом. Выходной интерфейс - интерфейс для получения откликов тестируемой системы в окружение. Будем называть его наблюдаемым интерфейсом. Дополнительно, в реальных системах, интерфейсы делятся на два класса по типу взаимодействия: Синхронные интерфейсы. Взаимодействия осуществляется с использованием синхронных неделимых операций. Системы с синхронными интерфейсами выдают результат непосредственно на оказанное входное воздействие. Во время выполнения синхронной операции система блокируется, т.е. не может обрабатывать входные воздействия. Асинхронные интерфейсы. Результат на входное воздействие появляется не сразу, а через некоторое время. Таким образом, после посылки входного сигнала, окружение переходит в режим ожидания ответа. Однако, прием входных воздействий во время этого ожидания возможен.
Важной характеристикой интерфейсов обмена является наличие параметров. Кроме самого факта события, по интерфейсу передаются данные, связанные с этим событием (как входным, так и выходным). Состав этих данных определяется спецификацией каждого конкретного интерфейса. Таким образом, можно ввести понятие импульса (или сигнала). Импульсом будем называть динамическую характеристику системы, которая описывает непосредственную реализацию интерфейса в процессе работы системы в заданный момент времени. Например, пусть интерфейс / специфицирован некоторой функцией F, с заданным множеством параметров V, в общем случае типизированных. Тогда:
В этом случае импульсом является вызов функции F с заданными значениями для каждого параметра v;. из множества V. Понятие импульса является одинаковым как для входного, так и для выходного интерфейса [88]. Импульс входного интерфейса несет в себе набор параметров для обработки тестируемой системой. В случае выходного интерфейса импульс содержит набор результирующих значений параметров работы тестируемой системы.
Применение технологии кодогенерации тестовых наборов с помощью инструмента ТАТ возможно лишь к реактивным системам [88]. Таким образом, необходимо представить основные компоненты Java ME платформы, подвергаемые тестированию, в виде реактивных систем. Каждый компонент будет представлять собой дискретную систему, а их параллельная композиция - параллельно-дискретную систему, описывающую функционирование мобильного устройства в целом. Основными тремя компонентами программной платформы мобильного устройства, интересными для наблюдения, являются: Java ME приложение, виртуальная машина Java (KVM) и, собственно, низкоуровневое окружение или платформа.
Представим динамическое поведение Java ME приложения. Можно говорить, что наблюдаемая работа любого Java ME приложения сводится к получению входных воздействий и посылку откликов на них в окружение. Окружением для Java ME приложения всегда является виртуальная машина - KVM.
Обобщенная концепция интеграции тестового набора, агента и тестируемого приложения
Использование классов-оболочек предоставляет возможность симулировать нажатия клавиш устройства путем простого вызова соответствующего метода приложения (как это обычно делает виртуальная машина после физического нажатия). Графическая информация приложения в полном объеме проходит через классы-оболочки, обеспечивая возможность ее автоматической обработки.
Последним ключевым моментом подхода является передача управления агенту, который запускает приложение в отдельном потоке внутри себя. Все взаимодействия в соответствии с жизненным циклом приложения происходят между виртуальной машиной и агентом, обеспечивающим исполнение тестового сценария. Автоматическая синхронизация потоков, встроенная в Java платформу, исключает необходимость решения синхронизационных проблем.
Диаграмма функционирования не инструментированного приложения. На рис. 24 представлена диаграмма функционирования для оригинального (не инструментированного) приложения. Виртуальная машина («KVM») управляет жизненным циклом приложения («Application») в соответствии с состояниями платформенного окружения («Platform»), инициируя вызовы startApp(), pauseApp() и destroyApp(). Виртуальная машина («KVM») принимает от приложения («Application») запросы на отрисовку экранов (как графических, так и текстовых), а также вызывает интерфейсный метод keyPressedO в те моменты, когда происходит нажатие клавиши на мобильном устройстве. Данная диаграмма является примером функционирования во времени интегрированной модели системы, рассмотренной в п. 2.2.4.
Стоит отметить, что с точки зрения Java машины, все используемые методы (keyPressedO, paintO и др.) являются синхронными неделимыми операциями. Это исключает проблемы синхронизации на уровне тестового сценария. представлена диаграмма функционирования системы после инструментирования и интеграции оригинального приложения с агентом и набором тестовых сценариев. Это один из примеров функционирования во времени модели, описанной в п. 2.3.2.
Теперь уже KVM управляет жизненным циклом агента с интегрированным тестовым набором («Agent + Test Suite»), который стал главным («фокусным») приложением. Агент, в свою очередь и в соответствии с тестовым сценарием, запускает приложение («Application») в отдельном потоке исполнения и принимает от него запросы к виртуальной машине, анализирует их, записывает в лог-файл и передает запрос дальше в KVM, таким образом, логика работы приложения полностью сохраняется. Также агент считывает из тестового сценария и генерирует последовательности нажатий клавиш (вызовов интерфейсного метода keyPressed()). Такой подход позволяет полностью автоматизировать стадию прогона теста.
Анализ результатов прогона может производиться как в online-режиме, прямо во время исполнения, так и в offline-режиме. Также существует возможность анализировать не весь экран, а только лишь те элементы (классы), которые изменились с момента получения последнего отклика тестируемого приложения.
Данный подход позволяет тестировать Java ME приложения не только на любом телефоне, но и на симуляторе, т.е. на эталонной KVM. Таким образом, данный подход к реализации методики встраиваемых агентов сохраняет свойство инвариантности относительно реализации конкретной KVM.
Взаимодействие между агентом, тестовым набором и тестируемым приложением осуществляется асинхронно. Несмотря на то, что, как уже упоминалось, вызовы практически всех используемых методов Java являются синхронными, тем не менее, они не возвращают необходимый результат сразу же. Это связано с тем, что используемые аппаратные ресурсы (клавиатура, экран, сетевые сервисы) работают по асинхронной схеме, поэтому их программная эмуляция также должна обеспечивать работу по этой схеме, для адекватного отображения реальности.
В случае необходимости существует возможность ввести небольшие временные задержки после каждого вызова. В этом случае агент приостанавливает поток приложения на заданное короткое время. Такой подход позволяет избежать проблем с использованием асинхронных вызовов (так называемых, «гонок событий»).
В результате работы методики автоматизации, мы получаем оттестированное, работающее по спецификации приложение. В случае обнаружения некорректной работы какого-либо конкретного устройства можно говорить, что ошибка заключена не в приложении, а в реализации виртуальной машины данного конкретного устройства. 3.1.2 Концепция тестирования системных Java ME приложений
Концепция использования классов-оболочек является универсальным решением по реализации методики встраивания агентов для автоматизации тестирования Java ME приложений. Тем не менее, существуют случаи, когда применение классов-оболочек является неэффективным.
Концепция использования классов-оболочек хорошо зарекомендовала себя для тестирования тех типов приложений, которые реализованы только с использованием стандартных JSR, т.е. имеющих строго ограниченный набор классов, для которых необходимо создание классов-оболочек.
Для тестирования MIDlet был разработан полный комплект необходимых классов-оболочек для MIDP-профайла. Эта библиотека получила название MTestAPI.
Также была разработана библиотека для профайла DoJa и i-appH приложений. Тем не менее, строгое ограничение размера i-appli приложения в 100К вынуждало разделять полные тестовые наборы на более мелкие поднаборы, чтобы размер нового приложения (оригинальное приложение + классы агента + тестовые сценарии) не превышал это ограничение.
Для системных приложений (CORElet) применение такого подхода было не целесообразным, т.к. используемое ими SynerJ Framework API [8] не стандартизировано, постоянно расширяется, а также имеет гораздо больший объем классов, нежели MIDP или DoJa профайлы.
Методика встраивания агентов в KVM Для автоматизации тестирования системных приложений в рамках методики встраиваемых агентов была разработана особая интегрированная модель встраивания универсального агента. Встраивание происходит не между двумя компонентами, а внутри компонента KVM. Как и в других методиках встраивания агентов, рассмотренных в п. 2.3, множество генерируемых агентом событий и множество наблюдаемых событий должно быть приведено в соответствие с множествами соответствующих компонентов, после чего параллельная композиция моделей агента, тестируемой системы и окружения выглядит следующим образом:
Таким образом, данный подход является промежуточным между методикой встраивания агентов для Java ME приложений (см. п. 2.3.2) и методикой встраивания агентов на уровне окружения (см. п. 2.3.3).
Для методики встраивания агентов на уровне KVM проведена проверка корректности взаимодействия компонентов (платформа, KVM, приложение) после встраивания агента. Логика функционирования межкомпонентных интерфейсов сохраняется (см. п. 2.4).
Модуль тестирования системных и DoJa приложений
Автоматизированные тесты, используемые в технологии, генерировались с помощью системы VRS/TAT. Затраты на настройку системы и разработку тестовых MSC-сценариев подробно рассмотрены в [88].
Собранная статистика демонстрирует (рис. 43), что сложно добиться 100%-ной автоматизации. Тем не менее, средний коэффициент автоматизации для выбранных проектов достаточно высок и составляет 91,6%. Коэффициент автоматизации - отношение числа автоматизированных тестов к общему числу тестов, необходимых для прогона. Чем выше коэффициент автоматизации, тем меньше времени необходимо затратить тестировщику на прогон одного тестового цикла [31][32][110].
Сложность 100%-ной автоматизации обусловлена не только спецификой работы Java ME приложений. Необходимо тестировать не только функциональность самого приложения, но и его взаимодействие с платформой. Методика встраивания агентов на уровне приложений с использованием классов-оболочек не позволяет оттестировать взаимодействие Java ME приложений с другими платформенньши компонентами, такими как входящие/исходящие вызовы, посылка/прием SMS и т.п. Это ограничение связано с тем,
В рамках применения методики встраивания агентов на уровне KVM данная проблема частично решена. Работа виртуальной машины, на которой исполняется COREIet, не прерывается на время запуска платформенных приложений, но из-за потери фокуса KVM, ограничения все равно остаются. Есть возможность генерировать нажатия клавиш, но нет возможности сохранять скриншоты экрана.
Несмотря на невозможность 100%-ной автоматизации, выигрыш по временным и человеческим затратам остается существенным.
На диаграмме (рис. 44) представлены временные и человеческие затраты на один тестовый цикл ручного и автоматизированного подхода к тестированию для каждого проекта. Стоит отметить, что при ручном подходе к тестированию используются только человеческие ресурсы и время человека. При автоматическом подходе существует два вида затрат:
Как видно из рис. 44 и таблицы 10, при автоматизированном подходе получается шестикратный вьшгрыш по затратам человеко-часов. При увеличении количества тестовых циклов, вьшгрыш во времени растет экспоненциально. В проекте «DoJa ImageEditor» временные затраты тестировщика немного больше затрат машинных часов, это происходит из-за высокой производительности аппаратного обеспечения DoJa устройств.
Временной выигрыш является не единственным при применении предлагаемой технологии. Также наблюдается небольшое увеличение качества (рис. 45). Это объясняется уменьшением влияния человеческого фактора.
Использование технологии автоматизации тестирования Java ME приложений с помощью методик встраивания агентов имеет ряд ограничений. Тем не менее, в большинстве случаев внедрение технологии позволяет получить существенные выигрыши по времени и трудозатратам. В таблице 11 показаны затраты по ресурсам, необходимые для применения методик встраивания агентов.
Данные приведены уже для отлаженных агентов. Для адаптации методики встраивания агентов на уровне приложения к новому профайлу необходимо разработать новую библиотеку классов оболочек, в среднем на это уходит 3 человека-дня. Для адаптации методики встраивания агентов на уровне KVM к новой платформе необходимо портировать платформенное API с учетом особенностей native ПО, в среднем на это уходит 5 человеко-дней. Таким образом, целесообразно использовать технологию автоматизации в крупных проектах, где сравнимое этими затратам время на один тестовый цикл, а также большое количество тестов циклов.
Рассмотрим использование системных ресурсов для методики встраивания агентов на уровне приложения. Усредненный размер библиотеки классов-оболочек - порядка 14 Кб, средний размер одного тестового сценария - 10 Кб. Подготовка приложения для тестирования (включает в себя настройку байт-код анализатора, интеграцию с библиотекой классов-оболочек и тестовым набором) занимает полчаса. Таким образом, необходимо включать в тестовый набор максимально возможное число сценариев, что, во-первых, сократит время на подготовку, во-вторых, уменьшит долю библиотечных классов в приложении.
Для методики встраивания агентов на уровне KVM использование системных ресурсов распределено иначе. Платформенное API увеличивает на 6 Кб не приложение, а программное обеспечение KVM, это увеличение абсолютно незначительно в этих рамках. Время на подготовку приложения 1 час (из-за необходимости подготовки эталонов для возможного выбора альтернатив), но размер одного тестового сценария - 1 Кб, правда, для хранения скриншотов экрана и, возможно, эталонов, в среднем требуется 300 Кб свободного места в файловой системе телефона. Для телефонов первого поколения с МГОР-профайлом размер файловой системы не позволял использовать этот подход. Зато, для MIDIet отсутствует ограничение на размер приложения, поэтому работает методика встраивания агентов на уровне приложений. Для DoJa приложений существует ограничение в 100Кб на приложение, именно поэтому приоритетной методикой для DoJa является использование KVM-агентов. Мобильные устройства с DoJa-профайлом оснащены внешними картами памяти, что обеспечивает наличие свободного места в файловой системе.
Модуль системы VRS/TAT из формальных спецификаций требований или тестовых сценариев генерирует тестовые наборы (или файлы конфигурации в случае использования пассивного агента для мониторинга работы) на специализированном скриптовом тестовом языке. Разработанный native-агент интегрируется с кодом платформенного ПО и загружается на мобильное устройство во время прошивки новой версии ПО. Тестовые наборы (или файлы конфигурации) загружаются в файловую систему мобильного устройства. После старта мобильного устройства автоматически происходит прогон тестовых сценариев, либо во время работы собирается протокол в соответствии с файлами конфигурации. Стоит отметить, что возможно тестирование не только платформенных приложений, но и Java ME приложений, а также их взаимодействий.
Поскольку агент может работать в двух режимах - активном и пассивном, при чем существует возможность переключаться между ними в рамках одного тестового сценария, анализ результатов, как правило, проводится «off-line». Во время прогона скриншоты и протоколы работы сохраняются в файловой системе мобильного устройства, которые анализируются с помощью специализированного ПО после окончания тестового цикла. Во время прогона возможен выбор путей тестовых сценариев на основе сравнения и анализа эталонов с помощью методики выбора альтернатив (п. 3.3).
