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

Интеграционное регрессионное тестирование
С появлением новых направлений в разработке программного обеспечения (например, объектно-ориентированного программирования), поощряющих использование большого количества маленьких процедур, повышается важность обработки межмодульного влияния изменений кода для методик уменьшения стоимости регрессионного тестирования. Для решения этой задачи необходимо рассматривать зависимости по глобальным переменным, когда переменной в одной или нескольких процедурах присваивается значение, которое затем используется во многих других процедурах. Такую зависимость можно рассматривать как зависимость между процедурами по потоку данных. Также возможны межмодульные зависимости по ресурсам, например по памяти, когда ресурс разделяется между несколькими процедурами. Отметим, что при системном регрессионном тестировании зависимости такого рода можно игнорировать.
Если изменение спецификации требований затрагивает глобальную переменную, могут потребоваться новые модульные тесты. В противном случае, повторному выполнению подлежат только модульные тесты, затрагивающие как измененный код, так и операторы, содержащие ссылку на глобальную переменную.
Брандмауэр можно определить как подмножество графа вызовов, содержащее измененные и зависящие от изменений процедуры и интерфейсы. Методы отбора тестов, использующие брандмауэр, требуют повторного интеграционного тестирования только тех процедур и интерфейсов, которые непосредственно вызывают или вызываются из измененных процедур.
Регрессионное тестирование объектно-ориентированных программ
Объектно-ориентированный подход стимулирует новые приложения методик выборочного повторного тестирования. Действительно, при изменении класса необходимо обнаружить в наборе тестов класса только тесты, требующие повторного выполнения. Точно так же при порождении нового класса из существующего необходимо определить тесты из множества тестов базового класса, требующие повторного выполнения на классе-потомке. Хотя благодаря инкапсуляции вероятность ошибочного взаимодействия объектно-ориентированных модулей кода уменьшается, тем не менее, возможно, что тестирование прикладных программ выявит ошибки в методах, не найденные при модульном тестировании методов. В этом случае необходимо рассмотреть все прикладные программы, использующие измененный класс, чтобы продемонстрировать, что все существующие тесты, способные обнаруживать ошибки в измененных классах, были запущены повторно и было выбрано безопасное множество тестов. При повторном тестировании прикладных программ, классов или их наследников применение методик выборочного повторного тестирования к существующим наборам тестов может принести немалую пользу.
В объектно-ориентированной программе вызов метода во время выполнения может быть сопоставлен любому из ряда методов. Для заданного вызова мы не всегда можем статически определить метод, с которым он будет связан. Выборочные методы повторного тестирования, которые полагаются на статический анализ, должны обеспечивать механизмы для разрешения этой неопределенности.
Уменьшение объема тестируемой программы
Еще один путь сокращения затрат на регрессионное тестирование состоит в том, чтобы вместо повторного тестирования (большой) измененной программы с использованием соответственно большого числа тестов доказать, что измененная программа адекватно тестируется с помощью выполнения некоторого (меньшего) числа тестов на остаточной программе. Остаточная программа создается путем использования графа зависимости системы вместо графа потока управления, что позволяет исключить ненужные зависимости между компонентами в пределах одного пути графа потока управления. Так, корректировка какого-либо оператора в идеале должна приводить к необходимости тестировать остаточную программу, состоящую из всех операторов исходной программы, способных повлиять на этот оператор или оказаться в сфере его влияния. Для получения остаточной программы необходимо знать место корректировки (в терминах операторов), а также информационные и управляющие связи в программе. Этот подход работает лучше всего для малых и средних изменений больших программ, где высокая стоимость регрессионного тестирования может заставить вообще отказаться от его проведения. Наличие дешевого метода остаточных программ, обеспечивающего такую же степень покрытия кода, делает регрессионное тестирование успешным даже в таких случаях.
Метод остаточных программ имеет ряд ограничений. В частности, он не работает при переносе программы на машину с другим процессором или объемом памяти. Более того, он может давать неверные результаты и на той же самой машине, если поведение программы зависит от адреса ее начальной загрузки, или если для остаточной программы требуется меньше памяти, чем для измененной, и, соответственно, на остаточной программе проходит тест, который для измененной программы вызвал бы ошибку нехватки памяти. Исследования метода на программах небольшого объема показали, что выполнение меньшего количества тестов на остаточной программе не оправдывает затрат на отбор тестов и уменьшение объема программы. Однако для программ с большими наборами тестов это не так.
Для теста 1для функции Equation остаточная программа выглядит так, как показано в. Нумерация строк оставлена такой же, как в исходной программе. Таким образом, можно заметить, что были удалены строки 6 и 7, которые не затрагиваются тестом 1 в ходе его выполнения, а также строки 3 и 8, содержащие вычисление предикатов, которые в ходе выполнения теста всегда истинны. Запуск теста на полной измененной программе и на остаточной программе приводит к активизации одних и тех же операторов, поэтому выигрыша во времени получить не удается, однако за счет сокращения объема программы уменьшается время компиляции. Для нашего примера этот выигрыш незначителен и не оправдывает затрат на анализ, необходимый для уменьшения объема. Таким образом, рассмотренная технология рекомендуется к применению, прежде всего, в случаях, когда стоимость компиляции относительно высока.

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

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

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

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

