5. МОДИФИЦИРОВАННЫЙ НИСХОДЯЩИЙ МЕТОД

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

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

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

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

6. МЕТОД БОЛЬШОГО СКАЧКА.

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

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

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

7. МЕТОД САНДВИЧА

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

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

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

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

8. МОДИФИЦИРОВАННЫЙ МЕТОД САНДВИЧА.

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

9. СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА МЕТОДОВ ТЕСТИРОВАНИЯ.

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