Глава 11: Инструментальные средства тестировщика 281

подробно рассказывалось в главе 3.) Самый очевидный способ ее выпол­нения — просто сесть перед компьютером с листингом и попытаться вы­явить все возможные ветви кода.

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

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

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

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

Средств мониторинга охвата на рынке имеется предостаточно. Стоит составить их список, чтобы иметь что предложить программистам. Одна­ко вполне возможно, что вы услышите от них целый ряд разумных возра­жений. Их основания могут быть такими.

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

• Со средствами мониторинга программа медленнее работает. В

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

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

• Нашпигованная зондами программа сильно увеличивается в разме­ре. Если размер программы имеет критическое значение, это обсто­ятельство может скрыть тот факт, что ее размер и в самом деле превысил допустимую величину.

• Некоторые из таких программных средств сами полны ошибок.

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

Проверка утверждений

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

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

Анализ использования памяти <

Работающая программа использует память следующими способами.

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

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

• Определенная память связана с аппаратным обеспечением. Про- j

грамма может общаться с внешним устройством, считывая и запи- '