• (T'') (T''PT)(T''T') [f(T')f(T'')]

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

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

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

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

Поскольку в общем случае оптимальный отбор тестов (то есть выбор в точности тех тестов, которые обнаруживают ошибку) невозможен, соотношение между затратами на применение методов выборочного регрессионного тестирования и выигрышем от их использования является основным вопросом практического применения выборочного регрессионного тестирования. На основании оценки этого соотношения делается вывод о целесообразности отбора тестов.
Эффективное регрессионное тестирование представляет собой компромисс между качеством тестируемой программы и затратами на тестирование. Чем больше регрессионных тестов, тем полнее проверка правильности программы. Однако большее количество выполняемых тестов обычно означает увеличение финансовых затрат и времени на тестирование, что на практике не всегда приемлемо. Выполнение меньшего количества регрессионных тестов может оказаться дешевле, но не позволяет гарантировать сохранение качества.
Когда отдельные модули невелики и несложны, а связанные с ними наборы тестов также небольшие, простой повторный запуск всех тестов достаточно эффективен. При интеграционном тестировании это менее вероятно. В то время как тесты для отдельных модулей могут быть небольшими, тесты для групп модулей и подсистем достаточно велики, что создает предпосылки для уменьшения издержек тестирования. С другой стороны, с ростом размера приложений стоимость применения выборочной стратегии повторного тестирования может возрасти до неприемлемой величины. Затраты на необходимый для отбора анализ могут перевешивать экономию от прогона сокращенного набора тестов и анализа результатов прогона. Однако в области тестирования достаточно больших программ положительный баланс затрат и выгод вполне достижим.
Модель затрат и выгод при использовании выборочных стратегий регрессионного тестирования должна учитывать прямые и косвенные затраты. Прямые затраты включают отбор и выполнение тестов и анализ результатов. Косвенные затраты включают затраты на управление, сопровождение баз данных и разработку программных средств. Выгоды – это затраты, которых удалось избежать, не выполняя часть тестов. Чтобы метод выборочного регрессионного тестирования был эффективнее метода повторного прогона всех тестов, стоимость анализа при отборе подмножества тестов вкупе со стоимостью их выполнения и проверки результатов должна быть меньше, чем стоимость выполнения и проверки результатов исходного набора тестов.
Пусть T' – подмножество T, отобранное некоторой стратегией выборочного регрессионного тестирования М для программы P, |T'| - обозначает мощность T', s – средняя стоимость отбора одного теста в результате применения М к P для создания T', а r – средняя стоимость выполнения одного теста из T на P и проверки его результата. Тогда для того, чтобы выборочное регрессионное тестирование было целесообразным, требуется выполнение неравенства:
s|T'| < r(|T| - |T'|)
Применяя вышеупомянутую модель стоимости с целью анализа затрат, полезно условно разделять регрессионное тестирование на две фазы – предварительную и критическую. Предварительная фаза регрессионного тестирования начинается после выпуска очередной версии программного продукта; во время этой фазы разработчики расширяют функциональность программы и исправляют ошибки, готовясь к выпуску следующей версии. Одновременно тестировщики могут планировать будущее тестирование или выполнять задачи, требующие наличия только предыдущей версии программы, такие как сбор тестовых траекторий и анализ покрытия. Как только в программу внесены исправления, начинается критическая фаза регрессионного тестирования. В течение этой фазы регрессионное тестирование новой версии программы является доминирующим процессом, время которого обычно ограничено моментом поставки заказчику. Именно на критической фазе регрессионного тестирования наиболее важна минимизация затрат. При использовании выборочного метода регрессионного тестирования важно использовать факт наличия этих двух фаз, уделяя как можно больше внимания выполнению задач, связанных с анализом, в течение предварительной фазы, чтобы на критической фазе заниматься только прогоном тестов и уменьшить вероятность срыва сроков поставки. Тем не менее, важно понимать, что до внесения последнего изменения в код анализ может быть выполнен только частично.
Если не учитывать не очень больших затрат на анализ при использовании детерминированных методов, решение о применении конкретного метода отбора тестов будет зависеть от отношения стоимости выполнения большего количества тестов к цене пропуска ошибки, что зависит от множества факторов, специфических для каждого конкретного случая. При отсутствии ошибок сбережения пропорциональны уменьшению размера набора тестов и могут быть измерены в терминах процента выбранных тестов, |T'| / |T|.
Модели стоимости могут использоваться как при выборе наилучшей, так и для оценки пригодности конкретной стратегии. При анализе учитываются такие факторы, как размер программы (в строках кода), мощность множества регрессионных тестов и количество покрываемых элементов, задействованных исходным множеством тестов.
Общий метод исследования проблемы целесообразности отбора тестов состоит в нахождении или создании исходной и измененной версий некоторой системы и соответствующего набора тестов. В этих условиях применяется методика отбора тестов, и размер и эффективность выбранного набора тестов сравнивается с размером и эффективностью первоначального набора тестов. Результаты показывают, что применение методов отбора регрессионных тестов, в том числе и безопасных, не всегда целесообразно, поскольку затраты и выгоды от их использования изменяются в широком диапазоне в зависимости от многих факторов. На практике наборы, основанные на покрытии, обеспечивают лучшие результаты отбора тестов.
Разумеется, отношение покрытия – не единственный фактор, который может отразиться на целесообразности применения выборочного регрессионного тестирования. Для некоторых приложений создание условий для тестирования (в том числе компиляция и загрузка модулей и ввод данных) может обходиться намного дороже, чем вычислительные ресурсы для непосредственного исполнения тестируемой системы. Например, в телекоммуникационной промышленности стоимость создания тестовой лаборатории для моделирования реальной сети связи может достигать нескольких миллионов долларов.
Подсчет порога целесообразности помогает определить, может ли отбор тестов вообще быть целесообразен для данного программного изделия и набора тестов. Однако даже в случаях, когда значение порога целесообразности указывает, что отбор тестов может быть целесообразен, он не обязательно будет таковым; результат зависит от параметров набора тестов, таких как размер набора, характеристики покрытия кода, уровень подробности и время выполнения тестов, а также от местоположения изменений. Существенно повлиять на общую оценку могут затраты на оплату труда тестового персонала, доступность свободного машинного времени для регрессионного тестирования, доступность стенда, на котором развернуто программное обеспечение приложения и т.п. Отметим, что стоимость прогона тестов связана не столько с размером программы, сколько с ограничениями на допустимое время прогона.
В некоторых случаях, когда число тестов, отброшенных выборочным методом регрессионного тестирования незначительно, но его применение тем не менее заслуживает внимания. Дело в том, что любое сокращение высокозатратного времени использования тестовой лаборатории особенно важно, а для отбора тестов используются другие ресурсы. Подобные обстоятельства необходимо включать в оценку стоимости анализа путем учета не только стоимости эксплуатации ресурса, но и таких факторов как время суток, день недели, время, оставшееся до выпуска очередной версии продукта и т.п. В этом случае модель стоимости должна соблюдать баланс между высокой стоимостью прогона тестов в тестовой лаборатории и относительно небольшой стоимостью проведения анализа на незанятых компьютерах.
Для некоторых программ и наборов тестов выборочное тестирование неэффективно, так как порог целесообразности превышает число тестов в наборе. В таких случаях методы отбора тестов, независимо от того, насколько успешно они уменьшают число тестов, требующих повторного выполнения, не могут давать экономию. Этот результат отражает тот факт, что целесообразность отбора зависит как от стоимости анализа, так и от стоимости выполнения тестов. Возможность достижения экономии при отборе регрессионных тестов для конкретной системы программного обеспечения и конкретного набора тестов должна, оцениваться комплексно с учетом всех влияющих на решение факторов.
Стоит заметить, что целесообразность применения выборочного метода регрессионного тестирования нельзя воспринимать как нечто само собой разумеющееся. Следует очень осторожно подходить к оценке целесообразности отбора повторно прогоняемых тестов. В ряде случаев, когда или получаемое число остаточных тестов близко к первоначальному их количеству, или накладные расходы на повторное тестирование незначительны, выгоднее прогонять заново все тесты, особенно если прогон тестов полностью автоматизирован.

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

