Методы автоматизации распределённого тестирования реактивных систем тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат наук Тютин, Борис Викторович

• Тютин, Борис Викторович
• кандидат наук
• 2013

Оглавление диссертации кандидат наук Тютин, Борис Викторович

Введение

Глава 1. Современные подходы к автоматизации создания и выполнения тестового набора

1.1 Критерии тестирования

1.2 Актуальные подходы к тестированию

1.2.1 Тестирование, управляемое данными

1.2.2 Тестирование на основе ключевых слов

1.3 Параллельное программирование в тестировании

1.3.1 Разработка параллельного алгоритма

1.3.2 Оценка качества параллельного алгоритма

1.3.3 Характеристики параллельных алгоритмов

1.5 Инструментальные средства автоматизации тестирования

1.5.1 Сравнение средств автоматизации тестирования

Выводы

Глава 2. Подходы к реализации этапов технологии распределённого тестирования

2.1 Метод создания параметризованного тестового набора на основе требований к продукту

2.1.1 Анализ формальной модели и построение поведенческих трасс с символическими параметрами

2.1.2 Требования к языку описания тестовых сценариев

2.1.3 Преобразование поведенческих трасс в тесты

2.1.4 Формулировка метода построения параметризированных тестовых сценариев

2.2 Метод автоматизации выполнения тестового набора на основе плана тестирования

2.2.1 Конкретизация тестового набора и составление плана тестирования

2.2.2 Сборка тестового набора

2.2.3 Выполнение тестового набора

2.2.4 Формирование результатов тестирования

2.2.5 Формулировка метода автоматизации тестирования

2.3 Метод автоматизации анализа результатов тестирования и коррекции тестов

2.4 Методы масштабирования выполнения тестового набора

2.4.1 Возможные подходы к масштабированию

2.4.2 Изолирование среды исполнения тестов

2.4.3 Метод кластеризации тестового набора

2.4.4 Метод параллельного выполнения тестов

2.5 Метод автоматизированного тестирования с обратной связью, основанный на анализе

требований

Выводы

Глава 3. Реализация этапов технологии распределённого тестирования

3.1 Реализация метода автоматизации создания параметризованного тестового набора на основе требований к продукту

3.1.1 Формализация требований

3.1.2 Генерация тестовых сценариев

3.1.3 Изменение набора сущностей

3.2 Реализация метода автоматизации выполнения тестового набора на основе плана тестирования

3.2.1 Конфигурирование тестового набора

3.2.2 Конкретизация параметров тестового сценария

3.2.3 Интерпретация языка тестовых сценариев

3.2.4 Построение тестового набора

3.2.5 Запуск тестирования

3.2.6 Завершение тестирования

3.3 Реализация метода автоматизации анализа результатов тестирования и коррекции тестового набора

3.4 Реализация методов масштабирования тестового набора

3.4.1 Модуль кластеризации тестового набора

3.4.2 Параллельное выполнение тестов

3.4.3 Сборка и запуск тестового набора при масштабировании

3.5 Реализация метода автоматизированного тестирования с обратной связью, основанного на анализе требований

3.5.1 Шаги метода

3.6.2 Контуры обратной связи

Выводы

Глава 4. Результаты применения разработанных методов автоматизации тестирования

4.1 Практическое применение результатов работы

4.1.1 Внедрение разработанных методов

4.1.2 Анализ затрат на изменение исходных требований и их проверку

4.1.3 Описание проектов для апробации метода

4.2 Оценка эффективности результатов внедрения разработанных методов применительно к реальным проектам

4.2.1 Анализ времени построения тестового набора

4.2.2 Анализ объёма тестового набора при использовании параметризованных тестов

4.2.3 Анализ времени конфигурирования тестового набора при ручном и автоматическом масштабировании

4.2.4 Анализ ускорения выполнения тестового набора при масштабировании

4.2.6 Анализ преимуществ использования системы тестирования как сервиса

4.2.7 Анализ затрат на внесение изменений в требования

Выводы

Заключение

Список сокращений и условных обозначений

Литература

Приложение 1, Критерии тестирования

Критерии «чёрного ящика»

Критерии «белого ящика»

Приложение 2. Виды объектов тестирования

Приложение 3. Технологии параллельного программирования

MPI

OpenMP

Приложение 4. Обзор инструментальных средств автоматизации тестирования

Fit

Robot Framework

JUnit

TAT

UniTesK

HP Quick Test Professional

IBM Rational Functional Tester

Приложение 5. Формализация требований

Приложение 6. Синтаксис языка гидов VRS

Приложение 7. Используемые в работе технологии и инструменты

Введение диссертации (часть автореферата) на тему «Методы автоматизации распределённого тестирования реактивных систем»

Введение

Актуальность работы. В настоящее время в процессе производства программного продукта (ПП) много внимания уделяется обеспечению его качества - соответствию начальным требованиям, эффективности решения поставленной задачи, надёжности работы. В силу особенностей решаемых задач непосредственная выгода от улучшения характеристик создаваемых информационных систем для заказчика часто неочевидна и скрыта. Потому в случае сокращения издержек производства, в первую очередь сокращаются затраты на поиск ошибок и расхождений между требованиями к программному продукту и его реализацией [59], что, в свою очередь, приводит к снижению ценности создаваемых программ.

Наиболее популярным инструментом управления качеством ПП является тестирование [60]. Актуальная задача снижения времени и стоимости тестирования решается с помощью автоматизации путем объединения в технологическом процессе тестирования различных готовых инструментов. Существенным недостатком такого подхода является интеграция разнородных средств автоматизации тестирования в существующий процесс разработки и их стыковка с уже использующимся инструментарием. Постепенное накопление опыта решения подобных задач привело к появлению каркасов для построения систем автоматизации тестирования [76]. Обзор наиболее известных из них представлен в Приложении 4. Проведенный в работе анализ, представленный в пункте 1.5, позволяет сделать вывод о том, что в области построения систем автоматизации тестирования всё ещё существуют проблемы, решение которых приведёт к созданию высокоэффективных инструментов.

Основная цель контроля качества программного продукта (ПП) - увеличить его ценность за счёт уменьшения количества ошибок реализации, обеспечения соответствия исходным требованиям и снижения стоимости сопровождения. Для достижения этой цели необходимы формализованный процесс и программные средства его поддержки. В то время как методы разработки программных продуктов становятся более гибкими (в качестве примера можно привести

идеологию Agile), использование сложных, бюрократизированных процессов для них практически невозможно. По этой причине возникает потребность в адаптируемых методах управления качеством программного продукта, обеспечивающих не только автоматизацию тестирования, но и проверку соответствия готового ПО его спецификациям, а также непротиворечивость последних [65]. Основным требованием к технологиям становится возможность построения единой методологической цепочки, обеспечивающей контроль качества разрабатываемых продуктов. В отличие от ранее предлагаемых решений, в текущих условиях наибольшую эффективность обеспечивают процессы, базирующиеся на инструментах, которые могут быть легко адаптированы и расширены.

Основным недостатком подобного подхода является то, что различные фазы процесса (хранение и модификация требований, построение тестового набора и другие) реализованы на основании разнородных готовых инструментов, интеграция которых в эффективную технологическую цепочку затруднена, а степень автоматизации недостаточно высока.

Развитие технологий разработки программного продукта, а также эволюция структуры рабочих коллективов приводят к появлению новых подходов в тестировании. Так в пункте 1.2 описаны современные подходы к организации автоматизированного тестирования, указаны их недостатки и ограничения. Возможности, предоставляемые ими, позволяют существенно снизить стоимость тестирования. Потому решение задачи устранения недостатков таких подходов, как тестирование, управляемое данными, и тестирования на основе ключевых слов, является востребованным при построении новых средств автоматизации тестирования. Среди рассмотренных в пункте 1.5 программных инструментов выбрана технология VRS/TAT, которая покрывает весь цикл управления качеством программного продукта, что не избавляет ее от некоторых из упоминаемых недостатков.

Помимо новых подходов к управлению качеством, появление новых технологий в сфере создания программного продукта расширяет круг возможных

областей применения средств автоматизации тестирования, а также способов его организации. Одни из наиболее молодых и интенсивно развивающихся направлений в данный момент это кластерные и облачные вычисления. Принципы, лежащие в основе предоставления программных средств и комплексных решений как сервиса (SaaS - software as a service, и IaaS -infrastructure as a service) могут быть распространено на автоматизацию тестирования. Это открывает перспективную область для научных исследований и разработок, результаты которых могут быть применены на практике.

Степень разработанности темы. Проблемам формализации и автоматизации методов верификации и тестирования, а также из применения на практике посвящены работы таких авторов, как Липаев В.В., Петренко А.К., Карпов Ю.Г. Среди зарубежных авторов наиболее значимыми с точки зрения близости к теме работы можно назвать труды R. Alura, Н. Wenhong, В. Bollig, К. Beck, М. Fewster, R. Osherove и других.

Указанными авторами были опубликованы как фундаментальные работы, сформировавшие теоретическую базу для дальнейших изысканий в области автоматизации тестирования и верификации ПО с применением формальных моделей, так и труды, обобщающие богатый опыт индустриального производства программного продукта. В научных статьях, издаваемых в течение последнего десятилетия, освещаются вопросы автоматического создания тестов и анализа спецификаций.

Однако в данных работах недостаточно рассмотрены вопросы интеграции современных подходов к тестированию, предлагаемые авторами методы автоматизации построения тестового набора обладают известными ограничениями на способ описания тестовых сценариев.

С другой стороны, при детальной проработке аспектов верификации, не до конца раскрывается потенциал её объединения с тестированием.

Цели и задачи диссертационной работы. Целью диссертации является разработка группы методов, автоматизирующих этапы тестирования ПО, начиная с получения тестового набора на основе формальных спецификаций и заканчивая

формированием результатов тестирования и их анализом, а также реализация средств поддержки, предоставляющих инструментарий для организации тестирования на различных этапах жизненного цикла ПО — модель, код, исполняемая программа.

Для достижения поставленной цели в работе были решены следующие задачи:

1) Разработка метода написания тестов, основанного на DDT (Data-Driven Testing) и KDT (Keyword-Driven Testing), и имеющего возможность выполнения нелинейных сценариев;

2) Определение способа взаимодействия тестирующей системы с моделью и её компонентами (интеграционное и модульное тестирование) на разном уровне;

3) Создание метода построения параметризованных тестов с определением набора значений параметров отдельно от тестовых сценариев;

4) Формулировка методов масштабирования выполнения тестового набора;

5) Создание средств автоматизации тестирования, реализующих разработанные подходы;

6) Разработка метода автоматизированного тестирования, основанного на созданных программных средствах, и реализующего полный набор действий по контролю качества программного продукта в течение всего цикла его создания.

Научные результаты и их новизна.

• Разработан метод создания параметризованного тестового набора на основе формальных спецификаций, сочетающий принципы тестирования, управляемого данными, и тестирования на основе ключевых слов, свободный от ограничений на описание нелинейного поведения и параллельных взаимодействий в тестовых сценариях;

• Создан метод автоматизации выполнения тестового набора на основе плана тестирования. Его научная новизна заключается в применении символьных

поведенческих трасс, которые затем автоматически конкретизуются и выполняются согласно плану тестирования;

• Предложен метод анализа результатов тестирования и коррекции тестов, автоматизирующий идентификацию точек останова в ходе выполнения теста и отображение поведенческих трасс, ведущих к этой точке, на исходной формальной модели системы;

• Предложено решение задачи масштабирования выполнения тестового набора с помощью разработанного метода кластеризации группы тестов по критериям её объёма и суммарной сложности тестов и метода параллельного выполнения тестов. Реализация методов автоматически обеспечивает изоляцию среды выполнения тестов, тем самым, исключая их взаимное влияние и снижая сложность автоматизации тестирования;

• На основе результатов работы создан метод автоматизированного тестирования, интегрирующий анализ требований, метод тестирования, управляемого данными, метод тестирования, основанного на ключевых словах, и автоматизацию масштабирования выполнения тестового набора. Теоретическая и практическая значимость работы. В ходе данной

