Отладка и тестирование программ: основные подходы и ограничения (Виды тестирования)
Содержание:
Введение
Сегодня мно гие программисты и организации заним аются прикладным и системным программи рованием и созда нием программного обеспе чения для посто янно растущих потреб ностей пользователей. Пр и этом значит ельная часть време нных и финан совых ресурсов трат ится на отла дку и тестир ование создаваемых им и приложений. Н о тем н е менее, несм отря на колосс альные затраты, коне чный продукт оче нь часто вызы вает много прете нзий у пользо вателя, и проб лема качества прод укта говорит на м о несомн енной важности проце ссов отладки и тестирования прог рамм на сегодн яшний день. Эт им обусловлена актуал ьность затрагиваемых в работе проб лем. Причем мно гие «производители» д о сих по р внятно да же не смо гут дать точ ное определение то му, что ж е все-та ки называется тестиро ванием и отла дкой. Некомпетентность в этом вопр осе является одн ой из при чин наводнения рын ка некорректным и некачественным програ ммным обеспечением (дал ее ПО).
Тестиро ванием называется проц есс, гарантирующий правил ьность функционирования прогр аммы и показы вающий отсутствие оши бок в програ ммном продукте. Мож но заметить, чт о данное опреде ление не сов сем корректно и даже неправ ильно. Человек с некоторым опы том прикладного программ ирования знает, чт о полное отсут ствие ошибок в программе выяв ить и пока зать невозможно. Бол ее правильным буд ет определить проц есс тестирования и отладки ка к – завершающий эт ап создания програ ммного продукта, кото рый заключается в выполнении прогр аммы с цел ью выявления сбо ев и оши бок программного ко да. Вместо то го, чтобы гаранти ровать отсутствие оши бок в нов ой программе, разу мней будет хо тя бы продемонс трировать их нали чие. Если прило жение корректно рабо тает при выпол нении множества разли чных тестов, эт о придает некот орую уверенность, н о еще н е гарантирует отсут ствие в не й ошибок. Эт о лишь показ ывает, что на м пока неизв естно, в как их случаях прогр амма может да ть сбой. Получ ается «парадокс тестир ования». В ег о основе леж ат два противоп оложных утверждения: с одной стор оны, тестирование позво ляет убедиться, чт о продукт рабо тает хорошо; а с дру гой — выявляет оши бки в П О, показывая, чт о продукт н е работает. Вто рая цель тестир ования является бол ее продуктивной с точки зре ния улучшения каче ства, так ка к не позво ляет игнорировать недос татки ПО.
Нереа льно внести в программу надеж ность в резул ьтате тестирования, он а определяется правиль ностью этапов проекти рования. Наилучшее Коне чно лучшим реше нием здесь буд ет - с сам ого начала н е делать оши бок в создав аемой программе. Н о стопроцентный безоши бочный результат практи чески невозможен. Во т и ро ль тестирования и отладки состоит как раз в том, чтобы определить местонахождение немногих ошибок, присутствующих в хорошо спроектированном программном продукте.
Отладка и тестирование тема очень хорошая и важная, какой бы язык программирования или платформа ни использовались. Именно на этой стадии разработчики сталкиваются со многими трудностями.
Ошибки в программах — это отличная практика. Они помогают нам узнать, как все это работает. Поиск багов и выявление ошибок дает нам ни с чем несравнимый опыт. Этим подтверждается практическая значимость выбранной темы. Разработчику следует найти их до того, как заказчик увидит результат вашей работы. А вот если ошибки в ваших программах находят заказчики, это совсем плохо.
Данная курсовая работа состоит из двух глав и приложений. В первой главе необходимо будет определить, что такое тестирование и отладка программ, что представляет собой сам процесс, какие приемы и способы существуют. Будут даны общие рекомендации по отладке приложений. Кроме этого речь пойдет о различных видах ошибок и способах их выявления. Во второй главе необходимо будет коснуться многих практических моментов на этапах отладки, на примере среды разработки приложений Delphi.
1. Сущность тестирования и отладки. Методика выявления ошибок
1.1 Тестирование и его виды
В пер вую очередь необх одимо внести ясно сть – в че м же разн ица между тестиро ванием и отла дкой программы. Эт и термины н е всегда озна чают одно и то ж е, пусть да же большая час ть программистов воспри нимают их н е как отдел ьные этапы разра ботки приложений. Важ но разделять проц есс тестирования и процесс отла дки на дв а различных эта па работы на д программой. Тестир ование ставит зад ачу определения нали чия ошибок, в то вре мя как отла дка служит дл я определения местопо ложения найденных оши бок и и х устранения. Ес ли цели эт их двух эта пов разработки прог рамм различны, т о используются соответ ственно и разли чные методика и инструментарий. Важ нее всего пр и разработке и проектировании прогр аммы придерживаться некот орых правил и принципов защ иты от оши бок. Для это го существуют некот орые проверенные спос обы, но о них поз же, а по ка немного исто рии.
Самые пер вые программные прод укты начали разраба тывать в рам ках программ науч ных исследований минист ерств обороны. Тестир ование подобных сис тем проводилось стр ого формализовано с записью вс ех тестовых проц едур, тестовых дан ных, полученных резуль татов. Тестирование бы ло выделено в самостоятельный проц есс, который им ел место пос ле завершения кодиро вания, и произво дилось все, обы чно, тем ж е персоналом.
В 60-е начали уделять большое внимание «исчерпывающему» тестированию, которое проводилось с применением всех путей в коде или всех возможных входных данных. В этих условиях полное тестирование ПО невозможно из-за слишком большого количества возможных входных данных, существующего множество путей, а также сложности в нахождении проблемы в архитектуре и спецификациях. Именно по этим причинам «исчерпывающее» тестирование было признано невозможным и впоследствии отклонено.
В 70-е годы тестирование программное обеспечение обозначалось как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация программное обеспечение обозначалась как «доказательство правильности». Данная концепция в целом была перспективна, но в работе она требовала много времени и не была комплексной. Комплексное тестирование – это контроль и испытание системы по отношению к исходным целям. Было принято решение, что доказывать правильность — неэффективно, разве что только - приемо-сдаточные испытания (поиск возможных ошибок, выполняя приложение в заданной реальной среде). Далее тестирование стало представляться, как выполнение программы с целью обнаружить ошибки, а не только продемонстрировать, что программа работает. Уже в 80-е годы тестирование было дополнено таким понятием, как предупреждение ошибок. Одним из наиболее эффективных методов предупреждения ошибок является – проектирование тестов. Тогда и осознали необходимость методологии тестирования, а именно, что тестирование программы необходимо осуществлять на всем протяжении цикла разработки, и процесс этот должен быть управляемым. При этом проверяется не только спроектированная сборка программ, но и их код, архитектура, спецификации, а также и сами тесты. Все это позволит выявить проблемы в требованиях и архитектуре и тем самым значительно снизить сроки и средства на разработку приложений. Позднее начали появляться первые инструменты для автоматизации процесса тестирования. Поскольку ЭВМ более надежна и способна выполнить больше тестов. Со временем простейшие методы усложнялись и стали использоваться скриптовые сценарии для автоматизированного тестирования.
В 90-е годы тестир ование программ дополн илось проектированием, планиро ванием, созданием и поддержкой тест овых систем. Эт о начался пере ход на качест венно новый уров ень на вс ем цикле разра ботки. Появляются разли чные программные инстру менты поддержки проц есса тестирования: усовершенс твованные автоматизированные сре ды с возмож ностью написания скрип товых сценариев и автоматического созд ания отчетов. Кро ме этого начи нают широко использ оваться системы управ ления тестами и приложения дл я проведения нагруз очного тестирования. Пос ле, с разви тием Интернет-техно логий, и созда нием множества ве б-приложений оче нь популярным ста ло «гибкое тестир ование».
В 2000-е годы появи лось еще бол ее широкое опреде ление тестирования, ког да в не го было добав лено понятие «оптими зация бизнес-техно логий» (BTO). BTO направляет разв итие информационных техно логий в соотве тствии с цел ями бизнеса. Осно вной подход заключ ается в оце нке и максим изации значимости вс ех этапов жизне нного цикла разра ботки для дости жения необходимого уро вня качества, производи тельности, доступности.[[1]]
1.2 Виды тестирования
В зависимости о т преследуемых цел ей, основные ви ды тестирования прог рамм, можно усло вно разделить н а три гру ппы:
Функциональные
Нефункци ональные
Связанные с изменениями
Функцио нальные виды тестир ования базируются н а функционале и особенностях сис тем, а так же взаимодействии с другими систе мами, и мог ут быть предст авлены на вс ех уровнях тестир ования: модульном, интегра ционном, системном, и приемочном.
Модул ьное тестирование – эт о контроль отдел ьного программного мод уля, обычно в изолированной сре де.
Интеграционное тестир ование – когда отдел ьные программные мод ули объединяются и тестируются в группе.
Систе мное тестирование - тестир ование программ, выполн яемое на пол ной, интегрированной сист еме с цел ью проверки соотве тствия системы исхо дным требованиям.
Прием очное тестирование - способ проверки и контроля за тем, чтобы работа приложения отвечала функциональным, нефункциональным и другим важным требованиям.[[2]]
Все эти виды тестирования рассматривают внешнее поведение системы и подразделяются на три подвида: 1) функциональное тестирование;
2) тестирование безопасности; 3) тестирование взаимодействия.[[3]]
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом. Эти тесты описываются в спецификациях и основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования.
Преимуществом функционального тестирования является имитация фактического использования программы, а к недостаткам можно отнести возможность упущения логических ошибок в продукте и возможную вероятность избыточного тестирования. Широко используется и автоматизация функционального тестирования.
Тестирование безопасности - это способ тестирования, используемый для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Стратегия безопасности включает соответствие трем принципам: конфиденциальность, целостность и доступность.
Существует огро мное множество вид ов атак и уязвимостей. Пос ле проведения полн ого цикла тестир ования безопасности, ник то не мож ет быть н а 100% уверенным, чт о система п о-настоящему наде жна в пла не безопасности. Н о проводить тестир ование безопасности необх одимо, хотя б ы для то го, чтобы значит ельно сократить вероят ность несанкционированных проникн овений, хищений инфор мации и утр аты важных дан ных.
Тестирование взаимод ействия можно косв енно отнести к функциональному тестир ованию, проверяющему способ ность приложения взаимодей ствовать с одн им и бол ее компонентами. Сю да входит тестир ование совместимости и интеграционное тестир ование. Программа, хор ошо взаимодействующая с другими компон ентами и програ ммами, может лег ко интегрироваться в другие сист емы, без осо бой потребности в дальнейших модифи кациях. При эт ом количество измен ений и вре мя, затрачиваемое н а их выпол нение, реально исполь зовать для измер ения возможности взаимод ействия.
Нефункциональное тестир ование основывается н а тестах, необхо димых для опреде ления различных характе ристик продукта, кото рые измеряются всевозм ожными величинами, т.е. показ ывает, как прогр амма ведет се бя в раб оте. Нефункциональное тестир ование включает в себя цел ый ряд подв идов. Это тестир ование производительности, устан овки, удобства, те ст на отк аз и конфиг урацию.
Тестирование производи тельности или нагруз очное тестирование имити рует работу сист емы несколькими пользов ателями в распред еленных ресурсах прогр аммы. Выявляются возмож ности и недос татки приложения пр и работе по д нагрузкой и в стрес совых условиях – стаби льная работа прог рамм.
Тестирование эт о одна и з важнейших зад ач по обеспе чению качества програ ммного обеспечения и служит он а для норма льной инсталляции прило жения, его настр ойки и обнов ления. Сейчас наибо льшее распространение полу чила установка прог рамм с помо щью специальных програ ммных модулей – инсталл яторов, которые са ми нуждаются в надлежащем тестир овании.
Если инсталл яторов нет, т о установка произв одится самостоятельно согл асно инструкциям и спецификациям, ли бо специальному пла ну установки; напр имер в распред еленных системах.
Тестир ование удобства пользо вания не име ет ничего общ его с тестиро ванием функциональности пользоват ельского интерфейса, он о лишь прово дится на пользова тельском интерфейсе, рав но как и на мно гих других возмо жных компонентах прод укта. Это ли шь метод тестир ования, определяющий удоб ство в использ овании программы, обуч ению, понятности для пользователей программного обеспечения в конкретных условиях. При этом оценивается удобство использования программы исходя из критериев производительности, эффективности, правильности действий пользователя, запоминаемости, а также необходимая эмоциональная реакция человека после работы с продуктом.
Проверяется и функционал самой программы тестом черного ящика, а также и ее интерфейс тестированием белого ящика, где уже проверяется удобство использования модулей, классов, методов и переменных, а также рассматривается возможность доработки, модификации системы и легкость интегрирования их с другими приложениями и компонентами. Все это направлено на повышение качества, скорости написания программного кода и его поддержки. Тестирование удобства пользования можно производить на различных этапах проектирования продукта. Для создания удобного дизайна программ полезно следовать принципау «защиты от дурака». Так, если в поле формы необходимо вводить только целочисленное значение, то следует ограничить пользователю диапазон ввода только цифрами и исключить иные символы для избегания возникновения исключений в работе кода.
Тестирование н а отказ и восстановление анализ ирует стрессовую устойч ивость программы пр и отказе оборуд ования, отказе в работе се ти и дру гие. Проверяются сист емы отката и восстановления, обеспеч ивающие целостность и сохранность дан ных ПО в случае сб оя в норма льной работе прогр аммы или окруж ения. Данное тестир ование просто необх одимо при проекти ровании веб-прило жений, поскольку и з-за пот ери данных мож но потерять мно го клиентов, ден ег, а глав ное репутацию ваш его продукта.[[4]]
Техни чески это вс е достигается имита цией симуляцией отклю чения электричества, обр ыва связи, отключ ением носителей, ли бо специальным тест овым набором дл я ситуации нали чия в сист еме неверных дан ных.
Необходимо отме тить, что те ст на отк аз и восстан овление является дово льно специфическим тестиро ванием. При разра ботке сценариев тестир ования следует учиты вать все особен ности тестируемого програ ммного обеспечения. Мет оды воздействия пр и этом примен яются достаточно жест кие, поэтому след ует сразу реш ить: необходимо и целесообразно воо бще проводить подо бные испытания дл я конкретной прогр аммы?
Конфигурационное тестир ование направлено н а проверку работоспо собности программы в разных конфигу рациях системы, платф ормах, средах, жел езе и т.д. Цел ями данного тестир ования могут бы ть: определение оптима льной конфигурации оборуд ования или возмож ность миграции и совместимости сист емы с разн ыми платформами и конфигурациями компью теров.
В слу чае с кли ент-серверными прилож ениями, тесты прово дятся на серве рном и клиен тском уровнях. Н а серверном уро вне проводится тестир ование продукта с аппаратными и программными средс твами. Особое вним ание здесь уделя ется определению оптима льной конфигурации оборуд ования, обеспечивающей хоро шее качество, производи тельность и надеж ность.
На клиен тском уровне анализируется работоспособность программы конечным пользователем с различными конфигурациями клиентских машин и операционных систем. Особое внимание уделяется функциональности и удобству пользования программным продуктом. Тесты проводятся с учетом всевозможных параметров: вида операционной системы, ее битность, вид браузера, особенности видеоадаптеров, драйверов, библиотек, разрешение экрана и др.
И чем больше требований предъявляется к работе программы при различных конфигурациях компьютеров, тем больше различных тестов потребуется провести. Именно в таких случаях очень эффективным будет автоматизация процесса тестирования, позволяющая экономить много времени и средств разработчиков.
Связанные с изменениями виды тестирования реализуются после внесения необходимых изменений и корректировки. Программа должна быть заново протестирована, чтобы подтвердить, что ошибка была устранена. [[5]]
1.3 Сущность и методика отладки программ. Виды ошибок
Весь спектр возможных ошибок в программных продуктах можно условно разделить на четыре категории:
Нелогичный пользовательский интерфейс;
Неудовлетворенные ожидания;
Низкая производительность;
Аварийные завершения или разрушение данных.
Нелогичный пользовательский интерфейс это разновидность не очень серьезных ошибок, однако может привести к потере потенциальных клиентов и снижению рейтинга вашего продукта. Почему, например, операционная система Windows от Microsoft пользуется такой популярностью? Одной из причин является как раз – удобный и понятный пользовательский интерфейс во всех ее приложениях. Если отклониться от ее стандартов, программа становится трудной для использования пользователем. В качестве примера такого трудного приложения можно привести Microsoft Outlook. В нем различные сочетания клавиш для быстрой работы не соответствуют вызовам привычных функций и действий пользователя; например поиск и др.
Если гово рить о клиен тских приложениях, т о в ни х проблема нелоги чности решается дово льно просто. Пр и разработке ли шь необходимо придерж иваться специальных рекоме ндаций и станд артов для Windows-прило жений.
В слу чае проектирования интер фейса Web-приложения, эт а задача сущест венно усложняется. Зде сь уже не т конкретных станд артов на пользова тельский интерфейс. Сам ое главное, чт о надо учиты вать при разра ботке интерфейса дл я Web-клиента, эт о возможную низ кую скорость траф ика, поэтому след ует создавать пользова тельский интерфейс максим ально простым и избегать загр узки с серв ера всяких нену жных мелочей, тяже лых графических элеме нтов и проч его. К прим еру, простые реше ния, подобные CNN.com, нрав ятся практически вс ем пользователям. Использ ование простого наб ора ссылок выгл ядит куда луч ше и рабо тает быстрее, че м нагромождение всяк ого ненужного функцион ального хлама, вызыв ающее неудобства и отпугивающего клие нтов.[[6]]
Одной и з наиболее труднора зрешимых ошибок явля ются неудовлетворенные ожид ания пользователей. Прич иной этого обы чно является недостат очность исследования реал ьных потребностей потреб ителя, т.е. возникает проб лема взаимодействия. Подо бные ошибки обы чно возникают н а самых ран них этапах проекти рования программы.[[7]]
Са ми разработчики н е общаются напр ямую с заказч иками своих прог рамм, поэтому он и сами н е изучают, чт о нужно пользов ателям. Поэтому необх одимо взаимодействие с заказчиками, что бы увидеть, чт о они дел ают с и х программами. Мно гое прояснится, ес ли понаблюдать з а действиями рядо вого пользователя ил и заказчика, ка к используется ва ш программный прод укт. Кроме то го, такой оп ыт позволит разраб отчику понять, чт о, по мне нию клиента, требу ется от разрабат ываемого приложения.
Наибо льшее разочарование приносят ошибки, приводящие к снижению производительности при некорректной обработке данных приложением. Зачастую именно эти ошибки вызваны недостаточным тестированием программного обеспечения. Они могут быть выявлены с запозданием при обработке большого массива данных. Очень часто бывает так, что выпуская первую версию недостаточно протестированной программы на рынок, производитель обрекает себя на полный провал. Причем последующие исправленные версии уже не хочет использовать большая часть пользователей, которые обожглись на первой версии приложения.
Существует два основных метода борьбы с подобными ошибками. С одной стороны необходимо сразу же установить конкретные требования к производительности программного продукта. Для выявления проблем с производительностью нужно сравнить основные показатели работы приложения под разными нагрузками. Если вдруг происходит потеря производительности на 10%, то необходимо принять меры и выяснить – по какой причине это произошло и внести нужные изменения в код.
Далее надо убедиться в том, что нагрузка действительно соответствует наиболее близким к реальной жизни сценариям, и делать это нужно на самых ранних этапах проектирования.
При возникновении аварийных завершений и потери данных, а также утечки памяти также являются очень болезненными для пользователей. Это наиболее распространенный вид ошибок. Среди таких дефектов встречаются как легкоразрешимые, так и практически неразрешимые ошибки. Недопустимо выпускать на рынок такой продукт, заранее зная о подобных дефектах, даже самых незначительных.
Если ж е уделять доста точно внимания всяк ого рода дета лям, то оши бок можно ес ли не избе жать, то минимиз ировать. Причин появл ения всех эт их ошибок доста точно много, н о из ни х можно выде лить основные. Эт о, во-пер вых, непонимание разрабо тчиками требований предъяв ляемых к програ ммному продукту. Та к происходит, ког да приложение наполн яется ненужными функц иями и друг ими мелочами бе з необходимости. В о-вторых, прич иной могут бы ть невежественные и мало обуче нные разработчики, кото рые недостаточно разбир аются в операц ионных системах, технол огиях и язы ках программирования. В-третьих, как ие либо админист ративные причины – слиш ком сжатые и невозможные дл я разработки постав ленные сроки. Воп рос о приемл емости поставленных сро ков должен обсужд аться всеми разрабо тчиками на основ ании набора реализ уемых функций. В случае недостат очности времени н а качественную раб оту целесообразней да же просто отказ аться от выпол нения заказа. Одн ой из час тых причин оши бок в прогр аммах является недоста точная ориентация н а выпуск качест венной продукции. Разраб отчики должны горди ться своим творе нием и кор пят над все ми элементами прод укта, а н е только на д теми, чт о им интер есны. Например, вме сто того что бы копаться в деталях алгор итма, они выби рают более прос той алгоритм и думают, ка к лучше ег о протестировать. В конце кон цов, заказчика интер есуют не алгор итмы, а качест венный продукт. Произво дители программного обеспе чения, по насто ящему приверженные каче ству, должны опира ться на тщате льное планирование, персон альную ответственность, надле жащий контроль каче ства и хоро шие способности к общению с клиентами и между соб ой. Многие програ ммисты на раз ных этапах разра ботки больших сис тем, но тол ько тот, кт о уделяет значит ельное внимание дета лям, будет выпус кать продукцию в нужные сро ки и отлич ного качества.[[8]]
Планир ование тестирования необх одимо производить совме стно с планиро ванием отладки. Пр и этом, в ходе планир ования ставится зад ача придумать раз ные способы ускор ения и оптими зации обоих проце ссов. В цел ях соблюдения предосто рожности следует паралл ельно писать и использовать всевоз можные утилиты дл я анализа дам па файлов и верификации внутр енних структур и бинарных фай лов. Если прило жение оперирует двоич ными данными и файлами, т о нужно предусм отреть написание специа льной тестовой утил иты, преобразующей и представляющей дан ные в удоб ном формате. Прило жение для дам па должна так же проверять дан ные и и х зависимости в бинарных фай лах. Подобные ме ры значительно упро стят процесс тестир ования и отла дки.
При планир овании и проектировании необходимо встраивать достаточное количество отладочного кода в свои программы, чтобы именно этот код подсказывал программисту, где возникают ошибки. Именно код, а не отладчик.
2. Практика отладки приложений в среде Delphi
2.1 Два важных инструмента
Двумя важне йшими структурными элеме нтами являются специа льные системы управ ления версиями прило жения и отслеж ивания ошибок. Эт и инструменты регист рируют всю проек тную историю. Мно гие программисты пыта ются хранить нуж ные сведения в уме. Одн ако если он и работают в компании, т о желательно, что бы и он а имела вс ю информацию. Оче нь часто докуме нтация о требов аниях к прод укту и проек тная документация веду тся плохо н а всем протя жении проектирования прило жения. В резул ьтате этого единств енными полезными докуме нтами становятся контро льные журналы сис тем управления верс иями проектов и отслеживания оши бок.
Наблюдение з а частотой обнару жения и реше ния проблем, приме нение системы отслеж ивания ошибок, позво ляет намного точ нее планировать да ту завершения раб оты над прогр аммой. Кроме это го, система управ ления версиями да ет представление о степени измен ения кода, благо даря чему мож но определить: скол ько потребуется внед рить дополнительного тестир ования. Этот инструм ентарий дает на м единственный хоро ший способ оце нки того, наско лько эффективны измен ения, вносимые в ходе разра ботки программного обеспе чения.
Это оче нь важно, напр имер, при най ме новых програм мистов, которые быст рее вливаются в рабочий проц есс, знакомясь предвар ительно с систе мами управления верс иями и отслежи ванием ошибок. О н сможет просл едить весь пу ть создания и изменения прое кта. Но в идеале не т ничего луч ше качественной проек тной документации, чт о имеет мес то далеко н е всегда.
Эт и две системы неразрывно связаны между собой. Система отслеживания ошибок фиксирует все дефекты, требующие изменения исходного кода приложения, а система управления версиями проводит регистрацию всех внесенных изменений. Необходимо постоянно поддерживать связь между обнаруженными проблемами и изменениями исходных текстов. Это помогает выявить причины и последствия исправления обнаруженных ошибок. Если это не делать, то будут часто возникать непонимания внесенных ранее изменений кода приложения. Очень часто при разработке более поздней версии программы начинают отыскивать сотрудника, который вносил те или иные изменения в проект. При этом остается только уповать на то, что он не забыл причину этих действий.
Существуют специализированные интегрированные средства, которые позволяют автоматически следить за связью изменений исходных кодов приложения с ошибками. В случае отсутствия такой возможности в системе, то нужно поддерживать связь вручную. При этом в комментариях указывается номер ошибки и способ ее исправления. При регистрации исправленного модуля в системе управления версиями номер найденной ошибки указывается в соответствующем комментарии.
Система управления версиями существует для контроля над исходным кодом, а также для хранения всего, что непосредственно относится к проекту. Это разные планы тестирования, автоматизацию тестов, различную справочную информацию, а также проектную служебную документацию. Если нужно, то можно включить сюда и средства для сборки приложений: используемые файлы, динамические присоединяемые библиотеки и компиляторы, т.е. все необходимые средства для воссоздания необходимой версии приложения. Включать надо только то, что может потребоваться другим программистам в будущем для сопровождения программного обеспечения.
Многих проб лем при разра ботке программных проду ктов можно избе жать используя в системе управ ления версиями, та к называемых, блоч ных тестов (unit test). Блоч ный тест, ил и тестовое прило жение, представляет соб ой фрагмент ко да, управляющей выполн ением основной прогр аммы. Этот специа льный код созда ется программистами дл я тестирования «бел ого ящика» и контролирует выпол нение программой осно вных процедур и операций прило жения. Подробное опис ание блочных тес тов. Блочные тес ты в сист еме управления значит ельно облегчает раб оту разработчикам, сопрово ждающим приложение, а также упро щает контрольное тестир ование программы и сосредоточить вним ание на бол ее важных моме нтах: производительности, масштаби руемости приложения, полн ому соответствию требо ваний заказчика, т.е. тестир ование приемлемости - пров ерка соответствия прогр аммы требованиям пользо вателя. Использование блоч ных тестов эт о хороший показ атель профессионализма разрабо тчиков программ.
Ес ли говорить о системе отслеж ивания ошибок, т о она н е только накапл ивает информацию о б ошибках, н о и оче нь удобна дл я хранения раз ных заметок и списка зада ний на эта пе разработки исход ного кода. Мно гие разработчики хра нят списки зада ний в телеф онах и час то теряют нуж ную информацию в куче отлад очных и дру гих файлов. Поэт ому желательно вс е-таки хран ить свои заме тки в сист еме отслеживания оши бок для то го, чтобы все гда они бы ли под рук ой и н е тратить вре мя на и х поиск. Вс е удобство сист емы отслеживания оши бок заключается в том, что бы вся инфор мация об ошиб ках и запр осы, о реали зации функций наход ились в одн ом месте. Пр и ее хран ении в раз ных местах — в электронной поч те, в запи сных книжках инжен еров, а н е в сист еме отслеживания оши бок, то усле дить за не й будет гора здо сложнее.
Естест венно, что сист ема управления верс иями должна соответс твовать потребностям разраб отчика. Если разраба тывает продукт комп ания с требов аниями класса «high-end», с поддержкой неско льких платформ, т о, скорее все го, придется приме нять более доро гую систему ил и использовать реше ние с откр ытым кодом, напр имер, CVS.
Если ж е группа разрабо тчиков небольшая и выпускающая прило жения только дл я Windows, можно выбр ать и бол ее дешевые вари анты. Придется потра тить некоторое вре мя на тщате льную оценку сист емы, которую планир уется внедрить, уде лив особое вним ание прогнозированию буду щих потребностей. Нуж но убедиться в том, чт о она буд ет развиваться вме сте с ваш им проектом. Выб ор правильной сист емы управления верс иями очень важ ен. Важно воо бще ее исполь зовать, т.к. хоть как ая-то сист ема управления верс иями все ж е лучше, че м вообще ника кой.
2.2 Применение точек остановки и модификация локальных переменных
В коде любого созданного приложения обязательно будут ошибки. Если говорить о синтаксических ошибках, которые вызваны неверным вводом команд в редакторе, либо неверной записью идентификаторов и иными неверными действиями программиста, то они почти всегда фиксируются самим компилятором Delphi. Следует постоянно обращать внимание на различные сообщения и предупреждения, выдаваемые при прогоне программы, это может помочь обнаружить найти ошибку в тексте кода. Но многие ошибки связаны с тем, что неточно реализована логика самого алгоритма. Такие дефекты обнаруживаются только во время выполнения контрольных примеров. Так бывает например, когда вместо символа "<" ошибочно введен символ "<=". Если вдруг исходный алгоритм реализуется неправильно, то работоспособность приложения может быть даже, и не нарушено, но результаты будут выдаваться неверные или программой будут выполняться неверные действия. Поэтому и обнаруживаются подобные ошибки лишь на этапе отладки.
Интегрированная среда разработки Delphi предоставляет разработчикам очень хорошее средство поиска и исправления ошибок в программе – отладчик. Отладчик позволяет наблюдать значения переменных, производить трассировку приложения, а также контролировать выводимые программой данные.
Из всех инструментов встроенного отладчика наиболее часто используются точки остановки - BreakPoint. После установки точки, приложение будет работать до тех пор, пока не достигнет ее, после чего работа программы будет остановлена и управление переходит к отладчику Delphi. Точки остановки удобнее всего снимать и ставить нажатием горячей клавиши «F5», либо зайти в меню «Debug->Toggle breakpoint», либо другими способами.
После остановки работы программы, анализируются значения локальных переменных процедуры, в точке прерывания работы программы. Кроме этого необходимо изучить стек вызовов, производимых до вызова данной процедуры. Если потребуется, то сразу можно изменить значение переменных.[[9]]
Возникает вопрос: где ставить эти точки? Однозначного ответа дать нельзя. Они предназначаются лишь для того, чтобы облегчить нам изучение работы программного кода, если нет уверенности в его корректности, или содержащего явную ошибку незаметную при беглом просмотре. Конечно куда проще поставить точку остановки и последовательно выполнить нужные строчки, чем потратить кучу времени на изучение этого же самого кода, пытаясь определить, где же он начал работать неправильно.
В качестве примера можно представить листинг, в котором значению переменной присваивается значение равное единице, а затем четыре раза будем прибавлять единицу и после этого прибавим 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;[[10]]
После прогона данной программы будут получаться совсем иные результаты, поскольку переменной не было присвоено единичное значение. В начале выполнения данной процедуры, эта локальная переменная будет брать различные значения из стека, либо 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» окажется очень удобным помощником.
Он предоставит доступ ко всем свойствам объекта, которые нуждаются в изменении.[[11]]
2.3 Пошаговая трассировка приложения
Сущность трассировки заключается в пошаговой прогонке программного кода. При выполнении трассировки можно использовать команды, представленные в таблице 1.[[12]]
Таблица 1
Наименование команды |
Горячая клавиша |
Действие отладчика |
«Trace Into» |
«F7» |
отладчик выполнит код текущей строчки кода и остановится на следующей. Если в данной строке происходит вызов процедуры, то следующей строкой будет первая строка вызываемой процедуры. |
«Step Over» |
«F8» |
аналогично «Trace Into», но вход в тело вызываемой процедуры не происходит. |
«Trace to Next Source Line» |
«Shift+F7» |
полный аналог первой команды, но используется в окне «CPU-View» |
«Run to Cursor» |
«F4» |
отладчик будет выполнять код программы до той строчки, на которой сейчас находится курсор |
«Run Until Return» |
«Shift+F8» |
отладчик будет выполнять код текущей процедуры до тех пор, пока не произойдет выход из нее. |
«Set Next Statement» |
«Shift+F4» |
изменить ход выполнения программы, установив в качестве текущей любую строку кода. Так же эта возможность доступна в редакторе кода там, где можно перетащить стрелочку, указывающую на текущую активную строчку в новую позицию. |
Компилятор среды разработки должен быть настроен должным образом, поскольку от выставленных опций будет зависеть не только поведение выполняемого кода, но и на отображаемую информацию, которая будет доступна при отладке проектируемого продукта.
К примеру, группа «Code generation», в которой параметр «Optimization» оказывает непосредственное влияние на оптимизацию программного кода. Этот параметр желательно включить, и он обеспечит генерацию кода наилучшим образом. Будет учтена и скорость исполнения кода, и его размер. Однако при этом возможно потеря доступа к некоторым из локальных переменных, поскольку в момент прерывания на точке остановки из-за оптимизации кода может произойти их удаление из памяти.
Опрция «Record field alignment» устанавливает выравнивание неупакованных записей. Эту опцию можно изменять в процессе кодирования модуля при помощи директив «{$A x}», либо «{$Align x}».
А вот в группе «Syntax options» все опции лучше оставить по умолчанию, чтобы компилятор работал нормально.
В группе параметров «Runtime errors» есть параметр «Range checking», который очень важен для отладки проектов. Этот параметр проверяет границы во время доступа к массивам данных.
Это один из наиболее востребованных параметров при отладке приложения. Он отвечает за проверку границ при доступе к массиву данных. В случае ошибки в границах блока при попытке записи в него – возможно даже разрушение памяти программы. Кроме этого данная опция контролирует возможность выхода за границы допустимого диапазона значений для локальных переменных. Поэтому производить отладку проекта всегда необходимо при включенной опции «Range checking». Параметр «Overflow cheking» работает аналогично, но только там, где используются арифметические операции с переменными (также желательно включить).
Если необходимо в отдельных модулях отключать проверку переполнения, как например, в алгоритмах шифрования, то в данных (отдельных) модулях используется директива «{$OVERFLOWCHECKS OFF}».
Группа параметров «Debugging» включает параметры, влияющие лишь на полноту отладочной информации в DCU-файлах. Исключение составляет лишь параметр «Assertions», включающий в работу процедуру Assert().
В целом рекомендуется во время отладки приложений устанавливать все параметры из групп «Runtime errors» и «Debugging» включенными, а отключать их уже при заключительной компиляции готового приложения. В Delphi 7 и ниже это приходится делать вручную, а более новых студиях есть хорошая поддержка билдов проекта, где персонально для отдельных видов сборок можно выставлять все необходимые опции.
Вторым по важности инструментом при отладке приложений является окно «Call Stack». Оно содержит описание всех вызовов до возникновения исключения, ошибки или прерывания в точке остановки.
Используя двойной клик можно быстро переключаться между вызовами и просматривать список локальных переменных для каждого вызова («View Locals»), а также устанавливать точки прерывания на любом вызове. Это позволяет быстро локализовать ошибку при отладке и значительно облегчает работу программисту.
С помощью этого инструмента удобно отслеживать и отыскивать нужные нам вызовы функций или процедур при очень большом коде приложения. Если ошибка эта происходит не всегда, а только при оперировании с определенными данными, в этом случае используется диалог настроек свойств точки остановки. Вызывается он через свойства BP в коде приложения.[[13]]
Помимо кода программы приходится работать также с данными различных типов и областями памяти. В отладчике, при помощи «Data breakpoint», предусмотрена возможность устанавливать точки остановки на адреса, указывающие ячейки памяти. Это делается через «Watch List» или в окне «Breakpoint List» при помощи «Add Breakpoint->Data Breakpoint», где, в диалоге, следует указать адрес области памяти, ее размер, либо или имя нужной переменной. Если мы указываем имя переменной, то отладчик будет пытаться отыскать ее в памяти и установить точку остановки. Адрес памяти где содержится значение переменной меняется при каждом новом запуске программы, поэтому получить значение довольно сложно.[[14]]
Область видимости глобальных переменных доступна всегда, и, даже без запуска приложения, отладчик разрешает устанавливать «Data breakpoint» на изменения в таких переменных, даже без запуска программы. При этом отладчик определяет адрес глобальной переменной исходя из предыдущей сборки программы. Этот адрес может не совпасть при следующем прогоне программы. А вот с локальными переменами дело обстоит еще хуже, поскольку они располагаются на стеке, и, выйдя из области видимости, то их место в стеке занимают другие значения. Получается, что установка «Data breakpoint» на любую локальную переменную возможна только тогда, когда она находится в области видимости.
Нужно отметить, что отладчик Delphi не является профессиональным средством отладки сторонних приложений. Столь важный и удобный инструмент как «Memory Breakpoint» имеет урезанный вариант. Там сохранена лишь возможность контролировать адрес памяти на запись.[[15]] Но, тем не менее, даже в очень урезанном варианте он является хорошим инструментом для контроля изменений в памяти приложения, конкретно для поиска ошибок при адресной арифметике.
Заключение
В большей степени успешность отладки программного продукта зависит от правильной и рациональной организации его тестирования. Во время отладки программы фиксируются и исправляются, как правило, лишь ошибки, обнаруженные ранее при тестировании продукта. При тестировании не ставится цель доказывать правильность и оптимальность приложения, оно служит для того, чтобы показать наличие в любом программном продукте ошибок и дефектов. Никто не может дать гарантию, что при тестировании программы каким либо набором тестов можно обнаружить все ошибки в программном обеспечении. Отсюда и необходимость проведения тестирования и отладки, в ходе которых необходимо решить две основных задачи. Во-первых, протестировать программу на таком наборе тестов, который позволит отыскать максимально возможное количество ошибок.
При эт ом надо уче сть возрастающую стоим ость программы пр и слишком слож ном и длите льном тестировании. В о-вторых, необх одимо определить, ког да уже мож но закончить отла дку программного прод укта; когда уж е достаточно испра влено ошибок; ког да работа прогр аммы была опроб ована во вс ех возможных ситуа циях и появл ение ошибок свед ено к мини муму. Все эт о производится исх одя из требо ваний к каче ству и надеж ности программного обеспе чения.
Отладка явля ется самым труд ным и ответст венным этапом проекти рования программного обеспе чения; так бы ло всегда, та к, наверное, и будет ещ е долго. Оши бки встречаются в любых прилож ениях, и в коммерческих, и в те х продуктах, чт о лежат в свободном дост упе на рын ке. Мы вс е привыкли к тому, чт о спустя некот орое время пос ле выхода прогр аммы на рын ок выходят всевоз можные патчи с исправлениями, т о есть небол ьшие утилиты, исправ ляющие ошибки в программе. Поско льку отладка явля ется важнейшей стад ией проектирования прило жений, то учиты вать это нуж но уже с самого нач ала его разра ботки. Отлаживать каж дый, новый созда нный класс, мет од или проце дуру. Невзирая н а то, чт о последние технолог ические решения в программировании позво ляют производить отла дку очень эффек тивно, и каж дый программист стара ется встроить возмо жные средства отла дки в св ой код, те м не мен ее, без ста дии отладки гото вого приложения обой тись нельзя. Каж дый профессиональный програ ммист обязан научи ться видеть сла бые стороны прило жения и прини мать необходимые реше ние об и х проверке и контроле.
Люб ая организация обяз ана беспокоиться о б ошибках в ее програ ммных продуктах, поско льку они мог ут дорого обой тись для и х бизнеса. Ина че ей прид ется тратить огро мные средства и время н а дальнейшую подде ржку своих прог рамм, в т о время ка к другие конкури рующие фирмы уж е создают следу ющие версии сво их аналогичных проду ктов. Закончится вс е тем, чт о потребители нач нут покупать прогр аммы конкурентов. Хоро шее программное обеспе чение сегодня востре бовано как нико гда, поэтому нак ал борьбы з а высокое каче ство программных проду ктов будет тол ько возрастать. Пользо ватели программ мог ут потенциально лег ко переключаться с программы одн ой фирмы н а программу дру гой, переходя с одного Web-сай та на дру гой. Поэтому ес ли чьи-т о программы буд ут содержать мно го ошибок, т о это нане сет непоправимый уд ар по бизн есу и ими джу компании. Вс е это дол жно побуждать произво дителей к созд анию более качест венных программ.
В заключении се бе и дру гим будущим програм мистам хочу да ть следующие рекоме ндации:
Необходимо счит ать тестирование и отладку главной ключевой задачей разработки программ. Следует поручать это наиболее квалифицированным и опытным программистам и лучше другим, чем самому.
Лучшим будет тест, который находит более всего ошибок, а вовсе не тот, который доказывает, что приложение работает правильно.
Тесты след ует готовить и для прави льных, так и для неве рных данных.
Нуж но вести прото колы работы тес тов; и подр обно изучать резул ьтаты тестирования. Ес ли использование тес та невозможно повто рить, то о т него луч ше вовсе отказ аться.
Модули дол жны подключаться к приложению тол ько один ра з; замена моду лей существенно услож няет тестирование.
И последнее. Необходимо прогонять вновь все тесты, связанные с проверкой работы какого-либо приложения или его взаимодействия с другими приложениями, если в него были внесены изменения, в результате исправления ошибок
Список использованных источников
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 стр.
Размещено на Allbest.ru
-
Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2009. ↑
-
Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010. ↑
-
Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2012. — 272 с. ↑
-
Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2012. — 272 с. ↑
-
Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010. ↑
-
Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2010. ↑
-
Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2012. — 272 с. ↑
-
Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2009. ↑
-
Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. — М.: «Вильямс», 2010. — 464 с. ↑
-
Пестриков В. М., Маслобоев А. Н. Delphi на примерах. — СПб.: БХВ-Петербург, 2009. — 496 с. ↑
-
Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. — М.: «Вильямс», 2010. — 464 с. ↑
-
Пестриков В. М., Маслобоев А. Н. Delphi на примерах. — СПб.: БХВ-Петербург, 2009. — 496 с. ↑
-
Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. — М.: «Вильямс», 2010. — 464 с. ↑
-
Пестриков В. М., Маслобоев А. Н. Delphi на примерах. — СПб.: БХВ-Петербург, 2009. — 496 с. ↑
-
Фленов М. Программирование в Delphi глазами хакера. — СПб.: БХВ-Петербург, 2009. - 368 с. ↑
- Алгоритмизация как обязательный этап разработки программы
- Планирование хозяйственной деятельности торговой организации, на примере реально существующей организации
- «Современные политические режимы»
- Функции операционных систем персональных компьютеров (Краткое описание операционной системы)
- Понятие и классификация функций государства (Понятие и признаки государства)
- Доказательства трудового стажа(Правовое регулирование стажа в Российской)
- Налоговые правонарушения (Понятие и виды налоговых преступлений)
- Правоприменительная деятельность (Определение применения права)
- «Оценка качества (выбрать из ОКП )товаров»
- Коммерческая информация и ее защита (Сущность и значение коммерческой информации)
- Анализ деятельности спортивной организации на примере континентальной хоккейной лиги (ТЕОРЕТИЧЕСКИЕ ОСНОВЫ СПОРТИВНОГО МЕНЕДЖМЕНТА)
- Адаптация детей в условиях первого класса в школе (Адаптация ребенка к школе: понятие, сущность, виды, уровни)