Ващенко Г.В., Добронец Б.С. Надежность информационных систем. Лабораторный практикум

Подождите немного. Документ загружается.

лучится”. Это — неряшливая и по многим причинам нежелательная форма

тестирования. Основной ее недостаток в том, что такие тесты мимолетны;

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

надобится тестировать повторно (например, после исправления ошибок или

после модификации), придется придумывать тесты заново.

Тестирование обходится слишком дорого и без этих дополнительных рас-

ходов. Никогда не используйте тестов, которые тут же выбрасываются (если

только программа не такова, что ее саму тут же надо выбросить). Более того,

тесты следует документировать и хранить в такой форме, чтобы каждый мог

использовать их повторно.

Готовьте тесты как для правильных, так и для неправильных входных

данных. Многие программисты ориентируются в своих тестах на “разумные”

условия на входе, забывая о последствиях появления непредусмотренных или

ошибочных входных данных. Однако многие ошибки, которые потом неожи-

данно обнаруживаются в работающих программах, проявляются вследствие

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

ставляющие неожиданные или неправильные входные данные, часто лучше

обнаруживают ошибки, чем “правильные” тесты.

Детально изучите результаты каждого теста. Самые изощренные те-

сты ничего не стоят, если их результаты удостаиваются лишь беглого взгляда.

Тестирование программы означает большее, нежели выполнение достаточно-

го количества тестов; оно также предполагает изучение результатов каждого

теста. “Да, я уже проверял такую ситуацию, но как-то не заметил в выдаче”,—

довольно распространенная реакция программиста на обнаруженную новую

ошибку.

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

ненте программного обеспечения увеличивается, растет также относи-

тельная вероятность существования в ней необнаруженных ошибок. Этот

противоречащий интуиции феномeн означает, что ошибки образуют класте-

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

компоненте программы (например, в модуле, подсистеме, функции пользо-

вателя), увеличивается также вероятность существования в этой компоненте

еще не обнаруженных ошибок. Если при тестировании двух модулей в них

обнаружены одна и восемь ошибок соответственно, опыт показывает, что для

модуля с восьмью ошибками вероятность того, что в нем еще есть ошибки,

выше.

Необходимо поручать тестирование самым, способным программистам.

Тестирование, и в особенности проектирование тестов,— этап в разработке

программного обеспечения, требующий особенно творческого подхода. К со-

жалению, во многих организациях на тестирование смотрят совсем не так.

Его часто считают рутинной, нетворческой работой, вследствие чего коллек-

тивы, занимающиеся тестированием, укомплектованы в основном неопытны-

ми или молодыми программистами. Однако практика показывает, что более

правильным было бы сделать наоборот. Проектирование тестов требует да-

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

граммного обеспечения.

Считать тестируемость ключевой задачей вашей разработки. Слож-

ность тестирования программы зависит от ее структуры и качества проекти-

рования.

Проект системы должен быть таким, чтобы каждый модуль подклю-

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

программных системах возникает из-за нарушения этой аксиомы. Ситуация,

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

ходится подключать больше десяти раз, не редкость. Каждая версия такого

модуля содержит еще одну маленькую дополнительную функцию, необходи-

мую для текущего уровня системы.

Никогда не следует изменять программу, чтобы облегчить ее тести-

рование. Часто возникает соблазн изменить программу, чтобы было легче ее

тестировать. Например, программист, тестируя модуль, содержащий цикл,

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

только 10 раз. Может быть, этот программист и занимается тестированием,

но только другой программы.

Тестирование, как почти всякая другая деятельность, должно начи-

наться с постановки целей. Как уже говорилось, цикл тестирования подобен

полному циклу разработки программного обеспечения. Тесты должны быть

спроектированы, реализованы, проверены и, наконец, выполнены. Поэтому

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

например для каждого конкретного типа тестирования должны быть опреде-

лены ориентиры (число пройденных путей, проверенных условных переходов

и т. п.) и доля ошибок, которые должны быть обнаружены на этом этапе.

Тестирование модуля

В каждом из шести рассмотренных подходов к тестированию и сбор-

ке внимание при тестировании сначала концентрируется на отдельном про-

граммном модуле. В случае нисходящих методов каждый тестируемый мо-

дуль подключается к уже тестированным модулям снизу, в случае восходя-

щих — сверху. Побочным продуктом всех этих методов, кроме метода боль-

шого скачка, является тестирование сопряжений.

Цель тестирования модуля или программной компоненты — найти несо-

ответствия между логикой и сопряжениями модуля, с одной стороны, и его

внешними спецификациями (описанием функций, входных и выходных дан-

ных и внешних эффектов), с другой стороны. Компиляция модуля также

должна рассматриваться как часть процесса тестирования, поскольку ком-

пилятор обнаруживает большинство синтаксических ошибок, а также неко-

