Нисходящее тестирование — Тестирование модулей — Тестирование программного средства

НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ

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

При этом подходе немедленно возникают два вопроса: 1. «Что делать, когда тестируемый модуль вызывает модуль более низко­го уровня (которого в данный момент еще не существует)?» и 2. «Как подаются тестовые данные?»

Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули — «заглушки», которые моделируют функции отсутствующих модулей.

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

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

Преимуществом нисходящего подхода очень часто считают отсутствие необходимости в драйверах; вместо драйверов вам просто следует написать «заглушки».

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

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

 

Популярные статьи

 

БАНКИ ДАННЫХ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ УПРАВЛЕНИЯ
ДОСТОИНСТВА И НЕДОСТАТКИ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ОБРАБОТКИ ДАННЫХ
ВИДЫ ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ 
ОСНОВНЫЕ ПОНЯТИЯ ТЕОРИИ АЛГОРИТМОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ АВТОМАТИЗАЦИИ ОФИСА
КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ
КОМПОНЕНТЫ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ АВТОМАТИЗАЦИИ ОФИСА
АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО СПЕЦИАЛИСТА
ЭТАПЫ РАЗВИТИЯ ИНФОРМАТИЗАЦИИ
ПОНЯТИЕ МУНИЦИПАЛЬНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ 
РЕЖИМЫ ОБРАБОТКИ ИНФОРМАЦИИ
ФУНКЦИИ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ
МЕТОДЫ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ПРОГРАММНЫХ СРЕДСТВ
ПРАВИЛА ЗАЩИТЫ ОТ КОМПЬЮТЕРНЫХ ВИРУСОВ
ДОКУМЕНТАЛЬНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ
ПРОТОКОЛЫ ТЕСТИРОВАНИЯ
ДЕСТРУКТИВНЫЕ ВОЗМОЖНОСТИ ВИРУСОВ
КЛАССИФИКАЦИЯ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
КОНЦЕПТУАЛЬНАЯ, ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ МОДЕЛИ
КОМПЬЮТЕРНЫЕ ТЕХНОЛОГИИ ПОДГОТОВКИ ТЕКСТОВЫХ ДОКУМЕНТОВ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ ЭКСПЕРТНЫХ СИСТЕМ
ДИАЛОГОВЫЙ РЕЖИМ АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ ИНФОРМАЦИИ
ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРНЫХ СЕТЕЙ