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

Содержание:

Введение

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

Тестирование - это процесс, который гарантирует правильную работу разрабатываемых программ, а также её различных функций и показывает отсутствие багов в программном продукте. Можно заметить, что данное определение не совсем корректно и даже неправильно. Человек с опытом программирования приложений знает, что полное отсутствие ошибок в программе невозможно идентифицировать и показать. Более подходящим является определение процесса тестирования и отладки в качестве конечного этапа создания программного продукта, который заключается в выполнении программы для обнаружения ошибок и ошибок в программном коде. Вместо того, чтобы гарантировать отсутствие ошибок в новой программе, было бы разумнее продемонстрировать по крайней мере их присутствие. Если приложение работает правильно при запуске многих различных тестов, оно дает некоторую уверенность, но все же не гарантирует отсутствие ошибок в нем. Это только показывает, что мы все еще не знаем, в каких случаях программа может выйти из строя. Получается «парадокс тестирования». Он основан на двух противоположных утверждениях: с одной стороны, тесты позволяют обеспечить надлежащее функционирование продукта; а с другой - обнаруживает ошибки в программном обеспечении, показывая, что продукт не работает. Вторая цель тестирования более продуктивна с точки зрения улучшения качества, поскольку она не позволяет игнорировать недостатки ПО.

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

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

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

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

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

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

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

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

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

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

Уже в 1980-х годах тестирование было дополнено понятием предотвращения ошибок. Одним из наиболее эффективных методов предупреждения ошибок является – проектирование тестов. Затем они осознали необходимость методики тестирования, а именно, что тестирование программы должно выполняться на протяжении всего цикла разработки, и этот процесс должен быть управляемым. Он проверяет не только запрограммированную сборку программ, но также их код, архитектуру, спецификации, а также сами тесты. Все это позволит выявить проблемы в требованиях и архитектуре и тем самым значительно сократить время и ресурсы для разработки приложений. Позже появились первые инструменты автоматизации процесса тестирования. Поскольку ЭВМ более надежна и способна выполнить больше тестов. Со временем простейшие методы стали более сложными, и скрипты сценариев для автоматических тестов стали использоваться.

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

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

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

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

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

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

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

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

Модульное тестирование - это управление одним программным модулем, обычно в изолированной среде.

Интеграционные тесты - когда отдельные программные модули объединяются и тестируются в группе.

Тестирование системы - тестирование программ, которое выполяется на главной интегрированной системе для того чтобы проверить соответствие системы исходным требованиям.

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

Все представленные виды тестирования изучают внешнее поведение системы, а также подразделяются на 3 вида: 1) функциональная проверка; 2) проверка безопасности; 3) проверка взаимодействия.

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

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

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

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

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

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

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

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

Если установщик не установлен, установка выполняется независимо в соответствии с инструкциями и спецификациями или специальным планом установки; например, в распределенных системах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 Два важных инструмента

тестирование отладка программный delphi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, вы можете представить список, в котором значение переменной присваивается значению, затем мы добавляем единицу четыре раза, а затем добавляем 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;^[1]

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

Получается следующая картина: точка установки стоит на строчке Inc(A). В специальном окне «Локальные переменные» вы можете увидеть значения всех локальных переменных, используемых для создания формы, а также переменную 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».

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

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

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

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

Таблица 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»	изменить ход выполнения программы, установив в качестве текущей любую строку кода. Кроме того, эта функция доступна в редакторе кода, где вы можете перетащить стрелку, указывающую на текущую активную строку в новой позиции.

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

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

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

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

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

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

Если необходимо отключить управление переполнением в отдельных модулях, например, в криптографических алгоритмах, (отдельные) модули данных используют директиву «{$ 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 стр.

Приложение

Глоссарий

№ п/п	Понятие	Определение
1	Интеграционное тестирование	тестирование, при котором, отдельные программные модули объединяются и тестируются в группе.
2	Испытание	поиск возможных ошибок, выполняя приложение в заданной реальной среде.
3	Комплексное тестирование	контроль и испытание системы по отношению к исходным целям.
4	Контроль	попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.
5	Отладка	завершающий этап создания программного продукта, который заключается в выполнении программы с целью выявления сбоев и ошибок программного кода, направлен на установление точной природы известной ошибки и ее исправление.
6	Приемочное тестирование	способ проверки и контроля за тем, чтобы работа приложения отвечала функциональным, нефункциональным и другим важным требованиям.
7	Тестирование системы	это тестирование программ, которое происходит на полной, интегрированной системе, для того чтобы проверить полное соответствие даннной системы изначальным требованиям.
8	Тестирование	процесс, гарантирующий правильность функционирования программы и показывающий отсутствие ошибок в программном продукте.
9	Тестирование внешних функций	контроль внешнего поведения системы, определенного внешними спецификациями.
10	Тестирование модуля	контроль отдельного программного модуля, обычно в изолированной среде.
11	Тестирование настройки	проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
12	Тестирование приемлемости	проверка соответствия программы требованиям пользователя.

Размещено на Allbest.ru

1. Пестриков В. М., Маслобоев А. Н. Delphi на примерах. — СПб.: БХВ-Петербург, 2009. — 496 с. ↑