Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
45
Добавлен:
23.03.2015
Размер:
884 Кб
Скачать

180 Глава 9

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

intset = cluster is create, insert, delete, member, size, elements rep == array [int]

create =r proc ( ) returns (cvt) return (rep$new ( )) end create

insert == proc (s: intset, x: int)

it member (s, x) then rep$addh (down (s), x) end end insert

delete = proc (s: cvt, x: int) for j: int in rep$indexes (s) do it s [j] = x then s [j] :== rep$top (s)

rep$remh (s) end end end delete

member = proc (s: cvt, x: int) returns (bool) for y: int in rep$elements (s) do if у = x then return (true) end end return (false) end member

size == proc (s; cvt) returns (int) return (rep$size (s)) end size

elements = iter (s: cvt) yields (int) for y: in rep$elements (s) do yield (y) end end elements

end intset Рис. 9.4. Реализация целочисленного набора intset.

Тестирование и отладка

9.2. Индивидуальное и интегральное тестирование

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

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

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

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

1. Модуль Q проверяется с входными значениями, которые не были учтены при индивидуальной проверке.

2. Модуль Q ведет себя не в соответствии с предположением, выдвинутым при тестировании Р.

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

Соседние файлы в папке POSIBNIK