Файл: Отладка и тестирование программ: основные подходы и ограничения.pdf

Система управления версиями должна соответствовать потребностям разработчика. Когда разработкой продукта занимается компания с требованиями класса «high-end», с поддержкой нескольких платформ, скорее всего, придется применять более дорогую систему или использовать решение с открытым кодом, например, CVS.

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

2.2 Применение точек остановки и модификация локальных переменных

2.2.1 Пошаговая трассировка приложения

Трассировка заключается в пошаговой прогонке программного кода. В процессе выполнения трассировки можно применять команды, приведенные в таблице 1.^[9]

Таблица 1

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

К примеру, группа «Code generation», в которой параметр «Optimization» оказывает непосредственное влияние на оптимизацию программного кода. Этот параметр желательно включить, и он обеспечит генерацию кода наилучшим образом. Будет учтена и скорость исполнения кода, и его размер. Однако при этом возможно потеря доступа к некоторым из локальных переменных, поскольку в момент прерывания на точке остановки из-за оптимизации кода может произойти их удаление из памяти.

Опрция «Record field alignment» устанавливает выравнивание неупакованных записей. Эту опцию можно изменять в процессе кодирования модуля при помощи директив «{$A x}», либо «{$Align x}».

В группе «Syntax options» все опции лучше оставить по умолчанию, чтобы компилятор работал нормально.

В группе параметров «Runtime errors» есть параметр «Range checking», который очень важен для отладки проектов. Этот параметр проверяет границы во время доступа к массивам данных.

Range checking - один из наиболее востребованных параметров при отладке приложения, Он отвечает за проверку границ при доступе к массиву данных. При возникновении ошибки в границах блока при попытке записи в него – возможно даже разрушение памяти программы. Помимо этого, данная опция контролирует возможность выхода за границы допустимого диапазона значений для локальных переменных. Поэтому производить отладку проекта всегда необходимо при включенной опции «Range checking». «Overflow cheking» работает аналогично, но только там, где используются арифметические операции с переменными

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Глоссарий

Список использованных источников

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

2 Керман М. К. Программирование и отладка в Delphi. Пер. с англ. — М.: Издательский дом "Вильямc", 2003, 672 с.

3 Коликова Т.В., Котляров В.П. Основы тестирования программного обеспечения, М., Бином, 2010, 285 стр.

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

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

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

7 Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М.: БИНОМ, 2008. — 368 с.

8 Стивен Р. Delphi. Готовые алгоритмы / Род Стивене; - 4-е изд. - М.: ДМК Пресс; СПб.: Питер, 2010. - 384 с.

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

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

11 Ховард М., Лебланк Д. Защищенный код: Пер. с англ, — 2-е изд., испр. М.: Издательско-торговый дом «Русская Редакция», 2004. — 704 стр.

1. Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2009. ↑

2. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010. ↑

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

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

5. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010. ↑

6. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010. ↑

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

8. Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2009. ↑

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

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

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

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