Тестирование и отладка программ. Разработка заглушек

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

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

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

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

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

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

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

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

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

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

Тестирование функциональности. Целью этого вида тестирования является проверка того, что для допустимых входных данных получаются правильные, т.е. соответствующие спецификации, результаты.

При организации данных для тестирования следует руководствоваться следующими положениями:

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

2. В качестве некоторых тестовых данных обязательно надо использовать экстремальные значения. Например, если числовая величина может находиться в диапазоне от A до B, то следует проверить следующие значения: A-1, A, A+1, B-1, B, B+1.

3. В качестве некоторых тестовых данных следует использовать специальные значения. К ним относятся константы 0, 1, пустая строка, nil, пустой файл, пустой список и др.

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

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

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

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

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

Тестовые операторы рекомендуется использовать в следующих случаях:

1.Для контроля входа подпрограммы. Можно вывести все входные данные на экран или в файл в момент ее вызова.

2. Для проверки спецификаций подпрограммы: проверка предусловия и постусловия в виде оператора if в начале и в конце подпрограммы.

3. Для контроля циклов: проверка инварианта в виде оператора if на каждой итерации.

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

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

2. Заглушка-константа. Присваивает всем входным и входно-выходным параметрам некоторые постоянные значения.

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

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

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

Дата добавления: 2014-01-07