Файл: Отладка и тестирование программ.pdf

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

Преимущества нисходящего подхода

У применения нисходящего метода по сравнению с восходящим имеются как достоинства, так и недостатки. Главное достоинство нисходящего подхода в том, что этот подход совмещает и тестирование сопряжений и тестирование модуля и частично тестирование внешних функций. И именно с этим связано его другое преимущество – тесты готовятся в удобном виде, при достижении стадии, когда модули ввода-вывода уже подключены.

Нисходящий метод будет более эффективным и в случае, когда в проекте программы могут иметься серьёзные дефекты и если имеются сомнения по части осуществимости программы в общем.

Ещё одним преимуществом нисходящего метода зачастую считают то, что не нужно писать драйверы, но вместо драйверов приходится писать «заглушки». Однако это спорное преимущество

Ограничения нисходящего подхода

Однако преимуществами нисходящий метод не ограничивается и у него имеются и свои недостатки. Главным недостатком считается то, что зачастую модуль не тестируют тщательно сразу после его подключения. Это связано с тем, что основательное тестирование отдельных модулей требует особенно изощренных заглушек. В основном, что бы не тратить уйму времени на их программирование вместо них программисты пишут простые заглушки, которые проверяют лишь часть условий в модуле.

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

2.3.3. Модифицированный нисходящий метод

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

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

2.3.4. Метод большого скачка

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

В сравнении с другими методами подход большого скачка хранит в себе достаточно большое количество недостатков и слишком мало достоинств.

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

Применение подхода большого скачка серьёзно усложняет отладку.

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

2.3.5. Метод сандвича

Создание метода сандвича – среднее решение между нисходящим и восходящим подходами. Это попытка использовать достоинства и того и другого методов и избежать их недостатки.

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

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

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

2.3.6. Модифицированный метод сандвича

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

Из этого следует, что модифицированный метод сандвича это тоже компромисс между нисходящим и восходящим методами.

Итог второй главы

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

Были определены главные методологии тестирования программных средств, а так же были определены их преимущества и недостатки, и определены наиболее эффективные методы для конкретных задач.

ГЛАВА 3.

Сравнение методов тестирования, отладка программных средств

3.1. Критерии сравнения методов тестирования

Если посмотреть с точки зрения надежности программного обеспечения можно оценить стратегии тестирования по семи критериям:

а) Первый критерий – время до начала сборки модулей в единую систему, по той причине что, это является важным аспектом при обнаружении ошибок в сопряжениях и предположениях модулей о свойствах друг друга

б) Второй критерий – время до появления первых работающих прототипов версий системы, потому как именно на этом этапе могут показаться основные недочёты проектирования

в) Третий критерий – необходимость наличия заглушек для проведения процесса тестирования

г) Четвертый критерий – необходимость наличия драйверов для проведения процесса тестирования

д) Пятый критерий – мера параллелизма, который может быть в начале или же на ранних стадиях тестирования (но не ближе к концу процесса тестирования)

е) Шестой критерий – это критерий, который связан с таким вопросом: „имеется ли возможность проверить любое условие в системе и любой имеющийся путь?”

ж) Седьмой критерий – охарактеризовывает сложность управления процессом тестирования, планирования.

Сравнение по всем этим критериям показано в таблице 3.1 на странице 24.

3.2. Этапы тестирования

Начало процесса процесса тестирования программного обеспечения состоит в том, что проходит проверка корректной работы обособленных

Таблица 3.1 – Качественная оценка подходов сборки