Нисходящее тестирование против восходящего

Существует и еще один принцип организации тестирования, при кото­ром программа так же, как и при восходящем способе, тестируется не целиком, а по частям. Только направление движения меняется — сначала тестируется самый верхний уровень иерархии модулей, а от него тестировщик постепенно спускается вниз. Такая технология называется нисходящей (top-down). Обе технологии — и нисходящую и восходящую — называют также инкрементальными.

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

Мнения специалистов о том, какая из двух инкрементальных стратегий тестирования более эффективна, сильно расходятся. Йордан (Yourdon, 1975) доказывает, что гораздо лучше нисходящее тестирование, а Майерс (Myers, 1976) утверждает, что, хотя у обоих подходов есть свои преимуще­ства и недостатки, в целом восходящее тестирование лучше. По мнению же Данна (Dunn, 1984), эти способы примерно эквивалентны.

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

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

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

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

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

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

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

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

Приёмочные испытания

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

Приемочные испытания иногда называют альфа - тестированием. Сделанные на заказ системы предназначены для одного заказчика. Для таких систем процесс альфа-тестирования продолжается до тех пор, пока разработчики и заказчик не удостоверятся в том, что разработанная система полностью соответствует системным требованиям.

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