На практике не существует способа в точности предсказать, сколько тестов будет выбрано при минимизации (или по результатам применения любой другой методики отбора тестов). Когда количество тестов, отсеянных по результатам отбора, незначительно, ресурсы, потраченные на отбор тестов, пропадают впустую. В таких случаях говорят, что выборочное регрессионное тестирование нецелесообразно. Чтобы выяснить, заслуживает ли внимания попытка применения выборочного метода регрессионного тестирования, необходимо использовать прогнозирующую функцию.
Прогнозирующие функции основаны на покрытии кода. Для их вычисления используется информация о доле тестов, активирующих покрываемые сущности – операторы, ветви или функции, – что позволяет предсказать количество тестов, которые будут выбраны при изменении этих сущностей. Существует как минимум одна прогнозирующая функция, которая может быть использована для предсказания целесообразности применения безопасной стратегии выборочного регрессионного тестирования.
Пусть P – тестируемая система, S – ее спецификация, T – набор регрессионных тестов для P, а |T| означает число отдельных тестов в T. Пусть М – выборочный метод регрессионного тестирования, используемый для отбора подмножества T при тестировании измененной версии P; М может зависеть от P, S, T, информации об исполнении T на P и других факторов. Через E обозначим набор рассматриваемых М сущностей тестируемой системы. Предполагается, что T и E непустые, и что каждый синтаксический элемент P принадлежит, по крайней мере, одной сущности из E. Отношение coversM(t, E) определяется как отношение покрытия, достигаемого методом М для P. Это отношение определено над T×E и справедливо тогда и только тогда, когда выполнение теста t на P приводит к выполнению сущности e как минимум один раз. Значение термина "выполнение" определено для всех типов сущностей P. Например, если e – функция или модуль P, e выполняется при вызове этой функции или модуля. Если e – простой оператор, условный оператор, пара определения-использования или другой вид элемента пути в графе выполнения P, e выполняется при выполнении этого элемента пути. Если e – переменная P, e выполняется при чтении или записи этой переменной. Если e – тип P, e выполняется при выполнении любой переменной типа e. Если e – макроопределение P, e выполняется при выполнении расширения этого макроопределения. Если e – сектор P, e выполняется при выполнении всех составляющих его операторов. Соответствующие значения термина "выполнение" могут быть определены по аналогии для других типов сущностей P.
Для данной тестируемой системы P, набора регрессионных тестов T и выборочного метода регрессионного тестирования М можно предсказать, стоит ли задействовать М для регрессионного тестирования будущих версий P, используя информацию об отношении покрытия coversM, достигаемого при использовании М для T и P. Прогноз основан на метрике стоимости, соответствующей P и T. Относительно издержек принимаются некоторые упрощающие предположения.
Пусть EC обозначает множество покрытых сущностей:
EC = {eE | (tT)(coversМ(t, E))}.
Обозначение |EC| используется для числа покрытых сущностей. Иногда удобно представить зависимость coversM(t, E) в виде бинарной матрицы C, строки которой представляют элементы T, а столбцы – элементы E. При этом элемент Ci,j матрицы C определяется следующим образом:
Ci, j = 1, если coversМ(i, j)
Ci, j = 0, иначе
Степень накопленного покрытия, обеспечиваемого T, то есть общее число единиц в матрице C, обозначается CC:
|T| |E|
CC = Σ   Σ Ci,j
i=1 j=1
Отметим, что если ограничиться включением в C только столбцов, соответствующих покрытым сущностям EC, накопленное покрытие CC останется неизменным. В частности, для всех непокрытых сущностей u Ci,u равно нулю для всех тестов i (так как coversM(i, u) ложно для всех таких случаев). Следовательно, ограничение на EC при вычислении суммы, определяющей CC, приводит только к исключению слагаемых, равных нулю.
Пусть TM – подмножество T, выбранное М для P, и пусть |TM| обозначает его мощность, тогда TM = {tT | M выбирает t}. Пусть sM – удельная стоимость отбора одного теста для TM при применении М к P, и пусть r – удельная стоимость выполнения одного теста из T на P и проверки его результата. М целесообразно использовать в качестве метода отбора тестов тогда и только тогда, когда:
sM|TM| < r(|T| - |TM|), то есть стоимость анализа, необходимого для отбора TM, должна быть меньше стоимости прогона невыбранных тестов, TTM.
Оценка ожидаемого числа тестов, требующих повторного запуска, обозначается NM и вычисляется следующим образом:
Nm = CC/|E|
Использование этой прогнозирующей функции предполагается только в случаях, когда цель выборочной стратегии регрессионного тестирования состоит в повторном выполнении всех тестов, затронутых изменениями, то есть используется безопасный метод отбора тестов. Несколько усовершенствованный вариант оценки NM, использующий в качестве пространства сущностей EC вместо E:
Ncm = CC/|Ec|
Прогнозирующая функция для доли набора тестов, требующей повторного выполнения, то есть для |TM| / |T|, обозначается М:
m= Nmc/|T| = CC/|Ec||T|
Прогнозирующая функция М полагается непосредственно на информацию о покрытии. Главные предпосылки, лежащие в основе применения прогнозирующей функции, таковы:

