Регрессионное

тестирование
Назначение регрессионного тестирования. В каких случаях
требуется его проводить? Выбор тест-комплектов для
регрессионного тестирования. Приоритизация и оптимизация
тест-комплектов.

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Регрессионное тестирование

Как меняется ПО в течение жизненного цикла?

Особенности регрессионного тестирования

Типы регрессионного тестирования

Виды регрессионного тестирования

Полное регрессионное тестирование

Выборочное регрессионное тестирование

Как выбрать тесты для регрессионного тестирования?

Анализ кода

Анализ бизнес-логики

Управление регрессионными тестами

Жизненный цикл теста

Когда надо добавлять новый регрессионный тест?

Когда можно удалять регрессионный тест из набора?

Нужно ли менять что-то в регрессионных тестах?

Оптимизация регрессионных тестов

Приоритизация регрессионных тестов

Когда проводят регрессионное тестирование?

Тестовое покрытие (Test Coverage)

Покрытие требований (Requirements Coverage)

Покрытие кода (Code Coverage)

Тестовое покрытие на базе анализа потока управления

Практика

Покрытие требований

Калькулятор

Домашнее задание

Дополнительные материалы

Используемая литература

© geekbrains.ru 1

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Регрессионное тестирование
Как меняется ПО в течение жизненного цикла?
Часто ПО меняется инкрементально, небольшими независимыми шагами. Происходит изменение
существующего кода – исправляются ошибки. Меняются требования на реализованную
функциональность и требуется вносить правки в код. Добавляется новая функциональность. При
реализации новых возможностей код в ПО адаптируется для поддержки новых функций.

При этом даже самые незначительные изменения в программном коде могут серьезно повлиять на
качество ПО. Чтобы убедиться в отсутствии ошибок в реализованном функционале ПО, проводят
регрессионное тестирование.

Особенности регрессионного тестирования

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

Регрессионное тестирование направлено на проверку изменений, сделанных в приложении или

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

Регрессионное тестирование проводится после того, как хотя бы часть запланированной

функциональности реализована, проверена и претерпела какие-то изменения (например, в ПО
добавили новую функцию).

Как правило, для регрессионного тестирования используются тест-кейсы, написанные на ранних

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

Регрессионное – основной (и наиболее продолжительный) вид тестирования в процессе разработки

ПО.

Главная задача этапа сопровождения – реализовать систематическую обработку изменений в коде.

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

Для регрессионного тестирования функциональных возможностей, изменение которых не

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

Выполняя регрессионное тестирование, мы стремимся обнаружить регресс в ПО, которое претерпело

изменения.

Типы регрессионного тестирования

● Регрессия ошибок (Bug regression) – попытка доказать, что исправленная ошибка на самом
деле не исправлена;

● Регрессия старых ошибок (Old bugs regression) – попытка доказать, что недавнее

© geekbrains.ru 2

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

 изменение кода или данных сломало исправление старых ошибок, и они стали снова
воспроизводиться;

● Регрессия побочного эффекта (Side effect regression) – попытка доказать, что недавнее
изменение кода или данных сломало другие части разрабатываемого приложения.

Виды регрессионного тестирования

Представим приложение-калькулятор, которое уже обладает достаточным объемом функций. Если
происходит модификация программы (добавили новую функцию), то мы должны проверить, что ранее
разработанные функции остались нетронутыми и работают так же, как и до изменения. Чтобы это
проверить, мы проводим регрессионное тестирование. Мы можем выполнить все тесты,
разработанные ранее, и провести полное регрессионное тестирование. Другой вариант – провести
выборочное регрессионное тестирование: выполнить часть тестов.

Полное регрессионное тестирование

При выполнении полного регрессионного тестирования уменьшается риск пропустить критические
ошибки в ПО, но увеличивается время на тестирование.

Рассмотрим на примере, как увеличивается количество тестов и время регрессионного тестирования.

Приложение-калькулятор разрабатывалось в несколько итераций. На первой сделали операцию

сложения, и появился «Тест-комплект 1», в котором описаны тесты на операцию сложения.
Регрессионное тестирование пока не проводим, т.к. это первая итерация и до нее у нас ничего не
было.

На второй итерации сделали операцию вычитания. Приложение изменилось. Операцию вычитания

проверили и создали для нее «Тест-комплект 2». При регрессионном тестировании проверяются все
тесты из «Тест-комплекта 1».

