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

Cтраница 1

Диаграмма PERT для нисходящего тестирования. [1]

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

Нисходящее тестирование позволяет выявить ошибки в реали-вации основных функций программы уже на ранних стадиях работа над программой, до начала реализации других, второстепенны. Таким образом, открывается возможность начинать активную отладку программ на машине и находить самые принципиальные ошибки гораздо раньше, чем обычно. Даже для достаточно сложныа программ можно получить первые тестовые результаты в самый первый день разработки алгоритма. Например, уже на первой стадия проектирования имеет смысл проверить установленные в программе самые внешние характеристики основных наборов данных, служащий для ввода-вывода или являющихся интерфейсом между основными частями программы. [3]

При нисходящем тестировании проверка начинается с главного модуля. К нему постепенно подключаются модули более низких иерархических уровней. Если модули нижних уровней не разработаны или не протестированы, то вместо них подключаются программы-заглушки. Таким образом тестируется некоторая модель группы программ с имитаторами-заглушками. При использовании этого метода появляется возможность сохранения и развития исходных тестовых данных по мере подключения модулей нижних иерархических уровней. С самого начала тестирования могут использоваться реальные исходные данные, которые постепенно уточняются по мере подключения модулей. При этом наиболее полно и на ранних стадиях проверяется межмодульный интерфейс. [4]

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

Поскольку при нисходящем тестировании детальные функции многих блоков обычно еще не определены и эти блоки не могут быть пока закодированы, такое тестирование возможно только при замене не конкретизированных еще блоков или их частей на имитаторы, в задачу которых входит поддерживать функционирование всей проверяемой программы. Имитаторы принимают передаваемые им данные и передают их после контрольной печати и некоторой переработки ( возможно и пустой) следующему или вызывающему блоку. [6]

Кодирование сверху вниз подразумевает использование нисходящего тестирования вновь закодированных модулей с уже отлаженными модулями верхних уровней, при этом еще не разработанные модули нижних уровней имитируются специальными подыгрывающими подпрограммами - заглушками. Тестированием последнего модуля завершается комплексное тестирование всего ПО. [7]

При использовании этого метода одновременно начинают восходящее и нисходящее тестирование, собирая программу как снизу, так и сверху и встречаясь в конце концов где-то в середине. Точка встречи зависит от конкретной тестируемой программы и должна быть заранее определена при изучении ее структуры. Например, если разработчик может представить свою систему в виде уровня прикладных модулей, затем уровня модулей обработки запросов, затем уровня примитивных функций, то он может решить применять нисходящий метод на уровне прикладных модулей ( программируя заглушки вместо модулей обработки запросов), а на остальных уровнях применить восходящий метод. [8]

Преимуществом ранней отладки центрального блока при нисходящем тестировании является то, что программист быстро получает возможность проверить периферийные блоки в условиях, которые в необходимой степени приближены к реальным. Действительно, центральный блок, снабженный хотя бы и простейшими функциональными возможностями, можно рассматривать как реальную среду, в которую погружаются вновь отлаживаемые блоки, добавляемые к центральной части. Добавление отлаживаемых блоков удобно производить по одному для быстрейшей локализации ошибок, возникающих при стыковке с центральным блоком. Подключение каждого нового блока к центральной части позволяет постепенно усложнять испытания, которым подвергается тестируемая программа. [9]

Кроме того, нисходящее кодирование позволяет осуществит нисходящее тестирование, под которым понимается тестирование, выполняемое сразу после реализации каждого шага алгоритмизации, до проведения следующего шага детализации. Нисходящее тестирование противопоставляется обычному, восходящему тестированию, при котором тестирование данного блока начинается только после проведения последнего уровня его детализации, а тестирование всей программы - после контроля всех блоков программы. [10]

Метод тестирования программных изделий, при котором тестирование входящих в изделие модулей начинается одновременно как сверху ( нисходящее тестирование), так и снизу ( восходящее тестирование) и заканчивается на одном из модулей, назначаемом заранее. [11]

Рассмотренные выше передовые методы разработки ПО ( HIPO - технология, нисходящее проектирование, структурное программирование, нисходящее тестирование, бригада главного программиста) были использованы фирмой IBM для создания программной системы объемом свыше 80 тыс. операторов языка программирования, при этом была достигнута производительность труда 65 операторов / день на каждого программиста и 35 операторов / день па каждого члена бригады. Если учесть, что бригада возглавлялась программистом чрезвычайно высокой квалификации, а проект поддерживался фирмой с колоссальными возможностями, то можно предположить, что эти показатели близки к предельным. Однако темпы выпуска ЭВМ во всем мире продолжают расти ( так, в США в настоящее время количество ежегодно выпускаемых ЭВМ превышает количество студентов, оканчивающих вузы), усиливаются потребности общества в системах ПО. Многие специалисты по электронной обработке данных связывают возможность разрешения этого противоречия с созданием и широким использованием генераторов прикладных программ. Например, такие интерактивные генераторы, как ADF и DMS, позволяют на несколько порядков повысить производительность труда программистов при разработке диалоговых прикладных программ для решения экономических задач. [12]

Конечно, подготовительная работа для проведения тестирования на каждом шаге, а также составление и проверка самих имитаторов ( затычек, заглушек) требует дополнительных усилий, и поэтому к нисходящему тестированию приступают не на самых первых шагах разработки, а несколько позже, когда логическая структура уже достаточно детализирована. Тем самым, для несложных программ нисходящее тестирование может оказаться невыгодным из-за сравнительно большой подготовительной работы. Практически, по различным причинам обычно осуществляется смешанная стратегия отладки, когда часть модулей отлаживается независимо от центральной части, а затем подключается к ней. [13]

Когда же ошибки все-таки найдены, то ясная программа позволяет легко понять их причину и место. Нисходящее тестирование более равномерно распределяет моменты обнаружения возможных ошибок, благодаря чему на исправление каждой ошибки удается выделить. [14]

Страницы: 1 2