автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Метод и средства автоматизации тестирования интерфейса программирования приложения

На правах рукописи

Бирюков Сергей Вячеславович

МЕТОД И СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ИНТЕРФЕЙСА ПРОГРАММИРОВАНИЯ ПРИЛОЖЕНИЯ

Специальность: 05.13.11 - Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

Автореферат

диссертации на соискание ученой степени кандидата технических наук

1 7 НОЯ 2011

Таганрог - 2011

005002747

Работа выполнена на кафедре Математического обеспечения и применения ЭВМ Технологического института ФГАОУ ВПО «Южный федеральный университет» в г.Таганроге.

НАУЧНЫЙ РУКОВОДИТЕЛЬ:

доктор технических наук, профессор Кравченко Павел Павлович

ОФИЦИАЛЬНЫЕ ОППОНЕНТЫ: доктор технических наук, профессор

Бабенко Людмила Кпиментьевна

кандидат технических наук, доцент Гранков Михаил Васильевич

ВЕДУЩАЯ ОРГАНИЗАЦИЯ:

Федеральное государственное научное учреэвдение «Научно-исследовательский институт «Специализированные вычислительные устройства защиты и автоматика», г.Ростов-на-Дону

Защита состоится 9 декабря 2011 г. в 1420 на заседании диссертационного совета Д 212.208.24 при Южном федеральном университете по адресу: г. Таганрог, ул. Чехова, 2, корп. «И», комн. 347.

С диссертацией можно ознакомиться в зональной научной библиотеке Южного федерального университета по адресу: г. Ростов-на-Дону, ул. Пушкинская, 148, автореферат размещен в сети Интернет по адресу: http://www.sfedu.ru

Автореферат разослан « 5 » ноября 2011 г.

Просим Вас прислать отзыв, заверенный печатью учреждения, по адресу: 347928, г. Таганрог, Ростовская область, ГСП-17А, пер. Некрасовский, 44, Технологический институт Южного федерального университета в г. Таганроге, Учёному секретарю диссертационного совета Д 212.208.24 Кухаренко Анатолию Павловичу.

Учёный секретарь

диссертационного совета, кандидат технических наук, доцент

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

Под интерфейсом программирования приложения (Application Programming Interface, API) понимается набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Детали реализации API при этом, как правило, скрыты. Примерами API могут служить библиотеки функций (COM DLL, .NET assembly), web-сервисы, встроенные средства программирования приложений (VBA в MS Office).

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

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

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

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

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

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

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

1) Анализ известных подходов к автоматизации тестирования интерфейса программирования приложения.

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

3) Разработка алгоритма автоматического построения унифицированной модели интерфейса на основе спецификации.

4) Разработка алгоритма обхода модели для генерации тестов.

5) Разработка алгоритма оптимизации тестов.

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

7) Выполнение экспериментальных исследований и апробации разработанного метода.

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

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

Научная новизна результатов диссертационной работы определяется тем, что в ней:

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

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

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

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

4) Впервые разработан алгоритм построения унифицированной модели, отличающийся наличием процедур разбора спецификации интерфейса, заданной в терминах IDL, UML или .NET-библиотеки.

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

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

Результаты, выдвигаемые на защиту:

1) Метод автоматизации тестирования интерфейса программирования приложения на основе универсальной среды APITest.

2) Алгоритм автоматического построения унифицированной модели интерфейса программирования на основе разбора спецификации.

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

4) Алгоритм оптимизации тестов на основе статического анализа.

5) Универсальная среда тестирования программных интерфейсов APITest.

Практическая ценность работы. В диссертации решена важная научная

задача, заключающаяся в создании метода и алгоритмов автоматизации тестирования интерфейсов программирования приложений, позволяющего в сравнении с другими методами тестирования API-интерфейсов в 1,5-1,8 раза сократить временные затраты за счет автоматического построения модели на основе спецификации API и генерации тестов с трансляцией в код без снижения качества тестового набора.

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

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

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

Внедрение результатов работы. Результаты работы использованы при выполнении х/д работы №12405-8/533 «Исследования и разработка методов и средств высокоточного определения местоположения маневренных объектов по стереоскопическим изображениям местности и топогеодезической информации» (шифр «Аксиома-ЮФУ») и в учебном процессе по курсу «Метрология и качество программного обеспечения».

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

1) II Международной научно-практической Интернет-конференции «Инновационные подходы к применению информационных технологий в профессиональной деятельности», Белгород, 2010.

2) VII Всероссийской научно-практической конференции студентов, аспирантов и молодых ученых "Молодежь и современные информационные технологии", Томск, 2009.

3) VII Всероссийской конференции студентов, аспирантов и молодых ученых «Технологии Microsoft в теории и практике программирования», Таганрог, 2010.

4) II Ежегодной Всероссийской научно-практической конференции с международным участием «Перспективы развития информационных технологий». Новосибирск, 2010.

5) Всероссийской научно-технической конференции аспирантов, студентов и молодых ученых "Информатика и вычислительная техника - 2010". Ульяновск, 2010.

Личный вклад автора. Все научные результаты получены автором лично.

Публикации. По результатам диссертации опубликовано 12 печатных работах, среди них 7 статей (2 статьи в журналах перечня ВАК) и 1 свидетельство об официальной регистрации программы для ЭВМ №2010617638 «Программа автоматизации функционального тестирования интерфейсов программирования приложений APITest».

Структура и объем диссертации. Материал основной части диссертационной работы изложен на 149 страницах машинописного текста. Диссертация состоит из введения, 3 разделов, заключения, списка литературы из 102 источников, содержит 49 рисунков и приложения на 17 страницах.

КРАТКОЕ СОДЕРЖАНИЕ РАБОТЫ

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

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

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

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