В третьей итерации добавили новую операцию, для которой создали «Тест-комплект 3». Проводя
регрессионное тестирование, нужно выполнять все тесты из тест-комплектов 1 и 2. Аналогично для
каждой последующей итерации. При этом время, выделенное на итерацию для добавления новой
функции, не меняется, но время на проведение полного регрессионного тестирования растет вместе
с функциональностью приложения.

© geekbrains.ru 3

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Регрессионное тестирование целесообразно автоматизировать. Без автоматизации проводить его
полностью – дорогое удовольствие для больших проектов.

Выборочное регрессионное тестирование

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

Отличия выборочного регрессионного тестирования от полного:

● Занимает меньше времени;

● С ростом функциональности в набор регрессионного тестирования добавляется меньше

тестов;

© geekbrains.ru 4

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

 ● Выше риск пропустить ошибки.

Как выбрать тесты для регрессионного

тестирования?
Основная проблема выборочного регрессионного тестирования – отбор тестов. Тестировщику,
который не читает код на уровне разработчика, сложно определить, на каких частях ПО отразятся
внесенные изменения.

Рассмотрим способы выбора регрессионных тестов, основанные на анализе программного кода и

бизнес-логики приложения.

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

«Квадратное уравнение – алгебраическое уравнение вида ​A​x2​​+ B

​ ​x + C
​ ​= 0»

A, B, C – коэффициенты квадратного уравнения. Корнями квадратного уравнения называются

значения переменной х, при которых уравнение принимает значение 0.

2​
Чтобы найти корни квадратного уравнения, нужно вычислить дискриминант по формуле D = B​ - 4AC.

Далее, в зависимости от значения дискриминанта, вычисляются корни:

© geekbrains.ru 5

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Теперь рассмотрим функцию ​Equation​, которая находит корни квадратного уравнения:

double​ ​Equation​(​int​ ​Print​,​ ​float​ A​,​ ​float​ B​,​ ​float​ C​,​ ​float​&​ X1​,​ ​float​&​ X2​)
{
float​ D ​=​ B ​*​ B ​-​ ​4.0​ ​*​ A ​*​ C​;
​
if​ ​(​
​ D ​>=​ ​0​
)
​
{
X1 ​=​ ​
(-​B ​+​ sqrt​(​D​))​ ​/​ ​2.0​ ​/​ A​;
X2 ​=​ ​
(-​B ​-​ sqrt​(​D​))​ ​/​ ​2.0​ ​/​ A​;
​
}
​
else
​
{
X1 ​=​ ​
-​B ​/​ ​2.0​ ​/​ A​;
X2 ​=​ sqrt​ (​D​)​ ​/​ ​2.0​ ​/​ A​;
​
}
if​ ​(​
​ Print​)
printf​(​"Solution: %f, %f\n"​,​ X1​,​ X2​);
​
return​ D;
}

В строке 1 описаны входные параметры функции ​Equation​. Это коэффициенты квадратного

уравнения ​A​
, ​B​, ​C​, и флаг ​Print​. Ненулевое значение флага ​Print указывает, что полученные решения
нужно вывести на экран (см. строку 15).

В строке 3 определяется значение дискриминанта. В строках 5 и 6 определяются корни уравнения

для дискриминанта D >= 0. В строках 11 и 12 определяются корни при отрицательном значении
дискриминанта. В строке 15 найденные корни уравнения выводятся на экран, если флаг ​Print больше
0.

К выходным параметрам функции ​Equation относятся ​Х1 и ​Х2​, предназначенные для хранения
корней уравнения. Возвращаемое значение функции – дискриминант уравнения.

Допустим, что у нас существуют следующие тесты для проверки функции E

​ quation​:

Тест Входные Ожидаемые выходные значения

параметры

A B C Print X1 X2 Возвращаемое Выводимая строка

значение

1 1 1 -6 1 2 -3 25 Solution: X1 = 2, X2 = -3

2 2 -3 5 1 0.75 5.5678 -31 Solution: X1 = 0.75+5.567764i,

X2 = 0.75-5.567764I

3 1 2 0 0 0 -2 4

4 1 2 1 0 -1 -1 0

5 1 2 0 -1 2 -4

По результатам второго теста было определено, что в функции содержится ошибка. Если
дискриминант оказывался отрицательным, то функция падала и прекращала выполнение. Создали
новую версию этой функции, в которой должны были исправить расчет корней уравнения, когда
дискриминант отрицательный. Функция E
​ quation​– измененная версия:

© geekbrains.ru 6

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

 double​ ​Equation​(​int​ ​Print​,​ ​float​ A​,​ ​float​ B​, ​float​ C​,​ ​float​&​ X1​,​ ​float​&​ X2​)
{
float​ D ​=​ B ​*​ B ​-​ ​4.0​ ​*​ A ​*​ C​;
​

​ f​ ​(​
i D ​>=​ ​0​
)
​
{
X1 ​
=​ ​
(-​B ​+​ sqrt​(​D​))​ ​/​ ​2.0​ ​/​ A​;
X2 ​
=​ ​
(-​B ​-​ sqrt​(​D​))​ ​/​ ​2.0​ ​/​ A​;
​
}
​
else
​
{
X1 ​
=​ ​
-​B ​/​ ​2.0​ ​/​ A​;
X2 ​
=​ sqrt​ (-​D​);
​
}
if​ ​(​
​ Print​)
​
{
​if​ ​
(​D ​>=​ ​
0​)
printf​(​"Solution: X1 = %f, X2 = %f\n"​,​ X1​,​ X2​);
​else
printf​(​"Solution: X1 = %f+%fi, X2 = %f-%fi\n"​,​ X1​,​ X2​,​ X1​,​ X2​);
​
}
​
return​ D​;
}

В измененной версии была исправлена ошибка в строке 13 и добавлен новый формат вывода
комплексных корней, который затронул весь формат вывода на строках с 17 по 20.

Для регрессионного тестирования данной функции достаточно выполнить тесты 1 и 2. Первый тест
проверит правильность вывода на экран вещественных корней уравнения. Второй – правильно ли
рассчитываются и выводятся на экран комплексные корни уравнения.

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

Анализ бизнес-логики
Наиболее подходящим способом для определения тестов для выборочного регрессионного
тестирования является анализ бизнес-логики приложения. Для него используются требования,
спецификация и интуиция тестировщика.

Представим сайт интернет-магазина, в котором нового покупателя должен подтвердить менеджер

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

● Регистрация нового покупателя;

● Подтверждение покупателя менеджером;

● Авторизация покупателя;

● Просмотр товаров в каталоге;

© geekbrains.ru 7

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

 ● Заказ товаров;

● Отправка отзыва на товар.

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

Управление регрессионными тестами

Жизненный цикл теста
Жизнь теста начинается, когда его создали и добавили в базу тестов. Тест добавляется на основе
требований к новой функциональности или при обнаружении ошибки в ПО.

Новый тест выполняется первый раз, когда тестируется новая функциональность или проверятся
исправление ошибки.

Тест считается пригодным для повторного использования, если увеличивает покрытие или
способствует выявлению ошибки. В противном случае он считается устаревшим и отбрасывается.
Устаревшими тестами могут быть не только те, которые уже не могут выполниться, так как потеряли
актуальность ввиду изменившейся функциональности, но и те тесты, которые не увеличивают
покрытие. Например, в начале разработки ПО для интернет-магазина была ошибка при регистрации
пользователя, если заполнено поле «Отчество». На эту ошибку завели тест. Но после исправления
бага он станет устаревшим, т.к. не увеличивает покрытие: поле «Отчество» покроет тест с
заполнением ФИО покупателя.

Во время регрессионного тестирования могут выполняться не все тесты, пригодные для повторного
использования.

© geekbrains.ru 8

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Когда надо добавлять новый регрессионный тест?
● Когда в ПО появилась новая функциональность;

● Когда в ПО была исправлена ошибка;

● Когда хотим улучшить тестовое покрытие ПО;

● Когда можем себе позволить добавить новый неповторяющийся тест.

Регрессионный набор тестов – не статичный, он меняется со временем жизни ПО и в него достаточно

часто добавляются новые тесты. Чем их больше, тем лучше тестовое покрытие. Но когда тестов
становится так много, что недостаточно времени на них, – начинаются проблемы.

Когда можно удалять регрессионный тест из набора?

Со временем регрессионный набор нужно проредить и проверить, что все тесты необходимы и имеют
обоснования к выполнению.

Регрессионный тест нужно удалять из набора:

● Когда тест дублирует другие тесты;

● Когда тест не улучшает тестовое покрытие;

● Когда тест ни разу не обнаружил ошибки за все время тестирования;

● Когда тест обнаруживает такие же ошибки, как и другие тесты.

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

