Добавлен: 25.10.2018
Просмотров: 6992
Скачиваний: 27
низкого уровня. Процесс повторяется до тех пор, пока не будет достигнута
вершина. Здесь завершаются и тестирование модулей, и тестирование сопря-
жении программы.
При восходящем тестировании для каждого модуля необходим драйвер:
нужно подавать тесты в соответствии с сопряжением тестируемого модуля.
Одно из возможных решении — написать для каждого модуля небольшую
ведущую программу.
Тестовые данные представляются как «встроенные» непосредственно в
эту программу переменные и структуры данных, и она многократно
вызывает тестируемый модуль,
с каждым вызовом передавая ему новые тестовые данные. Имеется и
лучшее решение: воспользоваться программой тестирования модулей — это
инструмент тестирования, позволяющий описывать тесты на специальном
языке и избавляющий от необходимости писать драйверы.
НИСХОДЯЩЕЕ ТЕСТИРОВАНИЕ
Нисходящее тестирование (называемое также нисходящей разработкой
не является полной противоположностью восходящему, но в первом
приближении может рассматриваться как таковое, При нисходящем подходе
программа собирается и тестируется сверху вниз. Изолировано тестируется
только головной модуль.
После того как тестирование этого модуля завершено, с ним соеди-
няются (например, редактором связей) один за другим модули,
непосредственно вызываемые им, и тестируется полученная комбинация.
Процесс повторяется до тех пор, пока не будут собраны и проверены все
модули.
При этом подходе немедленно возникает два вопроса: что делать, когда
тестируемый модуль вызывает модуль более низкого уровня (которого в
данный момент еще не существует), и как подаются тестовые данные. Ответ
на первый вопрос состоит в том, что для имитации функций недостающих
модулей программируются модули-заглушки», которые моделируют функции
отсутствующих модулей. Фраза «просто напишите заглушку» часто
встречается в описании этого подхода, но она способна ввести в
заблуждение, поскольку задача написания заглушки» может оказаться
трудной. Ведь заглушка редко сводится просто к оператору RETURN,
поскольку вызывающий модуль обычно ожидает от нее выходных
параметров. В таких случаях в заглушку встраивают фиксированные
выходные данные, которые она всегда и возвращает. Это иногда оказывается
неприемлемым, так как вызывающий модуль может рассчитывать, что
результат вызова зависит от входных данных. Поэтому в некоторых случаях
заглушка должна быть довольно изощренной, приближаясь по сложности к
модулю, который она пытается моделировать.
Интересен и второй вопрос: в какой форме готовятся тестовые данные и
как они передаются программе? Если бы головной модуль содержал все
нужные операции ввода и вывода, ответ был бы прост: тесты пишутся в виде
обычных для пользователей внешних данных и передаются программе через
выделенные ей устройства ввода. Так, однако, случается редко. В хорошо
спроектированной
программе
физические
операции
ввода-вывода
выполняются на нижних уровнях структуры, поскольку физический ввод-
вывод — абстракция довольно низкого уровня. Поэтому для того, чтобы
решить проблему экономически эффективно, модули добавляются не в стро-
го нисходящей последовательности (все модули одного горизонтального
уровня, затем модули следующего уровня), а таким образом, чтобы
обеспечить функционирование операций физического ввода-вывода как
можно быстрее. Когда эта цель достигнута, нисходящее тестирование
получает значительное преимущество: все дальнейшие тесты готовятся в той
же форме, которая рассчитана на пользователя.
Остается еще один вопрос: в какой форме пишутся тесты до тех пор,
пока не будет достигнута эта цель? Ответ: они включаются в некоторые из
заглушек.
Нисходящий метод имеет как достоинства, так и недостатки по
сравнению с восходящим. Самое значительное достоинство — в том, что
этот метод совмещает тестирование модуля, тестирование сопряжении и
частично тестирование внешних функций. С этим же связано другое его
достоинство — когда модули ввода-вывода уже подключены, тесты можно
готовить в удобном виде. Нисходящий подход выгоден также в том случае,
когда есть сомнения относительно осуществимости программы в целом или
если в проекте программы могут оказаться серьезные дефекты.
Преимуществом нисходящего подхода очень часто считают отсутствие
необходимости в драйверах; вместо драйверов вам просто следует
написать «заглушки». Как читатель сейчас уже, вероятно, понимает, это
преимущество спорно.
Нисходящий метод тестирования имеет, к сожалению, некоторые
недостатки.
Основным из них является тот, что модуль редко тестируется
досконально сразу после его подключения. Дело в том, что основательное
тестирование некоторых модулей может потребовать крайне изощренных
заглушек. Программист часто решает не тратить массу времени на их
программирование, а вместо этого пишет простые заглушки и проверяет
лишь часть условий в модуле. Он, конечно, собирается вернуться и закончить
тестирование рассматриваемого модуля позже, когда уберет заглушки. Такой
план тестирования определенно не лучшее решение, поскольку об от-
ложенных условиях часто забывают.
Второй тонкий недостаток нисходящего подхода состоит в том, что он
может породить веру в возможность начать программирование и
тестирование верхнего уровня программы до того, как вся программа будет
полностью спроектирована.
Эта идея на первый взгляд кажется экономичной, но обычно дело
обстоит совсем наоборот. Большинство опытных проектировщиков признает,
что проектирование программы — процесс итеративный. Редко первый
проект оказывается совершенным.
Нормальный стиль проектирования структуры программы предполагает
по окончании проектирования нижних уровней вернуться назад и подправить
верхний уровень, внеся в него некоторые усовершенствования или исправляя
ошибки, либо иногда даже выбросить проект и начать все сначала, потому
что разработчик внезапно увидел лучший подход. Если же головная часть
программы уже запрограммирована и оттестирована, то возникает серьезное
сопротивление любым улучшениям ее структуры. В конечном итоге за счет
таких улучшений обычно можно сэкономить больше, чем те несколько дней
или недель, которые рассчитывает выиграть проектировщик, приступая к
программированию слишком рано.
МОДИФИЦИРОВАННЫЙ НИСХОДЯЩИЙ МЕТОД
Нисходящий подход имеет еще один существенный недостаток,
касающийся полноты тестирования. Предположим, что есть большая
программа и где-то ближе к нижнему ее уровню находится модуль,
предназначенный для вычисления корней квадратного уравнения. Для
заданных входных переменных А, В и С он решает уравнение.
При проектировании и программировании модуля с такой функцией
всегда следует понимать, что квадратное уравнение может иметь как
действительные, так и комплексные корни. Для полной реализации этой
функции необходимо, чтобы результаты могли быть действительными или
комплексными числами (или, если дополнительные затраты на нахождение
комплексных корней не оправданы, модуль должен по крайней мере
возвращать код ошибки в случае, когда входные коэффициенты задают
уравнение с комплексными корнями). Предположим, что конкретный
контекст, в котором используется модуль, исключает комплексные корни (т.
е. вызывающие модули никогда не задают входных параметров, которые
привели бы к комплексным корням). При строго нисходящем методе иногда
бывает невозможно тестировать модуль для случая комплексных корней (или
тестировать ошибочные условия). Можно попытаться оправдывать это тем,
что, поскольку такое уравнение никогда не будет дано модулю, никого не
должно заботить, работает ли он и в этих случаях. Да, это безразлично
сейчас, но окажется важным в будущем, когда кто-то попытается
использовать модуль в новой программе или модифицировать старую
программу так, что станут возможными и комплексные корни.
Эта проблема проявляется в разнообразных формах. Применяя
нисходящее тестирование в точном соответствии с предыдущим разделом,
часто невозможно тестировать определенные логические условия, например
ошибочные ситуации или защитные проверки. Нисходящий метод, кроме
того, делает сложной или вообще невозможной проверку исключительных
ситуаций в некотором модуле, если программа работает с ним лишь в
ограниченном контексте (это означает, что модуль никогда не получит
достаточно полный набор входных значений). Даже если тестирование такой
ситуации в принципе осуществимо, часто бывает трудно определить, какие
именно нужны тесты, если они вводятся в точке программы, удаленной от
места проверки соответствующего условия.
Метод, называемый модифицированным нисходящим подходом, решает
эти проблемы: требуется, чтобы каждый модуль прошел автономное
тестирование перед подключением к программе. Хотя это действительно
решает все перечисленные проблемы, здесь требуются и драйверы, и
заглушки для каждого модуля.
ТЕМА 8. СОПРОВОЖДЕНИЕ ПО
Автор данного перевода SWEBOK с замечаниями и комментариями - Сергей Орлик.
Оригинальный перевод доступен в блоге Сергея Орлика
Сопровождение программного обеспечения в SWEBOK определяется
как вся совокупность деятельности, необходимой для обеспечения
эффективной (с точки зрения затрат) поддержки программных систем. Эти
работы выполняются как перед вводом системы в эксплуатацию, так и после
этого. Предварительные работы включают планирование деятельности по
сопровождению системы, а также организацию перехода к ее
полнофункциональному использованию. Если новая система должна
заменить старую систему, предназначенную для решения тех же задач,
просто на новом уровне эффективности, стоимости использования, новых
функциональных возможностей, в этом случае важно обеспечить плавный
переход со старой системы на новую, максимально естественный для
пользователей. С этим связано не только планирование, например, переноса
информации, хранимой в соответствующих базах данных, но и обучение
пользователей, подготовка, настройка и проверка “боевой” конфигурации,
определение последовательности операций, организация и обучение службы
поддержки (help-desk) и т.п.
Область знаний “Сопровождение программного обеспечения” связана с
другими аспектами программной инженерии. По сути, описание этой области
знаний непосредственно пересекается со всеми другими дисциплинами.
Определения и терминология (Definitions and Terminology)
Сопровождение программного обеспечения определяется стандартом
IEEE Standard for Software Maintenance (IEEE 1219) как модификация
программного продукта после передачи в эксплуатацию для устранения
сбоев, улучшения показателей производительности и/или других
характеристик (атрибутов) продукта, или адаптации продукта для
использования в модифицированном окружении. Интересно, что данный
стандарт также касается вопросов подготовки к сопровождению до передачи
системы в эксплуатацию, однако, структурно это сделано на уровне
соответствующего информационного приложения, включенного в стандарт.
В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC,
ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных
процессов жизненного цикла. Этот стандарт описывает сопровождение как
процесс модификации программного продукта в части его кода и