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

Взглянув на значение переменной 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» окажется очень удобным помощником.

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

2.3 Применение трассировки приложения при тестировании и откладке ПО.

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

Таблица 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что отладчик Delphi не является профессиональным инструментом для отладки сторонних приложений. Важный и удобный инструмент, такой как «Точка останова памяти», имеет упрощенную версию.

Там сохранена лишь возможность контролировать адрес памяти на запись.^[14]

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

Список литературы

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

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

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

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