Нужно ли менять что-то в регрессионных тестах?

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

Оптимизация регрессионных тестов

Со временем даже при удалении некоторых тестов регрессионный набор разрастается. Поэтому
тесты нужно оптимизировать:

● Похожие тесты можно склеить (есть одинаковые шаги теста, но разные проверки);

● Крупные тесты можно разбить на несколько или сократить, выкинув лишние участки;

● Мелкие тесты можно склеить.

Приоритизация регрессионных тестов

Регрессионные тесты можно запустить без специальной приоритизации – так, как они отсортированы
в базе тестов. Но такой подход не универсален. Даже при выборочном регрессионном тестировании

© geekbrains.ru 9

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

может не хватать времени на выполнение всего регрессионного набора. Или тестировщик находит
критичные ошибки достаточно поздно, а хотелось бы о них узнавать раньше. Поэтому набор нужно
разбивать на поднаборы и каждому присваивать приоритеты.

Зачем нужна приоритизация?

● Чем раньше мы узнаем о том, что в ПО появилась серьезная регрессионная ошибка, тем
скорее ее исправят;

● Часто причиной провала тестов (напрямую не связанных друг с другом) является одна и та же
ошибка в ПО;

● Время на тестирование – ограниченный ресурс. Необходимо найти наибольшее число важных

ошибок с учетом всех ограничений.

На основе чего формируется приоритет регрессионных тестов?

● На интуиции:

○ Подход работает, если интуиция развита;

○ Нужны глубокие знания в ПО.

● На знаниях о тестовом покрытии ПО:

○ Сначала выполняются тесты, которые имеют наибольшее покрытие ПО;

○ Сначала выполняются тесты, которые покрывают важные компоненты ПО;

● На истории разработки:

○ Приоритет отдается тем тестам, которые чаще других обнаруживали регрессионные

ошибки;

○ Первыми выполняются тесты, проверяющие корректность работы наиболее

«проблемных» компонентов ПО.

Когда проводят регрессионное

тестирование?
Распространено мнение, что регрессионное тестирование обязательно проводится после выхода
каждой новой версии ПО. На практике это не всегда так. Если новая версия отличается от старой тем,
что в разных разделах ПО исправлялись ошибки и вносились изменения, то нужно провести
регрессионное тестирование.

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

Тестовое покрытие (Test Coverage)

Когда уже существует проект, мы проводим регрессионное тестирование и накопили достаточно

© geekbrains.ru 10

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

тестовых артефактов (тест-планов, тест-кейсов, чек-листов), то можем заметить, что продукт окутан
плотным кольцом тестовых сценариев. Но сложно оценить, насколько хорошо проводится
тестирование ПО.

Как показывает практика, даже при тщательном проектировании тестов, самом тестировании и
подготовке к нему все же остаются белые пятна. Когда тестов становится много, то тестировщик
сходу не сможет ответить на вопрос: «А проверяешь ли ты вот такой сценарий?».

Тестовое покрытие – это одна из метрик оценки качества тестирования, представляющая собой
плотность покрытия требований или исполняемого кода тестами.

Если рассматривать тестирование как «проверку соответствия между реальным и ожидаемым

поведением программы, осуществляемая на конечном наборе тестов», то именно этот конечный
набор тестов и будет определять тестовое покрытие.

Чем выше требуемый уровень тестового покрытия, тем больше тестов будет выбрано для
проверки тестируемых требований или исполняемого кода.

Современное ПО и инфраструктура сложны, и провести тестирование со стопроцентным тестовым

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

Подходы к оценке и измерению тестового покрытия

● Покрытие требований (Requirements Coverage) – оценка покрытия тестами

функциональных и нефункциональных требований к продукту путем построения матриц
трассировки (traceability matrix);

● Покрытие кода (Code Coverage) – оценка покрытия исполняемого кода тестами путем
отслеживания непроверенных в процессе тестирования частей ПО;

● Тестовое покрытие на базе анализа потока управления – оценка покрытия, основанная на

определении путей выполнения кода программного модуля и создании выполняемых
тест-кейсов для покрытия этих путей.

Различия​​подходов

Метод покрытия требований сосредоточен на том, чтобы проверить соответствие набора проводимых
тестов требованиям к продукту. Анализ покрытия кода – на полноте проверки тестами разработанной
части продукта (исходного кода). Анализ потока управления – на прохождении путей в графе или
модели выполнения тестируемых функций (Control Flow Graph).