Проанализированы существующие подходы к автоматизации тестирования интерфейсов программирования приложений. Среди них выделены такие направления, как автоматизированное модульное тестирование, специализированные программы тестирования - тестовые драйверы и генераторы, генераторы шаблонов интерфейсных функций, технологии UniTesK и AsmL. Использование инструментария модульного тестирования (например, семейство xUnit) позволяет автоматизировать лишь процесс выполнения тестовых сценариев. Остальные шаги цикла тестирования API необходимо выполнять вручную. Генераторы шаблонов интерфейсных функций, используемые самостоятельно или в совокупности с инструментарием модульного тестирования, избавляют от части рутинной ручной работы по написанию кода вызовов интерфейсных функций. Однако они не решают ключевых проблем при тестировании API: генерации оракулов и последовательностей вызовов методов, выбора комбинаций значений входных параметров, эффективного покрытия тестируемого кода. Использование тестовых драйверов и тестовых генераторов не всегда целесообразно вследствие высокой трудоемкости сопровождения и сложности самих программ тестирования.

Разработанные независимо друг от друга технологии UniTesK и AsmL реализуют схожие идеи использования модели программной системы для автоматизации тестирования. Они достаточно универсальны, и могут быть применены для автоматизации тестирования API, но при этом требуется ручное описание всех компонент модели и медиаторов. Делается вывод о том, что повысить степень автоматизации можно за счет автоматического построения

модели на основе спецификации интерфейса, вырабатываемой на этапе проектирования API.

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

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

Рассматриваются различные форматы представления спецификаций интерфейсов: язык описания интерфейсом IDL, диаграмма классов UML и метаданные библиотеки .NET. Форматы имеют примерно одинаковый уровень абстракции, что позволяет использовать любой из них для построения модели интерфейса программирования.

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

Вторая глава посвящена описанию разработанного метода и алгоритмов автоматизации тестирования интерфейса программирования приложения. Определена совокупность действий метода. Она представлена в виде UML-диаграммы последовательности (см. рис 1).

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

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

П»СТП»НТ«.1Ь Обходчик Ошняпыгпр liusffiim СпсниФик» язмкч

2: Загрччка скеапфккшок

6: Дополнение доменов j

7: Определение конструктор«]

8; Л ""явление фупкннонал!.

3: Построение моя

^^^ Удач*

Удаление циклон

> 5: Добавление дож

11: OimiMinaiiiiH т

12: Шаблоны использования API на ЯВУ I* (?• Нзшптегп» «я ЯН

, 1$: Результаты работы API

Результаты тестирования

Рис. 1. Диаграмма последовательности метода автоматизации тестирования API

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

Разработан формат унифицированной модели интерфейса программирования, которая может быть построена путем разбора спецификаций в различных нотациях: IDL, UML, .NET-сборок. Унифицированная модель интерфейса представляет собой ориентированный граф. В нем выделяются вершины двух типов - объекты интерфейса и действия над ними (интерфейсные

методы). Вершины первого типа соответствуют объектам, причем выделяются сложные и простые объекты. Простые объекты - это элементарные типы данных среды использования API (языка программирования). Сложные объекты задекларированы непосредственно в интерфейсе. Их создание, удаление и операции над ними осуществляются посредством интерфейсных методов. Вершины второго типа соответствуют действиям над объектами. Среди них также различается две категории - атрибуты и методы. Атрибуты являются интерфейсом для получения или назначения некоторой характеристики объекта. Некоторые атрибуты доступны только для чтения данных, их модификация скрыта внутри объекта. Методы выполняют манипуляции над объектом в зависимости от набора входных параметров и позволяют получить результат (возможно пустой) - потенциально полезные стороннему пользователю API данные. Пример графа модели представлен на рисунке 2.

Рис. 2. Пример графа унифицированной модели API

Дуги графа всегда соединяют вершины разных типов. Таким образом, в графе присутствуют только дуги «объект-действие» и «действие-объект» При этом направление дуги показывает направление потока данных при выполнении действия.

Разработан алгоритм построения унифицированной модели на основе автоматического разбора спецификации (см. рис. 3).

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

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

граф добавляется .объект, соответствующий типу значения атрибута. Для атрибутов, доступных на запись, в качестве типа значения атрибута добавляется псевдо-объект (Null). В этом случае записываемый объект добавляется как параметр атрибута. Для методов перебираются и добавляются в граф все их параметры. На заключительном этапе добавленные вершины связываются дугами соответствующих типов. Помимо видимых после построения ребер в граф также добавляются обратные им ребра. Это в дальнейшем позволяет быстро перемещаться по графу, вычисляя следующую вершину за время 0(1). Общее время работы алгоритма построения модели оценивается как О(N:MK), где N -количество объектов интерфейса, М - количество действий в каждом объекте, К -количество параметров в каждом действии-методе.

Рис. 3. Блок-схема алгоритма построения модели API

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

11

заранее определена в шаблоне, а их добавление в домен тестовых значений объекта возможно автоматически.

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

Поскольку традиционный метод контрактных спецификаций недостаточно эффективен для представления функциональных требований, в работе была выполнена его модификация. Во-первых, были введены предикативные спецификации. Предусловие или постусловие называется предикативным, если проверке утверждения предшествует некоторый предикат. Утверждение проверяется только в случае в том случае, если значение предиката истинно. Это позволяет в одной точке валидации задавать различные требования к методу интерфейса в зависимости от текущего состояния системы. Во-вторых, был введен новый тип спецификации - условие исключения (exceptional condition) или спецификация исключения. Спецификация исключения позволяет указать в модели API, что в определенном состоянии системы ожидается исключение при выполнении метода, и это считается корректной работой. Спецификации исключений также могут быть предикативными.

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

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

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

Сложность алгоритма обхода модели зависит от установок флагов «порождающие действия» и «значения параметров». Минимальная сложность, равная О(Л0, достигается при значениях «порождающие действия» = «выбрать любое», «значения параметров» = «выбрать любые». Максимальная сложность, равная 0(Л'Л/) достигается при значениях флагов «перебрать все». Здесь /V -количество вершин в графе, к - количество параметров в действии, М -количество путей вычисления параметра.

В процессе обхода полученные тестовые сценарии записываются в виде последовательности лексем. В лексеме условными обозначениями записаны объекты, действия, параметры действий, способы создания объектов и так далее. Лексемы удобны для трансляции в конструкции языка программирования. При трансляции используется техника «скользящего окна» с размером 3 по трассе теста.

Сформулирована и доказана теорема 1 (о размере скользящего окна): для трансляции теста в виде лексем, полученного в результате обхода модели, в код на языке программирования достаточно скользящего окна размером 3 лексемы.

Важным следствием теоремы о размере скользящего окна является тот факт, что для трансляции теста в код на ЯВУ может быть построен линейный относительно длины трассы теста алгоритм.

Разработан алгоритм трансляции трасс тестов в виде лексем в код на языке программирования. Алгоритм последовательно выделяет лексемы в рамках скользящего окна и определяет их типы (метод, атрибут, конструктор, инициализация из домена и т.д.). Затем с помощью извлеченных из специфики языка соответствующих типам правил выполняется трансляция в код на ЯВУ. Попутно с этим, алгоритм извлекает из модели и транслирует контрактные спецификации.

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

Рис. 4. Блок-схема алгоритма оптимизации тестов

Пусть S- набор тестов. S- {Th Т2, ... , Тп), где Т, - отдельный тест. Каждый Т, состоит из упорядоченной последовательности лексем ttJ, '¡\ = (tih (,2, ... , i„„). Тогда существует такой (возможно, пустой) набор S' = {Т,', Т2\ ... , Тк'}, такой, что каждый тест Т,' входит в некоторый 7} в качестве «подтеста», то есть 7]' с 7]. Все Т,' необходимо удалить из исходного тестового набора. При этом степень тестового покрытия не уменьшается. Оптимизированный тестовый набор 5* определяется как S* = S -S'. Алгоритм состоит из двух основных этапов -заполнение хеш-таблицы (препроцессинг) и последовательный поиск в хеш-таблице каждого из тестов. Здесь хеш-функция используется для свертки данных (префиксов тестов). Чтобы не вносить дополнительную сложность во временную оценку эффективности алгоритма, хеш-функция должна удовлетворять следующим условияхt вычислимости:

1) Функция //(/;, t2, ..., t,„) вычислима за О(т), где т - количество лексем в тесте.

2) Функция H(t/, t2, ...,t,) такая, что

