Уменьшение объема тестируемой программы




Лекция №11.

Тема: Регрессионное тестирование: методики, не связанные с отбором тестов и методики порождения тестов

План:

Интеграционное регрессионное тестирование

Регрессионное тестирование объектно-ориентированных программ

Уменьшение объема тестируемой программы

Методы упорядочения

Целесообразность отбора тестов

Функции предсказания целесообразности

Порождение новых тестов

Интеграционное регрессионное тестирование

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

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

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

Регрессионное тестирование объектно-ориентированных программ

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

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

Уменьшение объема тестируемой программы

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

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

Для теста 1 рис. 12.1 для функции Equation остаточная программа выглядит так, как показано в Табл. 13.1. Нумерация строк оставлена такой же, как в исходной программе. Таким образом, можно заметить, что были удалены строки 6 и 7, которые не затрагиваются тестом 1 в ходе его выполнения, а также строки 3 и 8, содержащие вычисление предикатов, которые в ходе выполнения теста всегда истинны. Запуск теста на полной измененной программе и на остаточной программе приводит к активизации одних и тех же операторов, поэтому выигрыша во времени получить не удается, однако за счет сокращения объема программы уменьшается время компиляции. Для нашего примера этот выигрыш незначителен и не оправдывает затрат на анализ, необходимый для уменьшения объема. Таким образом, рассмотренная технология рекомендуется к применению, прежде всего, в случаях, когда стоимость компиляции относительно высока.

Таблица 13.1. Остаточная программа
Строка кода
  double Equation(int Print, float A, float B, float C, float& X1, float& X2) {
  float D = B * B - 4.0 * A * C;
  X1 = (-B + sqrt(D)) / 2.0 / A;
  X2 = (-B - sqrt(D)) / 2.0 / A;
  printf("Solution: %f, %f\n", X1, X2);
  return D;
  }

Сведения о методике уменьшения объема тестируемой программы приведены в Табл. 13.2.

Таблица 13.2. Результаты применения методики уменьшения объема
Характеристика Изменение в результате применения методики
Время компиляции тестируемой программы Уменьшается
Время выполнения тестируемой программы Не изменяется
Время работы метода отбора Увеличивается
Риск пропуска ошибок Увеличивается
Результаты применения методики на практике Отрицательные

Методы упорядочения

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

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

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

Проблему упорядочения тестов можно сформулировать следующим образом:

· Дано: T - набор тестов, PT - набор перестановок T, f - функция из PT на множество вещественных чисел.

· Найти: набор такой, что:

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

Упорядочение может преследовать различные цели:

· Увеличение частоты обнаружения ошибок наборами тестов, то есть увеличение вероятности обнаружить ошибку раньше при выполнении регрессионных тестов из этих наборов.

· Ускорение процесса покрытия кода тестируемой системы и достижение требуемой степени покрытия кода на более ранних этапах процесса тестирования.

· Быстрейший рост вероятности того, что тестируемая система надежна.

· Увеличение вероятности обнаружения ошибок, связанных с конкретными изменениями кода, на ранних этапах процесса тестирования и т.п.

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

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

Например, упорядочивать тесты можно по количеству покрываемых ими изменений кода. При безопасном отборе тестов из рис. 12.1 будут выбраны тесты 1, 2 и 5, из которых наиболее приоритетным является тест 2, так как он затрагивает оба изменения, тогда как тесты 1 и 5 – только одно.

Сведения о методике упорядочения тестов суммированы в Табл. 13.3.

Таблица 13.3. Результаты применения методики упорядочения тестов
Характеристика Изменение в результате применения методики
Время работы метода отбора Увеличивается незначительно
Частота обнаружения ошибок Увеличивается
Скорость покрытия кода Увеличивается
Результаты применения методики на практике Положительные


Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-11 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: