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

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

Группа параметров «Отладка» включает параметры, которые влияют только на всю отладочную информацию в файлах DCU. Единственным исключением является параметр «Утверждения», который включает процедуру «Утверждений».

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

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

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

В дополнение к программному коду вы также должны работать с данными разных типов и областей памяти. В отладчике с помощью «Точки останова данных» можно установить точки остановки по адресам, указывающим расположение памяти. Это делается через «Список наблюдения» или в окне «Список точек остановки», используя «Добавить точку разрыва-> точку остановки», где вы должны указать адрес зоны. памяти, ее размера или имени требуемой переменной. Если мы укажем имя переменной, отладчик попытается найти ее в памяти и установить точку остановки. Местонахождение памяти, где находится значение переменной, изменяется при любом новом запуске программы, из-за этого получить значение довольно проблематично.

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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 стр.

Приложение

Глоссарий