Файл: Тестирование программного обеспечения.pdf

По степени доступа к коду различают два типа тестирования: тестирование "черного ящика" (black box), или функциональное тестирование - без доступа к коду, и "белого ящика" (white box), или структурное тестирование - тестирование кода.

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

В случае "белого ящика" тестировщик пишет тесткейсы, основываясь исключительно на коде программы (тесты на правильность кода).

Расширение black-box тестирования, в котором также применяется изучение кода, называется тестированием "серого ящика" (grey box). В этом случае правильность поведения определяется любым удобным способом, в том числе изучением кода, что позволяет писать более эффективные black-box тесты (то есть тесты на правильность поведения).

2.2. Методы отбора тестов для Black-box тестирования

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

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

2.3. Тестирование сценариев использования - юз-кейсов (use-cases)

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

Чтобы уменьшить число тестов, можно проверить только те переходы, которые имеют смысл для пользователя. Use-case - это логически завершенная последовательность действий. Например, открытие файла в Notepad - это use-case, а выбор пункта меню "Открыть файл" в Notepad - это не use-case, а лишь первый шаг юз-кейса "открытие файла".

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

Здесь проверяется правильность перехода программы между внутренними состояниями при выполнении определенных операций (т.е. при определенных входных данных).

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

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

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

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

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. Тестирование запрещенных значений

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

2.5. Попарное тестирование.

Метод классов эквивалентности применяется для тестирования каждого входного параметра по отдельности.

Пусть наша программа принимает на вход десяток параметров. Баги, возникающие при определенном сочетании всех десяти параметров, довольно редки. Вообще, взаимное влияние параметров, о котором пользователь не знает - это баг интерфейса (интерфейс интуитивно не понятен).

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

Таким образом, можно упростить себе задачу и протестировать все возможные значения для каждой из пар параметров. Такой подход называется попарным тестированием (pairwise testing).

Вот пример. Пусть имеется 3 двоичных входных параметра (3 чекбокса). Количество всех возможных комбинаций - 2 в степени 3 = 8 , значит, нужно произвести 8 тестов. Давайте попробуем сэкономить, тестируя чекбоксы попарно.

Выпишем все комбинации для первого и второго чекбоксов:

1-й 2-й

0 0

0 1

1 0

1 1

Добавим третий столбец так, чтобы во втором и третьем столбце получились все 4 двоичные комбинации. Это можно сделать разными способами, мы сделаем так (на первый столбец можно не обращать внимания):

1-й 2-й 3-й

0 0 0

0 1 0

1 0 1

1 1 1

Итак, с помощью четырех наборов входных данных (четырех тестов) мы протестируем две пары параметров: первый со вторым и второй с третьим. Осталось протестировать пару "первый с третьим".

Выпишем отдельно 1 и 3 столбцы:

1-й 3-й

0 0

1 1

Как видно, мы имеем здесь две из четырех возможных комбинаций. Комбинации "01" и "10" здесь отсутствуют, а комбинации "00" и "11" присутствуют два раза. Ну что же, добавим еще 2 строки (еще два теста)

1-й 3-й

0 0

1 1

0 1

1 0

Вернем второй столбец на его законное место:

1-й 2-й 3-й

0 0 0

0 1 0

1 0 1

1 1 1

0 1

1 0

Выходит, что последние два теста можно проходить при любых значениях второго параметра. Можно дописать для определенности нули в эти пустые места:

1-й 2-й 3-й

0 0 0

0 1 0

1 0 1

1 1 1

0 0 1

1 0 0

Получаем 6 тестов вместо 8 при полном переборе.

Можно ли сэкономить еще? Оказывается, можно.

Вернемся к 1 шагу:

1-й 2-й

0 0

0 1

1 0

1 1

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

1-й 2-й 3-й

0 0 1

0 1 0

1 0 0

1 1 1

Все комбинации для 1 и 2, а также для 2 и 3 параметра здесь есть. Посмотрим теперь на комбинации 1 и 3 параметра

1-й 3-й

0 1

0 0

1 0

1 1

Изменив порядок значений в третьем столбце, мы одним махом убили двух зайцев: скомбинировали и 2-й с 3-м, и 1-й с 3-м параметры.

Итого имеем всего 4 строки, то есть 4 теста, эквивалентные первоначальным шести:

1-й 2-й 3-й

0 0 1

0 1 0

1 0 0

1 1 1

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

Вот строгое определение ортогонального массива:

Ортогональный массив OA(N,k,s,t) - это двумерный массив из N рядов (итераций) и k колонок (факторов) из набора S (т.е. факторы могут принимать любое из s значений), обладающий свойством:

выбрав любые t колонок (0<=t<=k) мы получим в рядах все комбинации сочетаний из s по t (Количество повторений одинаковых комбинаций обозначают через λ. Чаще всего рассматривают массивы, где λ = 1, т.е. каждая комбинация встречается только один раз). Параметр t называют мощностью ортогонального массива.

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

2.5. Использование информации о программе при Gray-Box тестировании

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

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

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

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

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

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

2.5.2. Информация о других внешних системах

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