Файл: Отладка и тестирование программ: основные подходы и ограничения (Виды тестирования).pdf
Добавлен: 28.03.2023
Просмотров: 150
Скачиваний: 1
В нем будет указано описание переменной, ее расположение в памяти и ее текущее значение, а для изменения нужно будет еще раз нажать на кнопку с троеточием, после чего появится дополнительное окно:
Изменив значение переменной A на правильное, можно продолжить выполнение нашей программы нажав «F9» или «Run». После произведенных действий при помощи отладчика, процедура возвратит нужные значения. Теперь можно спокойно исправлять код процедуры, т.е. присвоить переменной A значение 1 – «A:= 1».
Для изменения значений обычных переменных это все выглядит слишком трудоемко, но если необходимо изменять свойства объектов, то инструмент «Inspect» окажется очень удобным помощником.
Он предоставит доступ ко всем свойствам объекта, которые нуждаются в изменении.[[11]]
2.3 Пошаговая трассировка приложения
Сущность трассировки заключается в пошаговой прогонке программного кода. При выполнении трассировки можно использовать команды, представленные в таблице 1.[[12]]
Таблица 1
Наименование команды |
Горячая клавиша |
Действие отладчика |
«Trace Into» |
«F7» |
отладчик выполнит код текущей строчки кода и остановится на следующей. Если в данной строке происходит вызов процедуры, то следующей строкой будет первая строка вызываемой процедуры. |
«Step Over» |
«F8» |
аналогично «Trace Into», но вход в тело вызываемой процедуры не происходит. |
«Trace to Next Source Line» |
«Shift+F7» |
полный аналог первой команды, но используется в окне «CPU-View» |
«Run to Cursor» |
«F4» |
отладчик будет выполнять код программы до той строчки, на которой сейчас находится курсор |
«Run Until Return» |
«Shift+F8» |
отладчик будет выполнять код текущей процедуры до тех пор, пока не произойдет выход из нее. |
«Set Next Statement» |
«Shift+F4» |
изменить ход выполнения программы, установив в качестве текущей любую строку кода. Так же эта возможность доступна в редакторе кода там, где можно перетащить стрелочку, указывающую на текущую активную строчку в новую позицию. |
Компилятор среды разработки должен быть настроен должным образом, поскольку от выставленных опций будет зависеть не только поведение выполняемого кода, но и на отображаемую информацию, которая будет доступна при отладке проектируемого продукта.
К примеру, группа «Code generation», в которой параметр «Optimization» оказывает непосредственное влияние на оптимизацию программного кода. Этот параметр желательно включить, и он обеспечит генерацию кода наилучшим образом. Будет учтена и скорость исполнения кода, и его размер. Однако при этом возможно потеря доступа к некоторым из локальных переменных, поскольку в момент прерывания на точке остановки из-за оптимизации кода может произойти их удаление из памяти.
Опрция «Record field alignment» устанавливает выравнивание неупакованных записей. Эту опцию можно изменять в процессе кодирования модуля при помощи директив «{$A x}», либо «{$Align x}».
А вот в группе «Syntax options» все опции лучше оставить по умолчанию, чтобы компилятор работал нормально.
В группе параметров «Runtime errors» есть параметр «Range checking», который очень важен для отладки проектов. Этот параметр проверяет границы во время доступа к массивам данных.
Это один из наиболее востребованных параметров при отладке приложения. Он отвечает за проверку границ при доступе к массиву данных. В случае ошибки в границах блока при попытке записи в него – возможно даже разрушение памяти программы. Кроме этого данная опция контролирует возможность выхода за границы допустимого диапазона значений для локальных переменных. Поэтому производить отладку проекта всегда необходимо при включенной опции «Range checking». Параметр «Overflow cheking» работает аналогично, но только там, где используются арифметические операции с переменными (также желательно включить).
Если необходимо в отдельных модулях отключать проверку переполнения, как например, в алгоритмах шифрования, то в данных (отдельных) модулях используется директива «{$OVERFLOWCHECKS OFF}».
Группа параметров «Debugging» включает параметры, влияющие лишь на полноту отладочной информации в DCU-файлах. Исключение составляет лишь параметр «Assertions», включающий в работу процедуру Assert().
В целом рекомендуется во время отладки приложений устанавливать все параметры из групп «Runtime errors» и «Debugging» включенными, а отключать их уже при заключительной компиляции готового приложения. В Delphi 7 и ниже это приходится делать вручную, а более новых студиях есть хорошая поддержка билдов проекта, где персонально для отдельных видов сборок можно выставлять все необходимые опции.
Вторым по важности инструментом при отладке приложений является окно «Call Stack». Оно содержит описание всех вызовов до возникновения исключения, ошибки или прерывания в точке остановки.
Используя двойной клик можно быстро переключаться между вызовами и просматривать список локальных переменных для каждого вызова («View Locals»), а также устанавливать точки прерывания на любом вызове. Это позволяет быстро локализовать ошибку при отладке и значительно облегчает работу программисту.
С помощью этого инструмента удобно отслеживать и отыскивать нужные нам вызовы функций или процедур при очень большом коде приложения. Если ошибка эта происходит не всегда, а только при оперировании с определенными данными, в этом случае используется диалог настроек свойств точки остановки. Вызывается он через свойства BP в коде приложения.[[13]]
Помимо кода программы приходится работать также с данными различных типов и областями памяти. В отладчике, при помощи «Data breakpoint», предусмотрена возможность устанавливать точки остановки на адреса, указывающие ячейки памяти. Это делается через «Watch List» или в окне «Breakpoint List» при помощи «Add Breakpoint->Data Breakpoint», где, в диалоге, следует указать адрес области памяти, ее размер, либо или имя нужной переменной. Если мы указываем имя переменной, то отладчик будет пытаться отыскать ее в памяти и установить точку остановки. Адрес памяти где содержится значение переменной меняется при каждом новом запуске программы, поэтому получить значение довольно сложно.[[14]]
Область видимости глобальных переменных доступна всегда, и, даже без запуска приложения, отладчик разрешает устанавливать «Data breakpoint» на изменения в таких переменных, даже без запуска программы. При этом отладчик определяет адрес глобальной переменной исходя из предыдущей сборки программы. Этот адрес может не совпасть при следующем прогоне программы. А вот с локальными переменами дело обстоит еще хуже, поскольку они располагаются на стеке, и, выйдя из области видимости, то их место в стеке занимают другие значения. Получается, что установка «Data breakpoint» на любую локальную переменную возможна только тогда, когда она находится в области видимости.
Нужно отметить, что отладчик Delphi не является профессиональным средством отладки сторонних приложений. Столь важный и удобный инструмент как «Memory Breakpoint» имеет урезанный вариант. Там сохранена лишь возможность контролировать адрес памяти на запись.[[15]] Но, тем не менее, даже в очень урезанном варианте он является хорошим инструментом для контроля изменений в памяти приложения, конкретно для поиска ошибок при адресной арифметике.
Заключение
В большей степени успешность отладки программного продукта зависит от правильной и рациональной организации его тестирования. Во время отладки программы фиксируются и исправляются, как правило, лишь ошибки, обнаруженные ранее при тестировании продукта. При тестировании не ставится цель доказывать правильность и оптимальность приложения, оно служит для того, чтобы показать наличие в любом программном продукте ошибок и дефектов. Никто не может дать гарантию, что при тестировании программы каким либо набором тестов можно обнаружить все ошибки в программном обеспечении. Отсюда и необходимость проведения тестирования и отладки, в ходе которых необходимо решить две основных задачи. Во-первых, протестировать программу на таком наборе тестов, который позволит отыскать максимально возможное количество ошибок.
При эт ом надо уче сть возрастающую стоим ость программы пр и слишком слож ном и длите льном тестировании. В о-вторых, необх одимо определить, ког да уже мож но закончить отла дку программного прод укта; когда уж е достаточно испра влено ошибок; ког да работа прогр аммы была опроб ована во вс ех возможных ситуа циях и появл ение ошибок свед ено к мини муму. Все эт о производится исх одя из требо ваний к каче ству и надеж ности программного обеспе чения.
Отладка явля ется самым труд ным и ответст венным этапом проекти рования программного обеспе чения; так бы ло всегда, та к, наверное, и будет ещ е долго. Оши бки встречаются в любых прилож ениях, и в коммерческих, и в те х продуктах, чт о лежат в свободном дост упе на рын ке. Мы вс е привыкли к тому, чт о спустя некот орое время пос ле выхода прогр аммы на рын ок выходят всевоз можные патчи с исправлениями, т о есть небол ьшие утилиты, исправ ляющие ошибки в программе. Поско льку отладка явля ется важнейшей стад ией проектирования прило жений, то учиты вать это нуж но уже с самого нач ала его разра ботки. Отлаживать каж дый, новый созда нный класс, мет од или проце дуру. Невзирая н а то, чт о последние технолог ические решения в программировании позво ляют производить отла дку очень эффек тивно, и каж дый программист стара ется встроить возмо жные средства отла дки в св ой код, те м не мен ее, без ста дии отладки гото вого приложения обой тись нельзя. Каж дый профессиональный програ ммист обязан научи ться видеть сла бые стороны прило жения и прини мать необходимые реше ние об и х проверке и контроле.
Люб ая организация обяз ана беспокоиться о б ошибках в ее програ ммных продуктах, поско льку они мог ут дорого обой тись для и х бизнеса. Ина че ей прид ется тратить огро мные средства и время н а дальнейшую подде ржку своих прог рамм, в т о время ка к другие конкури рующие фирмы уж е создают следу ющие версии сво их аналогичных проду ктов. Закончится вс е тем, чт о потребители нач нут покупать прогр аммы конкурентов. Хоро шее программное обеспе чение сегодня востре бовано как нико гда, поэтому нак ал борьбы з а высокое каче ство программных проду ктов будет тол ько возрастать. Пользо ватели программ мог ут потенциально лег ко переключаться с программы одн ой фирмы н а программу дру гой, переходя с одного Web-сай та на дру гой. Поэтому ес ли чьи-т о программы буд ут содержать мно го ошибок, т о это нане сет непоправимый уд ар по бизн есу и ими джу компании. Вс е это дол жно побуждать произво дителей к созд анию более качест венных программ.
В заключении се бе и дру гим будущим програм мистам хочу да ть следующие рекоме ндации:
Необходимо счит ать тестирование и отладку главной ключевой задачей разработки программ. Следует поручать это наиболее квалифицированным и опытным программистам и лучше другим, чем самому.
Лучшим будет тест, который находит более всего ошибок, а вовсе не тот, который доказывает, что приложение работает правильно.
Тесты след ует готовить и для прави льных, так и для неве рных данных.
Нуж но вести прото колы работы тес тов; и подр обно изучать резул ьтаты тестирования. Ес ли использование тес та невозможно повто рить, то о т него луч ше вовсе отказ аться.
Модули дол жны подключаться к приложению тол ько один ра з; замена моду лей существенно услож няет тестирование.
И последнее. Необходимо прогонять вновь все тесты, связанные с проверкой работы какого-либо приложения или его взаимодействия с другими приложениями, если в него были внесены изменения, в результате исправления ошибок