#(//, t2, ..., /,) = //(//, 6, ..., X//(/,), для любых i=\..m. То есть, значение функции для префикса длины i можно вычислить, уже зная значение функции для префикса длины /'-1 и вычислив ключ #(*,■)• Здесь X - некоторая операция.

3) Операция X выполняется за время 0(1) относительно т.

Временная сложность алгоритма оптимизации оценивается как 0(NMIogNM), где N - число тестов, М - количество лексем в тесте.

Сформулирована и доказана теорема 2: Если хеш-функция удовлетворяет условиям вычислимости, то она не изменяет оценку временной сложности 0() алгоритма оптимизации тестов.

В работе была предложена хеш-функция вида:

Hit t прит>\.

где х X у = (Рх + у) mod 2b, Р - большое простое число, Р < 2Ь, b - число разрядов ключа. Операция Я не является коммутативной и ассоциативной.

Сформулирована и доказана теорема 3: Хеш-функция вида (1) удовлетворяет условиям вычислимости.

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

В третьей главе описывается структура и программная реализация метода автоматизации тестирования интерфейса программирования приложения, а также результаты экспериментальных исследований и практической апробации разработанного метода. Метод автоматизации тестирования реализован в виде универсальной среды тестирования программных интерфейсов APITest. APITest состоит из независимых программных модулей (подсистем), объединенных единым графическим интерфейсом пользователя. Структурная схема программной реализации представлена на рисунке 5.

Построитель унифицированной Mfuc. Ill

ж

Обходчик- унифицированной модели

Генератор тестов ^м/ Специфика ямлка I

1

Рис. 5. Структурная схема среды тестирования программных интерфейсов АРНея!

Программная система APITest реализует последовательность действий метода автоматизации тестирования API, представленную на рисунке I. Стрелками указано направление потока данных при взаимодействии отдельных подсистем.

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

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

Схема эксперимента представлена на рисунке 6.

Рис. 6. Схема эксперимента при проведении исследований метода автоматизации

тестирования API

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

Для проведения экспериментальных исследований по разработанному методу были выбраны следующие направления:

- анализ влияния параметров обхода модели на качество набора тестов;

- анализ влияния использования значений по умолчанию на качество набора тестов;

- анализ эффективности набора тестов;

- анализ эффективности оптимизации набора тестов;

- анализ временных ресурсозатрат на получение набора тестов.

Для оценки качества набора тестов были использованы следующие метрики:

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

- Количество обнаруженных при прогоне тестового набора дефектов.

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

размеру программы (в терминах выбранной метрики оценки размера). В работе используется метрика оценки размера программы как количества операторов в ней.

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

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

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

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

Внедрение результатов диссертации в рамках НИР "Аксиома-ЮФУ" для автоматизации функционального тестирования программных библиотек макета корреляционно-экстремальной системы навигации позволило сократить трудоемкость тестирования на 65-75% за счет автоматизации этапов построения модели, разработки и кодирования тестов, что подтверждается соответствующим актом.

