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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 31.03.2023

Просмотров: 428

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

ВВЕДЕНИЕ

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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