• Целесообразность применения выборочного метода регрессионного тестированияи, как следствие, наша способность к предсказанию целесообразности, непосредственно зависит от доли тестового набора, выбираемой для выполнения методом регрессионного тестирования.
• Эта доля в свою очередь непосредственно зависит от отношения покрытия.

Точность прогнозирующей функции на практике может значительно меняться от версии к версии. Проблема точности может оказаться достаточно серьезной, тем не менее, поскольку прогнозирующая функция используется для долговременного предсказания поведения метода на протяжении нескольких версий, применение средних значений считается допустимым. Отношение coversM(t, e) в ходе сопровождения изменяется очень слабо. По этой причине информация, полученная в результате анализа единственной версии, может оказаться достаточной для управления отбором тестов на протяжении нескольких последовательных новых версий.
Существуют факторы, влияющие на целесообразность отбора тестов, но не учитываемые прогнозирующей функцией. Один из подходов улучшения качества прогноза состоит в использовании информации об истории изменений программы, которую зачастую можно получить из системы управления конфигурацией.
Например, впрогнозирующая функция может быть подсчитана как отношение общего количества звездочек в таблице к количеству строк таблицы, т.е. числу покрываемых сущностей. Эта величина составляет 42 / 11 3.8, т.е. безопасный метод будет отбирать в среднем около 4 тестов. Сведения о методике предсказания суммированы в.

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