Результаты диссертации были использованы в учебном процессе Технологического института Южного федерального университета в г.Таганроге по курсу «Метрология и качество программного обеспечения».

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

ОСНОВНЫЕ РЕЗУЛЬТАТЫ И ВЫВОДЫ

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

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

1) Показано, что сокращение трудоемкости тестирования программных интерфейсов возможно за счет автоматического построения модели интерфейса на основе спецификации в формате IDL, UML или метаданных библиотеки .NET.

2) Для формализации функциональных требований к программному интерфейсу выбран метод контрактных спецификаций и выполнена его

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

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

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

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

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

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

8) Разработаны программные средства универсальной среды тестирования программных интерфейсов APITest, содержащие модули разбора спецификаций API, построения модели API, обхода модели, генерации тестов, оптимизации тестов.

ОСНОВНЫЕ ПУБЛИКАЦИИ ПО ТЕМЕ ДИССЕРТАЦИИ

Публикации в изданиях, входящих в перечень рекомендованных ВАК:

1. Бирюков C.B. Разработка метода автоматизации тестирования систем с интерфейсом программирования // Известия ЮФУ. Технические науки. Тематический выпуск «Перспективные системы и задачи управления». -Таганрог: Изд-во ТТИ ЮФУ, 2010. №3 (104) С.222-227.

2. Бирюков C.B. Автоматизация функционального тестирования web-сервисов // Известия ЮФУ. Технические науки. Тематический выпуск "Компьютерные и информационные технологии в науке, инженерии и управлении". - Таганрог: Изд-во ТТИ ЮФУ, 2008, № 2. С. 175-178.

Другие публикации:

3. Бирюков C.B. Анализ стратегий тестирования программного обеспечения // Известия ЮФУ. Технические науки. Специальный выпуск. Материалы LII1 научно-технической конференции профессорско-преподавательского состава, аспирантов и сотрудников ТТИ ЮФУ. - Таганрог: Изд-во ТТИ ЮФУ, 2008. № 1 (78). С.59-63.

4. Бирюков C.B. Анализ методов построения тестовых сценариев для обеспечения качества программных средств // Сборник трудов всероссийской научной школы-семинара молодых ученых, аспирантов и студентов "Интеллектуализация информационного поиска, скантехнологии и электронные библиотеки". - Таганрог: Изд-во ТТИ ЮФУ, 2008. С. 131-136.

5. Бирюков C.B. Об использовании моделей при автоматизации построения тестовых сценариев для тестирования интерфейса программирования приложения. Молодежь и современные информационные технологии // Сборник трудов VII Всероссийской НПК студентов, аспирантов и молодых ученых "Молодежь и современные информационные технологии". Томск, 25-27 февраля 2009г., ч.2. Томск: Изд-во СПБ Графике. С. 135-136.

6. Бирюков C.B. Метод автоматизации тестирования интерфейсов динамических библиотек и его реализация в программной системе APITest // Технологии Microsoft в теории и практике программирования: труды VII-ой Всероссийской конференции студентов, аспирантов и молодых ученых. Южный регион. Таганрог, 19-20 марта 2010г. -Таганрог: Изд-во ТТИ ЮФУ, 2010. С.5-8.

7. Бирюков C.B. Подход к автоматизации тестирования систем с интерфейсом программирования // Сборник материалов II Ежегодной Всероссийской научно-практической конференции с международным участием «Перспективы развития информационных технологий» / Под общ. ред. С.С.Чернова. - Новосибирск: Изд-во "СИБПРИНТ", 2010. С. 176-181.

8. Бирюков C.B. Программная реализация метода автоматизации функционального тестирования интерфейса программирования приложения // Сборник трудов второй Международной научно-практической Интернет-конференции Белгородского филиала НАЧОУ ВПО СГА «Инновационные подходы к применению информационных технологий в профессиональной деятельности». - Белгород: Изд-во ГиК. 2010. С. 297-301.

9. Бирюков C.B. Прототип системы автоматизации функционального тестирования интерфейса программирования приложения // Сборник научных трудов Российской конференции аспирантов, студентов и молодых ученых «Информатика и вычислительная техника», г. Ульяновск, 25-26 мая 2010г. - Ульяновск: Изд-во УлГТУ. С.46-49.

10. Бирюков C.B. Программа автоматизации функционального тестирования интерфейса программирования приложения APITest // Свидетельство о государственной регистрации программы для ЭВМ №2010617638 от 18.11.2010г.

Типография ТТИ ЮФУ, ГСП 17А, Таганрог, ул. Энгельса, 1. Заказ N»5' Ч. Тираж 120 экз.

19

Введение.

1. Аналитический обзор существующих подходов к автоматизации тестирования интерфейса программирования приложения.

1.1. История развития тестирования программного обеспечения.

1.2. Стратегии построения тестов.

1.2.1. Поведенческое тестирование.

1.2.2. Структурное тестирование.

1.3. Тестирование на основе модели программного обеспечения.

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

1.4.1. Автоматизированное модульное тестирование.

1.4.2. Генераторы шаблонов интерфейсных функций.

1.4.3. Технология ишТеэК.

1.4.4. Технология АвтЬ.

1.5. Особенности тестирования интерфейса программирования приложения.

1.6. Постановка задачи автоматизации тестирования интерфейса программирования приложения.

1.7. Форматы спецификаций интерфейса программирования приложения

1.8. Выводы.

2. Разработка метода автоматизации тестирования интерфейса программирования приложения.

2.1. Определение совокупности действий метода.

2.2. Разработка и построение унифицированной модели на основе спецификации.

2.3. Расширение унифицированной модели функциональными требованиями к интерфейсу программирования.

2.4. Разработка алгоритма обхода унифицированной модели для генерации тестов.

