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

Содержание:

Введение

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

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

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

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

Допущение в программах ошибок — это отличная практика. Ошибки помогают нам узнать принцип работы механизма отлалки. Разработчику следует найти ошибки до того момента, как заказчик увидит результат. Если ошибки в программах находят заказчики, это не есть хорошо.

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

1. Сущность тестирования и отладки. Методика выявления ошибок

1.1 Тестирование и его виды

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

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

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

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

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

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

В 2000-е было введено еще более широкое определение тестирования. оно было дполнено таким понятием, как оптимизация бизнес-технологий. Business Technology Ooptimiation задает направление развитию информационных технологий в соответствии с целями, преследуемыми бизнесом. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки для достижения необходимого уровня качества, производительности, доступности.^[1]

1.2 Виды тестирования

Исходя из преследуемых целей, можно условно разделить на три группы основные виды тестирования программ:

Функциональные

Нефункциональные

Связанные с изменениями

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

Модульное тестирование подразумевает контроль отдельного программного модуля.

Интеграционное тестирование – объединенное тестирование отдельных программных модулей.

Системное тестирование - выполняется на интегрированной системе с целью проверки системы на соответствие исходным требованиям.

Приемочное тестирование - способ проверки и контроля за соответствием работы приложения функциональным, нефункциональным и другим важным требованиям.^[2]

Такие виды тестирования рассматривают внешнее поведение системы. Они делятся на три класса: функциональное тестирование; тестирование безопасности; тестирование взаимодействия.^[3]

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

Достоинство функционального тестирования – имитация фактического использования программы, недостатки - возможность упущения логических ошибок в продукте и возможная вероятность избыточного тестирования. Автоматизация функционального тестирования Имеет широкое распространение.

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

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

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

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

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

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

Тестирование – одна из наиболее важных задач по обеспечению качества программного обеспечения. В настоящее время наибольшее распространение получила установка программ посредством инсталляторов.

При отстутствии инсталляторов установка производится самостоятельно согласно инструкциям и спецификациям..

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

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

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

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

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

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

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

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

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

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

1.3 Сущность и методика отладки программ. Виды ошибок

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

Нелогичный пользовательский интерфейс;

Неудовлетворенные ожидания;

Низкая производительность;

Аварийные завершения или разрушение данных.

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

Эта задача существенно усложняется при проектировании интерфейса Web-приложения. Уже не будет конкретных стандартов на пользовательский интерфейс. Необходимо учитывать возможную низкую скорость трафика. Исходя из этого, рекомендацией будет создание пользовательского интерфейса максимально простым. К примеру, простые решения, подобные CNN.com, большинство пользователей оцениваются положительно.^[6]

Наиболее трудноразрешиимая проблема – это неудовлетворенное ожидание конечного потребителя. Обычно это происходит по причине недостаточного исследования реальных потребительских потребностей, то есть возникает проблема взаимодействия. Такие ошибки часто возникают на начальных стадиях проектирования.^[7]

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

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

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

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

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

При уделении достаточного внимания всякого рода деталям можно существенно минимизировать ошибки. Существует достаточно много причин появления этих ошибок, однако из них можно выделить основные моменты. Чаще всего это непонимание требований, которые предъявляются к программному продукту. Примером тому является наполнение приложения ненужными функциями и другими мелочами без надобности. Также причиной могут быть сами разработчики, не имеющие достаточной квалификации. К административным причинам относятся сильно ужатые сроки на разработку продукта. Установленные сроки должны обсуждаться всем коллективом разработчиков, исходя из перечня функций, которые нужно реализовать. При нехватке временного ресурса на качественное выполнение работы целесообразнее просто отказаться от выполнения. Наиболее распространенной причиной возникновения ошибок в программах является недостаточная ориентация на выпуск продукции надлежащего качества. Разработчики должны гордиться своим творением и усердно работать со всеми элементами их продукта, а не только с интересными для них. К примеру, выбирается более простой алгоритм и проводится анализ метода, каким образом провести тесты вместо того, чтобы углубиться в детали алгоритма. Алгоритмы заказчика не интересуют. Он зинтересован в качественном продукте, котрый будет функционировать на приемлемом уровне. Разработчики ПО обязаны нести персональную ответственность, опираться на тщательное планирование, осуществлять надлежащий уровеньконтроль качества и обладать хорошими способностями к общению между собой и с клиеннтами.^[8]

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

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

2. Практика отладки приложений в среде Delphi

2.1 Два важных инструмента тестирование отладка программный delphi

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

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

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

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

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

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

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

Что касается системы отслеживания ошибок, так это то, что в ней не только копится информация об ошибках, но к тому же ее очень удобно применять с целью хранения разных заметок и списка заданий на стадии разработки исходного кода. Абсолютное большинство разработчиков хранит списки заданий в телефонах и нужная информация часто теряется среди отладочных и других файлов. По этой причине рекомендуется в системе отслеживания ошибок сохранять свои заметки с той целью, чтобы не тратить время на их поиск и они всегда были под рукой. Большим плюсом системы отслеживания ошибок является то, что полные сведения об ошибках и запросы реализации функций хранятся в одном месте. Уследить за информацией при хранении ее в разных местах – довольно проблематично.

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

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

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

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

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

Таблица 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 - один из наиболее востребованных параметров при отладке приложения, Он отвечает за проверку границ при доступе к массиву данных. При возникновении ошибки в границах блока при попытке записи в него – возможно даже разрушение памяти программы. Помимо этого, данная опция контролирует возможность выхода за границы допустимого диапазона значений для локальных переменных. Поэтому производить отладку проекта всегда необходимо при включенной опции «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 с. ↑