торые семантические и логические ошибки.

Проектирование теста

Для иллюстрации сложности задачи проектирования тестов рассмотрим

следующую задачу.

Есть небольшая программа, которая читает три целых числа, представ-

ляющих собой длины сторон треугольника. Программа исследует входные

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

ним, равнобедренным или равносторонним. Напишите тесты для полной про-

верки программы.

Следующий шаг при анализе тестов — представить себе возможные ошиб-

ки в программе.

Гипотетические ошибки можно получить, убирая одну из проверок или

каким-либо образом изменяя ее. Типичные ошибки при составлении тестов

— отсутствие проверки случая разностороннего треугольника. (При провер-

ке случая равнобедреннего треугольника, рассматривается случай 2–2–3, но

упускаются случаи 2–3–2 и 0–2–2).

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

ные данные вообще какой-нибудь треугольник, потому что, если бы она пе-

чатала “разносторонний” в ответ на входные числа 2–3–6, она допускала бы

ошибку (отрезки с длинами 2–3–6 не образуют треугольника).

В качестве упражения в проектировании тестов попробуйте написать

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

Получая на входе значения A, Bи C, она находит два значения X, удовлетво-

ряющие уравнению Ax

+ Bx + C = 0. Сравните свои результаты с приве-

денными в конце главы.

Сказанное призвано проиллюстрировать трудность высококачественного

проектирования тестов. Должно стать ясным, что разработка тестов — твор-

ческий процесс, требующий не только особого искусства, но и в некотором

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

правил, которыми можно пользоваться, чтобы составить разумный набор те-

стов. Они рекомендуют сначала рассмотреть модуль как черный ящик (левая

граница спектра стратегий), а затем исследовать его внутреннее устройство

для подготовки дополнительных тестов. Весь процесс состоит из следующих

четырех шагов:

1. Руководствуясь внешними спецификациями модуля, подготовьте тест

для каждой ситуации и каждой возможности, для каждой границы областей

допустимых значений всех входных данных, областей изменения данных, для

всех недопустимых условий.

2. Проверьте текст программы, чтобы убедиться, что все условные пе-

реходы будут выполнены в каждом направлении. Если необходимо, добавьте

соответствующие тесты.

3. Убедитесь по тексту программы, что тесты охватывают достаточно

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

соответствующий пути без выполнения тела цикла, с однократным его вы-

полнением и максимальным числом повторений.

4. Проверьте по тексту программы ее чувствительность к отдельным осо-

бым значениям входных данных и, если необходимо, добавьте соответствую-

щие тесты.

Первый шаг проектирования тестов предполагает подход к модулю как

черному ящику и получение тестов за счет манипуляций с входными данными

модуля. Именно на этом шаге в основном и требуются творческие способности

(остальные три шага, в отличие от первого, довольно методичны). Если чис-

ло различных входных значений модуля невелико (например, один из пяти

запросов), приготовьте тест для каждого из них. Если входных параметров

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

для всех комбинаций.

Минимальный критерий при автономном тестировании модуля — по

крайней мере один раз выполнить все разветвления в каждом из возмож-

ных направлений.

Поскольку нас интересует лишь последовательность выполнения ветвей

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

пользовать диаграмму управления: ориентированный граф, изображающий

структуру ветвлений в программе. Каждая вершина графа (кружок) пред-

ставляет линейный участок (последовательность операторов между точками

ветвления, или принятия решения, на которую можно попасть только через

первый из них). Дуги графа представляют связи между выполнением отдель-

ных линейных участков программы.

Выполнение теста

После того как тесты для модуля спроектированы, можно перейти к сле-

дующим этапам — написать их, тестировать и выполнить. Форма представле-

ния тестов зависит от принятого метода сборки модулей. Для нисходящих ме-

тодов тесты сначала пишутся в виде конкретных наборов выходных данных,

вырабатываемых заглушками, а затем уже в виде внешних входных данных,

задаваемых пользователем. Для восходящих методов или при автономном

тестировании модулей тесты приобретают вид ведущих программ (драйве-

ров) или операторов языка тестирования (если используются специальные

инструменты тестирования модулей). В следующем разделе мы рассмотрим

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

используются.

Процесс написания тестов (в отличие от их проектирования) носит в ос-

новном рутинный характер и представлен здесь поэтому лишь вкратце. На-

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

тестируемый модуль. Каждый тест представляется вызовом этого модуля и

передачей ему конкретного набора входных данных. Чтобы облегчить по-

вторное выполнение теста в будущем и избежать проблем типа “глаз видит

то, что хочет видеть”, следует попытаться сделать тесты самопроверяемыми.

Вместо того чтобы печатать выходные данные для каждого теста, следует,

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

и ожидаемых результатов.