2.5. Разработка алгоритма оптимизации тестов.

2.6. Выводы.

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

3.1. Программная реализация метода автоматизации тестирования интерфейса программирования приложения.

3.1.1. Основные требования к программной реализации.

3.1.2. Структурная схема программной системы.

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

3.1.4. Построитель унифицированной модели.:.

3.1.5. Обходчик унифицированной модели.

3.1.6. Генератор тестов.

3.1.7. Оптимизатор тестов.

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

3.2.1. Методика проведения экспериментальных исследований.

3.2.2. Анализ влияния параметров обхода модели на качество набора тестов

3.2.3. Анализ влияния использования значений по умолчанию на качество набора тестов.

3.2.4. Анализ эффективности оптимизации набора тестов.

3.2.5. Сравнительный анализ временных ресурсозатрат на получение набора тестов.

3.2.6. Сравнительный анализ эффективности набора тестов.

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

3.3.1. Структура программной системы моделирования.

3.3.2. Результаты тестирования программых библиотек наземной части КЭНС

3.4. Выводы.

Актуальность темы. В настоящее время необходимость систематизированного тестирования в промышленной разработке программного обеспечения (ПО) общепризнанна и неоспорима. Традиционные методы разработки тестов вручную уже не могут обеспечить качественное тестирование современных программных систем. Появляется все большее число методик автоматизации и инструментальных средств, направленных на повышение качества и сокращение ресурсозатрат на тестирование ПО. Недостаточно хорошо проведенное тестирование может нанести серьезный урон проекту в целом. Устранение ошибки на стадии сопровождения готового ПО обходится в среднем в 200 раз дороже, чем на стадии определения требований, а в результате позднего выявления ошибок общий бюджет проекта возрастает на 30-40% [1].

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

Под интерфейсом программирования приложения (Application Programming Interface, API) понимается набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах[2]. Детали реализации API при этом, как правило, скрыты. Помимо понятия «интерфейс программирования приложения» в литературе встречаются термины .«прикладной программный интерфейс»[3], «интерфейс прикладного программирования»^], которые являются синонимами. Примерами API могут служить библиотеки функций (COM DLL, .NET assembly), webсервисы, встроенные средства программирования приложений (YBA б MS Office).

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

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

Зачастую методы интерфейса оперируют данными сложного типа в качестве параметров. Эти данные не могут быть созданы напрямую, а должны быть получены в результате работы других методов. Например, в JavaScript API карт от Google[5] имеется интерфейсный метод Geocoder.geocode(.), принимающий в качестве параметра сложный объект GeocoderRequest. Объект GeocoderRequest создается отдельным методом-конструктором, при этом для создания этого объекта необходимо создать и передать конструктору сложные объекты LatLng и LatLngBounds. Таким образом, не всегда возможно независимое тестирование интерфейсных методов, необходимо уметь строить последовательности вызовов. Причем промежуточный результат должен быть пригодным для успешного вызова последующего метода в последовательности.

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

В последнее время определенный прогресс в автоматизации тестирования API достигнут в исследованиях в области моделирования программного обеспечения. Модели позволяют унифицировано описать структуру и функциональные требования к системам, а, значит, имеется возможность их обработки формальными методами. Вопросы применения моделей ПО для тестирования освещены в работах B.Beizer [15], H. Robinson [29], J. Whittaker [35] и других. Наиболее успешными технологиями, использующими идеи моделирования ПО для автоматизации тестирования, являются разработанная в Институте системного программирования РАН технология UniTESK [57, 58] и разработанная группой Microsoft Research технология AsmL [66, 67].

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

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

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

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

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

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

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

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

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

1) Провести анализ известных подходов к автоматизации тестирования интерфейса программирования приложения.

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

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

4) Разработать алгоритм обхода модели для генерации тестов.

5) Разработать алгоритм оптимизации тестов.

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

7) Провести экспериментальные исследования и апробацию разработанного метода.

Научная новизна диссертации состоит в том, что в ней:

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

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

3) Впервые разработан алгоритм построения унифицированной модели, отличающийся наличием процедур разбора спецификации интерфейса, заданной в терминах ГОЬ, ЦМЬ или .1ЧЕТ-библиотеки.

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

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

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

Практическая ценность работы подтверждается эффективностью применения предложенного метода и алгоритмов для тестирования программных библиотек макета корреляционно-экстремальной системы навигации в рамках научно-исследовательской работы №12405-8/533 «Исследования и разработка методов и средств высокоточного определения местоположения маневренных объектов по стереоскопическим изображениям местности и топогеодезической информации» (шифр* «Аксиома-ЮФУ»), что позволило сократить временные затраты на 65-75%.

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

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

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

1) II Международной научно-практической Интернет-конференции «Инновационные подходы к применению информационных технологий в профессиональной деятельности», Белгород, 2010.

2) VII Всероссийской научно-практической конференции студентов, аспирантов и молодых ученых "Молодежь и современные информационные технологии", Томск, 2009.

3) VII Всероссийской конференции студентов, аспирантов и молодых ученых «Технологии Microsoft в теории и практике программирования», Таганрог, 2010.

4) II Ежегодной Всероссийской научно-практической конференции с международным участием «Перспективы развития информационных технологий». Новосибирск, 2010.

5) Всероссийской научно-технической конференции аспирантов, студентов и молодых ученых "Информатика и вычислительная техника - 2010". Ульяновск, 2010.

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

Публикации. Результаты, полученные в диссертации, нашли отражение в 12 печатных работах, среди них 7 статей (2 статьи в журналах перечня ВАК) и 1 свидетельство об официальной регистрации программы для ЭВМ №2010617638 «Программа автоматизации функционального тестирования интерфейса программирования приложения АРГГезЪ).

