- •4.9.1. Изменяемость
- •4.9.2. Классы операций
- •98 Глава 4
- •4.9.3. Полнота
- •100 Глава 4
- •4.9.5. Операции egual, similar и copy
- •102 Глава 4
- •104 Глава 4
- •5. Исключительные ситуации
- •108 Глава 5
- •110 Глава 5
- •6.2.1. Сигнализация об исключительных ситуациях
- •5.2.2. Обработка исключительных ситуаций
- •112 Глава 5
- •5.2.3. Предложение resignal
- •6.2.4. Необрабатываемые исключительные ситуации
- •114 Глава 5
- •6.2.3. Предложение resignal
- •5.2.4. Необрабатываемые исключительные ситуации
- •116 Глава 5
- •118 Глава 5
- •118 Глава 5
- •120 Глава 5
- •122 Глава 5
- •124 Глава 5
- •128 Глава 6
- •130 Глава 6
- •6.2.1. Реализация итераторов
- •6.2.2. Использование итераторов
- •132 Глава 6
- •134 Глава 6
- •136 Глава 6
- •138 Глава 6
- •140 Глава 7
- •142 Глава 7
- •7.2. Абстракция данных
- •144 Глава 7
- •146 Глава 7
- •148 Глава 7
- •150 Глава 7
- •7.4. Генераторы
- •162 Глава 7
- •154 Глава 7
- •156 Глава 7
- •162 Глава 8
- •164 Глава 8
- •166 Глава 8
- •168 Глава 8
- •170 Глава 9
- •172 Глава 9
- •174 Глава 9
- •176 Глава 9
- •9.1.3. Пример
- •178 Глава 9
- •180 Глава 9
- •182 Глава 9
- •184 Глава 9
- •186 Глава 9
- •188 Глава 9
- •190 Глава 9
- •192 Глава. 9
- •194 Глава 9
182 Глава 9
лишь четырех маршрутов; различные маршруты получения результата процедурой pred в данном случае не анализируются. Однако проверка процедуры предполагает много различных тестов. Объединение всех этих вариантов проверки имеет много недостатков. Число тестов и время их выполнения возрастает) а при изменении в реализации любого из этих модулей необходимо пересматривать всю процедуру тестирования. Более эффективна индивидуальная проверка каждого модуля.
9.3. Средства тестирования
Процесс отладки всегда желательно максимально автоматизировать. Обычно мы не можем автоматизировать генерацию проверочных данных. Генерация соответствующих данных для проверки программы является неалгоритмическим процессом, требующим тщательного анализа. Далее, задача автоматизации принятия решения о том, какие выходные данные для произвольного входного набора считать удовлетворительными, обычно также трудна и так же подвержена ошибкам, как и процесс написания самой тестируемой программы.
Однако мы можем автоматизировать процесс вызова программы с заранее определенной последовательностью входных данных и дальнейшую проверку получаемых результатов с заданной проверочной последовательностью. Выполняющий это механизм называется драйвером. Драйвер вызывает тестируемую программу и следит за ее выполнением. Более конкретно, это предполагает:
1. Установку окружения, необходимого для вызова проверяемого модуля. В некоторых языках (но не в языке CLU) это предполагает создание и инициализирование глобальных переменных.
2. Выполнение ряда вызовов. Аргументы для этих вызовов могут быть считаны из файла или встроены в программу драйвера. Если аргументы считываются из файла, то, если это возможно, они должны быть проверены на соответствие. 3. Сохранение результатов и проверку их на соответствие. К наиболее распространенному способу проверки соответствия результатов предполагаемым является сравнение их с контрольной последовательностью значений, которая была помещена в файл. Однако иногда более удобно написать программу) которая сравнивает результаты непосредственно с входными значениями. Например, если программа должна находить корни полинома, то достаточно просто написать программу, проверяющую, являются ли в действительности полученные значения корнями данного полинома. Аналогично, результат работы программы sqrt легко проверить непосредственным вычислением.
^Тестирование и отладка
1Драйвер, проверяющий реализацию программы sqrt, показан 1иа рис. 9.5.
% считать следующие файлы в качестве входных; % file_of_tests, bad.tests, correct.results, incoirect.results
for % каждого теста в file_of_tests
do it test.square < 0 [ test.epsilon < .00001 I test.epsilon »> .001 then % добавить test к bad Jests else result := sqrt (test,square, test.epsilon) if real$abs (square — result * result) < == epsilon then % добавить (test, result) к correct_results else % добавить (test, result) к incorrect results end end end Рис. 9.5. Драйвер для программы sqrt.
При тестировании помимо драйверов также используются заглушки. Драйвер имитирует части программы, к которым обращается тестируемый модуль. Заглушки имитируют части программы, вызываемые тестируемой программой. Заглушка должна 1) проверять корректность окружения, создаваемого вызывающей программой; 2) проверять правильность аргументов, передаваемых пользователем; 3) модифицировать аргументы и окружение и возвращать значения, позволяя вызывающей программе продолжить свою работу. Лучше всего, если эти процессы соответствуют спецификации модуля, имитируемого данной заглушкой. К сожалению, это не всегда возможно. Иногда «правильное» значение может быть получено только самой имитируемой программой. В таких случаях мы должны остановиться на каком-нибудь «приемлемом» значении.
(Если все взаимодействия между модулями осуществляются через аргументы и результаты, то нет необходимости проверять или модифицировать аргумент.)
Очевидно, что драйверы требуются при тестировании тех модулей, для которых вызывающие их модули еще не были созданы. Заглушки используются для проверки тех модулей, для которых еще не были созданы вызываемые ими модули. Оба способа необходимы для проверки отдельных программных единиц, когда мы хотим максимально изолировать проверяемую единицу от остальных частей программы,
На практике заглушки и драйверы принято использовать для тестирования в интерактивном режиме. Самая простая реализация заглушки может просто печатать аргументы, с которыми она была вызвана, и выдавать запрос к пользователю на ввод значений, которые должны быть ею возвращены. Аналогично в случае использования простейшего драйвера проверка правильности результатов возлагается на производящего тестирование человека. Хотя такие драйверы и заглушки легко реализуются, их следует