работы были созданы методы, автоматизирующие различные этапы процесса контроля качества программного продукта, основанного на тестировании. Теоретической основой методов является разработанные модель параллельного запуска тестирования и расширение аппарата символьной верификации, предложенного A.A. Летичевским. Данные методы были формализованы до уровня алгоритмов, на основе которых были разработаны инструментальные средства поддержки методов, базирующиеся на технологии верификации VRS и технологии автоматизации тестирования TAT. На основании интеграции разработанных методов была создана методика автоматизации тестирования. Использование плана тестирования и конкретизации параметров тестов позволило упростить автоматизацию тестирования и снизить сложность реализации тестовых процедур. Реализованные методы и средства масштабирования тестирования решили задачу автоматизации настройки и запуска больших

тестовых наборов. Разработанные методы, алгоритмы и программные средства могут быть отчуждены и использованы как вместе, так и независимо друг от друга в качестве компонент сторонних методов и информационных систем. В рамках четырёх проектов по тестированию программного обеспечения применение результатов исследования позволило получить сокращение времени фазы тестирования в пределах 50-70%.

Исследование проводилось при финансовой поддержке в форме гранта Правительства Санкт-Петербурга 2013 г. для студентов, аспирантов вузов и академических институтов, расположенных на территории Санкт-Петербурга, а также стипендии Президента Российской Федерации 2012 года.

Методы исследования. Для решения поставленных в работе задач используются теория графов; теория алгоритмов в области параллельного программирования; теория конечных автоматов; теория инсерционного программирования; аппарат формальных спецификаций. Применяются стандарты языков Use Case Maps (UCM) и Message Sequence Charts (MSC).

Предметом исследования являются методы и инструментальные средства автоматизации процесса контроля качества ПП.

Положения, выносимые на защиту:

— Методы автоматизации этапов тестирования ПО:

1) автоматическое создание параметризованного тестового набора;

2) автоматическое тестирование на основе плана;

3) автоматизированный анализ результатов тестирования;

4) автоматизированное масштабирование выполнения тестирования;

— Реализация современных подходов к тестированию на базе символьной верификации;

— Адаптация технологии VRS/TAT для использования в облачных и кластерных вычислительных системах;

— Результаты экспериментальных исследований ускорения выполнения тестового набора при масштабировании запуска.

Обоснованность и достоверность полученных результатов

обеспечивается корректным использованием теории графов и теории алгоритмов; использованием формальных моделей проектирования параллельных вычислений; сравнением результатов практического применения в индустриальных проектах разработанных методов и программных средств с аналогичными существующими подходами; соответствие данных практических экспериментов теоретическим оценкам.

Апробация работы. Основные положения и результаты диссертационной работы были представлены на научных конференциях "Технологии Microsoft в теории и практике программирования" (СПб, 2012, 2011, 2010), 6th Spring/Summer Young Researchers' Colloquium on Software Engineering (Perm, 2012), XXXIX неделя науки СПбГПУ (СПб, 2010).

Публикации. По теме диссертационной работы было опубликовано 10 печатных работ, 5 из них в изданиях из перечня ВАК.

Внедрение. Разработанные методы и инструменты поддержки внедрены в компаниях ЗАО «Моторола Солюшнз», ООО «Научно-Технический Центр «Северо-Западная Лаборатория» и использованы при разработке учебно-методического комплекса по курсам "Технология разработки программного обеспечения" и "Технология параллельных вычислений" на кафедре "Информационные и управляющие системы" Института информационных технологий и управления Санкт-Петербургского государственного политехнического университета. Практическое использование представляемых на защиту результатов подтверждено соответствующими актами о внедрении.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы и семи приложений. Общий объём диссертации с приложениями - 185 страниц машинописного текста, содержит 43 рисунка, 22 таблицы, список литературы содержит 106 наименований.

Глава 1. Современные подходы к автоматизации создания и выполнения тестового набора

В главе проводится обзор актуальных методов и технологий тестирования. На основании результатов обзора выделяются особенности современных подходов к тестированию, а также ключевые признаки технологий, по которым производится сравнение. По его итогам делаются выводы о проблемах существующих подходов, и обосновывается целесообразность дальнейшего развития инструментов для поддержки процесса тестирования, ориентированных на обеспечение качества программного продукта. В главе сформулированы цели и задачи исследования.

1.1 Критерии тестирования

При организации тестирования основной целью является обнаружение

максимально возможного числа ошибок в условиях ограничений, накладываемых имеющимися ресурсами. Считается, что при отсутствии ограничений на время выполнения или стоимость тестирования его можно организовать таким образом, что будут найдены практически все дефекты реализации первоначальных требований [58]. Однако в реальности подобная ситуация неосуществима [27].

Одним из инструментов управления качеством программного продукта являются критерии тестирования. Они позволяют определить понятия полноты тестирования и способа оценки степени покрытия программного продукта тестами. Под степенью покрытия понимается отношение текущего объема проверяемой тестами информации о программном продукте к оценке полного объема подобной информации [28]. Полнота тестирования отражает то, в какой степени процесс тестирования реализует все возможные варианты проверки качества продукта. Критерии тестирования позволяют сравнить выполненный объём работ по тестированию с объемом, требуемым для достижения некоторого уровня качества. Тестирование - ресурсоёмкий и сложный процесс. Выбор критерия тестирования помогает найти приемлемое отношение полноты тестирования к расходам на его организацию.

В качестве основных групп критериев выделяют критерии "чёрного ящика" и "белого ящика" [28]. Первая группа подразумевает тестирование с точки зрения поставленной задачи без проверки особенностей реализации, тогда как тестирование по принципу белого ящика подразумевает тот факт, что о тестируемой системе известна вся информация.

Существует ряд требований, которым должен удовлетворять идеальный критерий тестирования [49]. Основными из них являются следующие свойста:

1) Критерий должен быть достаточным, то есть показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы;

2) Критерий должен быть полным, то есть в случае ошибки должен существовать тест, удовлетворяющий критерию, который позволяет диагностировать ошибку;

3) Критерий должен быть надежным, то есть любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы;

4) Критерий должен быть легко проверяемым. Это означает, что должна существовать процедура проверки любого теста на соответствие конкретному критерию.

В общем случае не существует полного и надежного критерия тестирования, применимость которого не зависит от конкретных задач, поэтому на практике применяют частные критерии. В Приложении 1 приведено описание различных критериев тестирования и их преимущества и недостатки.

1.2 Актуальные подходы к тестированию

Классификация действий по обеспечению качества программного продукта

начинается с определения того, что является базой проверки. Это может быть поведение исполняемой программы или её непосредственная реализация. Проверку качества программного продукта, основанную на анализе его работы на этапе выполнения, называют динамической. Анализ реализации программного продукта до его запуска на выполнение называют статическим. В случае

статического анализа обычно проверяют код системы или её модель без исполнения [41]. В качестве примера можно привести статический анализ кода или code review. Статический анализ проводится как вручную (code review), так и автоматически с использованием соответствующих программных инструментов (статический анализ кода) [62]. Данный подход широко применяется, однако его рассмотрение находится за пределами тематики данной работы. Динамический анализ проводится путём взаимодействия с работающей тестируемой сущностью и оценки параметров её реакции на воздействия. Именно он составляет суть тестирования.

Рис. 1. Схема функционального тестирования

Тестирование можно разделить на два вида: функциональное и нефункциональное. Функциональное тестирование проверяет соответствие реализованной функциональности тестируемой системы (System Under Test, SUT) исходным требованиям, заданным при постановке задачи. Обобщённо данный способ проверки представлен на Рисунке 1 и состоит из нескольких шагов. Сначала на работающую систему оказывается тестовое воздействие. Затем фиксируется отклик системы и изменения в её состоянии. Полученная информация сравнивается с эталонной, и по результатам сравнения выносится вердикт об успешности теста. В большинстве случаев все три шага могут быть автоматизированы [76].

Нефункциональное тестирование решает задачу оценки параметров работы системы, не относящихся напрямую к логике её работы [79]. Несоответствие системы требуемым значениям параметров зачастую влечёт за собой непригодность программного продукта к использованию даже при условии полного выполнения функциональных требований. В ходе нефункционального тестирования может производиться оценка производительности, безопасности, отказоустойчивости, удобства использования (usability) и других параметров. В отличие от функционального тестирования, в данном случае автоматизация может быть произведена далеко не всегда. Например, тестирование usability проводится исключительно вручную ввиду субъективности критериев оценки. Однако многие подходы к автоматизации, использующиеся в функциональном тестировании, могут быть применены для решения задач нефункционального (например, для тестирования производительности). В Приложении 2 описаны виды тестирования в зависимости от объекта тестирования с подробным описанием модульного тестирования как одного из наиболее популярных в настоящее время. П. 1.2.1 и 1.2.2 посвящены наиболее современным концепциям, применяемым при разработке архитектуры систем тестирования. Это тестирование, управляемое данными, и тестирование на основе ключевых слов.

1.2.1 Тестирование, управляемое данными

В простейшем случае параметры тестирования заданы явным образом в

тестовом сценарии. Это приводит к необходимости изменения исходного кода теста в случае, когда требуется изменить исходные данные. Для автора тестов это может быть тривиальной задачей, но при этом требовать существенных временных затрат в случае, если тест меняет инженер, ранее с ним не работавший. Если же код теста имеет большой объем, либо же плохо структурирован, задача усложняется ещё больше [102].

Другая проблема при определении данных внутри теста состоит в том, что при необходимости добавить в набор новый тест, логика которого повторяет существующий сценарий, а данные незначительно отличаются, требуется навыки программирования и написания тестов. Это требование действует даже в

простейшем случае, когда дублирование сценария может быть выполнено копированием его кода. В худшем случае подобное изменение может потребовать обновления всего тестового набора, либо существенной его части [93].

Очевидно, что при построении больших тестовых наборов данный подход неэффективен в силу возрастания издержек, связанных с модификацией тестов. В качестве альтернативы применяется отделение данных, используемых в тестировании, от логики тестов. При этом тестовый набор получает необходимую информацию из внешних источников и выполняется на её основании. Такой способ получил название тестирования, управляемого данными (ТУД, data-driven testing, DDT). Общая схема организации тестирования с его помощью приведена на Рисунке 2. Данные для тестирования могут быть легко изменены инженерами, не имеющими навыков программирования. Наиболее распространенный формат организации данных — табличный, что позволяет использовать большое число существующих редакторов таблиц. Использование табличного представления делает структуру тестового набора понятной широкому кругу пользователей, а не только техническим специалистам [92]. Также появляется возможность организовать управление тестированием на основании единой базы данных, что позволяет избежать дублирования информации и облегчить поддержку её актуальности и когерентности. Также централизованное хранение тестовых данных и обеспечение авторизованного доступа к ним извне позволяет проводить тестирование в облачной среде.

Таблицы могут быть сохранены в форматах, где данные разделены запятыми (CSV) или табуляцией (TSV), а также в формате, распознаваемым редакторами таблиц [93]. Данный подход обладает определёнными недостатками. Так, например, несмотря на то, что CSV и TSV удобны с точки зрения низкой алгоритмической сложности реализации кода, многие стандартные редакторы изменяют файлы этих форматов при работе. Реализация поддержки данной особенности работы редакторов таблиц требует существенных временных затрат.

Рис. 2. Концепция data-driven testing

Другим удобным способом является сохранение данных тестового набора в HTML. Организованные таким образом таблицы могут быть отредактированы как в визуальных редакторах, генерирующих код HTML, так и в любом текстовом редакторе. Использование данных в этом формате достаточно легко реализуемо ввиду наличия большого количества готовых инструментов для работы с документами в формате HTML.

