Проверка программы

Программа написана, настает время для ее отладки и тестирования, Этот процесс предшествует ее эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

Программы следует тестировать также для того, чтобы определить их вычислительные ограничения. Многие программы для некоторых входных данных работают хорошо, а для других плохо. Желательно, чтобы характеристика работы алгоритма «плавно» менялась от хоро­шей к плохой при переходе от входных данных, на которых алгоритм хорошо работает, к входным данным, для которых это не так. Алго­ритм ETS хорошо работает для n<7 и очень плохо для n>15. К сожа­лению, в данном случае переход не плавный, н алгоритм имеет тен­денцию плохо работать в промежуточных случаях. Желательно поль­зоваться как аналитическими, так и экспериментальными методами, чтобы охарактеризовать те входные данные, которые считаются или «хорошими», или «плохими».

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