Порождение новых тестов при структурном регрессионном тестировании обычно обусловлено недостаточным уровнем покрытия. Новые тесты разрабатываются так, чтобы задействовать еще не покрытые участки исходного кода. Процесс прекращается, когда уровень покрытия кода достигает требуемой величины (например, 80%). Разработка новых тестов при функциональном регрессионном тестировании является менее тривиальной задачей и обычно связана с вводом новых требований либо с желанием проверить некоторые сценарии работы системы дополнительно.
Основой большинства программных продуктов для управляющих применений, находящихся в промышленном использовании, является цикл обработки событий. Сценарий работы с системой, построенной по такой архитектуре, состоит из последовательности транзакций, управление после обработки каждой транзакции вновь передается циклу обработки событий. Выполнение транзакции приводит к изменению состояния программы; в результате некоторых транзакций происходит выход из цикла и завершение работы программы. Тесты для таких программ представляют собой последовательность транзакций.
Развитие программного продукта от версии к версии влечет за собой появление новых состояний. Поскольку большинство тестов легко может быть расширено путем добавления дополнительных транзакций в список, новые тесты можно создавать путем суперпозиции уже имеющихся, с учетом информации об изменении состояния тестируемой системы в результате прогона теста. Этот подход позволяет указать, какого рода новые тесты с наибольшей вероятностью обнаружат ошибки.
Обозначим тестируемую программу P, а множество ее тестов T = {t1, t2, … , tn}. Будем считать, что состояние тестируемой программы s определяется совокупностью значений некоторого подмножества глобальных и локальных переменных. При создании новых тестов будем рассматривать состояния программы перед запуском теста (s0) и после его окончания (sj). Информацию об этих состояниях необходимо собирать для каждого теста по результатам запуска на предыдущей версии продукта. Методика порождения новых тестов на основе анализа «подозрительных» состояний сводится к описанной ниже последовательности действий.