Расположение тестовых данных в одном файле приводит к плохой масштабируемости и высокой стоимости поддержания целостности информации в случае проектов большого размера, когда данные для тестирования используются и редактируются на нескольких рабочих станциях. Эффективным с точки зрения затрат решением по внесению изменений в данном случае является расположение всей информации в базе данных с реализацией пользовательского интерфейса в виде веб-приложения. При этом тестовые сценарии могут получать данные из базы либо на этапе выполнения, либо генерации тестового набора. Создание такой распределённой инфраструктуры является сложным и объемным проектом и рекомендуется только в случае, когда проблема масштабирования является критичной для реализации тестирования.

Также для хранения тестовых данных может быть использован метаязык, например, XML или JSON [55]. В этом случае требуется разработка пользовательского интерфейса для работы с данными, что приводит к

дополнительным затратам. Преимуществами такого подхода являются гибкость и платформонезависимость.

Независимость реализации отдельных элементов системы тестирования при использовании данного подхода позволяет интегрировать существующие решения с целью получения необходимого результата. При этом низкая сложность создания модуля чтения данных делает возможным создание собственного формата тестовых сценариев.

Основным преимуществом ТУД является простота и дешевизна создания и запуска большого количества тестов, различающихся только данными [102]. При этом создание новых тестов и редактирование уже существующих не требует специальных навыков [85]. Наборы тестовых данных могут быть подготовлены ещё до того, как будут созданы сами тестовые сценарии. Использование данного подхода при проектировании системы автоматизации тестирования делает её более дружественной к пользователю, а процесс изменения тестовых сценариев -более дешёвым.

1.2.2 Тестирование на основе ключевых слов

В качестве способа борьбы с ограничениями подхода к тестированию,

Список литературы диссертационного исследования кандидат наук Тютин, Борис Викторович, 2013 год

Литература

[1] Антонов A.C. "Параллельное программирование с использованием технологии ОрепМР: Учебное пособие". М.: Изд-во МГУ, 2009. 77 с.

[2] Средства поддержки интегрированной технологии для анализа и верификации спецификаций телекоммуникационных приложений / И.С. Ануреев, С.Н. Баранов, Д.М. Белоглазов, Е.В. Бодин, П.Д. Дробинцев,

A.B. Колчин, В.П. Котляров, A.A. Летичевский, A.A. Летичевский мл.,

B.А. Непомнящий, И.В. Никифоров, С.В. Потиенко, Л.В. Прийма, Б.В. Тютин // Труды СПИИРАН. 2013. №3 (26). С. 349-383.

[3] Верификационная технология базовых протоколов для разработки и проектирования программного обеспечения / С.Н. Баранов, П.Д. Дробинцев, A.A. Летичевский, В.П. Котляров // Программные продукты и системы. 2005. № 1(69). С. 25-28.

[4] Баранов С.Н., Котляров В.П., Летичевский A.A. Индустриальная технология автоматизации тестирования мобильных устройств на основе верификационных поведенческих моделей проектных спецификаций требований // Космос, астрономия и программирование. Лавровские чтения. 2008. С. 134-145.

[5] Баранов С.Н., Котляров В.П. Формальная модель требований, используемая в процессе генерации кода приложения и кода тестов // Моделирование и анализ информационных систем. 2011. Т. 18. №4.

C.118-130.

[6] Боэм Б. Инженерное проектирование программного обеспечения: Пер. с англ. М.: Мир, 1985. 514 с.

[7] Веселов А.О., Котляров В.П. Автоматизация тестирования проектов в области телекоммуникаций // Научно-технические ведомости СПбГПУ. 2010. №4. С. 180-185.

[8] Автоматизация тестирования телекоммуникационных приложений / А.О. Веселов, A.C. Иванов, Б.В. Тютин, В.П. Котляров // Научно-технические ведомости СПбГПУ. 2009. № 3. С. 208-212.

[9] Богачёв К.Ю. Основы параллельного программирования. М.: БИНОМ. Лаборатория знаний, 2009. 344 с.

[10] Воеводин В.В. Модели и методы в параллельных процессах. М.: Наука, 1986. 296 с.

[11] Воинов Н.В. Методы генерации тестовых сценариев на основе структурированных UCM-моделей проектируемой системы. Диссерт. на соискание уч. ст. канд. техн. наук. СПб.: СПбГПУ, 2011. 169 с.

[12] Воинов Н.В., Котляров В.П. Применение метода эвристик для создания оптимального набора тестовых сценариев // Научно-технические ведомости СПбГПУ. 2010. № 4 (103). С. 169-174.

[13] Гергель В. П. Высокопроизводительные вычисления для многопроцессорных и многоядерных систем. М.: Издательство Московского Университета, 2010. 544 с.

[14] Дробинцев П.Д. Интегрированная технология обеспечения качества программных продуктов с помощью верификации и тестирования. Диссерт. на соискание уч. ст. канд. техн. наук. СПб.: СПбГПУ, 2006. 238 с.

[15] Дробинцев П.Д., Котляров В.П., Черноруцкий И.Г. Автоматизация тестирования на основе покрытия пользовательских сценариев // Научно-технические ведомости СПбГПУ. 2012. № 4 (152). С. 123-126.

[16] Дробинцев П.Д., Никифоров И.В., Котляров В.П. Методика проектирования тестов сложных программных комплексов на основе структурированных UCM моделей // Научно-технические ведомости СПбГПУ. 2013. № 3(174). С. 99-105

[17] Подход к конкретизации тестовых сценариев в рамках технологии автоматизации тестирования промышленных программных проектов / П.Д. Дробинцев, A.B. Колчин, В.П. Котляров, A.A. Летичевский, B.C. Песчаненко // Моделирование и анализ информационных систем. 2012. Т. 19. №6 (2012). С. 79-91.

[18] Применение технологии UniTesK для функционального тестирования моделей аппаратного обеспечения / В. П. Иванников, А. С. Камкин, В. В. Кулямин, А. К. Петренко // Препринт Института Системного Программирования РАН. 2005. № 8. URL: http://www.unitesk.ru/download/papers/unitesk/Preprint_200512.pdf (дата обращения: 27.05.2013).

[19] Калбертсон Р., Браун К., Кобб Г. Быстрое тестирование. М.: Вильяме, 2002. 384 с.

[20] Карпов Ю.Г. Model Checking. Верификация параллельных и распределенных программных систем. СПб.: БХВ-Петербург, 2010. 560 с.

[21] Карпов Ю.Г., Теория автоматов. СПб.: Питер, 2003. 208 с.

[22] Кознов Д. В., Арчак Н. А. Апробация технологии тестирования UniTESK // Системное программирование. 2005. URL: http://www.unitesk.ru/download/papers/unitesk/whitebook-16.pdf (дата обращения: 14.05.2013).

[23] Колчин А. В. Метод направления поиска и генерации тестовых сценариев при верификации формальных моделей асинхронных систем // Проблемы программирования. 2008. № 4. С. 5-12.

[24] Колчин A.B. Разработка инструментальных средств для проверки формальных моделей асинхронных систем. Диссерт. на соискание уч. ст. канд. физ.-мат. наук. Киев, 2009. 140 с.

[25] Колчин A.B., Котляров В.П., Дробинцев П.Д. Метод генерации тестовых сценариев в среде инсерционного моделирования // Управляющие системы и машины. 2012. № 6. С. 43-48.

[26] Колчин A.B. Метод направления поиска и генерации тестовых сценариев при верификации формальных моделей асинхронных систем // Проблеми програмування. 2008. № 4. С. 3-12.

[27] Котляров В.П. Критерии покрытия требований в тестовых сценариях, сгенерированных из поведенческих моделей приложений // Научно-технические ведомости СПбГПУ. 2011. Т.6.1 (138). С.202-207.

[28] Котляров В.П. Основы современного тестирования программного обеспечения, разработанного на С#: Учебное пособие. СПб.: СПбГПУ, 2004. 170 с.

[29] Котляров В.П., Пинаев Д.В. Методы и средства автоматизации тестирования программного проекта. Санкт-Петербург, 1998.

[30] Криспин Л., Грегори Д. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. М.: Вильяме, 2010. 464 с.

[31] Летичевский A.A. Верификация и тестирование интерактивных систем, специфицированных базовыми протоколами. Диссерт. на соискание уч. ст.канд. физ.-мат. наук. Киев, 2005. 138 с.

[32] Летичевский А.Ад., Инсерционное моделирование // Управляющие системы и машины, Киев, Академпериодика. 2012. №6. С. 3-14.

[33] Свойства предикатного трансформера системы VRS / A.A. Летичевский, А.Б. Годлевский, A.A. Летичевский (мл.), C.B. Потиенко, B.C. Песчаненко // Кибернетика и системный анализ. 2010. № 4. С. 3-16.

[34] Спецификация систем с помощью базовых протоколов / A.A. Летичевский, Ю.В. Капитонова, В.А. Волков, A.A. Летичевский (мл.), С.Н. Баранов, В.П. Котляров // Кибернетика и системный анализ. 2005. №4. С. 256-268.

[35] Немнюгин С. А., Стесик О. Л. Параллельное программирование для многопроцессорных вычислительных систем. СПб.: БХВ-Петербург, 2002. 400 с.

[36] Никифоров И.В., Дробинцев П.Д., Котляров В.П., Интегральные критерии проверки требований к программному обеспечению // Научно-технические ведомости СПбГПУ. 2013. № 3(174). С. 111-118.

[37] Никифоров И.В., Петров A.B., Котляров В.П., Статический метод отладки тестовых сценариев, сгенерированных с помощью эвристик // Научно-технические ведомости СПбГПУ. 2012. № 4(152) С. 114-119.

[38] Никифоров И.В., Петров A.B., Юсупов Ю.В. Генерация формальной модели системы по требованиям, заданным в нотации Use Case Map // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2010. № 4(176). С. 191-195.

[39] Никифоров И.В., Котляров В.П., Дробинцев П.Д. Ограничения на многопоточные конструкции и временные задержки языка UCM // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2013. № 3(174). С. 148-153.

[40] Применение различных методик формализации для построения верификационных моделей систем по UCM-спецификациям / И.В. Никифоров, A.B. Петров, Ю.В. Юсупов, В.П. Котляров // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2011. № 3(126). С. 180-184.

[41] Петренко А.К., Бритвина Е.Н., Грошев С.Г., Монахов А.А., Петренко O.JI. Тестирование на основе моделей // URL: http://www.osp.ru/os/2003/09/183388 (дата обращения: 5.06.2013).

[42] Технология тестирования UniTESK // URL: http://www.unitesk.rU/content/section/5/27 (дата обращения: 10.05.2013).

[43] Тютин Б.В., Веселов А.О., Котляров В.П. Масштабирование выполнения тестового набора при автоматизированном тестировании // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2013. № 3(174). С. 118-122.

[44] Тютин Б. В., Никифоров И. В., Котляров В. П. Построение системы автоматизации статической и динамической проверки требований к программному продукту // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2012. № 4(152). С. 119123.

[45] Юсупов Ю.В. Интегрированная методика автоматизированного построения формальных поведенческих моделей С-приложений по исходному коду Диссерт. на соискание уч. ст. канд. техн. наук. СПб.: СПбГПУ, 2009. 176 с.

[46] Abrial J.-R. The B-Book: Assigning Programs to Meanings. Cambridge: Cambridge University Press, 1996. 813 p.

[47] Alur R., Etessami K., Yannakakis M. Realizability and verification of MSC Graphs // Proceedings of the 28th International Colloquium on Automata, Languages, and Programming (ICALP'01). 2001. P. 797-808.

[48] Alur R., Etessami K., Yannakakis M. Inference of Message Sequence Charts // Proceedings of the 22nd International Conference on Software Engineering (ICSE'00). 2000. P. 304-313.

[49] Bach J. Agile test automation // URL: http://www.satisfice.com/articles/agileauto-paper.pdf (date of access: 21.10.2012).

[50] Baranov S. N., Kotlyarov V.P., Weigert T. Verifiable Coverage Criteria For Automated Testing. SDL2011: Integrating System and Software Modeling // LNCS. 2012. Vol. 7083. P.79-89.

