Your SlideShare is downloading. ×
Predzazhita 2009 v16
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Predzazhita 2009 v16

440
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
440
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Здравствуйте. Меня зовут Кичигин Дмитрий, я работаю под научным руководством Александра Константиновича Петренко, тема моей работы называется «Метод редукции тестового набора для интеграционного тестирования».
  • Областью моего исследования является регрессионное интеграционное тестирование программного обеспечения. Начну с определений: Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного и / или аппаратного обеспечения. Регрессионное тестирование – повторное тестирование системы или компонента с целью убедиться что внесенные изменения не привели к неожидаемым эффектам, и что система или компонент продолжает удовлетворять своей спецификации. Заметим, что основным отличием регрессионного тестирования от тестирования, проводящегося во время разработки ПО, является наличие существующего набора тестов. Также заметим, что п ри переходе к интеграционному тестированию предполагается, что модульное тестирование, в основном, завершено. Это позволяет сфокусироваться на ошибках взаимодействия модулей. Поэтому д ля проведения интеграционного тестирования используются специализированные интеграционные тесты, целью которых является проверка взаимодействия модулей. Разработка таких тестов является достаточно дорогой процедурой и если при разработке ПО от нее никуда не деться, то на этапе сопровождения, для проведения регрессионного интеграционного тестирования, можно воспользоваться существующим набором тестов, изначально созданным для модульного или системного тестирования. Такой подход позволяет сэкономить ресурсы, однако является неэффективным : так как используемые в этом случае регрессионные тесты не создавались специально для интеграционного тестирования, на практике только часть таких запускаемых тестов тестирует взаимодействие между интегрируемыми модулями, а оставшаяся часть тестов работает «вхолостую», лишь потребляя ресурсы. Например, < обращаясь к диаграмме > допустим у нас есть ПО с несколькими модулями и изображенными связями между ними... < следующий слайд > ...где изменился один модуль... < следующий слайд > ... В этом случае для нас важны тесты, которые затрагивают взаимодействия с измененным модулем, т.е. лишь 4 взаимодействия из 8-ми. Вследствие этого возникает проблема отбора тестов для регрессионного тестирования таким образом, чтобы запускать только те тесты, которые проверяют взаимодействия между измененными модулями Заметим, что в случае современного программного обеспечения, нужно уметь работать и с текстовыми и с объектными модулями. Причем объектные модули вносят определенные сложности, такие как отсутствие исходного текста, но возможность работы с ними является важной. Мы учтем этот момент далее в презентации.
  • ...где изменился один модуль...
  • ... < заканчивая пример > ... В этом случае для нас важны тесты, которые затрагивают взаимодействия с измененным модулем, т.е. лишь 4 взаимодействия из 8-ми. Вследствие этого возникает проблема отбора тестов для регрессионного тестирования таким образом, чтобы запускать только те тесты, которые проверяют взаимодействия между измененными модулями Заметим, что в случае современного программного обеспечения, нужно уметь работать и с текстовыми и с объектными модулями. Причем объектные модули вносят определенные сложности, такие как отсутствие исходного текста, но возможность работы с ними является важной. Мы учтем этот момент далее в презентации.
  • Для решения проблемы отбора тестов используется подход, известный как редукция набора тестов, и заключающийся в выборе из исходного набора подмножества тестов, специально фокусирующегося на тестировании межмодульных взаимодействий. Редукция набора тестов ставит своей целью отбор набора тестов меньшего размера для тестирования выбранного взаимодействия между модулями, но при этом, желательно, с такой же, как и у исходного набора тестов, способностью обнаруживать интеграционные ошибки в выбранном взаимодействии. В контексте рассматриваемой задачи такая редукция позволяет: Отобрать тесты, концентрирующиеся на тестировании нужных взаимодействий Вследствие этого, уменьшить затраты на проведение регрессионого интеграционного тестирования.
  • Существующие методы редукции набора тестов используют метрики покрытия и заключаются в построении тестового набора меньшего размера, но эквивалентного исходному в терминах выбранной метрики . Заметим, что метрики покрытия делятся на 2 группы: основанные на спецификациях и на внутреннем устройстве программы , которые являются взаимодополняющими подходами. В данной работе рассматриваются метрик и основанные на внутреннем устройстве программы . Существующие методы проводят предварительный статический анализ исходного текста программы, затем инструментирование и динамический анализ выполнения программы на наборе тестов для сбора информации о достигнутом покрытии, по результатам которого происходит редукция набора тестов. За счет этого, они позволяют хорошо сокращать наборы тестов, но обладают рядом существенных недостатков, ограничивающих их использование для современного программного ообеспечения, характеризующегося большим объемом и гетерогенностью внутреннего устройства, включая использование разнообразных языков программирования, внутренних компонент и сред выполнения: Во первых, они непрактичны для использования для программного обеспечения большого объема. Инструментирование исходного кода большого количества модулей, есть очень сложная и затратная процедура. Во вторых, невозможность применения для тестирования бинарных компонент. Примером таких компонент являются повторно используемые программные компоненты, которые разрабатываются независимыми разработчиками и поставляются без исходного кода в бинарном виде. Такие компоненты являются все более популярными при разработке современного ПО, и поэтому указанное ограничение является серьезным. Во третьих, опять вследствие применения анализа исходного кода, существующие методы сильно зависимы от конкретного языка программирования, и, также, сильно зависимы от среды выполнения и операционного окружения. «повышенные требования к адаптивности к различным языкам программирования и технологической простоте применения на разных платформах / средах» Вследствие этого, существующие методы, использующие метрики основанные на внутреннем устройстве программы, оказываются неадекватны требованиям задачи редукции набора тестов для интеграционного тестирования современного программного обеспечения. Это обстоятельство делает актуальной разработку новых методов, способных работать без доступа к исходному коду ПО, что обусловило цель данной работы, а именно -> переход к следующему слайду
  • а именно - > далее по тексту слайда Заметим, что в качестве полигона для экспериментов были выбраны системы, реализованные на языке С. Это было обусловлено широкой распространенностью таких систем и тем, что много важных, иногда критичных по безопасности систем написаны на С. Такой выбор существенно ограничил технические возможности реализации метода, так как современные ОО языки и средства их поддержки могли бы дать дополнительные возможности для реализации метода, тем не менее аспект практической вожности систем был определяющим при выборе полигона для реализации и экспериментов.
  • Перед описанием метода определим класс рассматриваемых взаимодействий и опишем используемое понятие интеграционной ошибки. В данной работе рассматриваются межмодульные взаимодействия удовлетворяющие следующим условиям: 1. Во-первых, рассматриваются попарные взаимодействия модулей типа “ вызывающий / вызываемый ”; 2. Во-вторых, взаимодействия осуществляются только через интерфейс функций, общих данных нет ; 3. И, наконец, взаимодействия осуществляются синхронно в одном потоке / процессе . Для обзора интеграционных ошибок воспользуемся классификацией предложенной в работе Delamaro . Данная классификация основывается на определении интеграционной ошибки как ошибки возникающей при передаче некорректного значения между модулями. Выделяются три типа ошибок: (Ошибка 1 типа) Во время вызова модуля G из модуля F , в модуль G передаются некорректные значения, что приводит к ошибке в этом модуле; (Ошибка 2 типа) В модуль G передаются некорректные значения, в результате модуль G также возвращает набор некорректных значений, которые приводят к ошибке в модуле F; (Ошибка 3 типа) В модуль G передаются корректные значения, но из G возвращаются некорректные значения, которые приводят к ошибке в модуле F после выхода из G . Заметим, что в данной классификации не предусматривается случай, когда в модуль G поступают корректные значения, но дефект в G приводит к ошибке до возвращения из G . В этом случае ошибка не является интеграционной, т.к. не связана с взаимодействием между F и G , и должна была быть обнаружена на предыдущем этапе модульного тестирования.
  • В результате проведенной работы был предложен новый метод редукции набора тестов. Ключевым отличием данного метода редукции от методов, реализующих традиционный подход, является отсутствие этапа статического анализа исходного кода программного обеспечения. За счет этого метод не требует доступа к исходному коду интегрируемых модулей ПО. В остальном метод использует некоторые идеи существующих методов, и состоит из двух этапов: На первом этапе производится запуск ПО на наборе тестов и сбор информации о покрытии точек взаимодействия между интегрируемыми модулями. На втором этапе, исходя из собранной информации, осуществляется редукция набора тестов. Для проведения редукции используется эвристический алгоритм минимизации исходного набора тестов. Данный алгоритм базируется на предположении, что, если покрытие точек взаимодействия между интегрируемыми модулями на двух тестах одинаково, то возможности этих тестов по выявлению интеграционных ошибок между модулями также одинаковы. В частности, если тесты вообще не задействуют точки взаимодействия между модулями, то такие тесты не представляют пользы при тестировании взаимодействия. Метод основан на этих предположениях и состоит в «отсеивании» тех тестов, которые создают эквивалентные покрытия точек взаимодействия модулей. Описание метода состоит из трех частей: вначале мы опишем модель процесса взаимодействия, используемую для анализа покрытия точек взаимодействия; затем опишем способ сравнения моделей, который необходим для проведения редукции; в конце опишем алгоритм редукции, использующий модели взаимодействия и предложенный способ сравнения моделей для принятия решения какой тест следует «отсеять» из исходного тестового набора, а какой – нет.
  • В качестве точек взаимодействия принимаются интерфейсные функции интегрируемых модулей. Для описания модели введем несколько определений: Интерфейсной функцией называется функция, входящая в состав программного интерфейса модуля. Трассой взаимодействия между двумя модулями на тесте t называется последовательность вызовов интерфейсных функций вызываемого модуля при выполнении программного обеспечения на тесте t . Последовательностью функций длины K называется любая последовательность следующих друг за другом вызовов длины K , встречающаяся в трассе взаимодействия. Используя эти определения, модель поведения взаимодействия определяется как множество последовательностей вызовов интерфейсных функций длины К , выполненных во время тестирования взаимодействия. На данном рисунке представлен пример построения модели, для чего используется техника «скользящего окна». < Далее по рисунку > Замечание: в следствие ограниченности места на данном рисунке вызовы функций представлены только их именами. Тем не менее, при работе метода вызовы функций также включают значения переданных параметров .
  • В качестве способа сравнения моделей взаимодействия было предложено отношение, учитывающее значения параметров функций, переданных во время выполнения тестируемой программы на тесте, и определяемое с помощью формулы < на слайде > . Для данного выражения была сформулирована и доказана теорема о том, что оно является отношением эквивалентности, а именно, удовлетворяет свойствам рефлексивности, симметричности и транзитивности, в дальнейшем используемым в алгоритме редукции. Данная формула означает, что: Модели эквивалентны тогда и только тогда, когда эквивалентны множества последовательностей и, соответственно, сами последовательности вызовов функций Последовательности эквивалентны тогда и только тогда, попарно эквивалентны элементы, т.е. вызовы функций, которые эквивалентны, когда Совпадают имена функций Значения параметров эквивалентны В качестве отношений эквивалентности для значений параметров функций используются следующие отношения < на слайде > . Важным достоинством предложенного отношения эквивалентности является его адаптивность: оно позволяет задавать любые способы учета значений параметров интерфейсных функций, которые могут быть представлены в виде отношения эквивалентности. В частности, предложенное отношение эквивалентности можно использовать и для того, чтобы различать другие (т.е. не скалярные и не-указатели) типы параметров функций.
  • Алгоритм редукции заключается в последовательном переборе тестов из исходного набора, для каждого из которых принимается решение поместить данный тест в сокращенный набор или нет, и состоит из следующих шагов: На первом шаге выбирается очередной тест из исходного набора и на нем запускается тестируемое программное обеспечение. Во время работы программного обеспечения происходит сбор трассы взаимодействия интегрируемых модулей и построение модели их взаимодействия. Если построенная модель оказывается пустой, то это означает, что на данном тесте интегрируемые модули не взаимодействовали и, в таком случае, данный тест пропускается (не помещается в сокращенный набор тестов) и алгоритм возвращается к первому шагу. В противном случае, если построенная модель не пуста, то происходит ее сравнение с моделями, построенными на предыдущих итерациях алгоритма. В случае если обнаруживается модель, построенная на одном из предыдущих шагов и эквивалентная текущей модели, то это означает, что текущий тест повторяет один из предыдущих тестов в тестировании взаимодействия между модулями и, следовательно, также пропускается. Если же, наоборот, среди моделей, построенных на предыдущих шагах, не находится модели эквивалентной текущей, то такой тест заносится в сокращенный набор. После этого алгоритм возвращается к первому шагу. Когда исходный набор оказывается пройденным, алгоритм завершает свою работу и сокращенный тестовый набор считается построенным.
  • Описанный выше алгоритм редукции обладает вычислительной сложностью, максимальная оценка которой составляет < по слайду > где: T - количество тестов; K – длина последовательности интерфейсных функций; N - количество интерфейсных функций. При этом максимальный объем памяти, используемой для хранения модели в памяти компьютера, составляет < по слайду > . Для улучшения этих показателей была проведена оптимизация метода, заключающаяся в том, что табличное представление модели взаимодействия было заменено древовидным, при котором модель взаимодействия представляется в форме дерева, где каждой последовательности вызовов интерфейсных функций соответствует путь в дереве от корня до одного из листовых узлов. Такое представление позволило уменьшить сложность алгоритма примерно в N в степени K раз до < указать на слайде > , а максимальный объем используемой памяти примерно в К раз до < указать на слайде > .
  • Процесс регрессионного тестирования с использованием предложенного метода состоит из следующих этапов: На первом этапе осуществляется сбор трасс взаимодействий во время первоначального тестирования программного обеспечения на полном наборе тестов. Для сбора трасс учитываются вызовы всех интерфейсных функций всех модулей программного обеспечения. На втором этапе, перед регрессионным тестированием взаимодействий измененных модулей, происходит редукция набора тестов которая состоит из следующих шагов: Сначала происходит фильтрация трасс чтобы оставить только вызовы функций измененных модулей. Эта фильтрация производится инженером, проводящим тестирование, на основе списка измененных модулей < и модулей, вызываемых измененными > . После этого проводится редукция исходного набора тестов. Во время проведения редукции, метод редукции осуществляет построение моделей взаимодействия, и использует их для сокращения исходного набора тестов; Замечание (не произносится, на случай вопросов) . Описанная методика регрессионного тестирования с применением предложенного метода редукции подразумевает участие инженера, в задачи которого входит определение интерфейсов измененных, либо вызываемых измененными модулями, модулей программного обеспечения и фильтрация трасс взаимодействий перед использованием метода редукции. Также в задачи инженера входит экспертная оценка анализируемых интерфейсов на предмет того, насколько отношения эквивалентности между значениями параметров, используемые в методе редукции, отражают фактическую логику использования значений параметров интерфейсных функций и, в случае необходимости, настройка метода редукции для анализа взаимодействий через такие интерфейсы. Таким образом, в случае, если по оценкам инженера, существующие отношения эквивалентности являются неадекватными конкретным интерфейсам, то может быть принято решении об использовании специализированных отношений эквивалентности. Напомним, что метод достаточно легко адаптируем для использования специальных отношений эквивалентности. Например, как было показано в предыдущем разделе для строковых параметров, хоть и представляющихся в языке Си в виде указателей, использование специализированного отношения эквивалентности может давать лучшие результаты.
  • Архитектура и схема работы экспериментальной системы редукции набора тестов выглядит следующим образом < слайд > . Система состоит из следующих компонент: Сенсор / Классификатор параметров в задачи которого входят: Регистрация вызовов интерфейсных функций во время работы программного обеспечения на тесте. Для этого используется механизм функций-оберток, предоставляемый линкером ld входящим в состав пакета Binutils ; Классификация параметров функций по классам эквивалентности согласно отношению эквивалентности, определенному в предложенном методе редукции; Результатом работы модуля является файл, содержащий трассу взаимодействий, который затем поставляется на вход модулю анализа взаимодействий. Модуль анализа взаимодействий - компонента, производящая анализ трасс взаимодействий, построение моделей взаимодействий и построение сокращенного набора тестов; Управляющая консоль - приложение Microsoft Windows ® позволяющая пользователю в визуальном режиме производить редукцию набора тестов. Работа экспериментальной системы состоит из следующих этапов: На первом этапе происходит запуск объекта тестирования на исходном тестовом наборе и сбор трасс взаимодействия интегрируемых модулей; После этого, трассы взаимодействия направляются на вход модулю анализа взаимодействий; Модуль анализа взаимодействий считывает трассы взаимодействий, строит модели взаимодействий соответствующие тестам из исходного набора тестов, и, в процессе обработки трасс, производит редукцию набора тестов. Можно не говорить : Нужно заметить, что реализация модуля анализа взаимодействий собирать трассы взаимодействий интегрируемых модулей за один проход, во время первоначального тестированияпрограммного обеспечения на исходном наборе тестов. При регрессионном интеграционном тестировании достаточно часто встречается ситуация, когда меняется не один, а сразу несколько модулей, что требует проверки нескольких разных взаимодействий между модулями. В этом случае, возможность единовременного сбора трасс взаимодействий на полном наборе тестов позволяет значительно сократить издержки при построении регрессионных наборов для последующих регрессионных тестирований разных взаимодействий.
  • < Начать свежим голосом > Для оценки основных характеристик метода и его сравнения с методами случайной редукции и редукции пустых трасс была проведена серия экспериментов. Основными характеристиками, по которым осуществляется анализ методов редукции, являются полнота, точность, эффективность и универсальность: Полнота отражает меру отбора тестов, способных обнаруживать ошибки, появившиеся после модификации программного обеспечения. Т.е. Те на которых результат выполнения изменённой программы отличен от результата выполнения исходной программы. Метод, полный на 100%, называется безопасным. Точность измеряет способность метода избегать выбора тестов, неспособных обнаруживать ошибки. Точный метод отбирает только те тесты, на которых результат выполнения измененной программы отличается от результата выполнения первоначальной программы. Чем менее точен метод, тем больше лишних тестов выбрано и тем ближе объём выбранного набора к объёму исходного набора тестов. Эффективность отражает оценку вычислительных затрат на работу метода редукции. Для оценки затрат в основном используется объем используемой памяти и время работы метода. Универсальность отражает способность метода к применению в широком диапазоне ситуаций, встречающихся на практике. Для проведения экспериментов было выбрано взаимодействие между GNU Assembler и стандартной библиотекой языка Си, осуществляемое через подмножество функций библиотеки, реализующих операции ввода/вывода и объявленных в файле stdio . h . Использовались версии ассемблера GNU Assembler 2.17 и 2.18. В качестве существующего набора регрессионных тестов был взят набор, входящий в состав GNU Assembler .
  • Для измерения и оценки точности и полноты предложенного метода, и его сравнения с методами случайной редукции и редукции пустых трасс, использовались к оэффициент сокращения набора и коэффициент обнаружения ошибок. Предложенный метод оказался более точным чем метод редукции пустых трасс: коэффициент сокращения набора для предложенного метода в среднем составил 52 %, что на 42% выше аналогичного показателя для метода редукции пустых трасс. В то же время, хотя предложенный метод и не является безопасным, тем не менее, метод обнаружил все ошибки, обнаруживаемые исходным набором тестов, что совпало с результатом для метода редукции пустых трасс и на 20% превысило результат метода случайной редукции. Таким образом, результаты показали что предложенный метод не уступил методам случайной редукции и редукции пустых трасс, а по совокупности характеристик и превзошел их.
  • Для оценки универсальности метода был проведен эксперимент, проверяющий адаптируемость метода для учета параметров других типов данных (т.е. не скалярных и не указателей). Напомним, для адаптации метода для учета значений параметров других типов данных необходимо предложить отношение эквивалентности для таких параметров, и встроить его в отношение эквивалентности между моделями. Сам метод при этом менять не надо. Для проведения эксперимента в качестве примера выбран строковый тип параметров и была построена модификация метода, где в дополнение к скалярным параметрам и указателям также учитывались значения строковых параметров. Адаптация метода включала два шага: 1. Было предложено отношение эквивалентности между строками, определенное как отношение равенства между их длинами. Заметим, задание отношения экивалентности экивалентно разбитию множества значений на непересекающиеся классы эквивалентности. 2. Модификация экспериментальной системы. Для учета нового отношения эквивалентсности достаточно поменять лишь один компонент, а именно классификатор параметров. Данный классификатор отображает значения параметров в классы эквивалентности согласно предложенному отношению эквивалентности. После таких шагов мы получаем новую систему, которая в дополнение к скалярным параметрам и указателям учитывает значения строковых параметров.
  • Для сравнения характеристик метода до и после адаптации была проведена серия экспериментов, где тестировалось взаимодействие, большинство функций которого содержало строковые параметры. Результаты данного эксперимента подтвердили хорошую адаптируемость метода. В результате проведения адаптации коэффициент обнаружения ошибок значительно повысился и составил 100%, т.е. сокращенные тестовые наборы обнаруживали столько же ошибок, сколько и исходные наборы. В то же время коэффициент сокращения наборов тестов уменьшился, что является ожидаемым результатом, так как, вследствие учета значений дополнительных типов параметров, адаптированный метод способен лучше различать процессы взаимодействия, и, поэтому, размеры построенных им наборов оказываются не меньше, чем размеры наборов, построенных оригинальным методом.
  • Третья серия экспериментов была направлена на оценку эффективности метода: оценку затрат ресурсов и на оценку влияния длины последовательности интерфейсных функций K на работу метода. Длина последовательностей интерфейсных функций K является важным параметром предложенного метода редукции: бОльшая длина последовательностей повышает полноту (способность обнаруживать ошибки), но уменьшает точность метода (метод отсеивает меньше лишних вариантов). Меньшая длина последовательностей, соответственно, уменьшает полноту, но повышает точность. Также большая длина последовательности увеличивает затраты ресурсов. На слайде приводятся результаты сравнения характеристик различных модификаций метода, со значениями K , равными 1,2,3,6,10, и 15. Результаты эксперимента подтвердили зависимость точности, полноты и ресурсозатрат от параметра K : большие значения увеличивают полноту, уменьшают точность и увеличивают затраты. Результаты показали, что при значениях K больше 6, таких как 10 и 15, использование метода становится непрактичным: значительно возрастают временные затраты на проведение редукции, что, однако, не приводит к увеличению уровня обнаружения ошибок, так как коэффициент обнаружения ошибок уже достиг 100%. Также было замечено, что для тестируемых программ коэффициент обнаружения ошибок достигает 100% уже при К = 3, однако бОльшие значения K , такие как 6, добавляют «запас прочности» методу при незначительном увеличении затрат ресурсов.
  • Результаты предыдущих экспериментов показали что метод может успешно использоваться на реальном ПО и показывать неплохие результаты. Однако в предыдущих экспериментах не рассматривался вопрос какой выигрыш в потреблении ресурсов дает применение метода. Это обуславливалось в частности тем что выполнение исходного тестового набора происходило достаточно быстро и занимало примерно 5-7 минут. Чтобы ответить на этот вопрос было проведено экспериментальное исследование метода на тестовом наборе LSB Application Battery v3.1, который представляет собой коллекцию из 15 общеиспользуемых приложений. Проведение тестирования с помощью этого набора занимает около 2 часов. При проведении исследования, в дополнение к основным характеристикам, также был оценен выигрыш временных затрат, который дает применение метода. Для эксперимента использовалось взаимодействие между библиотекой X 11 и стандартной библиотекой. Эксперимент проводился в SUS Е Linux v10.2 . Результаты эксперимента подтвердили высокую практическую ценность метода: в результате работы метода было достигнуто сокращение исходного тестового набора в 9 раз, что привело к сокращению времени тестирования в 11.8 раз (до 10 минут). Затраты на работу метода редукции составили 1 минуту, таким образом суммарная экономия времени от использования метода редукции составила 1 час 47 минут или 10.7 раз от времени тестирования с помощью исходного набора тестов. При этом способность тестового набора обнаруживать ошибки не уменьшилась: сокращенный тестовый набор обнаруживал столько же ошибок, сколько и исходный тестовый набор.
  • На данном слайде представлены данные по проведенной работе < далее по слайду > АП: количественные характеристики затрат нужно показать более выпукло: Код такого-то типа Вспомогательные библиотеки *** Организация хранилища *** - и так далее Трудоемкость по разработке инфраструктуры - трудоемкость проведения экспериментов
  • В результате работы < далее по слайду > Разработанный метод редукции тестового набора значительно расширяет область применения методов редукции наборов тестов, делая их применимыми при регрессионном тестировании взаимодействий с участием готовых программных компонент, поставляемых без исходного кода. Проведенное экспериментальное исследование предложенного метода на наборе тестов, использующихся для тестирования индустриального программного обеспечения показало, что метод обеспечивает существенное сокращение размеров тестового набора без потери качества тестирования.
  • По теме работы были сделаны следующие доклады включая: Доклад на международной конференции PSI’09 в Новосибирске Доклад на секции Software Testing международной конференции SYRCoSE 2007 3 доклада на научном семинаре Института Системного Программирования Доклад на научном семинаре университета Loughborough
  • Также были опубликованы 4 работы, включая: Публикация в журнале РАН «Программирование» входящая в список ВАК Публикации в результате докладов на конференциях PSI и SYRCoSE И публикация в с борнике трудов Института Системного Программирования
  • На этом доклад закончен. Спасибо за внимание. Готов ответить на ваши вопросы.
  • Concerning the last example (error type C). We look at the call of fread function in isolated way, i.e. not taking into account the previous call to fopen function. In this case we see that we passed correct parameters to fread [as a spec for this function we take MSDN2001, where there are no words saying that fp should be opened for reading or for writing], but the function behaved incorrectly. That’s why we classify this case as of an error type C.
  • Transcript

    • 1. Метод редукции тестового набора для интеграционного тестирования Д.Ю.Кичигин Научный руководитель: д.ф.-м.н. А.К.Петренко Институт системного программирования Российской академии наук
    • 2. * ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование – повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов Регрессионное интеграционное тестирование ПО
    • 3. Регрессионное интеграционное тестирование ПО * ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование – повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов
    • 4. Регрессионное интеграционное тестирование ПО * ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Technology. The Institute of Electrical and Electronics Engineers, New York, 1990. Интеграционное тестирование – тестирование взаимодействия между интегрируемыми компонентами программного обеспечения. * Регрессионное тестирование – повторное тестирование ПО с целью убедиться что внесенные изменения не привели к неожидаемым эффектам.* Особенность регрессионного интеграционного тестирования: Проблема отбора тестов
    • 5. Задача редукции набора тестов
      • “ состоит в создании набора тестов меньшего размера, но при этом, желательно, с неменьшей способностью обнаруживать ошибки “ *
      • В контексте регрессионного интеграционного тестирования такая редукция позволяет:
      • отобрать из исходного набора тестов набор меньшего размера, нацеленного на регрессионное тестирование взаимодействий
      • вследствие этого , уменьшить затраты на выполнение программного обеспечения на тестовом наборе
      • * McMaster, S. and Memon, Call Stack Coverage for Test Suite Reduction, ICSM, pp.539-548, 21st IEEE International Conference on Software Maintenance (ICSM'05), 2005
    • 6. Существующие методы
      • Используют метрики покрытия исходного кода, полагающиеся на статический анализ и / или инструментирование исходного кода ПО.
      • (+) позволяют достаточно хорошо сокращать набор тестов за счет использования статического анализа исходного кода
      • (  ) непрактичны для программного обеспечения большого объема
      • (  ) неприменимы для тестирования взаимодействий с участием бинарных программных компонент
      • (  ) требуют специализированные средства инструментирования кода – сильно зависимы от используемой платформы / операционного окружения
      • (  ) вследствие работы в терминах исходного кода, сильно зависимы от конкретного языка программирования.
    • 7. Цель работы
      • Исследование, разработка и апробация метода редукции тестового набора для регрессионного интеграционного тестирования, применимого в условиях отсутствия доступа к исходному коду
      • Задачи:
      • Исследовать виды взаимодействия между модулями ПО и типичные для этих видов интеграционные ошибки;
      • Разработать модель процесса взаимодействия интегрируемых модулей, адекватную задаче анализа взаимодействия модулей при запуске различных тестов;
      • Разработать алгоритм редукции регрессионного тестового набора при помощи сравнения моделей взаимодействия, построенных на информации, полученной при прогоне тестового набора;
      • Реализовать разработанный метод в рамках экспериментальной системы редукции набора тестов; испытать метод и оценить его эффективность на наборах тестов, использующихся для тестирования индустриального программного обеспечения.
    • 8. Рассматриваемые взаимодействия и интеграционные ошибки
      • Интеграционная ошибка – ошибка, возникающая при передаче некорректного значения между взаимодействующими модулями. *
      * Delamaro, M. E., Maldonado, J. C., and Mathur, A. P., Interface Mutation: an approach to integration testing, IEEE TSE, Vol. 27, No. 3, March 2001, pp228-247.
      • Рассматриваемые взаимодействия :
      • Попарные взаимодействия модулей “ вызывающий / вызываемый ” (модуль F вызывает методы модуля G ) ;
      • Взаимодействия только через интерфейс функций, общих данных нет ;
      • Взаимодействия осуществляются синхронно в одном потоке / процессе .
      F G Некорректные данные Некорректный вывод F G Некорректные данные Некорректный вывод F G Некорректные данные Некорректный вывод Некорректные данные Корректные данные ( a) ( b) ( c)
    • 9. Предложенный метод редукции
      • Основная идея традиционных структурных методов редукции:
      • Используют метрики покрытия исходного кода для итеграционного тестирования
      • Состоят из 3 этапов :
        • статический анализ структуры исходного кода
        • запуск ПО на наборе тестов и сбор информации о достигнутом покрытии кода
        • редукция набора тестов на основе собранной информации о покрытии кода
      • Идея предложенного метода:
      • Основан на эвристическом алгоритме минимизации набора тестов
      • Анализируется покрытие точек взаимодействия между модулями
      • Состоит из 2 этапов :
        • запуск ПО на наборе тестов и сбор информации о выполненных взаимодействиях
        • редукция набора тестов на основе собранной информации о взаимодействиях между модулями
    • 10. Модель взаимодействия
      • Модель поведения взаимодействия – множество последовательностей вызовов интерфейсных функций длины К , выполненных во время тестирования взаимодействия.
      fopen fread fread fread fread fwrite fclose fopen fread fread fread fread fread fread fread fread fread fread fwrite fread fread fwrite fclose fopen fread fread fread fread fwrite fclose fopen fread fread fread fread fwrite fclose fopen fread fread fread fread fwrite fclose fopen fread fread fread fread fwrite fclose … FILE* fp = fopen(…); for (int i=0; i<4; i++) { fread(fp,…); } fwrite(fp, …); fclose(fp); … Трасса взаимодействия “ Скользящее окно ” размера K = 4 Модель взаимодействия
    • 11. Сравнение моделей Теорема : Выражение (*) есть отношение эквивалентности на множестве моделей взаимодействия Свойства: Адаптивность для учета значений параметров других типов (*) Учет значений параметров функций: Скалярные номинальные : eq ( x , y ) =  ( x , y ), где  - отношение равенства Скалярные числовые: eq ( x , y ) =  ( interval( x ) , interval( y ) ) Указатели: eq ( x , y ) = 1, если x = y = NULL; либо x != NULL, y != NULL Другие типы: eq ( x , y ) ≡ 1
    • 12. Схема работы метода редукции да нет Выбрать следующий тест t из исходного набора Построить модель M на выбранном тесте t да да результат := сокращенный набор нет 1 ) поместить тест t в сокращенный набор 2 ) поместить модель в пул моделей нет Модель M пуста ? Есть ли в Пуле моделей модель, эквивалентная M ? Исходный набор пройден? Сокращенный набор тестов :=  Пул моделей := 
    • 13. Вычислительная сложность метода
      • Сложность алгоритма:
      • Объем памяти:
      B A B B A B B A B B A B B A B C A B C B B C B C Оптимизация: древовидная структура для хранения модели: Сложность алгоритма: Объем памяти: T - количество тестов K - размер окна N - кол-во интерфейсных функций ROOT B A B B C A B B A C A B B B C C B Хеш-таблицы, сложность поиска O ( log ( N ))
    • 14. Технологический процесс применения метода Инструмен-тация модулей 1. Первоначальное тестирование: построение моделей взаимодействия Запуск ПО на исходном наборе тестов Сбор трасс Построение моделей Модели взаимодействий Исходный набор тестов 2. Регрессионное тестирование: редукция набора тестов Модели взаимодействий Список измененных модулей + Редукция набора тестов Сокращенный набор тестов Тестируемое ПО + Фильтрация трасс
    • 15. Архитектура и схема работы Особенности реализации : - Возможность адаптации для учета других типов параметров - Возможность адаптации к различным средам выполнения Объект тестирования Выполнение объекта Модуль анализа взаимодействий Модели взаимодействий Исходный тестовый набор Трассы вызовов функций Сокращенный набор тестов Консоль Экспериментальная система редукции набора тестов Классификатор параметров Сенсор
    • 16. Экспериментальное исследование
      • Цели исследования:
      • Оценка основных ( * ,**) характеристик предложенного метода:
        • Точность , Полнота , Эффективность , Универсальность
      • Сравнение с методом случайной редукции и редукции пустых трасс
      • Постановка экспериментов:
      • GNU Ассемблер v 2.17, 2.18
      • Размер исходных наборов тестов: 5-191 тестов
      • Модули: GNU Ассемблер и стандартная библиотека языка Си
      • Взаимодействие через функции ввода / вывода стандартной библиотеки языка Си ( stdio.h )
      * Rothermel,G.,Harrold,M.J.Analyzing regression test selection techniques. IEEE TSE. 22/8. 1996. ** Епифанов Н.А., Методы Реализации Регрессионного Тестирования по Расширенным Тестовым Наборам, Диссертация на соискание учёной степени кандидата технических наук, СПГПУ, 2003.
    • 17. Точность и полнота - Интегрируемые модули: GNU Ассемблер v 2.1 7 и стандартная библиотека языка Си - Взаимодействие через функции ввода / вывода ( stdio.h) 100% в ср. на 52% предложенный метод в ср. 80% метод случайной редукции 100% в ср. на 10% метод редукции пустых трасс Обнаружение ошибок (от кол-ва обнаруженных исх. н.т.) Сокращение
    • 18. Универсальность (1)
      • Определение:
      • строка - последовательность символов
      • Эквивалентность строк:
      • eq (s 1 ,s 2 )= истина  длина (s 1 )= длина (s 2 )
      • Класс эквивалентности: длина строки
      • s  E i  длина (s) = i
      Экспериментальная система редукции набора тестов Пример : адаптация метода к строковым параметрам Объект тестирования Модуль анализа взаимодействий Модели взаимодействий Консоль Классификатор параметров Сенсор Шаг 2. Адаптация экспериментальной системы: Шаг 1. Отношение эквивалентности для строк: Реализация отношения эквивалентности для строк
    • 19. Универсальность ( 2 )
      • Интегрируемые модули: GNU Ассемблер v 2.18 и стандартная библиотека языка Си
      • Взаимодействие через функции: - FILE *fopen(const char * filename, const char * mode)
          • - int fprintf(FILE *file_pointer, char *format_ string , ...)
          • - int fclose(FILE *file_pointer)
      0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10 30 50 70 90 110 130 150 170 190 Размер исходного набора % сокращения набора 0% 20% 40% 60% 80% 100% 120% 10 30 50 70 90 110 130 150 170 190 Размер исходного набора % обнаружения ошибок Все в ср. на 79%
        • после адаптации
      в ср. 91% в ср. на 8 8 %
        • до адаптации
      Обнаружение ошибок Сокращение
    • 20. Эффективность: оценка ресурсозатрат и влияние параметра K Интегрируемые модули: GNU Ассемблер v 2.18 и стандартная библиотека языка Си Взаимодействие через функции ввода / вывода ( stdio.h) 15.3 12.2 10.6 9.8 9.7 9.6 Объем используемой памяти (в Мб) 6.5 мин 1.2 мин 27 сек 9 сек 5 сек 2 сек Время работы 100% 100% 100% 100% 99% 92% Коэфф. обнаружения ошибок 45% 52% 54% 57% 61% 74% Коэфф. сокращения 15 10 6 3 2 1 Индикатор Длина K
    • 21. Экспериментальное исследование на тестовом наборе LSB Application Battery Исходный набор: LSB Application Battery v3.1 , 15 приложений, 81 тест Интегрируемые модули: библиотека X11 и стандартная библиотека языка Си Эксперимент проводился в среде SUS Е Linux v10.2 1 час 47 минут / 10.8 раз Выигрыш по времени 1 минута Время работы метода 11.8 раз Коэфф. сокращения времени 10 минут 1 час 58 минут Время выполнения 0% Изменение уровня обнаружения 6 6 Кол-во обнаруженных ошибок 9 раз Коэффициент сокращения 9 81 Размер набора Сокр. набор Исх. набор Индикатор
    • 22. Данные по программной реализации и проведенным экспериментам
      • В ходе работы было:
      • Разработаны:
        • Программная библиотека реализующая построение и сравнение моделей взаимодействий ;
        • Программная компонента реализующая разработанный метод редукции набора тестов ;
        • 8 вспомагательных компонент для преобразования трасс из различных форматов и автоматизации применения метода ;
      • Проведено более 30 различных экспериментов
        • Оценка характеристик предложенного метода
        • Сравнение с методом случайной редукции и методом редукции пустых трасс
    • 23. Основные результаты
      • Разработан , реализован и апробирован метод редукции тестового набора для регрессионного интеграционного тестирования, применимый в условиях отсутствия доступа к исходному коду:
      • Разработана новая модель процесса взаимодействия модулей на основе метода «скользящего окна» по трассе вызовов интерфейсных функций;
      • Предложено и обосновано отношение эквивалентности между процессами взаимодействия модулей на основе предложенной модели и формальное обоснование его корректности;
      • Предложен и реализован новый метод редукции тестового набора на основе использования предложенного отношения эквивалентности;
      • Разработана экспериментальная система, реализующая метод редукции тестового набора.
    • 24. Доклады
      • По теме работы были сделаны следующие доклады:
      • Seventh International Andrei Ershov Memorial Conference «PERSPECTIVES OF SYSTEM INFORMATICS » ( PSI’09), Новосибирск, 2009.
      • на секции Software Testing международной конференции SYRCoSE 2007 (The First Spring Young Researchers Colloquium on Software Engineering), Москва , 2007.
      • на научном семинаре Института Системного Программирования РАН, Москва, 2006, 2007, 2009.
      • на научном семинаре The Knowledge Management Research Group, Loughborough University, Loughborough, United Kingdom, 2005.
    • 25. Публикации
      • По теме работы были опубликованы следующие работы:
      • Кичигин Д.Ю. Метод редукции тестового набора для регрессионного интеграционного тестирования. Журнал РАН «Программирование», Номер 5, 2009, cc . 57-69.
      • (входит в список ВАК)
      • Dmitry Kichigin. A Method for Test Suite Reduction for Regression Testing of Interactions between Software Modules . In Proceedings of PSI’09, Novosibirsk, 2009. Springer: Volume 5947/2010 pp. 177-184, 2010.
      • D. Kichigin. Test Suite Reduction for Regression Testing of Simple Interactions between Two Software Modules. In Proceedings of SYRCoSE 2007. Volume 2, ISP RAS. pp. 31-37, 2007 .
      • Кичигин Д.Ю. Об одном методе сокращения набора тестов.
      • Сборник трудов ИСП РАН.. М: ИСП РАН, 2007.
    • 26. Спасибо !
    • 27. Примеры интеграционных ошибок
      • int printf(const char *format, ...)
      • int sprintf (char *str, const char *format, ...)
      • size_t fread (void * restrict ptr, size_t size, size_t nmemb, FILE * restrict stream)
      Тип ошибки Исходный код Код с добавленной ошибкой A char sz[16]; printf(“%s”, sz); char sz[16]; printf(“% d ”, sz); B char szParam[16]; char szResult[16]; sprintf(“%s”, szResult, szParam); char szParam[16]; char szResult[16]; sprintf(“% d ”, szResult, szParam); C char sz[30]; FILE* fp = fopen( &quot;file.txt&quot;, “r+t&quot; ); … fread( sz, sizeof( char ), 25, fp ); char sz[30]; FILE* fp = fopen( &quot;file.txt&quot;, &quot; w +t&quot; ); … fread( sz, sizeof( char ), 25, fp );
    • 28. Возможные направления будущих исследований
      • Исследования работы метода со специализированными функциональными интерфейсами:
        • Интерфейсы для работы с базами данных - > использование метрики сходства SQL запросов
        • ...
      • Исследования работы метода с другими типами интерфейсов
        • Интерфейсы основанные на обмене сообщениями
      • Многопоточные / многопроцессные взаимодействия
        • Использование thread id / process id