Содержание к диссертации
Введение
1. Аналитический обзор существующих подходов к автоматизации тестирования интерфейса программирования приложения 14
1.1. История развития тестирования программного обеспечения 14
1.2. Стратегии построения тестов 16
1.2.1. Поведенческое тестирование 18
1.2.2. Структурное тестирование 22
1.3. Тестирование на основе модели программного обеспечения 25
1.4. Существующие средства и подходы к автоматизации тестирования интерфейса программирования приложения 33
1.4.1. Автоматизированное модульное тестирование 33
1.4.2. Генераторы шаблонов интерфейсных функций 39
1.4.3. Технология UniTesK 41
1.4.4. Технология AsmL 47
1.5. Особенности тестирования интерфейса программирования приложения 50
1.6. Постановка задачи автоматизации тестирования интерфейса программирования приложения 51
1.7. Форматы спецификаций интерфейса программирования приложения 53
1.8. Выводы 57
2. Разработка метода автоматизации тестирования интерфейса программирования приложения 59
2.1. Определение совокупности действий метода 59
2.2. Разработка и построение унифицированной модели на основе спецификации 62
2.3. Расширение унифицированной модели функциональными требованиями к интерфейсу программирования 67
2.4. Разработка алгоритма обхода унифицированной модели для генерации тестов 74
2.5. Разработка алгоритма оптимизации тестов 90
2.6. Выводы 99
3. Результаты экспериментальных исследований и практической апробации метода автоматизации тестирования интерфейса программирования приложения 101
3.1. Программная реализация метода автоматизации тестирования интерфейса программирования приложения 101
3.1.1. Основные требования к программной реализации 101
3.1.2. Структурная схема программной системы 102
3.1.3. Разработка структуры данных для хранения унифицированной модели интерфейса программирования приложения 105
3.1.4. Построитель унифицированной модели : 107
3.1.5. Обходчик унифицированной модели 110
3.1.6. Генератор тестов 111
3.1.7. Оптимизатор тестов 112
3.2. Результаты экспериментальных исследований метода автоматизации тестирования интерфейса программирования приложения 113
3.2.1. Методика проведения экспериментальных исследований 113
3.2.2. Анализ влияния параметров обхода модели на качество набора тестов 117
3.2.3. Анализ влияния использования значений по умолчанию на качество набора тестов 120
3.2.4. Анализ эффективности оптимизации набора тестов 122
3.2.5. Сравнительный анализ временных ресурсозатрат на получение набора тестов 126
3.2.6. Сравнительный анализ эффективности набора тестов 137
3.3. Результаты практической апробации метода для автоматизации тестирования программных библиотек макета комбинированной корреляционно-экстремальной системы навигации 139
3.3.1. Структура программной системы моделирования 140
3.3.2. Результаты тестирования программых библиотек наземной части КЭНС 142
3.4. Выводы 145
Заключение 147
Список литературы 150
Приложение 1 161
Приложение 2 172
Приложение 3 174
- Форматы спецификаций интерфейса программирования приложения
- Расширение унифицированной модели функциональными требованиями к интерфейсу программирования
- Разработка структуры данных для хранения унифицированной модели интерфейса программирования приложения
- Анализ влияния использования значений по умолчанию на качество набора тестов
Введение к работе
Актуальность темы исследования. В настоящее время необходимость систематизированного тестирования в промышленной разработке программного обеспечения (ПО) общепризнанна и неоспорима. Традиционные методы разработки тестов уже не могут обеспечить качественное тестирование современных программных систем. Однако в большинстве случаев тестируемое ПО связывают с наличием в нем графического интерфейса пользователя, которое служит медиатором, преобразующим тестовые сценарии в реальные входные воздействия на целевое приложение, и представляющим результаты в удобной для восприятия форме. Зачастую при этом остается без должного внимания целый класс ПО, предоставляющий доступ к своей функциональности лишь посредством интерфейса программирования.
Под интерфейсом программирования приложения (Application Programming Interface, API) понимается набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах. Детали реализации API при этом, как правило, скрыты. Примерами API могут служить библиотеки функций (COM DLL, .NET assembly), web-сервисы, встроенные средства программирования приложений (VBA в MS Office).
Тестирование API обладает рядом особенностей, которые необходимо учитывать при автоматизации. Среди них вьщеляются: отсутствие графической или иной оболочки, позволяющей осуществлять тестовые воздействия и получать результаты; необходимость генерации небольшого набора перспективных в плане поиска дефектов значений входных параметров интерфейсных функций для выполнения тестов за разумное время; необходимость построения последовательностей вызовов в случаях, когда невозможно независимое тестирование отдельных функций интерфейса.
Среди существующих подходов к автоматизации тестирования программных интерфейсов вьщеляются метод разработки специализированных программ тестирования и тестирование на основе модели ПО. Использование специализированных программ тестирования затруднительно для приложений с большим количеством интерфейсных функций, поскольку при изменениях в интерфейсе возрастает трудоемкость модификации программы тестирования. Кроме того, код программы тестирования может быть достаточно сложным, возникает проблема необходимости верификации самой программы тестирования. Существующие подходы к автоматизации тестирования на основе специализированной модели ПО требуют ручного описания модели, разработки процедур преобразования модельных операций в реальные тестовые вызовы, создания итераторов входных воздействий. Указанные операции являются трудоемкими, что увеличивает время тестирования.
Таким образом, разработка метода автоматизации тестирования интерфейса программирования приложения, обеспечивающего на основе унифицированной модели интерфейса сокращение трудоемкости тестирования за счет уменьшения количества вводимых вручную строк является актуальной проблемой.
Объектом исследования являются методы автоматизации тестирования интерфейса программирования приложения на основе модели, а также программные средства автоматизации тестирования на основе программных интерфейсов.
Целью диссертационной работы является сокращение трудоемкости тестирования интерфейса программирования приложения.
Научная задача состоит в создании метода и алгоритмов универсальной среды тестирования программных интерфейсов, обеспечивающей сокращение трудоемкости тестирования API-интерфейсов.
Для достижения поставленной цели в диссертации решаются следующие задачи:
Анализ известных подходов к автоматизации тестирования интерфейса программирования приложения.
Разработка унифицированной модели интерфейса программирования приложения с расширением для формальных функциональных требований.
Разработка алгоритма автоматического построения унифицированной модели интерфейса на основе спецификации.
Разработка алгоритма обхода модели для генерации тестов.
Разработка алгоритма оптимизации тестов.
Разработка совокупности программных средств, объединенных в универсальную среду тестирования программных интерфейсов приложений.
Выполнение экспериментальных исследований и апробации разработанного метода.
Методы исследования. При выполнении данной работы использовался аппарат теории графов, теории моделирования систем, теории формальных спецификаций, методов тестирования на основе модели программного обеспечения.
Достоверность и обоснованность полученных в диссертации результатов подтверждается разработкой действующей универсальной среды тестирования программных интерфейсов APITest, проведенными экспериментальными исследованиями, а также апробацией научных результатов на международных и всероссийских конференциях.
Научная новизна результатов диссертационной работы определяется тем, что в ней:
Выполнена модификация метода контрактных спецификаций, заключающаяся во введении спецификаций исключения, позволяющих выполнить проверку контракта в момент генерации исключения интерфейсной функции, а также во введении предикативных спецификаций, позволяющих определять разные контракты в одной точке теста.
Разработана унифицированная модель интерфейса программирования, отличающаяся возможностью представления структуры интерфейса и
функциональных требований на основе модифицированного метода контрактных спецификаций в рамках единого типа данных.
Разработан метод автоматизации тестирования интерфейса программирования приложения, отличающийся автоматизацией процесса построения модели API-интерфейса с расширением функциональными требованиями по его спецификации и этапа генерации кода тестов.
Впервые разработан алгоритм построения унифицированной модели, отличающийся наличием процедур разбора спецификации интерфейса, заданной в терминах IDL, UML или .NET-библиотеки.
Разработан алгоритм обхода унифицированной модели интерфейса программирования, выполняющий автоматическую генерацию тестов в виде последовательности вызовов интерфейсных методов и условий проверки функциональных требований, отличающийся наличием параметров обхода, позволяющих гибко управлять степенью тестового покрытия модели.
Разработан алгоритм оптимизации тестов, отличающийся от известных способом выполнения оптимизации путем статического анализа тестового набора без изменения степени тестового покрытия.
Результаты, выдвигаемые на защиту:
Метод автоматизации тестирования интерфейса программирования приложения на основе универсальной среды APITest.
Алгоритм автоматического построения унифицированной модели интерфейса программирования на основе разбора спецификации.
Алгоритм обхода унифицированной модели для генерации тестов с параметрами управления степенью тестового покрытия модели.
Алгоритм оптимизации тестов на основе статического анализа.
5) Универсальная среда тестирования программных интерфейсов APITest.
Практическая ценность работы. В диссертации решена важная научная
задача, заключающаяся в создании метода и алгоритмов автоматизации тестирования интерфейсов программирования приложений, позволяющего в сравнении с другими методами тестирования API-интерфейсов в 1,5-1,8 раза сократить временные затраты за счет автоматического построения модели на основе спецификации API и генерации тестов с трансляцией в код без снижения качества тестового набора.
Практическую ценность представляют разработанные программные модули разбора спецификаций API, построения модели API, обхода модели, генерации тестов, оптимизации тестов, объединенные в универсальную среду тестирования программных интерфейсов APITest.
Данная работа представляет интерес для ее использования в одном из этапов совершенствования и повышения эффективности производственных процессов разработки программного обеспечения за счет сокращения ресурсозатрат, увеличения качества тестирования, снижения итоговой стоимости разработки. Программная реализация разработанного метода может быть полезна как сторонним организациям, которые занимаются тестированием программных
компонент с закрытым кодом, так и разработчикам ПО для самостоятельной верификации разрабатываемых программных классов.
Внедрение результатов работы. Результаты работы использованы при выполнении х/д работы №12405-8/533 «Исследования и разработка методов и средств высокоточного определения местоположения маневренных объектов по стереоскопическим изображениям местности и топогеодезической информации» (шифр «Аксиома-ЮФУ») и в учебном процессе по курсу «Метрология и качество программного обеспечения».
Апробация работы. Результаты работы докладывались и обсуждались на Международных, Всероссийских и региональных научно-технических конференциях, в том числе на:
1) II Международной научно-практической Интернет-конференции
«Инновационные подходы к применению информационных технологий в
профессиональной деятельности», Белгород, 2010.
2) VII Всероссийской научно-практической конференции студентов,
аспирантов и молодых ученых "Молодежь и современные
информационные технологии", Томск, 2009.
VII Всероссийской конференции студентов, аспирантов и молодых ученых «Технологии Microsoft в теории и практике программирования», Таганрог, 2010.
II Ежегодной Всероссийской научно-практической конференции с международным участием «Перспективы развития информационных технологий». Новосибирск, 2010.
Всероссийской научно-технической конференции аспирантов, студентов и молодых ученых "Информатика и вычислительная техника - 2010". Ульяновск, 2010.
Личный вклад автора. Все научные результаты получены автором лично.
Публикации. По результатам диссертации опубликовано 12 печатных работах, среди них 7 статей (2 статьи в журналах перечня ВАК) и 1 свидетельство об официальной регистрации программы для ЭВМ №2010617638 «Программа автоматизации функционального тестирования интерфейсов программирования приложений APITest».
Структура и объем диссертации. Материал основной части диссертационной работы изложен на 149 страницах машинописного текста. Диссертация состоит из введения, 3 разделов, заключения, списка литературы из 102 источников, содержит 49 рисунков и приложения на 17 страницах.
Форматы спецификаций интерфейса программирования приложения
Тестирование программного обеспечения является сравнительно молодой отраслью науки. История тестирования программного обеспечения отражает эволюцию разработки самого программного обеспечения. Днем рождения этого направления сферы информационных технологий можно считать 9 сентября 1945 года. Именно в этот день был официально зарегистрирован первый в истории дефект. Ученые Гарвардского университета тестировали вычислительную машину Mark II Aiken Relay Calculator и нашли мотылька, застрявшего между контактами электромеханического реле. Извлеченное насекомое было вклеено в технический дневник с сопроводительной надписью: "First actual case of bug being found" [6, 7].
После этого в течение длительного времени разработка программного обеспечения уделяла основное внимание крупномасштабным научным и военным программам, связанным с системами корпоративных баз данных, системами управления объектами, алгоритмами обработки данных. Тестовые сценарии записывались на бумагу. С их помощью проверялись целевые потоки управления, вычисления сложных алгоритмов и манипулирование данными. Окончательный набор тестовых процедур мог эффективно протестировать всю систему полностью. Тестирование обычно начиналось лишь после завершения плана-графика проекта и выполнялось тем же персоналом.
Появление настольных компьютеров открыло новую эру в сфере информационных технологий. Пакетная обработка данных вытеснялась системами, работающими в реальном времени под управлением стандартной операционной системы. Теперь рабочие потоки могли вызываться в любом порядке. Эта особенность привела к появлению огромного числа процедур тестирования, способных поддержать бесконечное число перестановок и сочетаний.
В это же время начали развиваться технологии создания программного обеспечения по принципу распределенной реализации. Такой подход означает, что при разработке программного модуля допускается использование объектов, уже реализованных ранее. При этом объекты хранятся в двоичном виде, а не в виде исходного кода. Это позволяет добиться повторного использования объектов, реализация которых скрыта, а доступен лишь интерфейс их программирования. К подобным технологиям можно отнести DLL (Dynamic linked library), COM (Component Object Model), COM+ [8, 9]. Подобные технологии и привели к появлению задачи тестирования приложений, предоставляющих лишь интерфейс программирования объектов.
Одной из основных особенностей современной разработки программного обеспечения стало появление клиент-серверных приложений, в том числе и приложений, работающих в сети Интернет. Теперь библиотеки реализованных объектов могли располагаться не только на локальной, но и на удаленной рабочей станции с доступом к ним через сеть. Эта идея нашла отражение в технологиях DCOM (Distributed COM), CORBA (Common Object Request Broker Architecture), .NET [10, 11].
В связи с этим усложнились работы по тестированию. Клиент-серверная архитектура включает в себя три основных компонента: клиент, сервер и сеть. Связность этих компонент увеличивает вероятность и число возможных ошибок. Возникает ситуация, когда процедуры тестирования не способны выполнить все возможные функциональные сценарии. Следовательно, тестировщики должны сосредоточить свою работу в той части приложения, которая выполняет основные системные требования. Стремительное увеличение числа тестовых сценариев и все возрастающая сложность их применения привели к осознанию необходимости внедрения автоматизации в процесс тестирования программного обеспечения. Наиболее привлекательной для автоматизации стала возможность записи и последующего автоматического воспроизведения сценариев навигации пользователя по экрану. Средства автоматизации тестирования, реализующие эту функциональность, появились на рынке и постепенно завоевали позиции. Возможности подобных программных продуктов постоянно развивались. Они включали в себя тестирование пользовательского графического интерфейса, совместимости требований, скорости загрузки, покрытия кода, web-интерфейса, сетевых коммуникаций, утечки памяти и т.д. [12].
При всем многообразии функциональности средств автоматизации тестирования не удается качественно реализовать генерацию тестов - эта работа должна выполняться вручную на этапе проектирования тестов. Решение данной проблемы предполагает появление нового поколения инструментов, использующих подход к тестированию на основе модели ПО.
Тестирование программного обеспечения по своей сути является процессом поиска ошибок в реализации программы. Естественно, хотелось бы организовать тестирование таким образом, чтобы выявить все ошибки в программе. Можно утверждать, что для подтверждения того факта, что программа абсолютно свободна от ошибок, необходимо: - Подготовить все возможные наборы входных данных, включая некорректные. - Выполнить программу на всех возможных перестановках и сочетаниях входных данных. - Проанализировать все выходные данные и установить, что каждый тестовый выходной набор соответствует правильному.
Однако для реализации подобного тестирования потребовалось бы колоссальные временные, финансовые и человеческие ресурсы. Легко понять, что даже для небольших программ с двумя-тремя входными параметрами количество тестовых случаев может исчисляться миллионами комбинаций. Например, для простейшей программы, имеющей три входных параметра - символа латинского алфавита - имеется более 16 миллионов комбинаций ввода с учетом негативных тестов. Даже если представить, что специалист по тестированию способен проверять одну комбинацию в секунду, ему понадобится более 190 суток беспрерывной работы на исчерпывающее тестирование! [13]
Тестирование еще более осложняется, когда программа работает с оперативной памятью, аппаратными приборами, сетью, базами данных, где результат работы на некотором наборе входных данных зависит от данных, поступивших в программу ранее.
Эти примеры доказывают, что исчерпывающее тестирование программного обеспечения за разумное время невозможно. Следовательно, невозможно выявить все ошибки в реализации программы. Утверждение о невозможности полной проверки сложного ПО является фундаментальным в теории тестирования. Этот факт заставляет тестировщика из всего многообразия выбирать некоторое мизерное подмножество тестовых входных данных. Но, чтобы обнаружить как можно большее число дефектов программы, этот выбор должен делаться не случайным образом, а на основании некоторых стратегий. Эта проблема и явилась основным толчком к разработке применяемых сегодня методов тестирования программного обеспечения.
Расширение унифицированной модели функциональными требованиями к интерфейсу программирования
Инструменты, поддерживающие UniTesK, — предоставляют пользователям библиотеки базовых итераторов значений простых типов, которые могут быть непосредственно использованы для генерации тестовых воздействий, а могут быть скомпонованы в более сложные генераторы. Для уменьшения затрат времени на тестирование сгенерированные тестовые воздействия можно фильтровать, отбрасывая те из них, которые не увеличивают достигнутый уровень покрытия. Фильтры для этого генерируются автоматически из определения критерия тестового покрытия.
Для автоматического построения последовательности тестовых воздействий используются модели тестируемой системы в виде конечных автоматов (КА). Тестовая последовательность строится как последовательность обращений к целевым операциям, соответствующая некоторым путям в графе переходов КА, например, обходу всех переходов автомата. Поскольку конечно-автоматная модель используется только для построения тестовой последовательности, а не для проверки корректности поведения целевой системы, осуществляемой оракулами, можно не задавать автомат полностью, а лишь указать способ идентификации его состояний и способ итерации входных воздействий в зависимости от текущего состояния. Представленные таким, неявным, образом автоматы удобно задавать в виде тестов. Часто тест можно сгенерировать автоматически на основе спецификации целевых операций, способа итерации наборов их аргументов и стратегии тестирования.
Стратегия тестирования определяет, когда тестирование можно заканчивать. UniTesK предлагает при этом опираться на достигнутый уровень тестового покрытия в соответствии с некоторым критерием покрытия. Из структуры спецификаций, разработанных в соответствии с технологией UniTesK, можно автоматически извлечь несколько таких критериев. Пользователь имеет возможность гибко управлять этими критериями или определять свои собственные.
Чтобы обеспечить более -удобную -интеграцию в существующие процессы разработки, UniTesK может использовать для представления спецификаций и тестов расширения широко используемых языков программирования. Расширения построены на основе единой системы понятий: описание медиаторов, спецификационных функций, пред- и постусловий и др. Такое представление делает спецификации и сценарии понятнее для обычного разработчика ПО и позволяет сократить срок освоения основных элементов технологии до одной недели. Сразу после этого обучения разработчик тестов может использовать UniTesK для получения практически значимых результатов [58]. Кроме того, использование расширений известных языков программирования вместо специального языка значительно облегчает интеграцию тестовой и целевой систем, необходимую для проведения тестирования. На данный момент в ИСП РАН разработаны инструменты, поддерживающие работу по технологии UniTesK с использованием расширений Java, С и С#.
Для определения связи между спецификациями и конкретной реализацией используются специальные компоненты - медиаторы, которые могут осуществлять описанные пользователем преобразования интерфейсов. Использование медиаторов открывает дорогу следующим возможностям: - Спецификации могут быть гораздо более абстрактными, чем реализация, и, тем самым, более близкими к естественному представлению функциональных требований. - Спецификации остаются актуальными для нескольких версий целевого ПО. Для переработки тестового набора под новую версию, в которой изменились внешние интерфейсы, но не их функции, достаточно заменить медиаторы. Во некоторых такая замена может быть автоматизирована. Основная идея архитектуры теста UniTesK состоит в том, что разрабатывается набор компонентов, пригодный для тестирования различных видов ПО с использованием разных стратегий тестирования. Она нацелена на решение двух основных проблем: - Невозможно полностью автоматизировать разработку тестов, поскольку критерии корректности целевого ПО и стратегии проведения тестирования может предоставить только человек. - Выбранная архитектура должна совмещать единообразие с возможностью тестирования ПО, относящегося к разным предметным областям, и в проектах, решающих различные задачи. Архитектура теста UniTesK [61] основана на следующем разделении задачи тестирования на подзадачи: - Задача проверки корректности поведения системы в ответ на единичное воздействие. - Задача создания единичного тестового воздействия. - Задача построения последовательности таких воздействий, нацеленной на достижение нужного покрытия. - Задача установления связи между тестовой системой, построенной на основе абстрактного моделирования, и конкретной реализацией целевой системы. Для решения каждой из этих задач предусмотрена технологическая поддержка. Рисунок 1.6 представляет основные компоненты архитектуры теста, используемой UniTesK. Для проверки корректности реакции целевого ПО в ответ на одно воздействие используются тестовые оракулы. Поскольку генерация тестовых воздействий отделена от проверки реакции системы на них, нужно уметь оценить поведение системы при достаточно произвольном воздействии. Для этого не подходит распространенный способ получения оракулов, основанный на вычислении корректных результатов для фиксированного набора воздействий. Используются оракулы общего вида, основанные на предикатах, связывающих воздействие и ответную реакцию системы.
Разработка структуры данных для хранения унифицированной модели интерфейса программирования приложения
Унифицированная модель интерфейса программирования приложения, построенная при помощи описанного в разделе 2.2 алгоритма, отражает лишь статическую структуру интерфейса. В ней отражены связи между объектами и действиями, но отсутствует информация о конкретных значениях параметров интерфейсных методов, условия выполнимости методов, процедуры проверки корректности работы методов. Совокупность такой информации описывают функциональные требования к интерфейсу программирования.
Каждый из объектов унифицированной модели может быть либо создан напрямую (в графе модели отсутствуют входящие дуги), либо получен из другого объекта при выполнении некоторого действия. Если определить способ конструирования для каждого из создаваемых напрямую объектов, тогда все остальные объекты интерфейса могут быть получены путем выполнения цепочки интерфейсных методов.
Создаваемые объекты интерфейса могут быть как простыми, так и сложными. Для простых объектов предлагается определять домен значений, которые может принимать данный объект. В дальнейшем алгоритм обхода модели будет выбирать одно, несколько или перебирать все значения домена при генерации тестов, подставляя их в качестве параметров в действия. В общем случае ничего не известно о том, как интерфейсный метод обрабатывает данные. В связи с этим тесты должны строиться на основе стратегии «черного ящика». Тогда наиболее перспективными кандидатами в домен выглядят значения, полученные при помощи методик разбиения по категориям [19] и анализа граничных значений [20].
Как правило, для стандартных типов данных языков программирования часть полученных таким образом значений повторяется независимо от семантики простого объекта. Например, для целых чисел «перспективными» в плане тестирования являются такие значения, как ноль, минимальное отрицательное число, максимальное отрицательное число, минимальное положительное число, максимальное положительное число. Эти значения могут быть заранее определены в шаблоне, а их добавление в домен тестовых значений объекта возможно автоматически. В рамках данной диссертационной работы были проанализированы распространенные атомарные типы данных языка программирования С#. При помощи методик разбиения по категориям и анализа граничных значений были сформированы рекомендации по выбору значений таких типов данных. Результаты представлены в таблице 2.1. Полученные домены могут быть использованы для других языков высокого уровня (например, C++, Java, Basic и другие), если типы данных такого языка совпадают с приведенными в таблице 2.1 данными.
Если существуют «перспективные» значения, зависящие от семантики объекта, они должны быть добавлены в домен конкретного объекта вручную. В данном случае невозможно извлечь знания о поведении интерфейсного метода из его спецификации, таким знанием обладает эксперт в предметной области. Например, для функции определения числа на простоту в домен могут быть добавлены типичное (не граничное) простое число и типичное составное число. Получение сложных объектов описывается способом их создания -конструктор, фабрика объекта и т.д. В этом случае определен не домен значений, а домен способов создания. В шаблоне заранее может быть определен пустой конструктор как типичный способ создания сложного объекта.
Домены значений позволяют определять параметры интерфейсных методов, но не задают функциональные требования и ограничения. Для их описания использует подход, основанный на контрактных спецификациях [59, 75, 76]. Для формализации функциональных требований к интерфейсным методам было предложено использовать подход на основе контрактных спецификаций. Контрактные спецификации и процесс проектирования на их основе (DbC, Design-by-Contract) были введены Бертраном Майером (Bertrand Meyer) в 1986 году в контексте разработки программного обеспечения. Центральная метафора подхода заимствована из бизнеса. Компоненты системы взаимодействуют друг с другом на основе взаимных обязательств (obligations) и выгод (benefits). Если компонент предоставляет окружению некоторую функциональность, он может наложить предусловие (precondition) на ее использование, которое определяет обязательство для клиентских компонентов и выгоду для него. Компонент также может гарантировать выполнение некоторого действия с помощью постусловия (postcondition), которое определяет обязательство для него и выгоду для клиентских компонентов.
Контрактные спецификации, с одной стороны, достаточно удобны для разработчиков, поскольку хорошо привязываются к архитектуре системы, с другой стороны, в силу своего представления стимулируют усилия по созданию независимых от реализации критериев корректности целевой системы. Основное же их преимущество состоит в том, что они позволяют автоматически строить тестовые оракулы, проверяющие соответствие поведения целевой системы требованиям, описанным в спецификациях.
Контрактные спецификации хорошо зарекомендовали себя при использовании их в системах автоматизации тестирования. Именно этот подход к формализации спецификаций применяется в рассмотренных в разделе 1.4 технологиях AsmL и UniTESK [77, 78, 79].
В контексте метода автоматизации функционального тестирования интерфейса программирования приложения контрактные спецификации (пред- и постусловия) имеют вид утверждений (assert). Утверждение представляет собой логическое выражение. Если утверждение истинно, реализованная функциональность метода не противоречит заявленной. Предусловие накладывается на действие и проверяется перед его выполнением. Действие будет выполнено, если все его предусловия разрешают выполнение. Постусловие также накладывается на действие, но проверяется после его выполнения. Если постусловие истинно, работа интерфейсного метода соответствует заданному этим условием функциональному требованию.
Анализ влияния использования значений по умолчанию на качество набора тестов
В НИР "Аксиома-ЮФУ" рассматриваются вопросы создания алгоритмов и программно-аппаратных средств, нацеленных на повышение точности программно-навигационного обеспечения летательного аппарата (ЛА) за счет комплексного использования методов высокоточного определения их координат по многозональным стереоскопическим изображениям местности и топогеодезической информации. В рамках этапа НИР осуществлена разработка макетного образца-корреляционно-экстремальной навигационной системы (КЭНС) [101]. Программное обеспечение (ПО) макетного образца КЭНС состоит из трех компонент: 1) ПО бортовой части макетного образца КЭНС, предназначенное для записи данных аэрофотосъемки в реальном времени во время полета; 2) дополнительное (промежуточное) ПО обеспечения доступа, контроля, визуализации, комплексирования и преобразования данных аэрофотосъемки; 3) ПО наземной части макетного образца КЭНС, предназначенное для обработки данных аэрофотосъемки. Для тестирования интерфейсов программных библиотек наземной части макета КЭНС был применен разработанный в рамках данной диссертационной работы метод автоматизации тестирования интерфейса программирования приложения, а также разработанное программное средство APITest. В качестве ПО наземной части макетного образца КЭНС была использована система моделирования, ранее разработанная для математического моделирования и экспериментальных исследований разработанных алгоритмов восстановления рельефа местности и определения местоположения ЛА [102]. Программная система моделирования построена с использованием принципа подключаемых программных библиотек ("плагинов"), реализующих основную функциональность. Любой значимый модуль системы оформляется в виде отдельного программного компонента, имеющего универсальный программный интерфейс. Общая структура программной системы представлена на рисунке 3.16. В приведенной структуре ядро программной системы предоставляет универсальный программный интерфейс для подключаемых модулей, позволяющий им осуществлять необходимые операции. Взаимодействие между модулями ограничивается только обменом данными, который построен с использованием технологии "классной доски" (whiteboard). Сущность данного принципа заключается в использовании единого централизованного хранилища данных, с которым работают программные модули. Модуль загрузки изображений (SourcePlugin) используется для загрузки исходных изображений в программную систему. Модуль сшивки многозональных изображений (JoinPlugin) предназначен для выполнения поиска значений параметров аффинных преобразований поворота относительно геометрического центра множества точек и параллельного переноса координат точек кадров отснятой последовательности изображений для обеспечения безориентирной сшивки -соответствующих многозональных изображений. Модуль автоматического восстановления рельефа (TerrainPlugin) служит для воссоздания рельефа по парам перекрывающихся фотоснимков. Модуль корреляции рельефа (CorrPlugin) используется для корреляции полученных из стереопар восстановленных регионов ландшафта с эталонной картой высот рельефа. Модуль определения положения ЛА (LocatorPlugin) используется для определения координат ЛА для каждого восстановленного региона ландшафта (т.е. для каждой стереопары), а также погрешности их нахождения по сравнению с эталонными. Библиотека общих функций и объектов взаимодействия (CommonDll) содержит декларации и реализации используемых подключаемыми модулями объектов. Функциональность ПО наземной части КЭНС, оформленная в виде отдельных программных библиотек, позволяет провести их независимое тестирование. Программые библиотеки наземной части КЭНС, оформленные в виде сборок .NET assembly, были поставлены для тестирования в бинарном виде без предоставления исходного кода. Для каждой библиотеки была построена модель программного интерфейса, который она предоставляет. Характеристики полученных моделей API представлены в таблице 3.29. Из таблицы видно, что метод характеризуется небольшим временем построения модели. Построенные модели API были расширены функциональными требованиями к методам интерфейсов. Затем был выполнен обход моделей с настройками алгоритма обхода «значения параметров» - «перебрать все», «порождающие действия» - «перебрать все». Выбор параметров обусловлен наличием достаточных вычислительных ресурсов для генерации и выполнения тестов, а также требованием обеспечения полного покрытия моделей интерфейсов. Полученные количественные характеристики данного этапа представлены в таблице 3.30.
Трудоемкость расширения модели функциональными требованиями пропорциональна объему добавленных контрактных условий и составляет 13-19 условий в час. Генерация значительного числа тестов для некоторых библиотек обусловлена настройками алгоритма обхода модели в совокупности с наличием-в интерфейсах методов с большим (от 4 до 7) количеством параметров. При этом время генерации остается приемлемым для практического применения метода.
В таблице 3.31 представлены численные характеристики заключительного этапа тестирования модулей КЭНС, заключающего в трансляции, выполнений тестов и анализе результатов. Подтверждена эффективность с точки зрения скорости работы алгоритма трансляции. Полученные тесты были выполнены в среде автоматизации модульного тестирования NUnit. Время выполнения тестов зависит только от внутренней реализации интерфейсных функций. В результате тестирования было обнаружено 3 дефекта реализации. Все найденные дефекты имеют низкую степень критичности для работы макета КЭНЦ, поскольку связаны с обработкой невалидных значений параметров интерфейсных функций. Проведенное тестирование подтвердило высокое качество программных библиотек макета. В таблице 3.32 представлено сравнение по затратам временных ресурсов для тестирования модулей КЭНС с использованием традиционного подхода ручной разработки тестов, использовавшегося ранее, и с применением предложенного метода автоматизации тестирования. При оценке затрат не учитывалось время на выполнение тестов, поскольку в этом случае необходимы лишь вычислительные ресурсы при минимальном участии тестировщика. Сравнение показывает, что применение разработанного метода для автоматизации функционального тестирования программных библиотек макета корреляционно-экстремальной системы навигации позволила сократить временные затраты на 65-75% за счет автоматизации этапов построения модели, разработки и кодирования тестов. 1) Разработаны программные средства универсальной среды тестирования программных интерфейсов APITest, содержащие модули разбора спецификаций API, построения модели API, обхода модели, генерации тестов, оптимизации тестов. 2) Предложена методика проведения экспериментальных исследований разработанного метода автоматизации тестирования интерфейса программирования приложения. 3) Проведенные экспериментальные исследования влияния параметров обхода модели на качество тестов позволяют сделать вывод о предпочтительном использовании комбинации параметров «порождающее действие - перебрать все», «значения параметров -выбрать любое» для практического применения. Комбинация параметров «порождающее действие — перебрать все», «значения параметров - перебрать все» может-быть использована для получения наилучших результатов в условиях наличия достаточных вычислительных ресурсов.
