Технологии программирования

Костерин В В

3) сообщения о серьезных ошибках, при наличии которых построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно;

4) сообщения об ошибках, обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода.

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

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

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

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

• использование в программе неинициализированных переменных (т. е. переменных, не получивших начального значения);

• наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;

• наличие в тексте подпрограммы фрагментов, никогда не выполняющихся;

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

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

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

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

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

1) проведение дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ;

2) максимальное использование результатов компиляции и линковки программы и, в частности, информации, включаемой в листинг компилятора и линкера;

3) вместо полного синтаксического разбора текста проверяемой программы необходимо построение для нее списка идентификаторов и списка операторов с

указанием всех их необходимых признаков.

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

Четвертой формой статического контроля программ является их верификация, т. е. аналитическое доказательство их корректности.

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

Динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т. е. тестирование. Минимальное автономное тестирование подпрограммы должно обеспечивать прохождение всех путей вычислений.

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

— по внешним спецификациям модуля подготовьте тесты для каждой ситуации и каждого недопустимого условия;

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

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

— проверьте по тексту подпрограммы ее чувствительность к особым значениям данных (наиболее опасные числа — это ноль и единица), в случае необходимости добавьте тесты.

11.8. ПРОЕКТИРОВАНИЕ КОМПЛЕКСНОГО ТЕСТА

В комплексном тесте должны проводиться следующие виды тестирования:

• работоспособности;

• стрессов;

• предельного объема вводимых данных;

• конфигурации различных технических средств;

• совместимости;

• защиты;

• требуемой памяти;

• производительности;

• настройки;

• надежности;

• средств восстановления при отказе;

• удобства обслуживания;

• программной документации;

• психологических факторов;

• удобства эксплуатации.

11.9. СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Генераторы тестов (automatic unit test) случайным образом генерируют данные.

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

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

ВЫВОДЫ

• Тестирование программ — главное, что определяет важнейшее качество программ — надежность.