[51] Implementation of an Integrated Verification and Testing Technology in Telecommunication Project / S. Baranov, V. Kotlyarov, A. Letichevsky, P. Drobintsev, Yu. Yusupov // IEEE. Russia Northwest Section. International conference "Radio - that connects time. 110 anniversary of radio invention". Proceedings. Vol. II. 2005. P. 87-92.

[52] Tools For Requirements Capturing Based on the Technology of Basic Protocols / S. Baranov, J. Kapitonova, A. Letichevsky, A. Kolchin, A. Letichevsky (Jr)., V. Radchenko, S. Potiyenko, V. Volkov, // Proceedings of St. Petersburg. IEEE Chapters. 2005. P. 92-97.

[53] The technology of Automation Verification and Testing in Industrial Projects. / S. Baranov, V. Kotlyarov, A. Letichevsky, P. Drobintsev // Proc. of St.Petersburg IEEE Chapter, International Conference. 2005. P. 81-86.

[54] Beck K. Test-Driven Development: By Example. MA: Addison-Wesley Professional, 2002. 240 p.

[55] Bird C., Sermon A. An XML-based approach to automated software testing // ACM SIGSOFT Software Engineering Notes. 2001. № 26(2). P. 64-65.

[56] Bollig B. Realizability of Dynamic MSC Languages // Lecture Notes in Computer Science. Vol. 6072. 2010. P. 48-59.

[57] Buhr R.J.A., Casselman R.S. Use Case Maps for Object-Oriented Systems. London: Prentice Hall, 1996. 302 p.

[58] Boehm B. Software Engineering Economics, N.J.: Prentice-Hall, 1981. 767 p.

[59] Boehm B. Software risk management: principles and practices // Software, IEEE.1991. 8(1). P. 32-41.

[60] Booch Gr., Maksimchuk R., Engel M., Young B., Conallen J., Houston K. Object-Oriented Analysis and Design with Applications. MA: Addison-Wesley Professional, 2007. 720 p.

[61] Butenhof D. Programming with POSIX Threads. MA: Addison-Wesley Professional, 1997.400 p.

[62] Burnstein I. Practical Software Testing: A Process-Oriented Approach. Berlin: Springer, 2003. 709 p.

[63] Cohen F. Java testing and design, from unit testing to automated web tests. London: Prentice Hall, 2004. 544 p.

[64] Craig R., Jaskiel S. Systematic Software Testing. Boston: Artech House Publishers, 2002. 536 p.

[65] Davis A. Just Enough Requirements Management: Where Software Development Meets Marketing. MA: Addison-Wesley Professional, 2013, 256 P-

[66] Digital Video Broadcasting (DVB). DVB-S2 Adaptive Coding and Modulation for Broadband Hybrid Satellite Dialup Applications // URL: http://www.etsi.org/deliver/etsi_ts/102400_102499/102441/01.01.01_60/ts_10 2441v010101p.pdf (date of access: 14.11.2012).

[67] Drobintchev P., Kotlyarov V., Nikiforov I. Technology Aspects of State Explosion Problem Resolving for Industrial Software Design // Proceedings of the 7th Spring/Summer Young Researchers' Colloquium on Software Engineering. 2013. P. 46-51.

[68] A Formal Approach for Generation of Test Scenarios Based on Guides / Drobintsev P.D, Nikiforov I.V., Kotlyarov V.P., Letichevsky A.A. // Proceedings of Fourth Workshop "Program Semantics, Specification and Verification : Theory and Applications". 2013. P. 31-42.

[69] Dustin E., Rashka J., Paul J.. Automated Software Testing. MA: Addison-Wesley, 1999. 608 p.

[70] Gastin P., Mukund M., Kumar N. Reachability and Boundedness in Time-Constrained MSC Graphs // Perspectives in Concurrency Theory. 2009. P. 157183.

[71] Goel A., Roychoudhury A. Synthesis and Traceability of Scenario-based Executable models // Proceeding of the Second International Symposioum on Leveraging Applications of Formal Methods. 2006. P. 347-354.

Hoare C.A.R. Communicating sequential processes. London: Prentice Hall, 1985. 260 p.

Holzmann G. Design and Validation of Computer Protocols. New Jersey: Prentice Hall, 1991. 543 p.

Hu W., Sun X. Test Case Generation Based on MSC TTCN-3 // Proceedings of the International Conference on Information Engineering and Applications (IEA). London: Springer-Verlag, 2013. 888 p.

Hunt A., Thomas D. Pragmatic Unit Testing in C# with NUnit. 2nd Edition. Raleigh: The Pragmatic Programmers, LLC, 2007. 239 p. Fewster M., Graham D. Software Test Automation. MA: Addison-Wesley, 1999. 600 p.

HP Quicktest Professional // URL: http://www8.hp.com/ru/ru/software-solutions/software.html?compURI=l 172957 (date of access: 18.10.2012). IBM Rational Functional Tester // URL: http://www-01.ibm.com/software/awdtools/tester/functional (date of access: 17.10.2012). IEEE Std 610.12-1990 // URL:

http://standards.ieee.org/findstds/standard/610.12-1990.html (date of access: 10.10.2012).

ITU Recommendation Z.120. Message Sequence Charts (MSC), 11/99 // URL: https://www.itu.int/ITU-T/2005-2008/coml7/languages/Zl20.pdf (date of access: 15.10.2012).

ITU-T Recommendation Z.151 : User requirements notation (URN) -

Language definition. Geneva, Switzerland, September 2003 // URL:

http://www.itu.int/rec/T-REC-Z.151-200811-I/en (date of access: 18.10.2012).

R. Johnson and B. Foote. Designing reusable classes // Journal of Object-

Oriented Programming. 1988. № 1(2). P. 22-35.

JUnit framework // URL: http://junit.org (date of access: 5.10.2012).

Kaner C., Bach J., Pettichord B. Lessons Learned in Software Testing: A

Context-Driven Approach. NY: John Wiley & Sons, Inc., 2001. 320 p.

Kaner C. Pitfalls and strategies in automated testing // IEEE Computer. 1997.

№30(4). P. 114-116.

Basic protocols, message sequence charts, and the verification of requirements specifications / A. Letichevsky , J. Kapitonova, A. Letichevsky Jr., V. Volkov, S. Baranov, T. Weigert // Computer Networks: The International Journal of Computer and Telecommunications Networking. 2005. Vol.49. № 5. P. 661675.

Insertion Programming / A.A. Letichevsky, J.V. Kapitonova, V.A. Volkov, V.V. Vyshemirskii, A.A. Letichevsky Jr. // Cybernetics and Systems Analysis. 2003. Vol. 39. № 1. P. 16-26.

Insertion modeling in distributed system design / A.A. Letichevsky, J.V. Kapitonova, V.P. Kotlyarov, A.A. Letichevsky Jr., N.S.Nikitchenko, V.A. Volkov, and T.Weigert. // npo6jieMH nporpaiviyBaHHfl. 2008. № 4. P. 13-38. Manna Z., Pnueli A. The Temporal Logic of Reactive and Concurrent Systems. Berlin: Springer, 1992. 427 p.

[90] Milner R. Communication and Concurrency. London: Prentice Hall, 1989. 300 P-

[91] MPI 3.0 // URL: http://www.mpi-forum.Org/docs/mpi-3.0/mpi30-report.pdf (date of access: 5.10.2012).

[92] Mugridge R., Cunningham W. Fit for Developing Software. London: Prentice Hall, 2005. 384 p.

[93] Nagle C. Test automation frameworks, 2000 // URL: http://safsdev.sourceforge.net/DataDrivenTestAutomationFrameworks.htm (date of access: 6.3.2013).

[94] OpenMP 3.1 // URL: http://www.openmp.org/mp-documents/OpenMP3.Lpdf (date of access: 24.11.2012).

[95] OpenMP: Wikipedia // URL: http://ru.wikipedia.org/wiki/OpenMP (date of access: 5.10.2012).

[96] Osherove R. The Art of Unit Testing: With Examples in .Net. Greenwich:Manning Publications, 2009. 320 p.

[97] Pettichord B. Design for testability // Proceedings of The 20th Annual Pacific Northwest Software Quality Conference. 2002. P. 243-270.

[98] Reniers M. Message Sequence Chart: Syntax and Semantics. Eindhoven: Eindhoven University of Technology, 1999. 216 p.

[99] Pohjolainen P. Software testing tools / URL: http://www.cs.uef.fi/tutkimus/Teho/SoftwareTestingTools.pdf (date of access: 14.04.2013).

[100]Robot framework // URL: http://robotframework.org (date of access:

19.10.2012).

[101]Selic, B. et al. Real-time Object-Oriented Modelling. NY: John Wiley and Sons, 1994. 560 p.

[102] Strang R. Data driven testing for client/server applications // Proceedings of the Fifth International Conference of Software Testing, Analysis & Review. 1996. P. 389-400.

[103]Telelogic Tau System // URL: http://en.wikipedia.org/wiki/Telelogic (date of access: 18.10.2012).

[104]Telelogic TAU G2. // URL: http://www.telelogic.com/products/tau/tau/index.cfm (date of access: 18.10.2012).

[105]Telelogic TTCN Suite. // URL: http://www.telelogic.com/products/ttcn/index.cfm (date of access: 18.10.2012).

[106] UniTesK technology // URL: http://www.unitesk.ru (date of access:

25.05.2013).

Приложение 1. Критерии тестирования

Критерии «чёрного ящика»

С точки зрения концепции черного ящика тестируемая система является

объектом, преобразующим входную информацию в выходную. При этом известны правила и характеристики преобразований, но неизвестны детали их реализации. Оценка корректности в данном случае может основываться только на сопоставлении наблюдаемых параметров работы системы (возвращаемый результат, работоспособность, время отклика и так далее) с их ожидаемыми значениями. Часто используемыми в данной области являются следующие критерии [28]:

1) Критерий тестирования функций: набор тестов должен содержать хотя бы один тест для каждой из функций, реализуемых программой;

2) Критерий тестирования классов входных данных: все возможные входные данные, которыми оперирует тестируемая система, делятся на классы, и тестовый набор составляется таким образом, чтобы проверялась работа с каждым классом. Считается, что выполнение программы при использовании заданного набора данных является эквивалентным выполнению на любом конкретном наборе данных из класса, к которому принадлежит исходный набор;

3) Критерий тестирования классов выходных данных: аналогично предыдущему пункту проверяются классы выходных данных.

При этом могут использоваться дополнительные критерии, определяющие, какие именно данные необходимо проверить [28]. Например:

1) Критерий области допустимых значений: тестовый набор должен проверять корректность работы тестируемой системы при всех значениях перечислимых типов данных, а также реакцию на недопустимые значения;

2) Критерий проверки диапазона значений: тестовый набор должен проверять корректность работы приложения с данными, принадлежащими заданному диапазону, в различных условиях:

• Нормальные условия (в середине класса),

• Граничные (экстремальные) условия (значения на краях диапазона),

• Исключительные условия (недопустимые значения).

3) Критерий объёма набора данных: определяет, при каком количестве элементов в наборе входных данных необходимо проверить работоспособность программы. В практике тестирования используются следующие варианты [28]:

• Пустой набор (не содержит ни одного элемента);

• Единичный набор (состоит из одного элемента);

• Слишком короткий набор (если предусмотрена минимально допустимая длина);

• Набор минимально возможной длины (если таковая предусмотрена);

• Корректный набор (состоит из нескольких элементов);

• Набор максимально возможной длины (если таковая предусмотрена);

• Слишком длинный набор (с длиной больше максимально допустимой).

4) Критерий упорядоченности данных: определяет состояния набора данных, подлежащих проверке, в случае, когда это имеет значение. Наиболее часто используемыми являются следующие варианты:

• Данные неупорядочены;

• Данные упорядочены согласно требуемой процедуре сортировки;

• Данные упорядочены в порядке, обратном требуемой процедуре сортировки;

• В наборе имеются повторяющиеся элементы;

• Минимальное/максимальное значение находится в середине набора;

• Минимальное/максимальное значение находится в начале набора;

• Минимальное/максимальное значение находится в конце набора;

• В наборе несколько совпадающих минимальных или максимальных значений.

