Cтраница 2
Эта проблема проявляется в разнообразных формах. Применяя нисходящее тестирование в точном соответствии с предыдущим разделом, часто невозможно тестировать определенные логические условия, например ошибочные ситуации или защитные проверки. [16]
Когда AUT используется для восходящего тестирования, все модули, находящиеся в структуре программы ниже тестируемого, автоматически загружаются по команде AUT. Для нисходящего тестирования AUT предоставляет средства имитации, позволяющие разрешить некоторые проблемы, связанные с использованием заглушек. [17]
Так как список В / В определяет сопряжение ( передачу данных) между модулями, то этот список становится полезным руководством при разработке заглушек. При нисходящем тестировании модулей заглушки нужно программировать так, чтобы они могли принимать входные данные в качестве аргументов и возвращать требуемые выходные данные. [18]
Тогда единственно целесообразным кажется тестирование сначала на наивысшем, наиболее интегрированном уровне, поскольку именно там каким-либо образом выявляется большинство ошибок, и начинать тестирование как можно раньше, даже до того, как написана большая часть фактически работоспособной программы. Такой подход относится к нисходящему тестированию, естественному расширению нисходящих проектирования и программирования. [19]
Конечно, подготовительная работа для проведения тестирования на каждом шаге, а также составление и проверка самих имитаторов ( затычек, заглушек) требует дополнительных усилий, и поэтому к нисходящему тестированию приступают не на самых первых шагах разработки, а несколько позже, когда логическая структура уже достаточно детализирована. Тем самым, для несложных программ нисходящее тестирование может оказаться невыгодным из-за сравнительно большой подготовительной работы. Практически, по различным причинам обычно осуществляется смешанная стратегия отладки, когда часть модулей отлаживается независимо от центральной части, а затем подключается к ней. [20]
Птцесс проверки принято делят на следующие этапы: синтаксическая проверка, семантическая проверка, проверка модулей, интегральная проверка. При структурном подходе предлагается использощть как нисходящее тестирование, так и восходящее. Каждому из них свойственны свои преимуществе и недостатки, а поэтому целесообразное комбинировать оба эти подхода. [21]
Метод тестирования программ, при котором каждый модуль программы подключается для тестирования к ранее оттестированным модулям. Различают две разновидности этого метода: восходящее тестирование и нисходящее тестирование. [22]
Рекомендуется разделять программный комплекс на модули по функциональному признаку, придерживаться принципов вертикального управления, при котором каждый модуль имеет один вход и один выход и возвращение из модуля допускается только в вызвавший его модуль. Для структурного программирования характерно использование нисходящего программирования и нисходящего тестирования программ, отказ от использования оператора goto, построение программ из ограниченного числа типов управляющих структур. В каждой технологии программирования устанавливаются свои правила представления и документирования проектных решений, принимаемых на различных иерархических уровнях разработки. На верхних уровнях распространено применение метаязыков, называемых также псевдоязыками или языками спецификаций, в этих языках наряду со средствами алгоритмических языков общего назначения допускается использование различных макрооператоров, часто выражаемых средствами естественного языка. Другими способами представления проектных решений на уровне проектирования программных комплексов являются граф-схемы, функциональные диаграммы, диаграммы вход - обработка - выход и другие графические средства укрупненного выражения структуры программного обеспечения. Получаемое описание отражает основные связи между модулями по управлению и информации и служит исходным документом для дальнейшей конкретизации программного обеспечения на последующих иерархических уровнях. [23]
Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе. Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы прост: тесты пишутся в виде обычных для пользователей внешних данных и передаются программе через выделенные ей устройства ввода. В хорошо спроектированной программе физические операции ввода-вывода выполняются на нижних уровнях структуры, поскольку физический ввод-вывод - абстракция довольно низкого уровня. Поэтому для того, чтобы решить проблему экономически эффективно, модули добавляются не в строго нисходящей последовательности ( все модули одного горизонтального уровня, затем модули следующего уровня), а таким образом, чтобы обеспечить функционирование операций физического ввода-вывода как можно быстрее. Когда эта цель достигнута, нисходящее тестирование получает значительное преимущество: все дальнейшие тесты готовятся в той же форме, которая рассчитана на пользователя. [24]