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

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

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

Многих проблем при разработке программных продуктов можно избежать используя в системе управления версиями, так называемых, блочных тестов (unit test). Блочный тест, или тестовое приложение, представляет собой фрагмент кода, управляющей выполнением основной программы. Этот специальный код создается программистами для тестирования «белого ящика» и контролирует выполнение программой основных процедур и операций приложения. Подробное описание блочных тестов. Блочные тесты в системе управления значительно облегчает работу разработчикам, сопровождающим приложение, а также упрощает контрольное тестирование программы и сосредоточить внимание на более важных моментах: производительности, масштабируемости приложения, полному соответствию требований заказчика, т.е. тестирование приемлемости - проверка соответствия программы требованиям пользователя. Использование блочных тестов это хороший показатель профессионализма разработчиков программ.

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

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

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

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

В коде любого созданного приложения обязательно будут ошибки. Если говорить о синтаксических ошибках, которые вызваны неверным вводом команд в редакторе, либо неверной записью идентификаторов и иными неверными действиями программиста, то они почти всегда фиксируются самим компилятором Delphi. Следует постоянно обращать внимание на различные сообщения и предупреждения, выдаваемые при прогоне программы, это может помочь обнаружить найти ошибку в тексте кода. Но многие ошибки связаны с тем, что неточно реализована логика самого алгоритма. Такие дефекты обнаруживаются только во время выполнения контрольных примеров. Так бывает например, когда вместо символа "<" ошибочно введен символ "<=". Если вдруг исходный алгоритм реализуется неправильно, то работоспособность приложения может быть даже, и не нарушено, но результаты будут выдаваться неверные или программой будут выполняться неверные действия. Поэтому и обнаруживаются подобные ошибки лишь на этапе отладки.

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

Из всех инструментов встроенного отладчика наиболее часто используются точки остановки - BreakPoint. После установки точки, приложение будет работать до тех пор, пока не достигнет ее, после чего работа программы будет остановлена и управление переходит к отладчику Delphi. Точки остановки удобнее всего снимать и ставить нажатием горячей клавиши «F5», либо зайти в меню «Debug->Toggle breakpoint», либо другими способами.

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

Возникает вопрос: где ставить эти точки? Однозначного ответа дать нельзя. Они предназначаются лишь для того, чтобы облегчить нам изучение работы программного кода, если нет уверенности в его корректности, или содержащего явную ошибку незаметную при беглом просмотре. Конечно куда проще поставить точку остановки и последовательно выполнить нужные строчки, чем потратить кучу времени на изучение этого же самого кода, пытаясь определить, где же он начал работать неправильно.

В качестве примера можно представить листинг, в котором значению переменной присваивается значение равное единице, а затем четыре раза будем прибавлять единицу и после этого прибавим 123. Результат будет представлен в виде десятичного и шестнадцатеричного значения, т.е. должно получиться 128 и 00000080. При этом в программном коде будет допущена ошибка.

var

Form1: TForm1;

A: Integer;

B: Integer = 123;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);

begin

Inc(A);

Inc(A);

Inc(A, B);

Inc(A);

Inc(A);

ShowMessage(IntToStr(A));

ShowMessage(IntToHex(A, 8));

end; [4]

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

Получается следующая картина: точка установки стоит на строчке Inc(A). В специальном окне «Local Variables», можно видеть значения всех используемых локальных переменных процедуры создания формы, а также переменной Self, передающейся неявно и всегда присутствующей в методах класса и параметра Sender.

Взглянув на значение переменной A можно сразу уяснить, что код выполняется с ошибкой, а результат не соответствует нужному значению. Так как выполнялись два инкремента на единицу и еще одно увеличение на число 123, должно было появиться значение переменной A равное 126. У нас получилось – 125, следовательно, исходное значение переменной A было не равно единице.

Для просмотра и изменения значения переменной в отладчике Delphi существуют два инструмента. Можно вызвать специальное окно «Evaluate/Modify» через меню или с помощью горячей клавиши «Ctrl+F7». Этот инструмент очень простой и используется в большинстве чаще всего. Выглядит он примерно так:

Чтобы изменить значение переменной A, необходимое нам значение вводится в поле «New value». Далее жмем «Enter» или кнопку «Modify».

Другой инструмент «Inspect» вызывается из диалога «Evaluate/Modify». Он является уже более продвинутым редактором значений переменных. Вызвать его можно и через меню «Run».

Это более «продвинутый» редактор свойств переменных, но его использование оправдано при изменении свойств объектов. Для изменения обычной переменной он несколько не удобен, и вот почему. При вызове его появится диалоговое окно, в котором можно увидеть описание переменной, адрес ячейки памяти, где она располагается, а также текущее значение переменной. Для внесения изменений необходимо нажать кнопку с троеточием, после чего откроется диалоговое окно окно:

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

Изменив значение переменной A на правильное, можно продолжить выполнение нашей программы нажав «F9» или «Run». После произведенных действий при помощи отладчика, процедура возвратит нужные значения. Теперь можно спокойно исправлять код процедуры, т.е. присвоить переменной A значение 1 – «A:= 1».

Для изменения значений обычных переменных это все выглядит слишком трудоемко, но если необходимо изменять свойства объектов, то инструмент «Inspect» окажется очень удобным помощником.

Он предоставит доступ ко всем свойствам объекта, которые нуждаются в изменении. [2]

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

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

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

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

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

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

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

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

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