Учебное пособие: Технология раработки програмного обеспечения УП
91
При
таком
подходе
обнаружение
всех
ошибок
в
програм-
ме
является
критерием
исчерпывающего
входного
тестирова-
ния.
Последнее
может
быть
достигнуто,
если
в
качестве
тесто-
вых
наборов
использовать
все
возможные
наборы
входных
дан-
ных.
Поэтому
для
тестирования
даже
небольшой
программы
требуется
бесконечное
число
тестов.
Как
пример
можно
при-
вести
задачу
о
треугольниках.
Даны
три
числа
—
A,
B
и
C.
Тре-
буется
определить,
могут
ли
эти
числа
являться
длинами
сторон
треугольника,
и
если
да,
то
является
ли
этот
треугольник
пря-
моугольным,
равнобедренным
или
равносторонним.
Очевидно,
что
если
A,
B
и
C
являются
вещественными
числами,
то
имеет-
ся
бесконечное
количество
комбинаций
их
значений.
Если
такое
испытание
представляется
сложным,
то
еще
сложнее
создать
исчерпывающий
тест
для
большой
программы.
Образно
говоря,
число
тестов
можно
оценить
«числом,
боль-
шим,
чем
бесконечность».
Из
изложенного
следует,
что
построение
исчерпывающе-
го
входного
теста
невозможно.
Это
подтверждается
двумя
ар-
гументами:
во-первых,
нельзя
создать
тест,
гарантирующий
от-
сутствие
ошибок;
во-вторых,
разработка
таких
тестов
противо-
речит
экономическим
требованиям.
Поскольку
исчерпывающее
тестирование
исключается,
нашей
целью
должна
стать
макси-
мизация
результативности
капиталовложений
в
тестирование
(иными
словами,
максимизация
числа
ошибок,
обнаруживае-
мых
одним
тестом).
Для
этого
мы
можем
рассматривать
внут-
реннюю
структуру
программы
и
делать
некоторые
разумные,
но,
конечно,
не
обладающие
полной
гарантией
достоверности
предположения.
6.2.2 Тестирование программы как белого ящика
Стратегия
белого
ящика,
или
стратегия
тестирования,
управляемого
логикой
программы,
позволяет
исследовать
внут-
реннюю
структуру
программы.
В
этом
случае
тестирующий
получает
тестовые
данные
путем
анализа
логики
программы
(к
92
сожалению,
здесь
часто
не
используется
спецификация
про-
граммы).
Сравним
способ
построения
тестов
при
данной
стратегии
с
исчерпывающим
входным
тестированием
стратегии
черного
ящика.
Непосвященному
может
показаться,
что
достаточно
по-
строить
такой
набор
тестов,
в
котором
каждый
оператор
испол-
няется
хотя
бы
один
раз;
нетрудно
показать,
что
это
неверно.
Не
вдаваясь
в детали,
укажем
лишь,
что
исчерпывающему
вход-
ному
тестированию
может
быть
поставлено
в
соответствие
ис-
черпывающее
тестирование
маршрутов.
Подразумевается,
что
программа
проверена
полностью,
если
с
помощью
тестов
уда-
ется
осуществить
выполнение
этой
программы
по
всем
возмож-
ным
маршрутам
ее
потока
(графа)
передач
управления.
Последнее
утверждение
имеет
два
слабых
пункта.
Один
из
них
состоит
в
том,
что
число
не
повторяющих
друг
друга
маршрутов
в
программе
—
астрономическое.
Чтобы
убедиться
в
этом,
рассмотрим
представленный
на
рис.
6.1
граф
передач
управления
простейшей
программы.
Каждая
вершина
или
кру-
жок
обозначают
участок
программы,
содержащий
последова-
тельность
линейных
операторов,
которая
может
заканчиваться
оператором
ветвления.
Дуги,
оканчивающиеся
стрелками,
соот-
ветствуют
передачам
управления.
По-видимому,
граф
описыва-
ет
программу
из
10–20
операторов,
включая
цикл
DO,
который
исполняется
не
менее
20
раз.
Внутри
цикла
имеется
несколько
операторов
IF.
Для
того,
чтобы
определять
число
неповторяю-
щихся
маршрутов
при
исполнении
программы,
подсчитаем
число
неповторяющихся
маршрутов
из
точки
A
в
B
в
предпо-
ложении,
что
все
приказы
взаимно
независимы.
Это
число
вы-
числяется
как
сумма
5
20
+
5
19
+
…
+
5
1
=
100
триллионов,
где
5
—
число
путей
внутри
цикла.
Приведем
такой
пример:
если
допустить,
что
на
составление
каждого
теста
мы
тратим
пять
минут,
то
для
построения
набора
тестов
нам
потребуется
при-
мерно
один
миллиард
лет.
93
Рис.
6.1
—
Граф
передач
управления
небольшой
программы
Второй
слабый
пункт
утверждения
заключается
в
том,
что,
хотя
исчерпывающее
тестирование
маршрутов
является
полным
тестом
и
хотя
каждый
маршрут
программы
может
быть
проверен,
сама
программа
может
содержать
ошибки.
Это
объ-
ясняется
следующим
образом.
Во-первых,
исчерпывающее
тес-
тирование
маршрутов
не
может
дать
гарантии
того,
что
про-
грамма
соответствует
описанию.
Например,
вместо
требуемой
программы
сортировки
по
возрастанию
случайно
была
написа-
на
программа
сортировки
по
убыванию.
В
этом
случае
ценность
тестирования
маршрутов
невелика,
поскольку
после
тестирова-
ния
в
программе
окажется
одна
ошибка,
т.е.
программа
неверна.
Во-вторых,
программа
может
быть
неверной
в
силу
того,
что
пропущены
некоторые
маршруты.
Исчерпывающее
тестирова-
ние
маршрутов
не
обнаружит
их
отсутствия.
В-третьих,
исчер-
пывающее
тестирование
маршрутов
не
может
обнаружить
оши-
бок,
появление
которых
зависит
от
обрабатываемых
данных.
B
A
≤ 20
раз
94
Существует
множество
примеров
таких
ошибок.
Приведем
один
из
них.
Допустим,
в
программе
необходимо
выполнить
сравнение
двух
чисел
на
сходимость,
т.е.
определить,
является
ли
разность
между
двумя
числами
меньше
предварительно
оп-
ределенного
числа.
Может
быть
написано
выражение
IF ((A – B) < EPSILON)…
Безусловно,
оно
содержит
ошибку,
поскольку
необходимо
выполнить
сравнение
абсолютных
величин.
Однако
обнаруже-
ние
этой
ошибки
зависит
от
значений,
использованных
для
A
и
B,
и
ошибка
не
обязательно
будет
обнаружена
просто
путем
исполнения
каждого
маршрута.
В
заключение
отметим,
что,
хотя
исчерпывающее
входное
тестирование
предпочтительнее
исчерпывающего
тестирования
маршрутов,
ни
то,
ни
другое
не
могут
стать
полезными
страте-
гиями,
потому
что
оба
они
нереализуемы.
Возможно,
поэтому
реальным
путем,
который
позволит
создать
хорошую,
но,
ко-
нечно,
не
абсолютную
стратегию,
является
сочетание
тестиро-
вания
программы
и
как
черного,
и
как
белого
ящиков.
Этот
во-
прос
обсуждается
в
п.
6.4.
6.2.3 Принципы тестирования
Сформулируем
основные
принципы
тестирования,
ис-
пользуя
главную
предпосылку
настоящего
раздела
о
том,
что
наиболее
важными
в
тестировании
программ
являются
вопросы
психологии.
Эти
принципы
интересны
тем,
что
в
основном
они
интуитивно
ясны,
но,
в
то
же
время,
на
них
часто
не
обращают
должного
внимания.
Описание
предполагаемых
значений
выходных
данных
или
результатов
должно
быть
необходимой
частью
тестового
набора.
Нарушение
этого
очевидного
принципа
представляет
од-
ну
из
наиболее
распространенных
ошибок.
Ошибочные,
но
правдоподобные
результаты
могут
быть
признаны
правильны-
ми,
если
результаты
теста
не
были
заранее
определены.
Здесь
мы
сталкиваемся
с
явлением
психологии:
мы
видим
то,
что
мы
хотим
увидеть.
Другими
словами,
несмотря
на
то,
что
тестиро-
вание
по
определению
—
деструктивный
процесс,
есть
подсоз-
95
нательное
желание
видеть
корректный
результат.
Один
из
спо-
собов
борьбы
с
этим
состоит
в
поощрении
детального
анализа
выходных
переменных
заранее
при
разработке
теста.
Поэтому
тест
должен
включать
две
компоненты:
описание
входных
дан-
ных
и
описание
точного
и
корректного
результата,
соответст-
вующего
набору
входных
данных.
Необходимость
этого
подчеркивал
логик
Копи:
«Пробле-
ма
может
быть
охарактеризована
как
факт
или
группа
фактов,
которые
не
имеют
приемлемого
объяснения,
кажутся
необыч-
ными
или
которые
не
удается
подогнать
под
наши
представле-
ния
или
предположения.
Очевидно,
что
если
что-нибудь
под-
вергается
сомнению,
то
об
этом
должна
иметься
какая-то
пред-
варительная
информация.
Если
нет
предположений,
то
не
мо-
жет
быть
и
неожиданных
результатов».
Следует
избегать
тестирования
программы
ее
автором.
Этот
принцип
следует
из
обсуждавшихся
ранее
положе-
ний,
которые
определяют
тестирование
как
деструктивный
про-
цесс.
После
выполнения
конструктивной
части,
при
проектиро-
вании
и
написании
программы
трудно
быстро
(в
течение
одного
дня)
перестроиться
на
деструктивный
образ
мышления.
Многие,
кому
приходилось
самому
делать
дома
ремонт,
знают,
что
про-
цесс
обрывания
старых
обоев
(деструктивный
процесс)
нелегок,
но
он
просто
невыносим,
если
не
кто-то
другой,
а
вы
сами
пер-
воначально
их
наклеивали.
Вот
так
же
и
большинство
програм-
мистов
не
могут
эффективно
тестировать
свои
программы,
по-
тому
что
им
трудно
демонстрировать
собственные
ошибки.
В
дополнение
к
этой
психологической
проблеме
следует
отметить
еще
одну,
не
менее
важную:
программа
может
содер-
жать
ошибки,
связанные
с
неверным
пониманием
постановки
или
описания
задачи
программистом.
Тогда
существует
вероят-
ность,
что
к
тестированию
программист
приступит
с
таким
же
недопониманием
своей
задачи.
Тестирование
можно
уподобить
работе
корректора
или
рецензента
над
статьей
или
книгой.
Многие
авторы
представ-
ляют
себе
трудности,
связанные
с
редактированием
собствен-
ной
рукописи.
Очевидно,
что
обнаружение
недостатков
в
своей
деятельности
противоречит
человеческой
психологии.