Критерии, применяемые при использовании подхода чёрного ящика, обычно требуют большего числа тестов, а также более сложны с точки зрения организации тестирования. Однако их применение даёт возможность создания тестовых наборов, пригодных для повторного использования за счёт отсутствия связей с конкретной реализацией проверяемых требований.

Критерии «белого ящика»

Критерии, относящиеся к данной категории, подразумевают использование

информации о внутреннем устройстве тестируемой системы. Наиболее распространёнными являются критерий проверки операторов или команд, критерий тестирования ветвей управляющего графа программы и критерий тестирования путей, существующих в этом графе [28].

Условие критерия тестирования команд (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.

Условие критерия тестирования ветвей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку количество ветвей в графе управления тестируемого приложения ограничено. Данный критерий часто используется в системах автоматизации тестирования.

Условие критерия тестирования путей (критерий Рм) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее одного раза. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой [28].

Последний критерий является наиболее полным с точки зрения проверки программы, однако он обладает существенным недостатком — его сложно реализовать на практике. Тестирование, основанное на применении этого критерия, позволяет обнаруживать большее число ошибок, но при этом число

путей в программе может быть практически неограниченным. Необходим компромисс: критерий, обеспечивающий более полную проверку, чем покрытие ветвей, но при этом реализуемый с затратами меньшими, чем в случае критерия покрытия путей.

Для решения данной задачи были предложены простой и комбинаторный критерии покрытия условий [28]. Простой критерий покрытия условий, также называемый критерием покрытия решений, требует подобрать такой набор тестов, чтобы каждая ветвь в программе была пройдена хотя бы один раз, и чтобы каждое простое условие (слагаемое в дизъюнкции или сомножитель в конъюнкции) хотя бы один раз было интерпретировано как истинное и ложное. Критерий надежнее, чем простое покрытие ветвей, но сохраняет его принципиальный недостаток: плохую проверку циклов. Критерий комбинаторного покрытия условий требует подобрать такой набор тестов, чтобы хотя бы один раз выполнялась любая комбинация простых условий [2]. Критерий значительно более надежен, чем покрытие решений/условий, но обладает двумя существенными недостатками. Во-первых, он может потребовать очень большого числа тестов. (2П для проверки комбинаций п простых условий). Во-вторых, даже комбинаторное покрытие условий не гарантирует надежную проверку циклов.

При решении задачи автоматизации тестирования использование критериев тестирования позволяет ограничить время создания тестового набора, оценить его характеристики и определить критерий полноты тестирования. Наиболее эффективным из существующих подходов к созданию тестового набора для автоматизированных систем тестирования является автоматическая генерация тестовых сценариев на основании анализа управляющего графа программы. При этом участие инженера-тестировщика сводится к настройке параметров критериев генерации, а также заданию правил анализа.

Приложение 2. Виды объектов тестирования

В зависимости от типа объекта тестирования выделяют модульное, интеграционное, системное и приёмочное тестирование [69]. Модульное тестирование ориентировано на проверку минимальной независимой части программного продукта - модуля [64]. Зачастую модульное тестирование реализуется разработчиками кода, обладающими знаниями об устройстве и логике работы объекта тестирования. Модуль имеет интерфейс взаимодействия с другими компонентами, который может быть непосредственно задействован при тестировании. Интерфейс снижает сложность организации тестирования. Кроме того обнаружение ошибок на уровне модулей снижает стоимость их исправления. Набор тестов для модуля может одновременно служить документацией и примером его использования. В практике промышленной разработки тесты создаются до того, как появляется реализация модуля, что требует заранее точно определять и по возможности не менять интерфейсы взаимодействия [54]. При решении задач автоматизации в данной области наиболее распространёны каркасы, или же frameworks из семейства xUnit (более детально его возможности рассматриваются в Приложении 3).

Тестирование компонент относится к интеграционному тестированию [64]. Оно проводится для группы модулей, взаимодействующих друг с другом для решения конкретной задачи. При этом компонента обладает единым для её составляющих интерфейсом взаимодействия с окружением. При автоматизации тестирования применяются как готовые компоненты, так и специально разработанные.

Системное тестирование [30] отличается от тестирования компонент по двум параметрам. Система, в отличие от меньших структурных единиц, функционирует и существует самостоятельно. Также у системы может быть несколько различных интерфейсов для взаимодействия с пользователями, другими системами и окружением. При этом для автоматизации определенную сложность представляет тестирование графического интерфейса [97].

В зависимости принципов, заложенных в основу способа определения тестового набора, запуска тестов и обработки результатов, выделяют различные подходы к организации тестирования, такие как тестирование, управляемое данными, тестирование на основе ключевых слов и ряд других [85].

Модульное тестирование в данное время наиболее распространено по причине наличия гибких методов разработки тестов, обеспечивающих быстрый результат и уменьшение затрат на управление качеством программного продукта. Например, в контексте данной работы принципы модульного тестирования нашли своё применение при проектировании архитектуры системы автоматизации тестирования, что позволило ввести более строгие ограничения на средства описания тестовых сценариев и способ исполнения тестов, сделав их тем самым удобнее и прозрачнее для пользователя.

Понятие Unit тестирования в области разработки программного продукта, появилось в начале семидесятых годов [96]. Unit тестирование зарекомендовалл себя как один из наиболее эффективных способов улучшения качества кода и достижения более детального понимания требований к функционированию тестируемого класса или метода. Один из основоположников Unit тестирования Кент Бек определил данный подход для языка Smalltalk [54], и вслед за этим Unit тестирование получило распространение и в других языках программирования. Совместно с Вардом Каннингемом и Эриком Гамма Кент Бек создал framework для модульного тестирования JUnit [96], что было отмечено как одно из самых значимых событий в сфере автоматизации тестирования. Принципы unit тестирования, сформулированные его создателями, нашли своё применение в технологии разработки программного обеспечения, основанного на тестировании, а также тестировании, основанном на ключевых словах и данных [30].

Модульным тестом называется код (обычно оформленный в виде метода), который вызывает методы другого модуля или класса и проверяет заранее определённые условия, включающие результаты вызова. Если проверка не проходит, тест считается "проваленным". Модулем в рамках данного подхода называется метод или функция, которую вызывает тест. При этом объектом

модульного тестирования является тестируемая система или тестируемый код (code under test, CUT).

Подобное определение даёт общее представление о подходе, однако не позволяет оценить его преимуществ. Основной акцент в unit-тестировании делается не столько на покрытии кода требованиями, что также является важным показателем, сколько на самих тестах. Именно создание хороших тестов позволяет сделать их аналогом документации по тестируемому коду, облегчить рефакторинг и регрессионное тестирование, улучшить коммуникацию между разработчиками.

Любой тест может быть оценён по следующим критериям [19]:

• автоматизация и многократность использования;

• лёгкость создания и запуска;

• возможность повторного использования;

• отчуждаемость кода и способа запуска;

• быстрота выполнения.

Unit-тесты обычно удовлетворяют всем перечисленным критериям. Для написания unit-тестов чаще всего используются каркасы [54], позволяющие снизить сложность работ и сделать тестовый набор автоматизированным, надежным, понятным и лёгким в поддержке. При этом средства, встроенные в каркас, могут брать на себя дополнительные функции, связанные с логикой тестов, например, по созданию заглушек или изоляции операций ввода-вывода в тестируемом коде. При этом не так важно, как создаются Unit тесты, как то, на каком этапе разработки они создаются. Большое распространение получил подход, при котором сначала пишутся тесты, а затем — код, который они тестируют [54]. После того, как часть тестов проходит, расширяют реализованную функциональность либо производят рефакторинг кода. Наиболее лаконично данная идея была сформулирована Кентом Беком [96]: «Мы хотим, чтобы наш код работал, и хотим, чтобы он был чистым». При этом тесты становятся формальным определением архитектуры системы. Данный подход

получил название разработки, основанной на тестировании (test-driven development, TDD).

Традиционно модульные тесты это реализованные в коде алгоритмы работы с тестируемой системой и проверки результатов взаимодействия. Такой подход усложняет модификацию тестов, и приводит к появлению параметризованных unit-тестов. Параметры тестов при этом могут быть предоставлены пользователем (например, в виде таблиц) [100] и сгенерированы каркасом для разработки систем тестирования [75].

Поскольку unit-тест предполагает изолированную проверку элемента кода, то в случае, когда проверяемый метод связан с другими компонентами системы, применяются специальные подходы, позволяющие убрать данные зависимости. Во-первых, при разработке кода большое внимание уделяют тестируемости системы. Например, везде, где требуется доступ к внешним ресурсам, объявляется интерфейс, через который затем осуществляется доступ. Во-вторых, на этапе тестирования создаются заглушки, использующиеся для имитации отдельных классов или методов системы в тестах. Выделяют два основных типа заглушек — fake и mock. Оба типа имитируют реальное поведение, обеспечивая передачу корректных данных при обращении к своим методам, а также диагностику возникающих ошибок. Основным отличием является то, что fake-объекты в реализуемых методах не содержат специальной логики, связанной с тестированием либо имитацией сложного поведения, тогда как тоск-объекты содержат правила и средства проверки правильности работы тестируемого кода. Примером fake-объекта может служить генератор случайных чисел, всегда возвращающий единицу. Примером mock — аналогичный генератор, проверяющий границы диапазона, которые указывает использующий его код.

В данный момент модульное тестирование является популярным подходом. Возможность автоматизировать данный вид тестирования является востребованной функциональностью при выборе средств поддержки разработки программного продукта.

Приложение 3. Технологии параллельного программирования

Для снижения сложности создания параллельных программ был разработан ряд стандартов и технологий, позволяющих программистам абстрагироваться от архитектуры вычислительных систем и сосредоточить свои усилия непосредственно на разработке алгоритмов. Наиболее известными в данной области являются технологии MPI [91] и ОрепМР [93].

MPI

В вычислительных системах с распределенной памятью процессоры работают независимо друг от друга. Для организации параллельных вычислений в таких условиях необходимо иметь возможность распределять вычислительную нагрузку и организовать информационное взаимодействие (передачу данных) между процессорами. Решение всех перечисленных вопросов и обеспечивает интерфейс передачи данных (message passing interface - MPI).

В рамках MPI для решения поставленной задачи принят следующий подход - разрабатывается одна программа и эта единственная программа запускается одновременно на выполнение на всех имеющихся процессорах. При этом для того чтобы избежать идентичности вычислений на разных процессорах, можно, во-первых, подставлять разные данные для программы на разных процессорах, а во-вторых, использовать имеющиеся в MPI средства для идентификации процессора, на котором выполняется программа. Подобный способ организации параллельных вычислений получил наименование модели "одна программа множество процессов" (single program multiple processes или SPMP) [13]. В случае использования данного подхода для параллельного выполнения тестов он может быть эффективно применён совместно с KDT. Интерпретация тестовых сценариев при таком подходе осуществляется библиотеками-драйверами. Таким образом, работает один и тот же код, в качестве входных данных получающий тестовые команды и данные. Это позволяет организовать параллельную обработку независимых тестовых сценариев.

Для организации информационного взаимодействия между процессорами в самом минимальном варианте достаточно операций приема и передачи данных. Стандарт MPI определяет достаточно большое количество операций передачи данных. Они обеспечивают разные способы и режимы пересылки информации. Именно данные возможности являются наиболее сильной стороной MPI.

На ранних этапах развития технологий создания параллельного программного обеспечения одна из самых серьезных проблем в программировании - переносимость программ - проявлялась в максимальной степени. Как результат, уже с 90-х годов стали предприниматься шаги по стандартизации средств организации передачи сообщений в многопроцессорных вычислительных системах. Началом работ, непосредственно приведших к появлению MPI, послужило проведение рабочего совещания по стандартам для передачи сообщений в среде распределенной памяти (the Workshop on Standards for Message Passing in a Distributed Memory Environment, Williamsburg, Virginia, USA, April 1992). По итогам совещания была образована рабочая группа, позднее преобразованная в международное сообщество MPI Forum. В 2012 году была принята третья версия MPI. Он определяет стандарт, которому должны удовлетворять средства организации передачи сообщений, а также программные библиотеки, реализующие этот стандарт. Как правило, аббревиатура MPI применяется при упоминании стандарта, а сочетание "библиотека MPI" указывает на его программную реализацию.

Под параллельной программой в рамках MPI понимается множество одновременно выполняемых процессов. Процессы могут выполняться на разных процессорах, причем на одном процессоре могут располагаться несколько процессов, работающих в режиме разделения времени. При этом может быть использован только один процессор - как правило, такой способ применяется для начальной проверки правильности параллельной программы.

Каждый процесс параллельной программы порождается на основе копии одного и того же программного кода. Данный программный код, представленный в виде исполняемой программы, должен быть доступен в момент запуска

параллельной программы на всех используемых процессорах. Исходный программный код для исполняемой программы разрабатывается на алгоритмических языках С или Fortran с применением той или иной реализации библиотеки MPI.

Количество процессов и число используемых процессоров определяется в момент запуска параллельной программы средствами среды исполнения MPI и в ходе вычислений не может меняться без применения специальных, но редко используемых средств динамического порождения процессов и управления ими, появившихся в стандарте MPI версии 2.0. Все процессы программы последовательно перенумерованы от 0 до р-1, где р есть общее количество процессов. Номер процесса именуется рангом процесса.

Основу MPI составляют операции передачи сообщений. Среди предусмотренных в составе MPI функций различаются парные операции между двумя процессами и коллективные коммуникационные действия для одновременного взаимодействия нескольких процессов. Для выполнения парных операций могут использоваться разные режимы передачи, среди которых синхронный, блокирующий и другие [13]. В случае проведения тестирования с организацией сложного окружения данные возможности позволяют снизить затраты на имплементацию логики взаимодействия участвующих в тестировании сущностей.

Процессы параллельной программы объединяются в группы, которые описываются с помощью коммуникатора. Под коммуникатором в MPI понимается специально создаваемый служебный объект, который объединяет в своем составе группу процессов и ряд дополнительных параметров, используемых при выполнении операций передачи данных. Парные операции передачи данных выполняются только для процессов, принадлежащих одному и тому же коммуникатору. Коллективные операции применяются одновременно для всех процессов одного коммуникатора. В случае тестирования распределённых систем это позволит эффективно реализовать групповые действия, в которых принимают участие сразу несколько сущностей, присутствующий при выполнении сценария.

При выполнении операций передачи сообщений для указания передаваемых или получаемых данных в функциях MPI необходимо указывать тип пересылаемых данных. MPI содержит большой набор базовых типов данных, во многом совпадающих с типами данных С и Fortran. Кроме того, в MPI имеются возможности создания новых производных типов данных для более точного и краткого описания содержимого пересылаемых сообщений.

Другим важным преимуществом стандарта MPI, кроме большой библиотеки стандартных методов передачи данных, является возможность формирования виртуальных топологий любого требуемого типа. Это позволяет легко адаптировать параллельные программы для любой архитектуры вычислительных средств. В случае необходимости организации взаимодействий в рамках различных групп компонент, которые могут пересекаться, подобный подход существенно снижает сложность реализации алгоритмов распределённых взаимодействий за счёт более предоставления простого способа передачи данных.

ОрепМР

ОрепМР - прикладной программный интерфейс (application programming interface, API) для создания параллельных приложений для многопроцессорных вычислительных систем, использующих общую память. При реализации ОрепМР основной упор делался на создание системы программирования, которая позволила облегчить параллельное программирование задач для систем с общей памятью.

Разработку спецификации ОрепМР ведут несколько крупных производителей вычислительной техники и программного обеспечения, чья работа регулируется некоммерческой организацией ОрепМР Architecture Review Board (ARB) [82]. В 2011 году вышла последняя полная версия стандарта ОрепМР 3.1 [93].

Стандарт ОрепМР предназначен, для выполнения параллельной программы на системах с архитектурой Symmetric Multiprocessing (SMP) за счет поддержки данного стандарта производителями суперкомпьютеров и создания реализаций стандарта для каждой вычислительной платформы. Развитие многоядерных и

многопоточных процессоров позволяет использовать ОрепМР для создания программ для однопроцессорных компьютеров [94]. Это делает код универсальным, позволяя запускать его практически на любой платформе.

ОрепМР реализует параллельные вычисления с помощью многопоточности, в которой «главный» поток (master) создает набор подчиненных потоков (slave), между которыми распределяется задача. Предполагается, что потоки выполняются параллельно на машине с несколькими процессорами. Задачи, выполняемые потоками параллельно, также как и данные, требуемые для выполнения этих задач, описываются с помощью специальных директив препроцессора соответствующего языка — прагм или директив. Количество создаваемых потоков может регулироваться как самой программой при помощи вызова библиотечных процедур, так и извне, при помощи переменных окружения [93].

Ключевыми элементами ОрепМР являются:

• Конструкции для создания потоков (директива parallel);

• Конструкции распределения работы между потоками (директивы DO/for и section);

• Конструкции для управления работой с данными (выражения shared и private для определения класса памяти переменных);

• Конструкции для синхронизации потоков (директивы critical, atomic и barrier);

• Процедуры библиотеки поддержки времени выполнения (например, omp_get_thread_num);

• Переменные окружения (например, OMP_NUM_THREADS).

ОрепМР поддерживается многими современными компиляторами. Компиляторы Sun Studio поддерживают официальную спецификацию — ОрепМР 2.5 — с улучшенной производительностью под ОС Solaris и планируемой поддержкой Linux. Visual С++ 2005 и 2008 поддерживает ОрепМР 2.0 в редакциях Professional и Team System, 2010 - в редакциях Professional, Premium и Ultimate, 2012 - во всех редакциях. GCC 4.2 поддерживает ОрепМР, а некоторые

дистрибутивы (такие как Fedora Core 5 gcc) включили поддержку в свои версии GCC 4.1. Intel С++ Compiler поддерживает версию ОрепМР 3.0, Intel - Cluster OpenMP для программирования в системах с распределённой памятью [95].

ОрепМР является расширением таких языков программирования, как С, С++ или Fortran. Использование директив ОрепМР в коде последовательной программы позволит увеличить производительность при её выполнении на многопроцессорных вычислительных системах с общей памятью. Архитектура расширения такова, что код, написанный с использованием технологии ОрепМР, может быть скомпилирован и собран в среде, не поддерживающей данную технологию [1]. При использовании данной технологии для организации параллельного запуска тестов подобный подход позволяет сделать код тестового набора универсальным по отношению к среде запуска.

Основным отличием от MPI является отсутствие возможности прямой привязки подзадач параллельного алгоритма к процессорам. Это не позволяет создавать программы, оптимизированные под конкретную топологию вычислительной системы. Вторым отличием является то, что приложение, выполняемое в среде ОрепМР, по факту является многопоточным только тогда, когда выполняется код, явно отмеченный, как параллельный. Также для реализации многопроцессорной обработки программы используются нити, а не потоки, для реализации концепции разделяемой потоками памяти на уровне кода. При этом программист никак не защищён от возникновения data race в случае отсутствия явной синхронизации обращения к памяти. С одной стороны, это может снизить накладные расходы на реализацию параллельной обработки данных или команд тестовых сценариев. С другой стороны, это затрудняет запуск параллельных вычислений на вычислительных узлах, расположённых удалённо.

Приложение 4. Обзор инструментальных средств автоматизации тестирования

Fit

Fit [92] расшифровывается как Framework for integrated test. Как следует из названия инструмента, Fit является каркасом для создания автоматизированных тестовых наборов. Его концепция была разработана в 2002 году Вардом Каннингемом и изначально базировалась на технологии JUnit. При этом в качестве языка разработки поддерживался только Java. В дальнейшем Fit был портирован на С#, Python, Perl, PHP и Smalltalk, что обусловлено, в первую очередь, тем, что он является программным обеспечением с открытым исходным кодом.

Создатели Fit поставили перед собой цель сделать процесс тестирования доступным для понимания любому заинтересованному лицу, принимающему участие в разработке программного продукта. Предполагается, что подход к разработке тестов с использованием Fit объединяет участников процесса создания программного продукта с различными ролями - аналитиков, тестировщиков, разработчиков и конечных пользователей. При этом разработка тестовых наборов становится коллективным процессом, ориентированным на демонстрацию реальной пользы, которую приносит тестирование.

Fit расширяет технологию JUnit. Его код собирается в одну библиотеку, которая затем подключается к разрабатываемому приложению. Изначально интерфейсом для большинства служебных программ Fit являлась командная строка. Для повышения удобства использования каркаса были созданы различные интерфейсы пользователя, в том числе модуль расширения для системы разработки Eclipse — Fit Runner, разработанный Chih-wei Но в 2004 году, а также среды разработки тестов, такие как основанная на wiki FitNesse, созданная в 2003. Позднее, в 2005 году, FitNesse начала свою ветку разработки Fit.

Создание тестового набора в Fit разделено на две основные части. Первая это таблицы, управляющие последовательностью выполнения тестов, данными, используемыми в тестовых наборах, а также обеспечивающие отображение

результатов выполнения тестов. Вторая часть - так называемые классы-фиксаторы на целевом языке, реализующие логику работы тестов, а также связывающие таблицы и тестируемый код [93].

Поскольку тесты отражают не только функциональные требования к готовому коду, но и пожелания пользователей, представление структуры тестов в виде таблиц позволяет программистам в ходе разработки придерживаться изначальной архитектуры и оценивать степень готовности программного продукта. Тестировщики получают в своё распоряжение инструмент, автоматизирующий тестирование и облегчающий анализ его результатов. Для участников, имеющих административные роли, Fit предоставляет средства анализа зависимостей между требованиями заказчика и ограничениями со стороны реализации.

На Рисунке 36 изображена принципиальная схема тестового набора, созданного с использованием Fit. На верхнем уровне находятся таблицы, содержащие данные тестов. За ними следуют классы-фиксаторы, ответственные за проверку того, что тестируемая система, располагающаяся на нижнем уровне иерархии взаимодействия компонент тестового набора, соответствует тестам в соответствующей таблице. Таким образом, структура похожа на общую для подхода DDT.

Рис. 36. Структура тестового набора Fit

Таблицы, определяющие тестовые наборы, могут быть созданы в любом редакторе на языке HTML. Классы-фиксаторы при этом могут быть созданы на

любом языке, для которого существует реализация данного framework. Всего существует три типа таблиц и соответствующих им фиксаторов: Column, Row и Action [93].

Таблицы типа Column позволяют запускать последовательность тестов, логика которых определяется классом-фиксатором, производным от ColumnFixture, на наборе данных, который задаётся строками таблицы. Причем одна строка соответствует одному тесту. При этом класс-фиксатор должен определять используемы в таблице переменные, а также вызываемые в ней методы, возвращающие значения, которые подлежат проверке. Пример теста с использованием таблицы типа Column приведён на Рисунке 37.

mypackage.ColumnClass

attributel attribute2 Methodl () Method2()

1 а true 10

3 b false 5

Рис. 37. Пример таблицы типа Column

Код класса-фиксатора для данной таблицы будет иметь следующий вид:

package mypackage; import fit.ColumnFixture;

public class ColumnClass extends ColumnFixture {

public int attributel; public String attibute2;

public boolean methodl () {

return true;

}

public int method2() { return attributel;

}

public void execute() { }

} _

Таблицы типа Action позволяют задавать последовательность действий, выполняемых над экземпляром соответствующего класса-фиксатора,

производного от ActionFixture, реализующего логику тестирования. При этом возможно четыре варианта действий:

• start — создание объекта;

• enter — вызывает метод объекта и передает ему данные, указанные в таблице;

• press - вызывает метод объекта без проверки возвращаемого значения;

• check — вызывает метод объекта и проверяет возвращаемое значение на соответствие указанному в таблице.

Пример теста с использованием таблицы Action приведён на Рисунке 38.

fit.ActionFixture

start mypackage. ActionClass

press method 1

enter method2 1

check method3 true

Рис. 38. Пример таблицы типа Action

Класс-фиксатор для данной таблицы будет иметь следующий вид: package mypackage;; import fit. Action Fixture;

public class ActionClass extends ActionFixture {

public void method"! () { }

public void method2 (int num) { }

public boolean method3() { return true;

}

} _______

Таблица типа Row позволяет создавать тесты, проверяющие результаты, представленные списком значений. Пример теста с использованием таблицы типа Row приведён на Рисунке 39. При этом класс-фиксатор для таблицы должен быть производным от RowFixture и реализовывать два метода:

• query — возвращает данные, представленные списком;

• getTragetClass — возвращает тип элемента в списке результирующих данных.

При этом в колонках таблицы указываются значения открытых членов класса, являющегося элементом списка, а в строках — значения, которые должны там присутствовать. Также возможно создание тестов, использующих таблицы различных типов.

RowClass

attributel attribute2

0 true

1 false

Рис. 39. Пример таблицы типа Row

Класс-фиксатор для данной таблицы будет иметь следующий вид: package mypackage; import fit.RowFixture;

public class RowClass extends fit.RowFixture {

public ObjectO query () throws Exception { // return array of elements of some class having public attributel and attribute2

}

public Class getTargetClass () { // return class of the list element

}

]_

В зависимости от типа таблицы Fit выбирает способ запуска теста и затем отображает результаты его выполнения. Зелёный цвет фона строки с тестом означает, что он прошёл успешно, красный сигнализирует о провале. При этом данные, полученные в ходе тестирования, отображаются рядом с ожидаемыми значениями. В случае возникновения исключения в ходе теста он будет отмечен жёлтым цветом, а также будет выведены сообщение об ошибке и стек вызовов. Несмотря на родство с JUnit, тесты, написанные с его помощью, следует размещать в проекте отдельно от тестов, созданных в Fit. Это вызвано тем, что JUnit будет пытаться запустить все тесты, которые он обнаружит, что, в случае с тестами для Fit, приведёт к ошибке.

Таким образом, Fit может быть использован для автоматизации модульного, пользовательского и функционального тестирования. Наличие средств наглядной демонстрации результатов делает его использование полезным для целей

управления и взаимодействия различных заинтересованных сторон в проекте по созданию программного продукта [93].

Robot Framework

Robot Framework [100] это универсальный каркас для построения автоматизированных тестовых наборов при приемочном тестировании и использовании подхода к разработке программного продукта, основанного на приёмочном тестировании (acceptance test-driven development, ATDD). В нём реализованы концепции тестирования, управляемого данными, и тестирования на основе ключевых слов.

Robot написан на языке Python и выпускается под лицензией Apache License 2.0. Проект доступен через сервис Google Code, где также можно найти всю необходимую документацию. Благодаря открытости исходного кода для Robot было разработано большое число дополнений и отдельных инструментов, использующих данный framework [102].

Тестовые сценарии для Robot создаются в простом текстовом формате либо в HTML с помощью любого редактора. Сообществом пользователей были разработаны инструменты, облегчающие создание и запуск тестовых наборов:

• Rebot. Создание логов и отчетов на основании XML, генерируемого тестами, а также слияния логов из нескольких источников;

• Libdoc. Автоматическое создание описания ключевых слов для библиотек тестирования;

• Testdoc. Создание описания тестового набора в HTML;

• Tidy. Преобразование формата и очистка данных для тестовых наборов. Также существует собственная среда разработки тестов - RIDE (Robot IDE).

Она предоставляет средства для удобного редактирования тестов, такие как подсветка синтаксиса и автодополнение, а также для запуска и обработки результатов. Были созданы и активно используются модули интеграции с Eclipse, Emacs, Vim, Sublime Text 2, TextMate. Для сборки и запуска тестовых наборов разработаны расширения для Jenkins, Maven и Ant [102].

Основными понятиями, которые используются в отношении тестовых наборов, создаваемых с помощью Robot, являются ключевое слово (keyword) и библиотека тестирования. Ключевое слово определяет некоторое действие, которое может быть произведено в ходе выполнения теста. Библиотека тестирования реализует логику операций, связанных с теми или иными ключевыми словами, тем самым предоставляя новые возможности разработчика тестов. Любой пользователь Robot может создавать собственные библиотеки тестирования для нужд конкретных проектов, а также определять новые ключевые слова путем комбинации уже существующих с использованием синтаксиса, аналогичного синтаксису написании тестов.

Библиотеки тестирования для Robot могут быть запущены на различных рабочих станциях и созданы с использованием любого языка программирования, поддерживающего XML-RPC. Чаще всего в качестве платформы для программирования библиотек тестирования выбирают Python, Java и .Net, но их создание также возможно и на PHP, JavaScript или Perl. Ядро каркаса включает в себя следующие библиотеки:

• Builtin. Определяет набор наиболее востребованных встроенных ключевых слов, доступных без подключения сторонних библиотек;

• Telnet. Позволяет устанавливать соединение с серверами Telnet и выполнять различные команды;

• Dialogs. Добавляет возможность останова тестов и пользовательского ввода;

• OperatingSystem. Реализует системные вызовы в рамках окружения, в котором выполняются тесты;

• String. Библиотека для работы со строками;

• XML. Библиотека для генерации, изменения и проверки XML файлов;

• Screenshot. Предоставляет ключевые слова для получения снимков экрана;

• Collections. Предоставляет ключевые слова для работы со списками и словарями в Python;

• Remote. Специальный модуль, функционирующий как посредник между Robot и библиотеками тестирования.

Дополнительные библиотеки Robot позволяют осуществлять тестирование мобильных приложений для Android и iOS, тестирование через HTTP, использовать сторонние средства тестирования (Selenium), тестировать приложения на Java, использующие Swing.

Пример тестового сценария, реализующего приложение "Hello, Workd!", представлен на Рисунке 40.

Log

Hello, World!

Рис. 40. Пример тестового сценария в формате Robot

Здесь Log - ключевое слово из стандартной библиотеки, помещающее переданный ему аргумент в лог, создаваемый Robot в процессе выполнения тестов.

При использовании библиотек интеграции со сторонними средствами тестирования возможно написание тестов, специфичных для конкретных предметных областей. Например, при использовании Selenium для тестирования веб-приложений. Пример, осуществляющий поиск в интернете, представлен на Рисунке 41.

Open browser http://www.google.com ie

Input text id=lst-ib Robot Framework

Click button Google Search

Рис. 41. Пример тестового сценария в формате Robot

Запуск тестового набора осуществляется через командную строку. Система интерпретирует данные и ключевые слова в тестовых наборах, и посредством библиотек тестирования взаимодействует с тестируемой системой согласно сценарию теста. Взаимодействие осуществляется напрямую либо через сторонние инструменты, используемые в качестве агентов. На основании результатов выполнения тестов формируется отчет в XML и HTML форматах.

JUnit

JUnit [83] является библиотекой для модульного тестирования программного обеспечения на языке Java. Созданный Кентом Беком и Эриком

Гаммой, JUnit принадлежит семье каркасов xUnit для разных языков программирования, берущей начало в SUnit Кента Бека для Smalltalk. JUnit породил систему расширений — Jmock, EasyMock, DbUnit, HttpUnit и многие другие. JUnit был реализован на других языках, включая PHP (PHPUnit), С# (Nunit), Python (PyUnit), Fortran (fUnit), Delphi (DUnit), Free Pascal (FPCUnit), Perl (Test::Unit), С++ (CPPUnit), Flex (FlexUnit), JavaScript (JSUnit), COS (COSUnit). В настоящее время в основном используется JUnit3 и JUnit4 [63]. В данной работе на примере JUnit рассматривается подход, применённый при проектировании всего семейства инструментов.

Данный framework предназначен в первую очередь для организации модульного тестирования кода, написанного на языке Java. При этом код тестов пишется также на языке Java. Единицей тестового набора является класс, наследованный от входящих в каркас типов, определяющих различные виды тестов, и переопределяющий методы, используемые при запуске.

В JUnit 3 базовым классом для теста является TestCase. Существует возможность определить действия, которые выполняются до запуска теста и после его завершения путём переопределения методов setup и tearDown. Тестирующие методы должны быть объявлены как public void, а их имена -начинаться с префикса "test". Для выполнения проверок используется класс Assert, содержащий методы, реализующие различные проверки: равенство объектов и массивов, истинность утверждений и другие. Для разделения логики тестирования от данных инициализацию переменных тестового класса можно разместить в методе setUp. Каркас позволяет группировать тесты с помощью реализации класса-наследника TestSuite. Для того, чтобы запустить тест несколько раз, можно использовать класс Repeated test. Для реализации тестовых сценариев, работающих с исключениями, используется наследование от класса ExceptionTestCase.

В JUnit 4 были добавлены возможности Java 5, а также исключён из каркаса класс RepeatedTest. Для определения роли метода используются аннотации:

• BeforeClass, AfterClass - методы выполняются перед инициализацией экземпляра тестового класса и перед его уничтожением;

• Before, After - методы выполняются перед запуском теста и после его прохождения;

• Test - тестовый метод. Имеет два параметра - expected для задания ожидаемого исключения и timeout для определения максимального времени выполнения теста, после истечения которого он считается проваленным;

• Ignore - метод, не запускаемый в ходе выполнения тестового набора.

• Rule - правила дополнительной функциональности при запуске тестов;

• Run With - определяет способ запуска класса-теста. Запуск может быть осуществлён с помощью класса, наследованного от класса Runner. Методы, для которых используются данные аннотации, должны быть

объявлены как public void.

Для обеспечения дополнительной функциональности при запуске тестов в четвертой версии каркаса были добавлены так называемые правила. Правилом является объявление нестатического public поля, производного от класса MethodRule и имеющего аннотацию Rule. Правила позволяют задать различные параметры теста, такие как таймаут, ожидаемые исключения или возможность параллельного запуска. Возможно создание пользовательских классов, реализующих правила. Данные правила могут использоваться как в самом тестовом методе, так и в качестве управляющего класса для всего теста.

Между третьей и четвёртой версиями JUnit сохраняется обратная совместимость.

При выполнении тестов создаётся по экземпляру объекта, наследующего TestCase, для каждого определённого внутри него тестирующего метода. Как упоминалось ранее, запуск тестов осуществляется классом, производным от класса Runner. С самим framework поставляются следующие реализации:

• JUnit4 — запуск JUnit 4 тестов, используется по умолчанию;

• SuiteMethod, AllTests, JUnit38ClassRunner - запуск тестов, написанных с использованием JUnit 3;

• Suite — запуск JUnit 4 тестов, позволяет настраивать тесты через аннотацию @SuiteClasses;

• Enclosed — аналогично предыдущему варианту, но вместо настройки с помощью аннотации используются все внутренние классы;

• Categories — организация тестов в группы. Категория теста задаётся с помощью аннотации @ Category, тестовые категории затем могут быть настроены;

• Parameterized - позволяет создавать параметризованные тесты через список параметров для конструктора;

• Theories - позволяет внедрять параметры в тестовые методы. При этом параметры обозначаются в тестовом классе аннотациями DataPoint и DataPoints, а параметризуемые методы - аннотацией Theories.

JUnit интегрирован во многие среды исполнения. Например, для NetBeans существует интерфейс, облегчающий создание тестов и их запуск. Также предоставлены средства отображения результатов запуска теста.

TAT

Изначально TAT создавался как система автоматизации модульного и интеграционного тестирования, тесто связанная с рядом инструментов разработки программного продукта. Однако в процессе создания архитектура TAT была структурирована так, что ключевые модули и компоненты системы составили ядро, отвечающее за обработку тестовых сценариев, тогда как реализация интеграции со сторонними CASE-средствами была выведена на отдельный уровень [44]. В дальнейшем при разработке TAT следование данному подходу позволило создать гибкий каркас для построения систем автоматизированного тестирования, полностью интегрируемых в процесс разработки программного продукта.

Тестовые наборы при использовании TAT это диаграммы Message Sequence Charts [80], представленные в текстовом формате mpr. Данная нотация позволяет описывать взаимодействие нескольких сущностей в рамках тестового сценария с использованием условных управляющих конструкций. Формат MSC

стандартизован, и для него существуют как графические, так и текстовые редакторы.

В состав системы автоматизации тестирования TAT входят следующие модули [44]:

1) Анализатор зависимостей,

