книги / Надежность программного обеспечения систем обработки данных

параметров, которые в зависимости от их значений могут оказывать различное влияние на дальнейший ход вычис­ лений. Обычно в таких случаях возвращаемым najiaM et- рам присваиваются условные фиксированные значения.

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

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

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

Как только к программе подключены все модули, осу­ ществляющие операции ввода-вывода, метод контроля «сверху вниз» получает дополнительное преимущество: все последующие тесты могут быть оформлены и введены в программу как входные данные.

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

числений.

К преимуществам метода часто относят также отсут­ ствие необходимости в разработке управляющих программ

для отдельных модулей, вместо этого необходимо «просто написать макеты модулей». Однако это преимущество дос­ таточно спорно.

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

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

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

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

М о д и ф и ц и р о в а н н ы й м е т о д к о н т р о л я . Контррдь метр-

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

/ М 2+ Д Я - |- С = 0

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

162

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

Эта проблема проявляется в нескольких различных формах. Используя метод «сверху вниз», как он описан ранее, невозможно испытать некоторые логические усло­ вия типа защитного программного контроля или ошибоч­ ных состояний, так как они действуют только в том случае, если модуль высшего уровня передаст недопустимый па­ раметр. Этот метод делает также невозможной провер­ ку специальных логических условий в тех случаях, ког­ да программа использует какой-либо модуль ограниче­ ния.

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

программу в точке, далеко отстоящей от этого уровня.

ном ны х усл о ви ях , п р еж д е чем он б у д ет вклю чен в п р о гр ам ­ му.

Однако при использовании этого метода требуется разрабатывать управляющие программы и макеты для каждого модуля.

Контроль при одновременном объединении. Этот метод является наиболее простым подходом к решению вопроса! о выборе последовательности объединения модулей в еди­ ную программу для совместного контроля. При его исполь­ зовании сначала контролируются все модули независимо друг от друга, затем они одновременно объединяются в программу и контролируются совместно. По сравнению с другими методами контроля этот метод имеет ряд недос­ татков и сравнительно мало достоинств. К недостаткам метода можно отнести следующие его особенности: для каждого из модулей необходимо создавать управляющие программы и макеты; до последнего момента модули не объединяются для совместного контроля, а это ведет к тому, что серьезные ошибки в сопряжении модулей дли* тельное время могут оставаться невыявленными.

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

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

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

Этот метод трудно проиллюстрировать на примере небольшой программы Контроль в двух направлениях небольших по объему программ не позволяет широко использовать достоинства этого метода. Его применение оправдано при интеграции больших программных систем, таких, как операционные системы.

Рассматриваемый метод предполагает объединение мо­ дулей на ранней стадии контроля, что позволяет доста­ точно быстро получать работающую программу, способ!

164

ную правильно выполнять основные требуемые функции. Кроме того, данный метод устраняет невозможность контроля некоторых специальных условий в программе при использовании контроля «сверху вниз», так как проверка модулей нижних уровней выполняется методом «снизу вверх»

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

Решение проблемы выбора метода интеграции и конт­ роля определяется особенностями контролируемой прог­ раммы.

8.3. ГАРАНТИИ КАЧЕСТВА

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

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

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

I6S

кого контроля является проверка всех возможных зна­ чений и комбинаций входных параметров.

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

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

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

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

Контроль всегда должен выполняться людьми, не свя-

166

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

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

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

В целях соблюдения объективности контроля не реко­ мендуется выполнять такие тесты, которые невозможно воспроизвести.

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

Такая небрежная форма контроля неприемлема по

167

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

Не рекомендуется упрощать программу для облегчения выполнения контроля, несмотря на то, что часто кажется привлекательным изменить программу для упрощения контроля Например, можно упростить контроль, сократив число итераций в цикле со ста до десяти, однако в этом случае будет контролироваться неверная программа

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

Вопросы к главе 8.

1 Сформулируйте основные принципы организации контроли

2 В чем состоит необходимость предварительного проектирования контроля'1

3Преимущества и недостатки выборочного контроля

4Дайте сравнительную оценку методов интеграции системы

5Почему трудно контролировать свою программу11

Г л а в а 9

ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ В ПРОЦЕССЕ ТЕСТИРОВАНИЯ

Контроль разработанного ПО включает последователь­ ную цепочку различного рода проверок с непересекающимися целями. Эта последовательность включает:

1)синтаксический и семантический контроль кодиро­ вания модулей при их трансляции в машинные программы;

2)единичный тестовый контроль каждого модуля, преследующий цели установления различий между логи­ ческой схемой модуля, а также его интерфейса с внеш­ ними спецификациями системы;

3)функциональное тестирование, преследующее цели обнаружения противоречий между программой и функция­ ми, определенными для реализации в системе внешни­ ми спецификациями;

4)системное тестирование, имеющее целью выявление противоречий между системой и целями, определенными для ее создания пользователем;

169

5)приемо-сдаточные испытания;

6)установочные испытания.

Рассмотрим компоненты представленного выше переч­ ня с учетом их значения для контроля создаваемой сис­ темы ПО.

9Л. ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ

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

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

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

Отладка. Нередкой ошибкой в программировании, осо­ бенно среди начинающих программистов, является жела­ ние выполнять только отладку н не проводить тестиро­ вания. Так, если программа хорошо работает с группой осторожно подобранных данных, то они верят, что прог- Йамма и дальше будет так же работать с любыми данными.

[вступает момент искреннего удивления, когда после использования результатов нескольких прогонов програм­ мы, в верности которых у них нет сомнения, получают явно неверный результат.

Обычно существуют два подхода к отладке: либо большая часть времени тратй^и на то, чтобы выявить ошибки вручную, либо выполнить эту работу с исполь­ зованием ЭВМ. Некоторые статистические характеристи­ ки этих подходов были рассмотрены в работе (3]. Выбор альтернативы в значительной мере зависит от наличия машинного времени.

170