Содержание

• Содержание
  • Поиск и исправление ошибок
  • Правила составления тестов
• Оптимизация программ
• Примечания

Поиск и исправление ошибок

При поиске ошибок большим подспорьем является возможность пошагового выполнения (трассировки) программы с параллельным отслеживанием того, как меняются в ходе неё значения переменных. В среде Turbo Pascal для этого имеются следующие инструменты:

• Нажатие клавиши F4 выполнит программу до той строки, на которой установлен курсор, затем приостановит выполнение.
• Нажатие клавиши F7 или F8 позволяет выполнять программу пошагово: по одному оператору (различие между этими функциями состоит в том, производится или нет трассировка текстов подпрограмм).
• Использование окна отладочной выдачи Отладка | Наблюдения (в английской версии Debug | Watch) позволяет в процессе выполнения программы следить за тем, как изменяются значения переменных (нажатие клавиши Insert добавляет в это окно новую переменную).

Более подробно эти возможности описаны в руководствe по среде Turbo Pascal.

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

Совет 16. Пользуйтесь всеми доступными инструментами отладки.

Совет 17. На всех ключевых участках, а также на границах логически самостоятельных блоков вставляйте в программу отладочные операторы печати, которые позволят вам проследить изменение состояния основных переменных. Эта процедура не всегда может быть заменена просмотром изменений, который можно осуществить с помощью окна Watch. Зачастую бывает необходимо иметь перед собой для сравнения результаты нескольких последовательных итераций, либо нужно видеть одновременно первые и последние результаты, либо в процессе прогонки возвращаться по списку выдачи назад, к предыдущим результатам. Ничего этого параллельный просмотр в Watch сделать не позволяет.

Если отладочная выдача настолько объёмна, что не помещается целиком на экран, её приходится производить в файл.

Совет 18. Следите за тем, чтобы отладочная печать выдавала именно то, что нужно. Совершенно невозможно отловить ошибку в программе, если под именем проверяемой переменной вам выдаётся значение другой переменной!

Самый легкий случай, — когда из–за опечатки полностью меняется вид вывода. Например, правильный оператор WriteLn(a + 1) должен выдать число, если же вместо числа на экране вдруг появляется слово FALSE, то это явный признак того, что произошла опечатка и выдаётся результат сравнения переменной а с единицей: WriteLn(a = 1).

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

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

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

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

Правила составления тестов

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

Заметим, что если полученный результат отличается от эталонного, то тест считается удачным (!), потому что он помог обнаружить ошибку. А если полученный ответ совпал с правильным — радоваться рано. Один тест не может полностью проверить всю программу, ошибка вполне могла затаиться в той части, которая осталась на сей раз невыполненной. Для того, чтобы протестировать всю программу, проверить все возможные частные случаи, составляют не один тест, а набор тестов.

И здесь существуют следующие правила.

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

Проверяйте вручную результаты тестов, с помощью которых вы отлаживаете программу. Немногого можно добиться, если выдаваемый программой правильный ответ вы считаете неверным и продолжаете поиск несуществующей ошибки. Хуже того — если вы всё–таки добьётесь, чтобы программа выдавала ожидаемый вами неверный результат, объяснить её неправильное поведение на других тестах вам будет ещё сложнее.

Из двух предыдущих абзацев вытекает очень важный вывод: нельзя строить тесты при помощи генератора случайных чисел. Конечно, вы можете случайным образом составить входные данные, но как быть с правильным ответом? Откуда его взять, если вы сами понятия не имеете, что там подаётся на вход?

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

Правило 3. Не ограничивайтесь только похожими тестами.

Все тесты можно разделить на три группы: регулярные, граничные и критические. Например, при заданных ограничениях на параметр 0 <= x <= 100 регулярными будут все тесты, где 1 <= x <= 99; граничными, где х = 0 и х = 100; остальные — критическими. Если ваша программа правильно работает для пяти–шести тестов из какой–либо группы, можно предположить, что она выдаст правильный результат и для всех остальных тестов из этой группы.

В тестовом наборе, составленном для проверки программ, обязательно должны присутствовать тесты первых двух групп, а для проверки работоспособности «защиты от дурака» (см. лекцию 14) — и третьей тоже. Если входных параметров несколько — комбинируйте! Пусть в одном и том же тесте первый параметр будет граничным, второй — регулярным, а третий — критическим. Всегда интересно посмотреть, достаточно ли надёжна ваша программа, справится ли она с таким заданием.

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

Правило 4. Исправления, вносимые в программу, могут повлиять на результаты нескольких тестов.

После того, как вы нашли и исправили ошибку, вновь выполните программу на всех тех тестах, которые раньше не были успешными (то есть, выдавали правильные ответы) — а вдруг найдётся новая ошибка?

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

Оптимизация программ

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

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

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

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

Например, ясно, что из двух эквивалентных кусков

и

второй является и более быстрым (особенно если b = 10000), и более компактным, чем первый.

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

Успехов вам в написании красивых и полезных программ!

Примечания