Тестирование и отладка программного обеспечения

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Курсовая работа

Название дисциплины Информационные технологии

Тестирование и отладка программного обеспечения

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приемочное тестирование - способ проверки и контроля за тем, чтобы работа приложения отвечала функциональным, нефункциональным и другим важным требованиям. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010.

Все эти виды тестирования рассматривают внешнее поведение системы и подразделяются на три подвида: 1) функциональное тестирование; 2) тестирование безопасности; 3) тестирование взаимодействия. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. -- М.: «Диалектика», 2012. -- 272 с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В случае проектирования интерфейса Web-приложения, эта задача существенно усложняется. Здесь уже нет конкретных стандартов на пользовательский интерфейс. Самое главное, что надо учитывать при разработке интерфейса для Web-клиента, это возможную низкую скорость трафика, поэтому следует создавать пользовательский интерфейс максимально простым и избегать загрузки с сервера всяких ненужных мелочей, тяжелых графических элементов и прочего. К примеру, простые решения, подобные CNN.com, нравятся практически всем пользователям. Использование простого набора ссылок выглядит куда лучше и работает быстрее, чем нагромождение всякого ненужного функционального хлама, вызывающее неудобства и отпугивающего клиентов. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010.

Одной из наиболее трудноразрешимых ошибок являются неудовлетворенные ожидания пользователей. Причиной этого обычно является недостаточность исследования реальных потребностей потребителя, т.е. возникает проблема взаимодействия. Подобные ошибки обычно возникают на самых ранних этапах проектирования программы. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. -- М.: «Диалектика», 2012. -- 272 с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После остановки работы программы, анализируются значения локальных переменных процедуры, в точке прерывания работы программы. Кроме этого необходимо изучить стек вызовов, производимых до вызова данной процедуры. Если потребуется, то сразу можно изменить значение переменных. Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. -- М.: «Вильямс», 2010. -- 464 с.

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

В качестве примера можно представить листинг, в котором значению переменной присваивается значение равное единице, а затем четыре раза будем прибавлять единицу и после этого прибавим 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; Пестриков В. М., Маслобоев А. Н. Delphi на примерах. -- СПб.: БХВ-Петербург, 2009. -- 496 с.

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

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

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

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

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

Сущность трассировки заключается в пошаговой прогонке программного кода. При выполнении трассировки можно использовать команды, представленные в таблице. Пестриков В. М., Маслобоев А. Н. Delphi на примерах. -- СПб.: БХВ-Петербург, 2009. -- 496 с.

Таблица 1

Наименование команды	Горячая клавиша	Действие отладчика
«Trace Into»	«F7»	отладчик выполнит код текущей строчки кода и остановится на следующей. Если в данной строке происходит вызов процедуры, то следующей строкой будет первая строка вызываемой процедуры.
«Step Over»	«F8»	аналогично «Trace Into», но вход в тело вызываемой процедуры не происходит.
«Trace to Next Source Line»	«Shift+F7»	полный аналог первой команды, но используется в окне «CPU-View»
«Run to Cursor»	«F4»	отладчик будет выполнять код программы до той строчки, на которой сейчас находится курсор
«Run Until Return»	«Shift+F8»	отладчик будет выполнять код текущей процедуры до тех пор, пока не произойдет выход из нее.
«Set Next Statement»	«Shift+F4»	изменить ход выполнения программы, установив в качестве текущей любую строку кода. Так же эта возможность доступна в редакторе кода там, где можно перетащить стрелочку, указывающую на текущую активную строчку в новую позицию.

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

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

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

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

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

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

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

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

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

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

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

С помощью этого инструмента удобно отслеживать и отыскивать нужные нам вызовы функций или процедур при очень большом коде приложения. Если ошибка эта происходит не всегда, а только при оперировании с определенными данными, в этом случае используется диалог настроек свойств точки остановки. Вызывается он через свойства BP в коде приложения. Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. -- М.: «Вильямс», 2010. -- 464 с.

Помимо кода программы приходится работать также с данными различных типов и областями памяти. В отладчике, при помощи «Data breakpoint», предусмотрена возможность устанавливать точки остановки на адреса, указывающие ячейки памяти. Это делается через «Watch List» или в окне «Breakpoint List» при помощи «Add Breakpoint->Data Breakpoint», где, в диалоге, следует указать адрес области памяти, ее размер, либо или имя нужной переменной. Если мы указываем имя переменной, то отладчик будет пытаться отыскать ее в памяти и установить точку остановки. Адрес памяти где содержится значение переменной меняется при каждом новом запуске программы, поэтому получить значение довольно сложно. Пестриков В. М., Маслобоев А. Н. Delphi на примерах. -- СПб.: БХВ-Петербург, 2009. -- 496 с.

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

Нужно отметить, что отладчик Delphi не является профессиональным средством отладки сторонних приложений. Столь важный и удобный инструмент как «Memory Breakpoint» имеет урезанный вариант. Там сохранена лишь возможность контролировать адрес памяти на запись. Фленов М. Программирование в Delphi глазами хакера. -- СПб.: БХВ-Петербург, 2009. - 368 с. Но, тем не менее, даже в очень урезанном варианте он является хорошим инструментом для контроля изменений в памяти приложения, конкретно для поиска ошибок при адресной арифметике.

Заключение

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

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

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

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

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

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

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

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

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

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

Глоссарий

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

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

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