Ограничения​​
подходов

Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным
продуктом, а с существующим исходным кодом.

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

Покрытие требований (Requirements Coverage)

Расчет тестового покрытия относительно требований проводится по формуле:

T​
cov​= (L​ /L​
cov​ ) * 100%
total​

© geekbrains.ru 11

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

где:

T​
cov​– тестовое покрытие;

L​
cov​– количество требований, проверяемых тест кейсами;

L​
total​– общее количество требований.

Для измерения покрытия требований необходимо проанализировать требования к продукту и разбить

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

Тесты, не связанные с требованиями, не имеют смысла. Требования, не связанные с тестами - это

«белые пятна». Выполнив все созданные тест-кейсы, нельзя дать ответ, реализовано ли данное
требование в продукте.

Для оптимизации тестового покрытия при тестировании на основании требований рекомендуется

использовать стандартные техники тест-дизайна.

Задача оценить покрытие тестами требований к ПО и проста, и сложна одновременно. В

определенный момент аналитик или руководитель проекта выдает нам список требований к ПО – в
виде ТЗ и спецификаций или писем и устных пожеланий. Видим горизонт работ – что нужно
проверить. Составляем тест-кейсы, используя техники тест-дизайна. Получаем набор тест-кейсов.
Выполняем их, проводим несколько итераций и дополняем новыми тест-кейсами.

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

Тесты, не покрывающие ни одного требования, нужно убрать из набора, а для непроверенных

требований добавить тесты.

Открытым остается вопрос о количестве тест-кейсов на одно требование. Идеального решения в

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

Покрытие кода (Code Coverage)

Расчет тестового покрытия относительно исполняемого кода программного обеспечения проводится
по формуле:

T​
cov​= (L​
tc​/L​
code​) * 100%

где:

T​
cov​– тестовое покрытие;

L​
tc​– количество строк кода, покрытых тестами;

L​
code​– общее количество строк кода.

© geekbrains.ru 12

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Существует инструментарий, позволяющий проанализировать, какие строки кода выполнялись во
время тестирования. Благодаря этому можно значительно увеличить покрытие, добавив новые тесты
для конкретных случаев, а также избавиться от дублирующих тестов. Проведение такого анализа
кода и последующая оптимизация покрытия достаточно легко реализуется в рамках тестирования
методом белого ящика (white-box testing) при модульном, интеграционном и системном тестировании.
При тестировании методом черного ящика (black-box testing) задача дорожает, так как требует много
времени и ресурсов на установку, конфигурацию и анализ результатов работы – как со стороны
тестировщиков, так и разработчиков.

Тестовое покрытие на базе анализа потока управления

Тестирование потоков управления (Control Flow Testing) – это одна из техник тестирования белого
ящика, основанная на определении путей выполнения кода программного модуля и создания
выполняемых тест-кейсов для покрытия этих путей.

Фундаментом для тестирования потоков управления является построение графов потоков

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

● точка, на которую выполняется переход, является первой инструкцией в базовом блоке;

● базовый блок завершается инструкцией перехода.

Основными блоками графа потока управления являются:

● блок процесса – одна точка входа и одна точка выхода;

● точка альтернативы – одна точка входа, две и более точки выхода;
● точка соединения – две и более точек входа, одна точка выхода.

Например, при тестировании ПО можно составить граф перехода по формам/страницам ПО для

тестирования методом черного ящика.

Рассмотрим пример на простом сайте интернет-магазина, который имеет главную страницу, страницу
поиска, карточку товара и страницу «О нас».

Допустим, что граф возможных переходов у нас будет таким:

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

© geekbrains.ru 13

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

которое нужно устранить.

Для тестирования потоков управления определены разные уровни тестового покрытия:

Таблица 1. Уровни тестового покрытия

Уровень Название Краткое описание

Уровень 0 -- «Тестируй все, что протестируешь, а пользователи протестируют

остальное»

Уровень 1 Покрытие Каждый оператор должен быть выполнен как минимум один раз.
операторов

Уровень 2 Покрытие Каждый узел с ветвлением (альтернатива) выполнен как минимум

альтернатив / один раз.
Покрытие ветвей

Уровень 3 Покрытие Каждое условие, имеющее TRUE и FALSE на выходе, выполнено

условий как минимум один раз.

Уровень 4 Покрытие Тестовые случаи создаются для каждого условия и альтернативы.

условий
альтернатив

