Файл: Отладка и тестирование программ: Основные подходы и ограничения (Сущность тестирования и отладки. Методика выявления ошибок).pdf

Если необходимо в отдельных модулях отключать проверку переполнения, как например, в алгоритмах шифрования, то в данных (отдельных) модулях используется директива «{$OVERFLOWCHECKS OFF}».

Группа параметров «Debugging» включает параметры, влияющие лишь на полноту отладочной информации в DCU-файлах. Исключение составляет лишь параметр «Assertions», включающий в работу процедуру Assert().

В целом рекомендуется во время отладки приложений устанавливать все параметры из групп «Runtime errors» и «Debugging» включенными, а отключать их уже при заключительной компиляции готового приложения. В Delphi 7 и ниже это приходится делать вручную, а более новых студиях есть хорошая поддержка билдов проекта, где персонально для отдельных видов сборок можно выставлять все необходимые опции.

Вторым по важности инструментом при отладке приложений является окно «Call Stack» второй по значимости. Оно содержит описание всех вызовов до возникновения исключения, ошибки или прерывания в точке остановки.

Используя двойной клик можно быстро переключаться между вызовами и просматривать список локальных переменных для каждого вызова («View Locals»), а также устанавливать точки прерывания на любом вызове. Это позволяет быстро локализовать ошибку при отладке и значительно облегчает работу программисту.

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

Помимо кода программы приходится работать также с данными различных типов и областями памяти. В отладчике, при помощи «Data breakpoint», предусмотрена возможность устанавливать точки остановки на адреса, указывающие ячейки памяти. Это делается через «Watch List» или в окне «Breakpoint List» при помощи «Add Breakpoint->Data Breakpoint», где, в диалоге, следует указать адрес области памяти, ее размер, либо или имя нужной переменной. Если мы указываем имя переменной, то отладчик будет пытаться отыскать ее в памяти и установить точку остановки. Адрес памяти где содержится значение переменной меняется при каждом новом запуске программы, поэтому получить значение довольно сложно. [4]

Область видимости глобальных переменных доступна всегда, и, даже без запуска приложения, отладчик разрешает устанавливать «Data breakpoint» на изменения в таких переменных, даже без запуска программы. При этом отладчик определяет адрес глобальной переменной исходя из предыдущей сборки программы. Этот адрес может не совпасть при следующем прогоне программы. А вот с локальными переменами дело обстоит еще хуже, поскольку они располагаются на стеке, и, выйдя из области видимости, то их место в стеке занимают другие значения. Получается, что установка «Data breakpoint» на любую локальную переменную возможна только тогда, когда она находится в области видимости.

Нужно отметить, что отладчик Delphi не является профессиональным средством отладки сторонних приложений. Столь важный и удобный инструмент как «Memory Breakpoint» имеет урезанный вариант. Там сохранена лишь возможность контролировать адрес памяти на запись. [6] Но, тем не менее, даже в очень урезанном варианте он является хорошим инструментом для контроля изменений в памяти приложения, конкретно для поиска ошибок при адресной арифметике.

ЗАКЛЮЧЕНИЕ

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

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

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

В заключении себе и другим будущим программистам хочу дать следующие рекомендации:

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

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

Тесты следует готовить и для правильных, так и для неверных данных.

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

Модули должны подключаться к приложению только один раз; замена модулей существенно усложняет тестирование.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Гласс Р. Руководоство по надежному программированию. / Р. Гласс. – М.: Финансы и статистика, 2010. — 256 с.

2. Криспин Л., Грегори Дж. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. / Л. Криспин, Дж. Грегори. — М.: «Вильямс», 2010. — 464 с.

3. Майерс Г., Баджетт Т., Сандлер К. Искусство тестирования программ, 3-е. / Г. Майерс, Т. Баджетт, К. Сандлер. — М.: «Диалектика», 2012. — 272 с.

4. Пестриков В. М., Маслобоев А. Н. Delphi на примерах. / В. Пестриков М., А. Маслобоев — СПб.: БХВ-Петербург, 2009. — 496 с.

5. Тамре Л. Введение в тестирование программного обеспечения. / Л. Тамре. – М., Дрофа. — 2009. – 359 с.

6. Фленов М. Программирование в Delphi глазами хакера. / М. Фленов — СПб.: БХВ-Петербург, 2009. — 368 с.

ПРИЛОЖЕНИЕ

Глоссарий

продолжение таблицы