В идеальном случае тесты сами должны быть проверены перед их ис-

пользованием для тестирования реальной программы. Обычно это неосу-

ществимо; единственная возможность проверить правильность теста (кроме

просмотра человеком) — действительно выполнить его. Однако при тестиро-

вании следует иметь в виду, что сами тесты могут содержать ошибки.

Критический момент в выполнении тестов — анализ результатов, будь

то с помощью программы либо визуально. Распространенная нелепость —

потратить часы на проектирование изощренных тестов и затем не заметить

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

да. Чрезвычайно важно тщательно изучить результаты каждого теста, выис-

кивая малейшие тревожные признаки. Здесь-то уж жизненно важно опреде-

лить, какие результаты вы ожидаете, прежде чем изучать реальные выход-

ные данные.

Тесты для квадратного уравнения

Ниже перечисляются тесты для квадратного уравнения.

1. A=0, B=0, C=0. В этом случае уравнение сводится к виду 0=0 и не

может быть разрешено относительно X. Пробовали ли вы этот тест для про-

верки поведения модуля при таких входных данных?

2. A=0, B=0, C=10. Это соответствует уравнению 10=0, которое не имеет

решений. Интересный тест на ошибочные входные условия.

3. A=0, В=5, C=17. Соответствующее уравнение 5X + 17 = 0 не явля-

ется квадратным. Справится ли с ним модуль? Этот тест может обнаружить

также попытку деления на нуль.

4. А =6, B=1, С=2. Это один из нескольких “нормальных” тестов, кото-

рые вам следует выполнить. Не забыли ли вы заранее вычислить результат

для каждого теста?

5. A=3, B=7, С=0. Еще один “нормальный” тест. Проверяется ситуация,

когда один из корней равен нулю.

6. A=3, B=-2, C=5. Помните ли вы, что квадратное уравнение может

иметь комплексные корни?

7. A=7, B=0, C=0. Этот тест проверяет, умеет ли модуль извлекать квад-

ратный корень из нуля.

8. Полезны также тесты, проверяющие границы диапазонов арифмети-

ческих значений и точность модуля.

Задания

Напишите тесты для следующих модулей.

1. Решение квадратного уравнения.

2. Площадь треугольника.

3. Интерполяционный полином Лагранжа.

4. Сортировка списка.

5. Интегрирование функции.

6. Редактор строки.

7. Сумма ряда.

Лабораторная работа № 6.

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

Цель работы: Закрепление знаний по теме “Тестирование программно-

го обеспечения” и приобретение навыков по тестированию модульного про-

граммного обеспечения на этапе его сборки.

В данной работе используются результаты предыдущих лабораторных

работ.

Самостоятельная работа студента под контролем преподавателя. Вы-

полнение лабораторной работы студентом состоит из следующих этапов:

тестирование модулей низкого уровня

тестирование модулей более высокого уровня с присоединенными, протести-

рованными модулями более низкого уровня

тестирование модулей самого нижнего уровня (“терминальных” модулей то

есть, не вызывающих другие модули).

Процесс тестирования повторяется до тех пор, пока не будет достигнута

вершина.

Форма отчетности: Демонстрация, протестированного ПО и отчет о

прохождении каждого теста и обнаруженных ошибках.

Интеграция модулей

Вторым по важности аспектом тестирования (после проектирования те-

стов) является последовательность слияния всех модулей в систему или про-

грамму. Эта сторона вопроса обычно не получает достаточного внимания и

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

нако, является одним из самых жизненно важных решений, принимаемых на

этапе тестирования, поскольку он определяет форму, в которой записываются

тесты, типы необходимых инструментов тестирования, последовательность

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

этапа тестирования. По этой причине такое решение должно приниматься на

уровне проекта в целом и на достаточно ранней его стадии.

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

пользованы для слияния модулей в более крупные единицы. В большинстве

своем они могут рассматриваться как варианты шести основных подходов,

описанных далее. Сразу же за ними идет раздел, где предложенные подходы

сравниваются по их влиянию на надежность программного обеспечения.

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

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

Только модули самого нижнего уровня (“терминальные” модули; модули, не

вызывающие других модулей) тестируются изолированно, автономно. После

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

надежен, как вызов встроенной функции языка или оператор присваивания.

Затем тестируются модули, непосредственно вызывающие уже проверенные.

Эти модули более высокого уровня тестируются не автономно, а вместе с уже

проверенными модулями более низкого уровня. Процесс повторяется до тех

пор, пока не будет достигнута вершина. Здесь завершаются и тестирование

модулей, и тестирование сопряжений программы.

При восходящем тестировании для каждого модуля необходим драйвер:

нужно подавать тесты в соответствии с сопряжением тестируемого модуля.

Одно из возможных решений — написать для каждого модуля небольшую ве-

