Критическим этапом в жизненном цикле программного обеспечения является этап сопровождения, на котором предполагается поддержка командой разработчиков программного обеспечения, поставляемого их клиентам. По таким причинам как исправление ошибок, сопровождение программного обеспечения приводит к расширению его возможностей, отказу от неактуальных возможностей и оптимизации. Измененное или модифицированное программное обеспечение требует тестирования, которое известно как регрессивное тестирование. В статье представлен обзор двух основных групп методов регрессивного тестирования (методы выбора регрессивных тестов и методы приоритезации) и обсуждение открытых проблем и потенциальных направлений будущих исследований. The most crucial phase in the software life cycle is maintenance phase, in which the development team is supposed to maintain the software which is delivered to the clients by them. Software maintenance results for the reasons like error corrections, enhancement of capabilities, deletion of obsolete capabilities and optimization. Now the changed or modified software needs testing known as regression testing. This paper surveys the two main groups of methods of regression testing (regression test selection methods and methods of prioritization) and discuss open problems and potential directions for future research Введение Одним из наиболее важных этапов жизненного цикла программного обеспечения (ПО) является этап сопровождения. Согласно данным, приведенным в [1], затраты на этом этапе могут превышать две трети затрат на весь жизненный цикл ПО. На этом этапе разработчику от пользователей ПО поступают сообщения об обнаруженных дефектах, запросы на расширение, улучшение или адаптирование к изменяющейся среде существующей функциональности, предложения по переносимости его на различные платформы или языки программирования и т. п. В течение некоторого времени вся эта информация интегрируется, а затем осуществляется модификация данного ПО, чтобы удовлетворить потребности пользователей. Новая версия ПО обязательно подвергается, так званому, регрессивному тестированию (РТ), чтобы гарантировать, что никакие новые ошибки (называемые ошибками регресса) не были введены в ранее проверенный код (т. е. неизмененные части программы) [2]. После того как РТ завершено, выпускается новая версия ПО, которая затем подвергается подобному циклу. РТ является дорогим действием. Оно требует больших ресурсо-временных затрат, которые часто составляют почти половину всех затрат на поддержку ПО [2]. Поэтому м и н и м и з а ц и я р е с у р с о - в р е м е н н ы х з а т р а т н а р е г р е с с и в н о е т е с т и р о в а н и е является очень важной как научной, так и прикладной проблемой, решение которой позволит улучшить качество и существенно сократить общие затраты на поддержку ПО. Несмотря на большое количество появившихся в последние два десятилетия публикаций, посвященных этой проблеме, она еще весьма далека от своего полного решения. Как показывают результаты некоторых исследований [3], подходы, которые чаще всего используются на практике для идентификации необходимых регрессивных тестов, основаны или на экспертной оценке, или на некоторой форме ручного анализа программы. Поскольку выбор тестов на основе экспертной оценки имеет тенденцию становиться все менее эффективным и надежным с увеличением размера и сложности ПО, а при ручном анализе ПО даже для умеренно сложных программ, обычно, чрезвычайно трудно вручную идентифицировать тесты, которые имеют отношение к изменениям в ПО, то в конечном итоге все это приводит к излишне высоким стоимостновременным затратам на РТ и значительной потере тестов, которые в состоянии обнаружить ошибки регресса. Можно констатировать, что на сегодня при наличии большого количества публикаций, посвященных различным аспектам РТ, все же наблюдается острая нехватка инструментальных средств поддержки автоматической генерации наборов регрессивных тестов, разработка которых требует дальнейших серьезных как теоретических, так и экспериментальных исследований. В данной работе для лучшего понимания состояния дел в области РТ мы сначала рассмотрим две основные группы методов (подходов) к РТ, а затем остановимся на некоторых перспективных, по нашему мнению, направлениях будущих исследований.
Регрессивное тестирование заключается в многократном использовании T0 на P1 и определении новых
тестов, необходимых для эффективной проверки кода, а также добавленных или измененных функциональных
возможностей при разработке P1 [4]. Одним из стандартных методов регрессивного тестирования (РТ) является
больших ресурсо-временных затрат, необходимых для выполнения всего набора тестов, и ограничений графика
выпуска, которому часто подвергаются проекты ПО, этот метод практически неприемлем [
На сегодня можно выделить две основные группы методов РТ: (1) методы Выбора Регрессивных Тестов (ВРТ), (2) методы приоритезации (т. е. установления приоритетов) тестов.
П р о б л е м а в ы б о р а р е гр е с с ив но го т е с т а формально может быть определена таким образом [5]: Дано: P0 , P1 и T0 . Приоритезация регрессивных тестов упорядочивает их таким образом, чтобы в процессе РТ тесты с более высоким приоритетом (относительно некоторой метрики) всегда выполнялись раньше, чем тесты с более низким приоритетом. В качестве такой метрики в большинстве случаев берется метрика APFD (Average of the Percentage of Faults Detected) или ее модификации [7]. Она выражается в процентах и имеет вид: n TFi APDF 1 i1 nm 1 , 2n где n – количество тестов в наборе; m – количество ошибок, выявленных данным набором тестов; T Fi – порядковый номер теста в упорядоченном наборе, первым обнаружившим i -ю ошибку.
Чем больше ее значение, тем быстрее выявляются ошибки. 2. Методы выбора регрессивных тестов
В зависимости от парадигмы программирования методы ВРТ по разному устанавливают компромис между стоимостью выбора и выполнения тестов, с одной стороны, и эффективностью обнаружения ошибок – с другой. Далее рассмотрим подходы к ВРТ для процедурных, объектно-ориентированных, компонентноориентированных и аспектно-ориентированных программ, а также приложений с базами даннях, Вебприложений и сервисов.
2.1. Методы ВРТ для процедурных программ. Различные подходы к ВРТ для таких программ можно условно сгруппировать в следующие основные классы: 1) методы на основе анализа потока данных; 2) методы, основанные на срезах; 3) методы, основанные на брандмауэре или брандмауэр-методы; 4) методы на основе различий; 5) методы, основанные на анализе потока управления. Методы, основанные на анализе потока данных. Эти методы ВРТ обнаруживают пары «определение – использование» переменных, которые затрагиваются модификациями программы, и выбирают тесты, которые отрабатывают пути от определения измененных переменных до их использования. Методы ВРТ на основе потока данных, приведенные в [8], обычно выполняют анализ либо путем отработки одного изменения за другим и постепенного обновления информации потока данных в P1, либо вычисляют полную информацию потока данных для P0 и P1 и сравнивают различия между парами «определение - использование». Оба эти метода требуют сохранения информации потока данных в ходе сеансов тестирования или повторного вычисления в начале каждого сеанса тестирования.
Методы, основанные на срезах. Современные технологии создания программ предполагают так называемый slicing — выделение из программы ее определенных частей, называемых срезами программы. Agrawal и другие [9] предложил ряд методов ВРТ, основанных на срезах программы. Цель этих методов состоит в выборе таких тестов, которые могут порождать разные выходы при их выполнении с измененной версией программы P1 . Авторы определяют срез теста t как набор выполняемых операторов программы, когда P0 выполняется с t . Они предложили подходы к вычислению четырех типов срезов: исполнительный срез, динамический срез, релевантный срез и приближенно релевантный срез. Методы к ВРТ, предложенные в [9], выбирают тест t для РТ только в том случае, если срез t , вычисленный с помощью любого из четырех подходов, содержит оператор, измененный в P1 .
Брандмауэр-методы уровня модуля. Брандмауэр-метод ВРТ, впервые предложенный Leung и White
[
Vokolos и Frankl [12, 13] предложили метод ВРТ, который основан на определении расхождения программ P0 и P1 , а не на использовании какого-либо промежуточного представления программ. Примитивное определение текстового расхождения программ включает в себя поиск тривиальных различий между двумя версиями, таких как вставка пустых строк, комментариев и т. д. Поэтому в предложенном подходе программы перед сравнением преобразуется в каноническую форму [12]. Каноническая версия P0 снабжается средствами измерения и затем выполняется с целью формирования информации тестового покрытия. Эта информация идентифицирует базисные блоки, которые выполняются каждым тестом вместо операторов программы. Канонические версии P0 и P1 синтаксически сравниваются для определения изменений в коде. Ин
Методы, основанные на анализе потока управления. В ряде работ были предложены методы ВРТ, которые анализируют модели потока управления исходной программы для выбора тестов регрессии. Так, Laski и Szermer [14] предложили технику идентификации кластера, основная концепция которой состоит в локализации изменений программы в одну или несколько областей кода, именуемых кластерами. Кластеры определяются как части кода с одним входом и одним выходом, которые изменялись от одной версии программы к другой. Техника идентификации кластера моделирует программы P0 и P1 как графы потока управления (ГПУ), обозначаемые G0 и G1 . Определяются вершины в G0 и G1 , которые соответствуют изменениям в коде, и набор всех таких вершин образует кластер. Техника, основанная на идентификации кластера, использует информацию о зависимости по управлению исходной и измененной процедурами для вычисления кластеров в двух графах. Как только все кластеры идентифицированы в ГПУ P0 и P1 , каждый из них далее представляется единственной вершиной для формирования сокращенного ГПУ. Анализ сокращенных графов потока основывается на предположении, что любая сложная модификация программы может быть достигнута одной из следующих трех операций: вставка кластера в код, удаление кластера или изменение функциональных возможностей кластера.
Rothermel и Harrold в предложили метод ВРТ, который основан на пересечении ГПУ исходной и измененной программ [15]. Этод метод более эффективен по сравнению с методами ВРТ на основе обхода графа, основанных на моделях графа зависимостей [5].
Ball в работе[16] предложил более точный метод ВРТ по сравнению с предложеным в [15], моделируя ГПУ G0 для программы P0 специальным детерминированным конечным автоматом (ДКА), который допускает
Брандмауэр-подходы. Эти подходы призваны определить классы, подвергшиеся воздействию в измененной версии ПО. Брандмауэр может быть определен как набор всех затронутых классов, которые должны быть повторно протестированы. В этих подходах выбираются все тестовые сценарии, которые охватывают по меньшей мере один класс в брандмауэре.
Kung и другие [18] предложили брандмауэр-подход к ВРТ для C++ программ на уровне классов. Было предложено три модели для представления зависимостей между их различными элементами: диаграмма отношений объектов (ДОО), диаграмма переходов блока (ДПБ) и диаграмма состояний объектов (ДСО). ДОО является орграфом, который представляет наследование, отношения агрегирования и ассоциации и концентрирует информацию о статических зависимостях между классами. Дуга в ДОО аннотируется типом отношения (наследование, ассоциация, агрегация), которое существует между конечными вершинами, связанными с этой дугой. ДПБ представляет интерфейс и структуру управления методами класса, а также связь класса с другими классами в программе. ДСО предназначена для охвата динамического поведения классов.
Jang и другие в [
Подходы на основе модели программы. Rothermel и Harrold были одними из первых, кто предложил такой поход в [20]. Они разделили проблему ВРТ для ООП на две части: ВРТ прикладной программы и ВРТ измененных или производных (полученных) классов. Для ВРТ прикладной программы в подходе моделируется оригинальная программа P0 и измененная программа P1 с помощью моделей Графа Межпроцедурных Зависимостей Программ.
В работе [21] предложен подход ВРТ для C ++ программ, основанный на анализе представлений потока управления оригинальной и измененной программ, расширяющий поход, что дан в [15]. Так как ГПУ представляет информацию о потоке управления только единственного метода, были введены понятия графа межпроцедурного потока управления (ГМПУ) и графа потока управления класса (ГПУК), чтобы представить поток управления многофункциональных программ и объектно-ориентированных программ, соответственно. ГМПУ используется для моделирования программ, имеющих единственную точку входа, тогда как класс может иметь несколько точек входа [21]. ГПУК используется для моделей классов и состоит из индивидуальных ГПУ для всех методов класса. Учитывая модели графа для исходной и модифицированной программ, алгоритм ВРТ [21] расширяет подход, основанный на обходе графа [15], чтобы пересечь модели и выбрать соответствующие регрессивные тесты.
В работе [22] впервые был предложен безопасный подход к ВРТ для Java-программ, основанный на анализе потока управления. Их подход является адаптацией подходов к обходу графа, предложенных в [15, 21], и может работать с различными объектно-ориентированными свойствами, такими как наследование, полиморфизм, динамическое связывание и обработка исключений. Подход включает три шага: построение промежуточных представлений для исходных программ, анализ графов и определение набора опасных дуг и выбора тестов.
Необходимость объединения эффективности точных, но дорогих, подходов к ВРТ с подходами, которые работают на более высоком уровне абстракции и являются относительно неточними, привела к поялению подходов, основанных на разбиении. В работе [23] Orso и другие представили подход двухэтапного разбиения для ВРТ больших Java программ. Подход работает в два этапа: разбиение и отбор. На этапе разбиения оригинальная и измененная программы моделируются как графы отношений между классами [23]. На этапе отбора проводится более детальный анализ разбиения и строятся модели JIG (Java Interclass Graph), представляющие измененные области кода из разбиения. JIG модели затем анализируются с помощью метода ВРТ, предложенного в [15] и отбираются тесты, которые выполняют затронутые части кода.
Mansour и Statieh в [24] предложили двухэтапный подход ВРТ, предназначенный для C # программ. В их подходе к ВРТ сначала создается диаграмма затронутых классов (ДЗК), основанная на изменениях, сделанных к модифицированной программе. ДЗК представляет модификации, сделанные на уровне класса, интерфейса, Вебили оконных сервисов и компонентов COM+. Затем используется критерий покрытия тестами, основанный на ДЗК, для выбора подмножества тестовых сценариев. пользуется для выбора соответствующих регрессивных тестов.
Gorthi и другие [30] предложили подход к ВРТ, основанный на UML-диаграммах прецедентов. Они использует концепцию поведенческих срезов, по которой прецеденты декомпозируются на пользовательские действия, сопровождаемые некоторыми вычислениями и выходом.
Briand и другие [26]. предложили подход к ВРТ, основанный на анализе моделей проекта UML. Их подход предполагает полную отслеживаемость между моделью(моделями) проекта, кодом и тестами. Отслеживаемость между проектом и тестами помогает ассоциировать изменения в моделях проекта с тестами, которые должны быть выполнены, чтобы отработать затронутые части в проекте. Подходы к ВРТ, основанные на спецификации. Часто сложность осуществления ВРТ состоит в том, что тестировщики не имеют доступа к моделям проекта или фактическому исходному коду. В таких случаях анализ на основе моделей или на основе кода невозможен. Эти ограничения заставили исследователей развивать подходы к ВРТ на основе спецификаций, которые обычно доступны для тестировщиков. В этом контексте нужно отметить, что, хотя мы классифицировали эти подходы как подтип объектно-ориентированных подходов к ВРТ, они могут быть распространены на более широкий спектр парадигм программирования, таких как компонентно-ориентированное.
Chen и другие [31] предложили основанный на спецификации подход к ВРТ, который использует UML диаграммы деятельности для моделирования потенциально затрагиваемых требований и поведение системы. Они также классифицировали регрессивные тесты, подлежащие отбору, на целевые тесты и тесты безопасности. Идея состоит в том, чтобы более тщательно проверить те части кода, для которых вероятность присутствующей ошибки и ее стоимость (то есть, последствие воздействия) высока.
Chittimalli и Harrold [32] предложили подход к ВРТ, который, по существу, основан на отслеживании того, какие спецификации проверяются и какими тестами из T0 . Эта информация представляется в виде матрицы покрытия требований между набором требований и тестами. Подход, предложенный в [23], использовался для идентификации задетых частей кода, а также набора требований, которые затронуты вследствие изменений.
2.3. Подходы к ВРТ для компонентно-ориентированного ПО. В модели разработки компонентноориентированного ПО (КОПО) программный продукт создается путем интеграции различных компонентов собственной разработки или сторонних поставщиков. Надежность КОПО в значительной степени зависит от надежности отдельных компонентов. Эти компоненты, представляющие “черный ящик”, часто модифицируются поставщиками с целью исправления ошибок и включения расширений. Поэтому при РТ КОПО должно определяться, каким образом изменения, внесенные в компоненты, могут повлиять на выполнение прикладных программ, использущих эти измененные компоненты. Подходы к ВРТ для традиционных программ не могут обоснованно применяться для ВРТ ПО, использующего готовые коммерческие компоненты потому, что код этих компонентов, как правило, не доступен. Остановимся кратко на основных методах ВРТ для КОПО.
Методы ВРТ на основе метаконтента. Трудности неадекватного информационного обмена между пользователем компонента (К-пользователем) и разработчиком компонента (К-разработчиком) во время разработки КОПО могут быть преодолены путем совместного использования релевантной информации о компоненте, необходимой для анализа ВРТ. Orso и другие [33] предложили концепцию информации об измененном содержимом, называемую метаконтентом компонента, как средства совместного использования информации об изменениях, которым компонент подвергается от версии к версии. Различные подходы к ВРТ могут определять свои собственные наборы необходимых метаконтентов, которые должны быть разделены с К-разработчиками. Ниже мы обсуждаем различные подходы ВРТ, основанные на метаконтенте.
Orso A. в [34] предложен подход к ВРТ на основе покрытия кода для КОПО и существующих процедурных подходов к ВРТ [11, 15]. В случае, если К-пользователи не знают о компонентах, которые претерпели изменения, тогда во время ВРТ прикладного кода для РТ отбирается любой тест, в котором вызывается метод модифицированных компонентов. Это может привести к выбору тестов, не связанных с конкретными изменениями. С информацией об изменениях, внесенных в компоненты, можно сделать более точный выбор тестовых сценариев.
Mao и другие обнаружили [35], что применимость подхода, предложенного в [33, 34], ограничена из-за того, что он нуждается в очень подробной метаконтентной информации, предоставляемой К-разработчиком. Они предложили подходы ВРТ [35, 36], которые акцентируют внимание на доступности для К-пользователей определенных данных от К-разработчиков.
Подход, основанный на встроенных тест-скриптах. О подходе к ВРТ для КОПО, который использует иной уровень информационного обмена между К-пользователями и К-разработчиками, сообщалось в [36]. Появление подхода обусловлено тем фактом, что только К-разработчики имеют подробные знания о работе компонента и модификациях, подготовленных для каждой из его версий. Этот подход предлагает, чтобы Кразработчики помещали тестовые скрипты в исходный код компонента во время модификации. Цель этих тестовых скриптов заключается в сборе информации о шаблоне выполнения компонента во время исполнения тестов. Эта информация помогает находить тесты, которые покрывают измененные операторы компонента.
Подходы к ВРТ, основанные на моделях. Предложенные для КОПО подходы к ВРТ, основанные на моделях, являются по существу развитием подходов к ВРТ, основанных на моделях, предложенных для процедурных и ООП. Ниже мы кратко обсуждаем несколько таких подходов.
В работе [37] предложен подход к ВРТ, использующий модели UML и OCL (Object Constraint Language). Предполагается, что функциональные возможности, предоставляемые измененным компонентом, являются сверхнабором функциональных возможностей, предоставленных оригинальным компонентом, то есть, новая версия компонента может включать исправления ошибок и оптимизацию существующих функциональных возможностей наряду с новыми функциональными возможностями, которые были введены.
Wu и Offutt в [38] предложили другой подход к ВРТ, основанный на моделях UML, в котором диаграммы кооперации и последовательности используются для анализа поведения потока управления компонента и того, каким образом объекты взаимодействуют друг с другом через описание сообщений. Изменения, внесенные в модифицированную версию компонента, будут отражаться в диаграмме кооперации как изменения в методе класса или изменения в последовательностях взаимодействия.
В работе [39] предложен подход к ВРТ для КОПО, в котором с использованием моделей анализируется динамическое поведения (например, взаимодействие методов во время выполнения) компонентов для выбора тестовых сценариев. В этом подходе есть возможность выбрать регрессивные тесты для компонентов, разработанных в .NET и Java.
Анализ исполняемого кода. Zheng и другие [40] предложили семейство подходов к ВРТ, основанных на анализе исполняемого кода (двоичных файлов, таких как .dll. или lib) измененных компонентов. Эти подходы известны как I-BACCI (Integrated-Black-box Approach for Component Change Identification, Интегрированный подход “черного ящика” для идентификации изменения компонентов), с указанием номера версии для конкретизации подхода семейства. Семейство I-BACCI использует подход брандмауэра для анализа связующего кода (прикладного кода, который интегрирует готовые коммерческие компоненты).
2.4. Подходы к ВРТ для аспектно-ориентированных программ. Парадигма аспектноориентированной разработки ПО является относительно новой и направлена на улучшение разбиения ПО на модули, изолируя низкоприоритетную и вспомогательную функциональность от основной и значимой для приложения бизнес-логики. В традиционном программировании программисту свойственно иметь дело со вспомогательными функциями и располагать их чередующимися пластами (называемыми слоями функциональности, concerns) в основном коде приложения. Слои, которые распространяются через несколько модулей, называются сквозными (пересекающими), образуя сквозную функциональность (crosscutting concerns). Аспектноориентированное программирование (AOП) позволяет программистам отсылать эту вторичную сквозную функциональность к автономным модулям, называемым аспектами. АОП усвоено многими объектноориентированными языками программирования, а АОП-языки, такие как AspectJ, приобрели большую популярность среди Java разработчиков. Введение аспектов обычно изменяет поведение исходной Java программы. Таким образом, программы на AspectJ также должны быть подвержены тщательному РТ после внесения изменений. Ниже мы обсуждаем предлагаемые подходы к ВРТ для AspectJ программ.
ВРТ программ на AspectJ с использованием моделей потока управления. Zhao и другие [41] предложили подход ВРТ для AspectJ-программ, расширяя работу Harrold и др. [22]. Они предложили граф потока управления системой (ГПУС) и Граф Потока Управления Аспектом для моделирования AspectJ программ. После того как построены графы ГПУС для оригинальной и измененной пары AspectJ программ, используется метод поиска вглубь (depth-first search), предложенный в [22], для идентификации опасных дуг в графе. Тестовые сценарии, которые выполняют опасные дуги, отбираются для РТ.
Подход к ВРТ для AspectJ-программ, основанный на расширенном JIG. В работе [42] приведен подход безопасного ВРТ, который основан на представлении вспомогательного графа для AspectJ программ. Авторы сначала предложили модель графа, основанного на потоке управления для AspectJ-программ, назвав его AspectJ межмодульный граф (AspectJ Intermodule Graph, AJIG), который является расширением межклассового графа Java (JIG, Java Interclass Graph). Соответствующие регрессивные тесты выбираются путем сравнения графов AJIG для P0 и P1. Авторы расширили алгоритм обхода графа, предложенный в [22]. Их двухфазный алгоритм также обрабатывает ситуации, когда вершины назначения для пары сравниваемых дуг являются следами описания оператора.
2.5. Подходы к ВРТ для приложений с базами даннях. В настоящее время используется большое количество приложений с базами данных (БД), которые обычно состоят из нескольких компонентов, способствующих повышению их сложности [43]. Приложения с БД также должны часто изменяться из-за различных требований, например, изменений в компонентах, растущего количества пользователей и данных и т. д. Поэтому РТ приложений с БД является еще одним важным видом деятельности. Требования и проблемы при выборе регрессивных тестов для приложений с БД отличаются от таковых для классов программ, которые мы обсуждали до сих пор. При выборе регрессивных тестов для приложений с БД нужно учитывать следующие особенности [43, 44]:
– подходы к ВРТ для других классов программ неявно предполагают, что тесты независимы друг от друга и могут быть выполнены в любом порядке. Это предположение неверно для приложений с БД, поскольку выход теста может изменить состояние базы данных, влияя на выполнение других тестов. Поэтому помимо глобального состояния программы, для приложений с БД необходимо рассматривать состояния базы данных в ходе ВРТ;
– в процессе РТ состояние базы данных обычно приходится многократно сбрасывать, то есть, восстанавливать начальную конфигурацию БД. Переустановка БД является дорогостоящей деятельностью как с точки зрения затрат, так и времени;
– языки БД поддерживают такие возможности как структурированные запросы, ограничения целостности, обработка исключений и триггеры таблиц, которые усложняют анализ влияния измененных частей программы. Например, срабатывание триггеров может создать неявные зависимости межмодульного управления. Традиционные понятия безопасности и зависимостей не могут быть применены в РТ приложений с БД, поскольку соответствующие подходы были разработаны для простых приложений. В этой связи для приложений с БД были предложены несколько подходов к ВРТ, которые мы кратко рассмотрим.
Двухэтапный подход ВРТ для систем, основанных на SQL. В этом подходе, предложенном Haraty и др. [44], помимо традиционных зависимостей по управлению и данным между элементами в приложении с БД, определяются следующие аспекты, которые необходимо учитывать:
зависимости потока данных – зависимости потока данных могут возникать между модулями базы данных за счет использования сквозных таблиц модулей;
зависимости компонентов – они возникают между различными модулями БД из-за срабатывания триггеров таблиц, изменений в таблицах или представлениях, а также вследствие изменения инструкций SQL; обработка исключений (особых случаев) – возникновение исключительных состояний может повлиять на отношения в потоке управления, которые должны учитываться в ходе анализа ВРТ.
Подход безопасного ВРТ, основанный на ГПУ. Willmor и Embury [45] развили алгоритм ВРТ, основанный на безопасном анализе потока управления, предложенном Rothermel и Harrold [15] для процедурных программ, применительно к приложениям с БД. ВРТ, основанный только на отношениях определениеиспользование данных, не безопасен для приложений с БД, поскольку возможна ситуация, когда инструкция запишет в БД какие-то данные, которые позже будут прочитаны оператором программы, обрабатывающим более раннюю инструкцию в каком-то пути исполнения [45]. Поэтому авторы ввели понятие зависимостей базы данных, чтобы охватить дополнительные зависимости, которые возникают между элементами в программе базы данных.
Подход к ВРТ для Web приложений, основанный на срезах. Такой подход предложили Xu и другие в [46]. Они предполагали, что Веб-приложения состоят из множества статических HTML-страниц и программ, выполняемых на стороне сервера. Типы изменений, которым может подвергнуться страница HTML, могут быть разделены на следующие основные классы: вставка элемента страницы (например, якорь, гиперссылка и т. д.), удаление элемента страницы, вставка страницы и удаление страницы. Более сложные изменения декомпозируются на комбинацию из этих базовых модификаций.
Подход к ВРТ, основанный на моделях системы. Tarhini и другие [47]. предложили подход безопасного ВРТ для приложений на основе Веб-сервисов. В подходе Веб-сервисы определяются как автономные компонентные приложения, которые находятся в разных местах и имеют коммуникацию с помощью XMLсообщений, используя интерфейсы SOAP. Коммуникация, использующая обмен сообщениями, может также быть ограничена во времени. Услуги, предоставляемые Веб-сервисом, являются коллективно используемыми с помощью спецификаций WSDL.
Подходы к ВРТ, основанные на анализе моделей потока управления. Подход к ВРТ, предложенный Ruth и другие [48], является подходом серого-ящика (gray-box), так как сложно провести РТ белого ящика (white-box) для Веб-сервисов из-за того, что зачастую исходный код компонентов не может быть доступным разработчикам Веб-сервисов. Это подход серого-ящика, поскольку он не требует наличия исходного кода Вебсервисов. Вместо этого предполагается, что поставщики компонентных Веб-сервисов смогут предоставить следующую информацию в виде метаданных наряду с новым вариантом сервиса: спецификация WSDL, набор тестов, ГПУ для Веб-сервисов и данные о покрытии тестами.
Lin и другие [49] предложили подход безопасного ВРТ для Веб-сервисов Java на основе преобразования кода. В их подходе моделируется Java-код на стороне клиента и на стороне сервиса как единая объединенная программа. Услуги и интерфейсы, предоставляемые Веб-сервисом, доступны из спецификаций WSDL. 3. Методы приоритезации
Чтобы лучше понять динамику исследований в области приоритезации регрессивных тестов, было, с
определенной долей условности, выделено шесть основных категорий методов и подходов, которые кратко
описаны ниже.
Подход, основанный на покрытии. Приоритезация на основе покрытия базируется на том факте, что
чем большее покрытие достигнуто тестовым набором, тем больше шансов обнаружить ошибки на ранних
стадиях процесса тестирования. В работе [50] Rothermel и др. продемонстрировали четыре метода на основе
покрытия: общее/дополнительное, операторов/ветвей, соответственно. При сравнении этих методов
использовался инструмент для анализа программ «Аристотель» [
Srivastava и Thigarajan [52] предложили подход к приоритезации на основе двоичного кода. Была построена тестовая система Echelon для расположения по приоритетам множества ошибок на основе изменений, внесенных в программу. Предлагаемое преимущество использования двоичного представления состоит в устранении шага перекомпиляции для покрытия набора ошибок и т. д., что облегчает интеграцию процесса встраивания тестовой системы в производственную среду.
Приоритезация на основе графовой модели Веб-системы ISELTA с использованием подхода нечеткой кластеризации была предложена Belli и другие в [53]. Показано, что этот подход полезен, когда наборы тестов упорядочиваются в рамках ограниченного времени и способа. Влияние ограничения времени на стоимость РТ были изучены Do и другие [54]. Они предложили четыре метода приоритезации, два из которых были основаны на общем/дополнительном покрытии и два на сетях Байеса. Метод с дополнительным покрытием оказался более эффективным, чем с общим.
Jiang и другие [55] предложили девять основанных на покрытии методов приоритезации тестов при адаптивном случайном тестировании (Adaptive Random Test, АRТ). Эти методы были разделены на три группы, а именно: maxmin, maxavg и maxmax. Для каждой группы уровень покрытия данных основывался на операторах, функциях и ветвях. Сравнение предлагаемых методов из случайным упорядочением показало, что ART методы являются более эффективными, чем случайное упорядочение. Также были найдены лучший и худший методы среди всей группы ART методов.
В работе [56] Bryce и другие рассмотрен основанный на покрытии подход, касающийся разработки единой абстрактной модели тестирования путем комбинирования GUI (интерфейса пользователя) и Вебприложений. Определение приоритетов было выполнено на основе покрытия взаимодействующих значений параметров или частоты. Был также определен обобщенный критерий приоритезации как для GUI, так и для Веб-приложений.
Подход, основанный на изменении. Цель этого подхода состоит в установлении приоритетов тестов на основе изменений, сделанных в программе. Впервые этод подход был предложен Wong и другие [57]. Korel и другие [58] предложили методы избирательной приоритезации тестов на основе системной модели и приоритезации тестов на основе модельной зависимости с использованием расширенных конечных автоматов для системных моделей. Хотя последний метод был более дорогим, улучшение в эффективности приоритезации наблюдалось при использовании метрик скорости обнаружения ошибки для обоих методов. В работе [59] Korel и другие предложили еще пять эвристических методов и сравнили все семь методов. Метод, основанный на модельной зависимости, показал лучшую эффективность из всех семи методов.
Основанный на модели подход к приоритезации тестов, опирающийся на связи трассируемости между моделями, тестами и артефактами кода, был предложен Filho и др. в [60]. Этот метод поддерживает РТ, основанное на изменениях, используя временные метки и приоритезацию на основе свойств. Авторы выполняли приоритезацию и фильтрацию как часть процесса генерации тестов, использующего модификаторы набора тестовых сценариев.
Подход, основанный на ошибках. Методы приоритезации на основе ошибок впервые были предложены в [50]. Согласно этому подходу свойство ошибки быть выявленной тестом зависит не только от того, будет ли протестирован определенный оператор, но также от вероятности того, что ошибка в операторе повлечет за собой отказ этого теста. В исследовании были представлены два метода, касающиеся потенциала теста в выявлении ошибки – метод приоритезации с учетом FEP (Fault Exposing Potential – Потенциал выявления ошибки) при общем покрытии и метод приоритезация по FEP при дополнительном покрытии.
Elbaum и другие в [6] представили шесть методов функционального уровня для определения приоритетности тестов относительно ошибок. Два из них являются методами приоритезации функционального уровня с учетом FEP; два других основаны на индексе ошибок (fault index, FI), который представляет собой склонность к содержанию ошибок в соответствующей функции, и еще два объединяют как FI, так и FEP, сперва применяя общую приоритезацию индекса ошибок ко всем тестам, а затем, в качестве вторичного упорядочивания, приоритезацию FEP к тем из них, которые обладают равными значениями FI. Было предоставлено достаточно статистических доказательств, чтобы показать, что методы функционального уровня менее эффективны, чем методы уровня оператора. В дополнение к вышеупомянутым методам в [7] представлено еще четыре метода приоритезации на уровне функций, которые являются DIFF-базируемыми методами. Эти методы требуют вычисления синтаксических различий между двумя версиями программы. Степень изменения измеряется для каждой функции, присутствующей в обеих версиях, с помощью количества строк, добавленных, удаленных или измененных в выводе команды UNIX diff, примененной к обеим версиям. Два из этих четырех методов основаны только на DIFF, а два других сочетают DIFF с FEP.
Подход на основе требований. Srikant и другие [61] был предложен метод системного уровня PORT V 1.0 (Prioritization Of Requirements for Testing) для приоритезации на основе требований и разработан инструмент для его реализации. Подход основан на четырех факторах: назначенных потребителем приоритетов требований, сложности реализации с точки зрения разработчика, изменчивости требований и предрасположенности требований к ошибкам. Цель состоит в раннем выявлении серьезных ошибок и улучшении качества ПО с точки зрения потребителя. Более серьезными считались ошибки в требованиях с большим диапазоном PFV, где PFV – значение коэффициента приоритетов для конкретного требования, вычисленное по формуле, предложенной авторами. Исследование показало, что метод PORT может повысить эффективность тестирования благодаря концентрации внимания на наиболее значимой для потребителя функциональности и на улучшении скорости обнаружения серьезной ошибки, тем самым минимизируя область появления ошибок.
Krishnamoorthi и другие в [62] для повышения удовлетворенности пользователя и скорости обнаружения серьезной ошибки была представлена модель приоритезации тестов для системного уровня исходя из спецификации требований к ПО. Модель расположила по приоритетам тесты системы, основываясь на следующих шести факторах: приоритет потребителя, изменения в требованиях, сложность реализации, удобство и простота использования, поток управления в приложении и последствия ошибки. Другой метод тех же авторов был представлен в [63]. Он отличался только по двум факторам, затрагивающим алгоритм установления приоритетов. Факторы, представленные в [63]: назначенный потребителем приоритет, изменения в требованиях, сложность реализации кода с точки зрения разработчика, последствия ошибки, полнота и трассируемость. При сравнении методов с общим покрытием операторов и общим покрытием методов было установлено, что для метода авторов скорость обнаружения серьезных ошибок возрасла.
Подход, базирующийся на прошлом опыте. Kim і Porter [64] предложили метод установления приоритетов, основанный на исторических данных выполнения программы. Они показывают, что историческая информация может быть полезной для сокращения затрат и увеличения эффективности процесса РТ. Для этого ими было введено понятие РТ с полной памятью.
Fazlalizadeh и другие [65] усовершенствовали базируемый на прошлом метод приоритезации, предложенный в [64] для ускорения обнаружения ошибок в средах с ограниченным ресурсом и временем. В работе представлено уравнение, которое учитывает историческую эффективность тестов в обнаружении ошибки, историю выполнения тестов и последний приоритет, присвоенный тестам.
Подход, на основе метаэвристик глобальной оптимизации. Метод установления приоритетов с учетом времени, использующий генетический подход, был предложен Walcott и другие [66]. Эксперимент проводился на уровне детализации программ двух объектов: Gradebook и JDepend. Были задействованы инструменты отслеживания процесса Emma и Linux и результаты были определены количественно, используя метрику APFD. В конечном счете, осуществление приоритезации с помощью генетического алгоритма (ГА) дало улучшение по сравнению с неупорядочиванием, обратным упорядочиванием и установлением приоритетов с учетом ошибок.
Другой вид приоритезации тестов на основе ГА был предложен Conrad и другие в [67]. Работа представила широкий спектр мутаций, кроссинговеров, селекций и операторов преобразования, которые использовались для изменения порядка тестов. Экспериментальное исследование было проведено на 8 реальных приложениях (таких же, как в [68]), используя одну и ту же метрику эффективности покрытия [49] и их тесты JUnit на уровне системы. Результаты были проанализированы с помощью горохообразных (beanplots) диаграмм, являющихся альтернативой диаграммам размаха. При сравнении предлагаемого метода с методами случайного поиска и поиска экстремума ГА дал лучшие результаты. Заключение и направления будущих исследований
Признано, что подходы к РТ, которые анализируют изменения программы на более низком уровне детализации (например, на уровне операторов), более точны, чем подходы, которые выполняют анализ на сравнительно более высоком уровне абстракции (например, моделях проекта). Однако, объемные вычисления для низкоуровневого анализа делают эти подходы более дорогими и менее эффективными по сравнению с высокоуровневыми подходами. Поэтому при выборе подходящего метода ВРТ, необходимо придерживаться компромисса между стоимостью и эффективностью, с одной стороны, и уровнем детализации, с другой.
Современные коммерческие программные продукты становятся все более крупными и сложными, и для их проверки, обычно, требуется тысячи тестов. Поэтому для получения дополнительной экономии усилий при РТ исследователи должны помнить: – с тенденцией увеличения размера приложений подходы к ВРТ должны масштабироваться для очень больших программ, имеющих размеры кода порядка миллионов KLOC. Для современных больших программных систем масштабируемость является важной проблемой. Поэтому интересным направлением исследования могло бы быть изучение композиционных и интеграционных подходов к ВРТ;
– подход к ВРТ должен учитывать при выборе тестов все возможные взаимосвязи в зависимости от рассматриваемого класса программ, то есть, он должен быть безопасным для этого класса программ.
Основанное на модели РТ. Учитывая тот факт, что статический анализ больших программных систем является в вычислительном отношении дорогостоящим, перспективными представляются подходы к ВРТ, основанные на модели, поскольку они не только хорошо масштабируются, но являются более эффективными. Кроме того, в последнее время МОР уделяется много внимания. В МОР существует тесная взаимосвязь между моделью (моделями) проекта и кодом в том смысле, что любое изменение в модели получает отражение в коде и наоборот. Поэтому вместо осуществления ВРТ на коде, его можно автоматически выполнять, базируясь на моделях проекта. Основанный на модели ВРТ может также помочь учесть некоторые аспекты поведения программы (например, переходы состояний, пути сообщений, критичность задач и т. д.), которые нелегко идентифицируются при статическом анализе кода.
Улучшенная инструментальная поддержка РТ. В будущих работах по РТ следует постепенно переходить от теоретических исследований к инструментам реализации. В ряде исследований [3] отмечалось, что текущая инструментальная поддержка для автоматизации ВРТ довольно слабая. Поэтому совместные усилия должны быть направлены на разработку интегрированных инструментов ВРТ, используя механизмы записи и воспроизведения (capture-and-replay).
Синтезированные методы РТ. Большинство упоминаемых в литературе подходов к РТ основаны либо на коде, либо на модели. Так как у обоих этих подходов есть свои собственные уникальные преимущества, возможно эти подходы могут быть обоснованно синтезированы, и эта проблема заслуживает дальнейшего исследования. Например, осуществляемый анализ в методе ВРТ, основанном на коде, может быть сделан более эффективным при использовании информации, доступной по UML-моделям проекта, документам Спецификации требований к ПО и т. д.
Большая часть работ, посвященных многоцелевому РТ, находится в областях минимизации набора тестов и установления приоритетов [69]. Однако в реальном РТ при выборе тестов, необходимо учитывать множество целевых показателей, таких как количество выполненных тестов, затраты, привлеченные для тестирования, достигнутое покрытие кода, время, доступное для тестирования и т. д. Интересный путь исследований мог бы состоять в объединении методов выбора регрессивных тестов с подходами либо минимизации, либо приоритезации. При таком обобщенном подходе техника выбора тестов могла бы затем включать дальнейшую минимизацию/приоритезацию. РТ, используя такой синтезированный подход, может учесть одновременно несколько целевых критериев в ходе тестирования и потенциально может помочь добиться дальнейшей экономии усилий РТ, не ставя под угрозу тщательность тестирования.
Встроенное ПО. Возрастающее использование встроенного ПО реального времени в критических по безопасности приложениях (ПО атомных станций, космических кораблей, самолетов и т. п.) привело к повышенным требованиям к качеству их кода. Высокая стоимость и сложность выполнения РТ для такого ПО должны были бы стать дополнительным стимулом к разработке особых подходов к РТ для этих программ. Однако к настоящему времени успехи в этом направлении весьма скромны, несмотря на то, что это направление исследований представляется весьма важным.
Приложения с гибридным управлением. Для приложений с дискретным управлением обычно используют UML-модели, тогда как для приложений с гибридным управлением популярны модели MATLAB Simulink/Stateflow [70]. В этом контексте необходимы подходящие подходы к ВРТ для приложений с гибридным управлением. Кроме того, более детальное исследование требуется для изучения эффективности подходов к ВРТ для тестирования нефункциональных требований.
Агентно-ориентированное программирование. В последние годы стремительно развивается агентноориентированная парадигма ПО [71], которую можно рассмотреть как естественное расширение объектноориентированной парадигмы. Сегодня программные агенты являются ключевой технологией для удовлетворения потребностей современного бизнеса. Они предлагают также эффективную концептуальную методологию для разработки адаптивных и динамичных сложных систем. На практике исследования по разработке программных агентов и мультиагентных систем приобрели очень больших масштабов и используются в различных активных областях. Однако, поскольку агенты имеют более высокий уровень абстракции по сравнению с объектами и во многих аспектах существенно отличаются от них, то известные методы РТ для ООП совершенно непреемлемы для агентно-ориентированых программ (АОП). Разработка эффективных методов РТ для АОП – еще одна очень важная область исследований.