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

Статическое тестирование против динамического

При статическом тестировании программный код вообще не выполня­ется — он тестируется только путем логического анализа.

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

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

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

• Обзорные, инспекционные и рецензионные совещания. Это точно та­кие же совещания, какие проводятся для анализа проекта программ­ного продукта. Майерс (Myers, 1979) предлагает для них очень полезный список контрольных вопросов. Он утверждает (1978), что для выявления ошибок обзорные совещания не менее полезны, чем динамическое тестирование специалистом, который не является автором кода программы. А у Фергана (Fergan, 1976) можно найти описание классического способа проведения таких дискуссий.

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

Вычитывать программный код (как собственный, так и чужой) — работа довольно скучная, и многие ее не любят. В пользу этой процедуры горячо высказывается Вейнберг (Weinberg, 1971), а Бейзер (Beizer, 1984, 1990)

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

советует ускорить работу за счет игнорирования синтаксиса и всего того, что может сделать компилятор.

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

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

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

Программная статистика

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

Но на практике это может привести разве что к замедлению работы и появлению лишних ошибок и проблем, поскольку, как известно, лучшее — враг хорошего. Да и как вообще можно “измерить” качество программы. Если она работает, выполняет все необходимое, если она тщательно про­думана и протестирована — оставьте ее в покое.

И еще не следует забывать, что краткость — сестра таланта. А относи­тельно посредственный программист, пытаясь предельно сократить и опти­мизировать код, не сможет его как следует отладить и в результате испортит то, что прекрасно работало. НИ В КОЕМ СЛУЧАЕ НЕ СЖИМАЙТЕ ПРО­ГРАММНЫЙ КОД!

Если вы потребуете, чтобы программисты уменьшили коэффициент сложности кода, можете ли вы быть уверены, что новый код будет полностью функционально эквивалентным старому?