Глава 3: Типы тестов ... 73

1 К (А < В and С = 5)

THEN Сделать НЕЧТО

г. кт D = 5

'||п()ы проверить этот код, нужно Проанализировать следующие четы­ре н.филпта.

(.1) А < В и С = 5

(НЕЧТО выполняется, затеи D присваивается 5)

(о) А < В и С Ф 5

(НЕЧТО не выполняется, D присваивается 5)

(в) А > В и С = 5

(НЕЧТО не выполняется, D присваивается 5)

(г) А > В и С * 5

(НЕЧТО не выполняется, D присваивается 5)

Для выполнения всех трех строк кода достаточно проверить вариант (а).

При более основательном способе тестирования — по критерию охва­ти ветвлений — программист проверяет вариант (а) и еще один из трех остальных вариантов. Смысл этого способа в том, что проверяются дей- С1Ш1Я программы при выполненном условии оператора IF и при невыпол­ненном. Таким образом программа проходит не только все строки кода, но и нее возможные ветви.

Иногда охват ветвлений называют полным охватом кода. Но термин этот некорректен: как похазал Бейзер (Beizer, 1984), охват ветвлений не может претендовать на полноту тестирования, поскольку в лучшем случае позво­ляет обнаружить половину имеющихся в программе ошибок.

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

Тестирование путей программы считается завершенным, когда выбран­ный критерий охвата полностью выполнен. Для автоматизации этого про­цесса разработаны программы, анализирующие программный код и вычисляющие количество подлежащих тестированию путей, а затем под­считывающие, сколько их уже проверено. Такие программы называют сред­ствами мониторинга охвата (execution coverage monitors).

Классически при тестировании путей не поощряется проверка одного и того же пути на различных данных. Хотя варианты (б), (в) и (г) нашего примера могут оказаться важными, большинство средств мониторинга ох­вата посчитают их проверку пустой тратой времени. Все три начинаются с одного и того же оператора и приводят к выполнению одной и той же последовательности команд — проверять их все означает трижды проверять один и тот же путь.

Хотя критерии охвата очень полезны, одного только тестирования пу­тей недостаточно для эффективного выявления ошибок. Гуденаф и Герхарт

74 Часть I: Основы

(Goodenough & Gerhart, 1975) привели классический пример того, что проход строки кода еще не означает выявления имеющейся в ней ошибки. Рассмотрим такую строку программы.

set а = в/с

Она вполне успешно выполняется, если С не равно нулю. Но если С равно нулю, программа или сообщит об ошибке и прекратит работу, или “зависнет”. А разница между этими двумя вариантами не в пути, а в дан­ных.

Де Милло (DeMillo, 1987) называет программный путь чувствительным к ошибкам, если при его прохождении ошибки могут проявиться. Если же ошибки обязательно проявятся при прохождении данного пути, то такой путь называется обнаруживающим ошибки. Любой путь, проходящий через приведенную строку программы чувствителен к ошибкам. Ошибка прояв­ляется только при нулевом значении переменной С. Для выявления подоб­ных ошибок технология тестирования “черного ящика” подходит лучше, чем анализ программного кода.

Формальное описание технологии тестирования программных путей можно найти у Реппса и Вейакера (Rapps & Weyuker, 1985), более подроб­ное исследование проблемы — у Бейзера (Beizer, 1984,1990), а особенно детальное обсуждение критериев охвата — у Майерса (Myers, 1979).

Тестирование частей против тестирования целого

Любая система разрабатывается по частям — как набор процессов или модулей. Можно ее так и тестировать — сначала отдельные части, а потом уже их взаимодействие. Такая стратегия называется восходящей (bottom-up).

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

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

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