Глава 12: Планирование и документация 297

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

Программист тестирует и анализирует код изнутри, он выполняет стан­дартное тестирование “стеклянного ящика”. Он, и только он отвечает за анализ путей выполнения программы, только он видит все ее ветви, и он должен гарантировать, что каждый модуль, откуда бы он ни был вызван, выполнится успешно и данные между всеми взаимодействующими модуля­ми будут передаваться правильно.

Вполне возможно, что принять участие в процедуре тестирования “стек­лянного ящика” предложат и вам. В этом случае ознакомиться с вопросом нам помогут книги таких авторов, как Хезел (Hetzel, 1988), Бейзер (Beizer, 1990), Гласс (Glass, 1992) и Миллер и Хауден (Miller & Howden, 1981). В такой ситуации было бы очень хорошо воспользоваться средствами мони­торинга охвата — тестировочными утилитами, отслеживающими пути вы­полнения программы, выполняемые ветви и модули.

Тестирование “стеклянного ящика” окружено особым мистическим ореолом. Оно кажется более научным, логическим, более профессиональ­ным и академическим и считается более престижным. Некоторые тестиров­щики не считают тестирование полноценным до тех пор, пока не будет проведено тестирование “стеклянного ящика”.

Однако эксперименты двух весьма уважаемых исследователей показали, что ни один из двух видов тестирования не является более эффективным. Этими исследователями являются Хезел (Hetzel, 1976) и Майерс (Myers, 1978).

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

Что упускается при тестировании "стеклянного ящика"

Вот три примера ошибок, проявляющихся в системах MS-DOS и не выявляемых при анализе путей и ветвей программы.

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

• Если подключить к компьютеру два монитора, монохромный и цвет­ной, и запустить одну из ранних игр под одной из ранних версий MS-

298 Часть II: Приемы и технологии тестирования

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

• Подключите к компьютеру принтер, включите его и установите пе­реключатель в Off line. Затем в какой-нибудь старой программе попробуйте выполнить команду печати. Если программа не “завис­нет”, проделайте то же самое с другой версией MS-DOS. Очень часто программы сбоят при тестировании с конфигурациями, отли­чающимися от тех, с которыми они разрабатывались.

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

В целом для поиска ошибок, подобных перечисленным на рис. 12.1, тестирование “стеклянного ящика”, без сомнения, является более слабым средством.

Эта книга посвящена тестированию работающего кода, тестированию извне, которое осуществляется путем выполнения

программы самыми разными способами и с самыми разнообразными нагрузками. Этот подход дополняет подход программиста и позволяет выполнить тесты, которые он едва ли когда-нибудь

проведет.

РИСУНОК 12.1.

Чего нельзя узнать, тестируя пути выполнения программы

1. Ошибки, связанные со временем.

2. Неожиданные ошибочные ситуации.

3. Особые стечения данных.

4. Неверная информация на экране.

5. Неадекватность пользовательского интерфейса.

6. Другие проблемы, связанные с пользовательс­ким интерфейсом.

7. Взаимодействие с параллельно выполняемыми задачами.

8. Проблемы, связанные с конфигурацией и со­вместимостью.

9. Аппаратные ошибки, нестандартные ситуации и сбои.