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

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

нательное

желание

видеть

корректный

результат.

Один

из

спо-

собов

борьбы

с

этим

состоит

в

поощрении

детального

анализа

выходных

переменных

заранее

при

разработке

теста.

Поэтому

тест

должен

включать

две

компоненты:

описание

входных

дан-

ных

и

описание

точного

и

корректного

результата,

соответст-

вующего

набору

входных

данных.

Необходимость

этого

подчеркивал

логик

Копи:

«Пробле-

ма

может

быть

охарактеризована

как

факт

или

группа

фактов,

которые

не

имеют

приемлемого

объяснения,

кажутся

необыч-

ными

или

которые

не

удается

подогнать

под

наши

представле-

ния

или

предположения.

Очевидно,

что

если

что-нибудь

под-

вергается

сомнению,

то

об

этом

должна

иметься

какая-то

пред-

варительная

информация.

Если

нет

предположений,

то

не

мо-

жет

быть

и

неожиданных

результатов».

Следует

избегать

тестирования

программы

ее

автором.

Этот

принцип

следует

из

обсуждавшихся

ранее

положе-

ний,

которые

определяют

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

как

деструктивный

про-

цесс.

После

выполнения

конструктивной

части,

при

проектиро-

вании

и

написании

программы

трудно

быстро

(в

течение

одного

дня)

перестроиться

на

деструктивный

образ

мышления.

Многие,

кому

приходилось

самому

делать

дома

ремонт,

знают,

что

про-

цесс

обрывания

старых

обоев

(деструктивный

процесс)

нелегок,

но

он

просто

невыносим,

если

не

кто-то

другой,

а

вы

сами

пер-

воначально

их

наклеивали.

Вот

так

же

и

большинство

програм-

мистов

не

могут

эффективно

тестировать

свои

программы,

по-

тому

что

им

трудно

демонстрировать

собственные

ошибки.

В

дополнение

к

этой

психологической

проблеме

следует

отметить

еще

одну,

не

менее

важную:

программа

может

содер-

жать

ошибки,

связанные

с

неверным

пониманием

постановки

или

описания

задачи

программистом.

Тогда

существует

вероят-

ность,

что

к

тестированию

программист

приступит

с

таким

же

недопониманием

своей

задачи.

Тестирование

можно

уподобить

работе

корректора

или

рецензента

над

статьей

или

книгой.

Многие

авторы

представ-

ляют

себе

трудности,

связанные

с

редактированием

собствен-

ной

рукописи.

Очевидно,

что

обнаружение

недостатков

в

своей

деятельности

противоречит

человеческой

психологии.