2) Модуль проверки MSC,

3) Макро препроцессор,

4) Генератор трасс,

5) Генератор абстрактных тестов,

6) Компоновщик MSC,

7) Конвертор MSC,

8) Генератор программы-адаптера,

9) Автоматический анализатор результатов. Каждый из модулей TAT позволяет:

• задать входной список файлов;

• указать выходной каталог;

• вывести подробную информацию о работе;

• перенаправить поток ошибок в заданный файл;

• создать список генерируемых файлов.

При запуске тестового набора TAT строит конечный автомат, реализующий логику тестирования, и транслирует его в код на целевом языке. При этом обработка событий, указанных на диаграмме, осуществляется в коде модуля wrapper, который создаётся пользователем.

По результатам исполнения тестового набора генерируются журналы событий в текстовом формате, а также в виде диаграмм MSC. На основании журналов событий создаётся отчёт о тестировании, содержащий результаты выполнения тестов и диагностическую информацию.

UniTesK

Технология тестирования UniTesK [106] была разработана в Институте системного программирования РАН. Первоначальное и основное назначение

технологии — разработка качественных функциональных тестов для программного обеспечения [18]. Технология ишТевК и реализующие ее инструменты были успешно применены для тестирования различных классов программных систем: ядер операционных систем, телекоммуникационных протоколов, систем реального времени и т.д. [22].