Структура работы. Материал основной части диссертационной работы изложен на 149 страницах. Диссертация состоит из введения, трех глав, заключения, списка литературы из 102 источников и приложений на 17 страницах.

3.4. Выводы

1) Разработаны программные средства универсальной среды тестирования программных интерфейсов АР1Тез1, содержащие модули разбора спецификаций АР1, построения модели АР1, обхода модели, генерации тестов, оптимизации тестов.

2) Предложена методика проведения экспериментальных исследований разработанного метода автоматизации тестирования интерфейса программирования приложения.

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

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

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

6) Сравнительный анализ временных ресурсозатрат на получение тестовых наборов показал, что предложенный метод позволяет до 1,7 раз сократить временные затраты и до 3 раз уменьшить долю ручного труда по сравнению с другими модельными подходами за счет автоматического построения модели на основе спецификации АР1 и генерации тестов с трансляцией в код.

7) Проведенное формальное сравнение по критерию вводимых вручную строк кода разработанного метода с подходом на основе специализированных программ тестирования показывает, что использование системы АР1Тез1 с учетом времени на обучение работе с системой в 1,5-1,8 раз обеспечивает выигрыш в трудоемкости тестирования интерфейсных функций.

8) Апробация разработанного метода для автоматизации функционального тестирования программных библиотек макета корреляционно-экстремальной системы навигации позволила сократить временные затраты на 65-75% за счет автоматизации этапов построения модели, разработки и кодирования тестов.

ЗАКЛЮЧЕНИЕ

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

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

1. Показано, что сокращение трудоемкости тестирования программных интерфейсов возможно за счет автоматического построения модели интерфейса на основе спецификации в формате IDL, UML или метаданных библиотеки .NET.

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

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

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

5. Разработан алгоритм построения унифицированной модели, отличающийся наличием процедур разбора спецификации интерфейса, заданной в терминах ГОЬ, ИМЬ или метаданных ЛчГЕТ-библиотеки.

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

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

8. Разработаны программные средства универсальной среды тестирования программных интерфейсов АР1Тез1: модуль разбора спецификаций АР1, модуль построения модели АР1, модуль обхода модели АР1, модуль генерации тестов, модуль оптимизации тестов.

Основные научные результаты диссертационной работы опубликованы в работах [14, 73, 74, 91, 92].

По результатам диссертационной работы получено свидетельство об официальной регистрации программы для ЭВМ №2010617638 «Программа автоматизации функционального тестирования интерфейса программирования приложения АРХТеБЪ).

Результаты диссертации использованы при выполнении научно-исследовательской работы №12405-8/533 «Исследования и разработка методов и средств высокоточного определения местоположения маневренных объектов по стереоскопическим изображениям местности и топогеодезической информации» (шифр «Аксиома-ЮФУ») для автоматизации тестирования программных библиотек макета корреляционно-экстремальной системы навигации и в учебном процессе по курсу

Метрология и качество программного обеспечения», что подтверждается соответствующими актами и справками.

Все научные результаты, полученные при решении научной задачи создания метода и алгоритмов универсальной среды тестирования программных интерфейсов, обеспечивающих сокращение трудоемкости тестирования АР1-интерфейсов, получены автором лично.

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

1. Новичков А., Панкратов В. Автоматизированное тестирование: оценка возврата инвестиций и сопутствующие риски // КомпьютерПресс -2005 -№11.

2. Интерфейс программирования приложений электронный ресурс.: Электронная энциклопедия Википедия. Режим доступа: http://ru.wikipedia.org/wiki/

3. Интерфейспрограммированияприложений, свободный.

4. Оринштейн Д. Прикладной программный интерфейс // Computerworld Россия, №9, 2009.

5. Пройдаков Э., Теплицкий J1. Англо-русский толковый словарь по вычислительной технике, Интернету и программированию. М.: Изд-во Русская редакция, 2004. - 858 с. - ISBN 5-7502-0195-3

6. Google Maps Javascript API Version 3 Reference электронный ресурс. Режим доступа:http://code.google.eom/intl/ru/apis/maps/documentation/javascript/3.4/refere псе.html, свободный.

7. Berger S. Understanding Bugs and Patches электронный ресурс.: An explanation of what a bug is and how a patch affects a software program. Режим доступа: www.aaф.org/learntech/computers/howto/a2003-03-07-bugsandpatches.html, свободный. Яз. англ.

8. Галицкая С. Информационные технологии в Беларуси электронный ресурс.: Обеспечение качества и тестирование ПО. Практический опыт и тенденции. Режим доступа: http://www.it-belarus.net/publications/view/53/, свободный.

9. Троелсен Э. Модель СОМ и применение ATL 3.0. Изд-во BHV-СПб, 2001. - 928 с. - ISBN 5-7791-0096.

10. Рихтер Дж. Windows для профессионалов: создание эффективных-Win32 приложений с учетом специфики 64-разрядной версии Windows/Пер, англ 4-е изд. - М.: Издательско-торговый дом "Русская Редакция", 2001. - 752 е.; ил.

11. Ю.Орфали Р., Харки Д. "JAVA и CORBA в приложениях клиент-сервер". М.: Изд-во Лори, 2000. - 717 с.

12. Аншина М. Цимбал А. Технологии создания распределенных систем. Для профессионалов. Изд-во Питер, 2002. - 576 с. ISBN 5-94723-4130.

13. Дастин Э., Рэшка Д., Пол Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация. -М.: Изд-во Лори, 2003. 567 с.

14. Black R. Critical Testing Processes: Plan, Prepare, Perform, Perfect. New York, 2003.-608 p.

15. Бейзер Б. Тестирование черного ящика. Технология функционального тестирования программного обеспечения. Изд-во Питер, 2004. - 320 с.