дущую программу. Тестовые данные представляются как “встроенные” непо-

средственно в эту программу переменные и структуры данных, и она мно-

гократно вызывает тестируемый модуль, с каждым вызовом передавая ему

новые тестовые данные. Имеется и лучшее решение: воспользоваться про-

граммой тестирования модулей — это инструмент тестирования, позволяю-

щий описывать тесты на специальном языке и избавляющий от необходимо-

сти писать драйверы.

Задания

Проведите восходящее тестирование для следующего ПО.

1. Решение квадратного уравнения.

2. Площадь треугольника.

3. Интерполяционный полином Лагранжа.

4. Сортировка списка.

5. Интегрирование функции.

6. Редактор строки.

7. Сумма ряда.

Лабораторная работа № 7.

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

Цель работы: Закрепление знаний по теме “Тестирование программно-

го обеспечения” и приобретение навыков по тестированию модульного про-

граммного обеспечения на этапе его сборки.

В данной работе используются результаты предыдущих лабораторных

работ.

Самостоятельная работа студента под контролем преподавателя. Сту-

денты собирают и тестируют сверху вниз программу из разработанных мо-

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

вниз.

Выполнение лабораторной работы студентом состоит из следующих эта-

пов:

изолированное тестирование головного модуля

к головному модулю присоединяются (например, редактором связей) один за

другим модули, непосредственно вызываемые им, и тестируется полученная

комбинация

процесс повторяется до тех пор, пока не будут собраны и проверены все мо-

дули.

Форма отчетности: Демонстрация, протестированного ПО и отчет о

прохождении каждого теста и обнаруженных ошибках.

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

Нисходящее тестирование (называемое также нисходящей разработкой)

не является полной противоположностью восходящему, но в первом прибли-

жении может рассматриваться как таковое. При нисходящем подходе про-

грамма собирается и тестируется сверху вниз. Изолированно тестируется толь-

ко головной модуль. После того как тестирование этого модуля завершено,

с ним соединяются (например, редактором связей) один за другим моду-

ли, непосредственно вызываемые им, и тестируется полученная комбинация.

Процесс повторяется до тех пор, пока не будут собраны и проверены все мо-

дули.

При этом подходе возникают два вопроса: что делать, когда тестируе-

мый модуль вызывает модуль более низкого уровня (которого в данный мо-

мент еще не существует), и как подаются тестовые данные. Ответ на пер-

вый вопрос состоит в том, что для имитации функций недостающих модулей

программируются модули-“заглушки”, которые моделируют функции отсут-

ствующих модулей. Фраза “просто напишите заглушку” часто встречается в

описании этого подхода, но она способна ввести в заблуждение, поскольку

задача написания “заглушки” может оказаться трудной. Ведь заглушка ред-

ко сводится просто к оператору RETURN, поскольку вызывающий модуль

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

встраивают фиксированные выходные данные, которые она всегда и возвра-

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

может рассчитывать, что результат вызова зависит от входных данных. По-

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

приближаясь по сложности к модулю, который она пытается моделировать.

Интересен и второй вопрос: в какой форме готовятся тестовые данные

и как они передаются программе? Если бы головной модуль содержал все

нужные операции ввода и вывода, ответ был бы прост: тесты пишутся в виде

обычных для пользователей внешних данных и передаются программе через

выделенные ей устройства ввода. Так, однако, случается редко. В хорошо

спроектированной программе физические операции ввода-вывода выполня-

ются на нижних уровнях структуры, поскольку физический ввод-вывод —

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

блему экономически эффективно, модули добавляются не в строго нисходя-

щей последовательности (все модули одного горизонтального уровня, затем

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

рование операций физического ввода-вывода как можно быстрее. Когда эта

цель достигнута, нисходящее тестирование получает значительное преимуще-

ство: все дальнейшие тесты готовятся в той же форме, которая рассчитана

на пользователя.

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

необходимости в драйверах; вместо драйверов вам просто следует написать

“заглушки”. Как читатель сейчас уже, вероятно, понимает, это преимущество

спорно.

Нисходящий метод тестирования имеет, к сожалению, некоторые недо-

статки. Основным из них является тот, что модуль редко тестируется доско-

нально сразу после его подключения. Дело в том, что основательное тестиро-

вание некоторых модулей может потребовать крайне изощренных заглушек.

Программист часто решает не тратить массу времени на их программирова-

ние, а вместо этого пишет простые заглушки и проверяет лишь часть усло-

вий в модуле. Он, конечно, собирается вернуться и закончить тестирование

рассматриваемого модуля позже, когда уберет заглушки. Такой план тести-

рования определенно не лучшее решение, поскольку об отложенных условиях

часто забывают.

Второй тонкий недостаток нисходящего подхода состоит в том, что он

может породить веру в возможность начать программирование и тестирова-

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