Уровень 5 Покрытие Достигается покрытие альтернатив, условий и условий

множественных альтернатив (уровни 2, 3 и 4).
условий

Уровень 6 «Покрытие Если в случае зацикливания количество путей становится

бесконечного бесконечным, допускается существенное их сокращение – через
числа путей» ограничение количества циклов выполнения (для уменьшения
числа тестовых случаев).

Уровень 7 Покрытие путей Все пути должны быть проверены.

Основываясь на данных этой таблицы, вы сможете спланировать необходимый уровень тестового

покрытия, а также оценить уже имеющийся.

● Уровень 0​означает, что мы тестируем, не опираясь на конкретные методики;

● Уровень 1 говорит о том, что мы каждую из наших страниц должны были открыть хотя бы
один раз;

● Уровень 2 – мы должны были, к примеру, сделать переход со главной страницы, страницы

«Каталог» и «Поиск» на страницу «Карточка товара»;

● Уровень 3 – нужно проверить, например, что отобразит страница с карточкой товара, когда
закончилась акция и цена стала прежней. Или что нельзя перейти на карточку товара,
которого нет в наличии;

● Уровень 4 и выше ​очень сложно выполним при тестировании методом черного ящика, и
достигается при необходимости автоматизированными тестами, (т.е. при тестировании
методом белого ящика). Например, если в нашем каталоге 200 000 товаров, то на уровнях,
начиная с четвертого, нужно проверить переход на карточку каждого товара, из каждого
возможного места. Для нашего примера это 200 000 *3 = 600 000 тестов.

© geekbrains.ru 14

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Практика
Покрытие требований
Для представленных ниже требований определить, является ли количество тестов на каждое
требование достаточным. Какие тест-кейсы нужно добавить? Есть ли лишние тест-кейсы?

Калькулятор
Посмотрим, как выбирать тесты для регрессионного тестирования, когда мы знаем, как
взаимодействуют между собой области программы.

Рассмотрим программу абстрактного калькулятора. Мы знаем, что он выполняет функции, указанные

на рисунке. Стрелками показано возможное отражение изменений одной функции на другую.
Например, если вносились какие-то изменения в операцию сложения, то это может отразиться на
операции вычисления синуса и косинуса.

© geekbrains.ru 15

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Разберем, тесты для каких функций нужно выполнить повторно, если внесены изменения:

1. В функцию сложения;

2. В функцию вычисления квадратного корня;

3. В функцию вычисления произведения и синуса.

Домашнее задание
Для рассмотренных ниже ситуаций нужно решить:

1. Проводить ли регрессионное тестирование всего приложения?

2. Тесты для каких разделов нужно выполнить, чтобы подтвердить отсутствие регрессии?

Ситуации:

1. ПО Калькулятор, рассмотренное на практике. В новой версии внесли изменения:

a. В функции сложения, вычитания, деления и произведения;

b. Внесли изменения для вычисления тангенса и котангенса;

2. Интернет-сайт для просмотра и заказа товаров (это наш интернет-сайт, по которому была
доработка на запрещенные продукты). Схема модулей сайта представлена ниже.
Направление стрелок указывает, на что может повлиять изменение в текущем разделе ПО. В
новой версии внесли изменения:

a. В раздел «Каталог товаров»;

b. В раздел «Оформление товара»;

c. В раздел «Менеджер/Администрирование».

© geekbrains.ru 16

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!

Дополнительные материалы
1. https://habrahabr.ru/post/106406/

2. http://qastugama.blogspot.ru/2013/01/1.html

3. https://habrahabr.ru/post/270365/

Используемая литература
Для подготовки данного методического пособия были использованы следующие ресурсы:

1. https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%80%D0%B5%D1%81%D1%81%D0
%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%
B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

2. http://kspt.icc.spbstu.ru/media/files/2013/courses/softwarequality/04-Testing-102-RT.pdf

3. http://www.intuit.ru/studies/courses/48/48/lecture/1444?page=3

4. http://2009.cee-secr.org/docs/secr2009_presentation_Itsykson_Akhin.pdf

5. http://www.protesting.ru/testing/testcoverage.html

6. https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BA%D1%80%D1%8B%D1%82%D0%B8%D0
%B5_%D0%BA%D0%BE%D0%B4%D0%B0

© geekbrains.ru 17

СКАЧАНО С WWW.SHAREWOOD.BIZ - ПРИСОЕДИНЯЙСЯ!