16. Howden W. Functional program testing and analysis. New York, 1987. -ISBN: 0-070-30550-1.

17. Clarke L. A formal evaluation of data flow path selection criteria // IEEE Transactions on software Engineering #15, pp.1318 1332.

18. Cohen E. A finite domain-testing strategy for computer program testing // Ph.D. diss., Ohio State University, 1978.

19. Ostrand Т., Balcer A., -The category-partition technique for specifying and generating functional tests // Communications of the ACM, 20, 10 (1988). pp. 676-686.

20. Blake N. Boundary Value Analysis электронный ресурс. Режим доступа: www.cs.swan.ac.uk/~csmarkus/CS339/dissertations/NeateB.pdf, свободный. Яз.англ.

21. Jorgenson P. Software Testing A Craftsman's Approach. - CRC Press, New York, 1995.

22. Topics in Syntax Testing электронный ресурс.: Material drawn from Beizer. Drexel University. Режим доступа: http://www.cs.drexel.edu/~spiros/teaching/CS576/slides/syntax.pdf, свободный. Яз.англ.

23. Myers G. The art of software testing. New York, 2004.

24. Канер С., Фолк Д., Кек Нгуен Е. Тестирование программного обеспечения. Киев, 2000.

25. Калбертсон Р., Браун К., Кобб Г. Быстрое тестирование. Вильяме, 2002.-384 с.

26. Тамре JI. Введение в тестирование программного обеспечения. -Вильяме, 2003. 368 с.

27. Beizer В. Software Testing Techniques, Second Edition. New York: Van Nostrand Reinhold, 1990. - 550 p.

28. Петренко А., Бритвина Е., Грошев С., Монахов А. Тестирование на основе моделей // «Открытые системы», 2003. №9.

29. Apfelbaum L., Doyle J. Model-Based Testing // Software Quality Week Conference, 1997.

30. Clarke J. Automated test generation from a behavioral model // Proceedings of the 11th International Software Quality Week (QW 98), 1998.

31. Боггс У., Боггс М. UML и Rational Rose 2002. М.: Изд-во Лори, 2004. -509 с.

32. James A. Whittaker, Michael G. Thomason. A Markov chain model for statistical software testing // IEEE Transactions on Software Engineering, 20(10), 1994. pp. 812-824.

33. Peter M. Maurer. The design and implementation of a grammar-based data generator // Software Practice & Experience, 1992, pp. 223-244.

34. Emin Gun Sirer, Brian N. Bershad. Using production grammars in software testing // The 2nd Conference on Domain-Specific Languages. 1999.

35. Robinson H. Using Pre-Oracled Data in Model-Based Testing электронный ресурс.: Internal Microsoft white paper. 1999. Режим доступа: http://www.geocities.com/harryrobinsontesting/pre-oracled.htm, свободный.- Яз.англ.

36. Ibrahim К. El-Far, James A. Whittaker. Model-based Software Testing. Encyclopedia on Software Engineering (edited by J.J. Marciniak) Wiley, 2001.- 1584 p.

37. Dennis К. Peters; David L. Parnas. Using test oracles generated from program documentation // IEEE Transactions on Software Engineering 24(3), 1998, pp. 161-171.

38. James A. Whittaker. Stochastic software testing // Annals of Software Engineering. 4, 1997, pp. 115-131.

39. Fujiwara S., Bochmann G., Khendek F., Amalou M., Ghedamsi A. Test selection based on finite state models // IEEE Transactions on Software Engineering, 17(6), 1991, pp. 591-603.

40. Dahbura A., Uyar, M. Optimal Test Sequence Generation for Protocols: The Chinese Postman Algorithm // Q.931, IEEE GLOBECOM, 1986.

41. Bodin L., Tucker A. A Model for Municipal Street Sweeping Operations. Modules in Applied Mathematics. Vol. 3: Discrete and System Models. -1983.

42. Jorgensen A., Whittaker J. An API Testing Method электронный ресурс. Режим доступа:http://www.geocities.com/modelbasedtesting/apitestingmethod.doc, свободный. Яз. англ.

43. Osherove R. The Art of Unit Testing. Softbound print, 2009, 375 p. -ISBN: 1933988274.

44. Макгрегор Д., Сайке Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. К.: ООО «ТИД «ДС», 2002. - 432с.

45. Beck. К. Simple Smalltalk Testing: With Patterns электронный ресурс. Режим доступа: http://www.xprogramming.com/testfram.htm, свободный. — Яз. англ.

46. Месарош Дж. Шаблоны тестирования xUnit: рефакторинг кода тестов. Вильяме, 2009, 832 с.

47. Голуб В., Лысачев П., Потапова Т., Москальцов В. Методика тестирования динамических библиотек // Вестник ВГУ, серия: системный анализ и информационные технологии, 2007, № 2.

48. Watkins-Gibbs J. API Testing vs. Unit Testing: What's the difference? электронный ресурс. Режим доступа: http://www.logigear.com/newsletter/apivsunit.asp, свободный. Яз. англ.

49. McCaffrey J. API Testing vs. Unit Testing электронный ресурс. Режим доступа:http://jamesmccaffrey.spaces.live.com/blog/cnsl504C7CC53E7E7FE8 !116.е ntry, свободный. Яз. англ.

50. SoapUI Feature Overview электронный ресурс. Режим доступа: http://www.soapui.org/features.html, свободный. Яз. англ.

51. Бирюков C.B. Автоматизация функционального тестирования web-сервисов // Известия ЮФУ. Технические науки. Тематический выпуск "Компьютерные и информационные технологии в науке, инженерии и управлении". Таганрог: Изд-во ТТИ ЮФУ, 2008, № 2. С. 175-178.

