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

Содержание:

ВВЕДЕНИЕ

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

Цель курсовой работы: Изучение принципов и подходов откладки и тестирования ПО.

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

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

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

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

Объектом исследования является структура откладки и тестирования ПО.

Предметом исследования являются откладка и тестирование программ, выявление основные подходы и ограничений.

При написании работы, были использованы труды таких известных авторов как: Артамонова, Н.В Астахова, И.Ф. Карасева, М.В Коньков, К.А Назаров, С.В. Назаров, С.В Мартемьянов, Ю.Ф Партыка, Т.Л Синицын, С.В Стащук, П.В. Столлингс, В.М Таненбаум, Э.Е

Задачами курсовой работы являются:

- изучение понятий Тестирования и Откладки ПО

- определение востребованности и новшеств

- изучение основных видов тестирования и откладки

Курсовая работа состоит из введения, 2 глав, заключения и списка литературы.

Глава 1. Методы, сущность и подходы тестирования и отладки.

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

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

При этом используют различные методы[2]:

• ручного тестирования;
• индукции;
• дедукции;
• обратного прослеживания.

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

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

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

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

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

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

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

Общая методика отладки программного обеспечения:

Суммируя все сказанное выше, можно предложить следующую методику отладки программного обеспечения, написанного на универсальных языках программирования[9]:

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

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

Если ошибка не обнаружена или система просто «зависает», переходите ко второму этапу.

2 этап - локализация ошибок - определение конкретного фрагмента, при выполнении которого произошло отклонение от ожидаемого процесса обработки.

Локализация может быть выполнена:

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

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

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

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

Уровень 4 - Исправление ошибок - внесите соответствующие изменения для всех операторов, совместное выполнение которых привело к ошибке. Уровень 5. Повторное тестирование. Повторите все тесты с самого начала, так как новые ошибки часто добавляются в программу при исправлении обнаруженных ошибок.

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

Создайте программу «сверху вниз» от интерфейса к подпрограммам обработки, протестируйте ее при добавлении подпрограмм, отобразите данные, введенные пользователем для мониторинга, и проверьте их достоверность сразу после их ввода.

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

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

1.2 Тестирование ПО и Откладка.Разница понятий.

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

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

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

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

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

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

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

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

1.3 Виды тестирования програмного обеспечения

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

• Функциональные
• Нефункциональные
• Связанные с изменениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Нелогичный пользовательский интерфейс;
• Неудовлетворенные ожидания;
• Низкая производительность;
• Аварийные завершения или разрушение данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1 Необходимые инструменты для откладки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Применение трассировки приложения при тестировании и откладке ПО.

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

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

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

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

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

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

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

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

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

Помимо кода программы приходится работать также с данными различных типов и областями памяти. В отладчике, при помощи «Data breakpoint», предусмотрена возможность устанавливать точки остановки на адреса, указывающие ячейки памяти. Это делается через «Watch List» или в окне «Breakpoint List» при помощи «Add Breakpoint->Data Breakpoint», где, в диалоге, следует указать адрес области памяти, ее размер, либо или имя нужной переменной. Если мы указываем имя переменной, то отладчик будет пытаться отыскать ее в памяти и установить точку остановки. Адрес памяти где содержится значение переменной меняется при каждом новом запуске программы, поэтому получить значение довольно сложно.^[13]

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

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

Там сохранена лишь возможность контролировать адрес памяти на запись.^[14]

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

Список литературы

1. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2016. – 100 с.

2. Керман М. К. Программирование и отладка в Delphi. Пер. с англ. — М.: Издательский дом "Вильямc", 2017, - 672 с.

3. Коликова Т.В., Котляров В.П. Основы тестирования программного обеспечения, М., Бином, 2016, - 285 с.

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

5. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2018. — 272 с.

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

7. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М.: БИНОМ, 2018. — 368 с.

8 Стивен Р. Delphi. Готовые алгоритмы / Род Стивене; - 4-е изд. - М.: ДМК Пресс; СПб.: Питер, 2016. - 384 с.

9. Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2015 г. – 144 с.

10. Фленов М. Программирование в Delphi глазами хакера. — СПб.: БХВ-Петербург, 2015. - 368 с.

11. Ховард М., Лебланк Д. Защищенный код: Пер. с англ, — 2-е изд., испр. М.: Издательско-торговый дом «Русская Редакция», 2014. — 704 стр.

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

1. Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2019. ↑

2. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2018. ↑

3. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2016. — 272 с. ↑

4. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2016. — 272 с. ↑

5. Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 2018. ↑

6. Майерс, Баджетт, Сандлер Искусство тестирования программ, 3-е. — М.: «Диалектика», 2016. — 272 с. ↑

7. Тамре Л. Введение в тестирование программного обеспечения, М., Дрофа, 2019. ↑

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

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

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

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

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

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

14. Фленов М. Программирование в Delphi глазами хакера. — СПб.: БХВ-Петербург, 2019. - 368 с. ↑