Тестирование классов эквивалентности.

Чтобы удостовериться в правильности поведения программы при различных входных данных, в идеале следует протестировать все возможные значения для каждого элемента этих данных. (а также все возможные сочетания входных параметров)

 

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

Пример взят из книги A Practitioner's guide to Sofware Test Design (Lee Copeland).

 

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

 

0-13 лет - не нанимать

14-17 лет - можно нанимать на неполный день

18-54 года - можно нанимать на полный день

55-99 лет - не нанимать

 

Чтобы проверить все возможные разрешенные данные (только разрешенные!) нам нужно протестировать ввод чисел от 0 до 99. (Возможен ведь еще ввод отрицательных чисел и нечисловых данных.) Так ли необходимо тестировать все числа от 0 до 99? В случае, если программа анализирует каждое чиcло по отдельности, вот таким образом, то видимо, да:

...

if (age == 13) hireStatus="NO";

if (age == 14) hireStatus="PART";

if (age == 15) hireStatus="PART";

if (age == 16) hireStatus="PART";

if (age == 17) hireStatus="PART";

if (age == 18) hireStatus="FULL";

...

 

Но к счастью, программы обычно пишут по-другому:

 

if (age >= 0 && age <=13)

hireStatus="NO";

if (age >= 14 && age <=17)

hireStatus="PART";

if (age >= 18 && age <=54)

hireStatus="FULL";

if (age >= 55 && age <=99)

hireStatus="NO";

 

 

Становится очевидным, что можно протестировать одно из чисел каждого диапазона. Например: 5, 15, 20, 60. А также граничные значения (первое и последнее значения из каждого диапазона): 0, 13, 14, 17, 18, 54, 55, 99.

 

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

а) разбиение множества всех значений входной переменной на подмножества (классы эквивалентности), а затем

б) тестирование одного любого значения из каждого класса.

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

 

В данном случае имеем 12 классов эквивалентности (каждое из 8 граничных значений по сути является отдельным классом).

Чтобы проверить правильность работы программы на всех разрешенных данных, нужно провести 12 тестов.

 

Запрещенные данные тестируются аналогично - можно выделить классы эквивалентности "дробное число от 0 до 99", "отрицательное число", "число больше 99", "набор букв", "пустая строка" и т.д.

 

Таким образом, метод классов эквивалентности можно разделить на три этапа:

1. Тестирование разрешенных значений

2. Тестирование граничных значений

3. Тестирование запрещенных значений

 

Часто в литературе второй и третий этапы называют отдельными методами, но сути это не меняет.

 

Тестирование «белого ящика»

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

Тестирование «белого ящика» применяется на уровне модулей и графовой модели программы путем выбора тестовых ситуаций, подготовки данных и включает тестирование следующих элементов:

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

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

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

Тестирование «белого ящика» — это технология тестирования, которая применяется на этапе разработки (иногда ее еще называют тестированием «стеклянного ящика»).

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

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

■ полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте;

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

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

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

Тестирование «белого ящика» — часть процесса программирования.

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

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

Покрытие кода

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

• покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована?

• покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована?

• покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы?

• покрытие функций — каждая ли функция программы была выполнена?

• покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены?

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

 

Тестирование «серого ящика»

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

 

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

 

Информация о базе данных

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

Например, если вводимая фамилия пользователя записывается в поле типа "строка" длиной 128 символов, мы должны:

1) попробовать найти фамилию длиннее, чем 128 символов - здесь будет довольно серьезный баг, если такие фамилии существуют - человек с такой фамилией не сможет воспользоваться нашей системой.

2) вне зависимости от того, существуют или нет такие фамилии, попробовать ввести строку длиннее 128 символов - программа не должна ломаться (должно показываться внятное сообщение об ошибке)