52. Кулямин В., Петренко А., Косачев А., Бурдонов И. Подход UniTesK к разработке тестов // Программирование, 29(6), 2003. С. 25-43.

53. Meyer В. Applying «Design by Contract» // IEEE Computer, vol. 25, No. 10, 1992, pp. 40-51.

54. Bourdonov, A. Kossatchev, A. Petrenko, D. Gaiter. KVEST: Automated Generation of Test Suites from Formal Specifications // FM'99: Formal Methods. LNCS 1708, Springer-Verlag, 1999, pp. 608-621.

55. Bourdonov, A. Kossatchev, V. Kuliamin, and A. Petrenko. UniTesK Test Suite Architecture // Proc. of FME 2002. LNCS 2391, Springer-Verlag, 2002, pp. 77-88.

56. Мутилин В. Тестирование компонентов, взаимодействующих посредством удаленного вызова методов электронный ресурс.: Труды Института системного программирования РАН. Режим доступа: http://citforum.univ.kiev.ua/SE/testing/mutilin/, свободный.

57. Gurevich Y. Evolving Algebras 1993: Lipari Guide, in Specification and Validation Methods, E. Boerger, Editor. 1995, Oxford University Press, p. 9-36.

58. Barnett M. and others. Model-Based Testing with AsmL // .NET. Microsoft Research.

59. Jacky J., Veanes M., Campbell C., Schulte W. Model-Based Software Testing and Analysis with C#. Cambridge University Press. 2008. 349p.

60. Таненбаум Э., Ван Стеен М. Распределенные системы. СПб.: Питер, 2003.-877 с.

61. Леоненков А. Самоучитель UML 2. СПб: «БХВ-Петербург», 2007. -576с.

62. How to read Object Model Diagrams электронный ресурс. Режим доступа:http://edndoc.esri.eom/arcobjects/8.3/Diagrams/ReadingOMDs.htm, свободный. Яз. англ.

63. Kovse J., Härder Т. Generic XMI-Based UML Model Transformations. ZDNet UK Whitepapers, 2002.

64. Meyer В. Eiffel: The Language. Prentice Hall, 1992.

65. Meyer B. Object-Oriented Software Construction, Second Edition. -Prentice Hall, 1997.

66. Иванников В., Камкин А., Косачев А., Кулямин В., Петренко А. Использование контрактных спецификаций для представления требований и функционального тестирования моделей аппаратуры // Программирование, № 5, 2007. С. 47-61.

67. Камкин А. Тестирование в условиях неполной информации. Подход к разработке спецификаций и генерации тестов электронный ресурс.: Труды Института системного программирования РАН. Режим доступа: http://citforum.ru/SE/testing/incinftesting/, свободный.

68. Сортов А., Хорошилов А. Функциональное тестирование Web-приложений на основе технологии UniTesK // Труды Института системного программирования РАН, №8, 2004, С. 77-97.

69. Винокуров Н., Ворожцов А. Практика и теория программирования. В 2-х книгах. Книга 2. Изд-во «Физматкнига», 2008. - 288с.

70. Проверка графа на ацикличность и нахождение цикла электронный ресурс. Режим доступа: http://e-maxx.ru/algo/findingcycle, свободный.

71. McMaster S., Memon A. Call Stack Coverage for Test Suite Reduction. // 21st IEEE international Conference on Software Maintenance (ICSM'05) -Volume 00 (September 25 30, 2005). ICSM. IEEE Computer Society, Washington, DC, pp. 539-548.

72. Rothermel G., Harrold J., von Ronne J., Hong C. Empirical studies of testsuite reduction // Journal of Software Testing, Verification, and Reliability, V. 12, no. 4, December, 2002.

73. Harrold M., Gupta R., Soffa M. A methodology for controlling the size of a test suite // ACM Transactions on Software Engineering and Methodology, 2(3), July 1993, pp. 270-285.

74. Кичигин Д. Об одном методе сокращения набора тестов// Сборник трудов ИСП РАН, том 13, часть 1, М: ИСП РАН, 2007, С.79-92.

75. Кормен Т., Лейзерсон Ч., Ривест Р. Алгоритмы: построение и анализ. -М: МЦНМО, 1990, 960 С.

76. Knuth D., Morris J., Pratt V. Fast pattern matching in strings // SIAM Journal on Computing 6 (2), pp. 323-350.

77. ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».

78. Вигерс К. Разработка требований к программному обеспечению. -Изд-во «Русская Редакция», 2004. 576 С.

79. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Вильяме, 2001.448 С.

80. Новиков Ф. А. Дискретная математика для программистов. Питер, 2000.304 С.

81. Nachmanson L., Robertson G., Bong-shin Lee. Drawing graphs with GLEE technical report электронный ресурс.: Microsoft Research materials.

82. Режим доступа: ftp://ftp.research.microsoft.com/pub/tr/TR-2007-72.pdf, свободный. Яз. англ.

83. Страница проекта GameToolBox электронный ресурс. Режим доступа: http://sourceforge.net/projects/gametoolbox/, свободный.

84. Липаев В. Тестирование программ. М.: Радио и связь, 1986. - 296 С.

85. Липаев В. Обеспечение качаства программных средств. Методы и стандарты. М.: Синтег, 2001. - 380 С.

86. Рахманов В., Тимченко Б. Метрики в современном тестировании // Научно-технический вестник СПбГИТМО (ТУ). Выпуск 10. Информация и управление в технических системах. СПб.: СПбГИТМО(ТУ), 2003. С. 108-111.

87. Кичигин Д. Метод редукции тестового набора для регрессионного интеграционного тестирования // Журнал РАН «Программирование», №5, 2009, С. 57-69.

88. Humphrey W. Introduction to the Personal Software Process. -Addison-Wesley Longman Publishing Co, 1997. 278 p.