1. Вычисление списка глобальных и локальных переменных, определяющих состояние программы s.
2. Сбор информации (на основе анализа профиля программы, полученного на предыдущей версии продукта i-1, для каждого существующего теста tj) о состояниях программы перед запуском теста и после его окончания (т.е. s0 и sj). Множество таких состояний обозначается Si - 1: Si – 1 = s0{sj | j}
3. Выполнение на текущей версии продукта i новых и выбранных регрессионных тестов из множества T’ . По аналогии с Si–1 вычисляется множество Si, которое сохраняется под управлением системы контроля версий.
4. Оценка «подозрительных» с точки зрения наличия ошибок множества новых по сравнению с предыдущими версиями состояний Ni в соответствии со следующей формулой: Ni = Si \ Si - 1
5. Анализ состояний множества Ni, в которых дальнейшая работа продукта невозможна в соответствии со спецификацией. Предмет анализа - определить создаются ли эти состояния в результате выполнения тестов, проверяющих нештатные режимы работы продукта, или каких-либо других тестов. В последнем случае фиксируется ошибка.
6. Исключение нештатных состояний из множества Ni.
7. Переход к шагу 10, если новых состояний, допускающих продолжение выполнения программы, не обнаружено, т.е. Ni=.
8. Для каждого состояния множества Ni вычисление вектора отличия от исходного состояния s0, т.е. множества переменных, измененных по сравнению с s0.
9. Модификация множества измененных строк исходного кода P на основе информации об измененных переменных и использование какой-либо методики отбора тестов для выборочного регрессионного тестирования.
10. Повторное выполнение шагов 3-9 до достижения состояния Ni= либо до истечения времени, отведенного на регрессионное тестирование. Использование методов разбиения на классы эквивалентности для досрочного принятия решения о прекращении цикла тестирования, если ни один из тестов, созданных на очередном этапе, не принадлежит к новому классу эквивалентности.

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