Архитектура ишТевК была разработана на основе опыта тестирования промышленного программного обеспечения из разных предметных областей. Архитектура системы основана на реализации следующих ключевых аспектов тестирования:

• Построение последовательности тестовых воздействий, нацеленной на достижение нужного покрытия;

• Создание единичного тестового воздействия в рамках последовательности;

• Установление связи между тестовой системой и реализацией целевой системы;

• Проверка правильности поведения целевой системы в ответ на единичное тестовое воздействие.

Для решения каждой из этих подзадач предусмотрены специальные компоненты тестовой системы: для построения последовательности тестовых воздействий и создания единичных воздействий — обходчик и итератор тестовых воздействий, для проверки правильности поведения целевой системы — оракул, для установления связи между тестовой системой и реализацией целевой системы — медиатор. Обходчик является библиотечным компонентом тестовой системы итТевК и предназначен вместе с итератором тестовых воздействий для построения последовательности тестовых воздействий. В основе обходчика лежит алгоритм обхода графа состояний конечного автомата, моделирующего целевую систему на некотором уровне абстракции. Итератор тестовых воздействий работает под управлением обходчика и предназначен для перебора в каждом достижимом состоянии конечного автомата допустимых тестовых воздействий. Итератор тестовых воздействий автоматически генерируется из тестового сценария, представляющего собой описание конечно-

автоматной модели целевой системы. Оракул оценивает правильность поведения целевой системы в ответ на единичное тестовое воздействие. Он автоматически генерируется на основе формальных спецификаций, описывающих требования к целевой системе в виде пред- и постусловий интерфейсных операций и инвариантов типов данных. Медиатор связывает абстрактные формальные спецификации, описывающие требования к целевой системе, с конкретной реализацией целевой системы [22].

Трасса теста отражает события, происходящие в процессе тестирования. На основе трассы можно автоматически генерировать различные отчеты, помогающие в анализе результатов тестирования.

В рамках данной технологии реализована возможность тестирования кода приложений, написанных на языках С и Java, для проверки интерфейсов систем различной сложности [42].

HP Quick Test Professional

Данный инструмент является частью информационной системы для обеспечения контроля качества программного продукта HP Quality Center. Изначально инструмент был разработан Mercury Interactive, приобретённой HP в 2006 году. Последняя версия HP Quick Test Professional (QTP) [77] выпущена в 2010 году.

Данная система реализует концепцию среды разработки при создании тестов. В качестве языка тестовых процедур используется VBScript. С его помощью осуществляются доступ к объекту тестирования (элементы интерфейса, программа, объекты операционной системы) и реализация воздействий (например, имитируются события мыши или клавиатуры).

Инструмент позволяет с помощью парадигмы контрольных точек (checkpoint) осуществлять контроль хода тестирования. При этом в желаемой точке тестовой процедуры возможны, по аналогии с отладкой программы, установка точки прерывания (breakpoint) и просмотр и изменение различных аспектов состояния тестируемой системы. Возможен доступ к свойствам

объектов, данных в таблицах и записях в базе данных, изображениям и тексту, отображаемым на форме приложения. В зависимости от просматриваемой информации, контрольные точки могут иметь один из следующих типов: стандартный, изображение, таблица, страница, текст, текстовое поле, база данных. Также возможно определение пользовательских контрольных точек.

Возможно восстановление процесса тестирования после сбоя, однако ввиду особенностей архитектуры не во всех случаях (это связано с тем, что QTP интегрируется в области памяти, принадлежащие тестируемой системе).

QTP реализует DDT путём экспорта необходимых локальных и глобальных данных в рабочую книгу MS Excel. Эта информация может быть затем использована для управления состоянием переменных и вынесения вердикта по тесту.

В базовой поставке инструмент поддерживает тестирование приложений, созданных с применением web-технологий, а также .NET, Java и Delphi. Существует возможность создания дополнений, расширяющих набор поддерживаемых окружений.

В первую очередь QTP ориентирован на функциональное и регрессионное тестирование. Основная его область применения - автоматизация тестирования графического интерфейса пользователя, а также работы с файлами и базой данных.

Программа обладает как стандартным оконным, так и web-интерфейсом. Создание тестов может производиться как в режиме построения сценариев на основе таблицы действий (keyword view), так и в режиме непосредственного редактирования кода (expert view). Результаты выполнения тестов формируются в формате XML с возможностью экспорта в HTML, PDF и MSWord.

Ограничениями при работе с данным инструментом являются, во-первых, возможность запуска только в Windows, во-вторых, отсутствие возможности тестирования приложений, запущенных в большинстве современных браузеров (Opera, Chrome, Safari).

IBM Rational Functional Tester

Инструмент был разработан в IBM Rational Software в 2002 году под именем RobotJ. В следующем году вышла вторая версия, называвшаяся XDE Tester. Последний релиз под номером 8.2 выпущен в 2010 году.

Основным принципом, которым руководствовались при создании IBM Rational Functional Tester (RFT) [78], является то, что пользователю не придётся писать код тестов при их создании. Основным сценарием создания тестов является автоматическая запись действий пользователя, производимых над тестируемой системой, с последующей генерацией кода тестового набора на целевом языке в виде .Net-приложения. Начиная с версии продукта 8.1 появилось иллюстрирование теста с помощью набора последовательно сделанных снимков экрана или рабочей области программы. Запись действий пользователя осуществляется с помощью инструментов с графическим интерфейсом (Recorder, Verification Point и Action Wizard). При необходимости возможно как редактирование кода тестов на языках Java и Visual Basic, так и редактирование логики тестирования путём перемещения имеющихся снимков экрана.

Тестовый сценарий при использовании RFT может проверять как статические, так и динамические данные. Сценарий может управляться данными, то есть можно будет повторить выполнение одних шагов для нескольких наборов тестовых данных. При автоматической записи тестов записываются действия мыши и клавиатуры. При этом возможен выбор активных элементов, содержимое которых может быть использовано в качестве изменяемых параметров тестирования. Подстановка значений параметров осуществляется из специальных источников (spreadsheet).

Functional Tester для идентификации объектов во время воспроизведения использует четыре фрагмента данных: свойства class, classlndex, accessibleName и name. При выполнении тестов RFT просматривает все свойства, поэтому изменение одного из них не приводит к провалу. Functional Tester определяет, что имя изменено и регистрирует изменение в журнале, затем продолжает работу.

Такая технология позволяет Functional Tester уменьшить временные затраты на адаптацию тестов к небольшим изменениям в программе.

В инструменте реализован пул данных, который хранит все данные, которые использовались при тестировании. Данный подход является элементом DDT.

Functional Tester поддерживает два языка сценариев: Java и Visual Basic.NET. Для тестирования Java-приложений в программу Functional Tester включена открытая среда разработки Eclipse. Установка дополнительных компонентов не требуется. Если требуется использовать язык сценариев Visual Basic.NET, перед установкой IBM Rational Functional Tester необходимо установить Visual Studio.NET.

При проведении тестирования пользователь записывает свои действия с помощью RFT и создаёт код тестов. Далее определяется набор контрольных точек (verification point), в которых происходит контроль состояния системы: значения полей, свойства объектов. Для оценки правильности значений могут быть использованы шаблоны или записанные в ходе создания теста значения. Сгенерированные тесты запускаются последовательно в виде тестового набора.

При выполнении сценария компоновка графических элементов интерфейса приложения не влияет на способность Functional Tester выполнять сценарий. RFT создает журналы с описанием процесса выполнения тестирования. По умолчанию, эти журналы создаются в HTML-формате. Для предоставления дополнительных сведений программа Functional Tester также запускает приложение comparator, выделяющее все различия между ожидаемыми и фактическими результатами. В журнал записываются основные события, например, запуск и закрытие сценария и приложения, а также все точки проверки. Также записываются события в случае, если в сценарии имеются ошибки, или если объекты в приложении отличаются от их записей в карте объектов. Журнал содержит секцию с гиперссылками на наиболее значимые события или разделы.

Инструмент является средой разработки тестов и в первую очередь ориентирован на функциональное и регрессионное тестирование. Основной

областью его применения являются тестирование пользовательского интерфейса, Java, .Net и Web-приложений, а также консольных программ. Стоимость лицензии на использование данного продукта составляет от трёх до двенадцати тысяч долларов.

RFT работает в Windows и Linux. Для Linux отсутствует возможность автоматической записи тестов, поддерживается тестирование только приложений на Java.

Приложение 5. Формализация требований

Для обеспечения однозначной интерпретации требований при создании тестового набора необходимо из неявного или неформального вида преобразовать их в нотацию, обеспечивающую смысловую инвариантность при работе со спецификацией системы [50]. При этом требуется, чтобы она была удобна для восприятия и редактирования человеком. Тестирование в области телекоммуникационных технологий требует возможность описывать параллельные взаимодействия. Этим требованиям отвечают нотации расширенных Use Case Map (UCM) [38] и Base Protocol (BP) [24]. Они позволяют описать тестируемую систему: её управляющий граф и данные. Обе нотации имеют возможность графического представления, они обеспечены инструментами редактирования и стандартами, поэтому они использованы для описания поведенческих моделей систем, которые при достаточной детализации используется для автоматической генерации тестового набора.

Нотация UCM стандартизована в ITU-T в 2003 году [57]. UCM представляет собой набор связанных и структурированных диаграмм, каждая из которых состоит из последовательности UCM элементов. В совокупности набор диаграмм задает возможные поведения системы, описанные в требованиях [81].

Стандартная UCM нотация позволяет в удобном графическом виде задавать поведения системы, но она не поддерживает работу с данными и не позволяет детально описывать действия, производимые моделируемыми объектами. Для целей описания работы с данными, указания точек отправки и приема сигналов и

добавления условий ветвления и прерываний, расширена описаниями специальных конструкций, помещаемых в метаданные элементов [39]. К основным элементам нотации UCM можно отнести:

• Team. Задаёт на диаграмме объект исследования или наблюдения;

• Responsibility (х). Отражает точки выполнения каких-либо действий (реализации событий) объектом наблюдения;

• StartPoint (•) и EndPoint (4). Используются для задания начальной и конечной точек сценария.

• AndFork (-£) и AndJoin (5-). Используются для задания начала и окончания параллельных сценариев.

• FailurePoint ( т1"). Участвует в описании механизма генерации и обработки исключений.

• Timer (о). Описывает временную задержку.