Тестирование и отладка программного средства. Отладка и тестирование программ Тестирование и отладка по

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Институт математики и компьютерных наук

Кафедра математики и информатики

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

По дисциплине: «Основы программирования»

Этапы разработки программ. Тестирование и отладка. Документирование программ


Введение

Глава 1. Этапы разработки программ

1.1 Постановка задачи

1.1.1 Формулировка и анализ физической задачи

1.1.2. Составление математической модели

1.2 Создание программы

1.3 Документирование программы

1.3.1 Пользовательская документация программы

1.3.2 Документация по сопровождению программы

1.4 Запуск готовой программы и анализ полученных результатов


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

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

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


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

Этапы разработки программ:

1. Постановка задачи

1. Формулировка и анализ физической задачи

2. Составление математической модели

3. Составление алгоритма задачи

2. Создание программы

1. Составление текста программы

2. Ввод текста программы в компьютер

3. Синтаксическая отладка программы

4. Тестирование и семантическая отладка

5. Документирование программы

3. Запуск готовой программы и анализ полученных результатов

Рассмотрим подробно каждый этап.

1.1 Постановка задачи

Первый этап - это этап разбора задачи по кусочкам, для упрощения написания программы. Его ещё называют математическим этапом.

1.1.1Формулировка и анализ физической задачи

Формулировка задачи – это само её объявление, её постановка.

Но просто формулировка ничем не поможет программистам. Для этого и существует второй подэтап – это анализ задачи.

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

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

1.1.2 Составление математической модели

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

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

«Математическая модель - это упрощенное описание реальности с помощью математических понятий. Существует два основных класса задач, связанных с математическими моделями: прямые и обратные. В первом случае все параметры модели считаются известными, и нам остается только исследовать её поведение. А во втором какие-то параметры модели неизвестны, и требуется их найти, сопоставляя поведение реальной системы с её моделью.» - данное определение используется в основном в экономике.

«Математическая модель - это математическое представление реальности» - это определение созданное математиками.

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

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

1.1.3 Составление алгоритма задачи

Изначально появление алгоритма связывают с возникновением математики. Алгоритм – описание последовательности действий (план), строгое исполнение которых приводит к решению поставленной задачи за конечное число шагов.

У алгоритма есть 2 обязательных условия:

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

· Алгоритм должен быть представлен в форме, понятной тому объекту (в том числе и человеку), который будет выполнять описанные в алгоритме действия.

Так же у алгоритмов есть свойства:

1. Дискретность, т. е. алгоритм должен состоять из конкретных действий, следующих в определенном порядке.

2. Детерминированность, т. е. любое действие должно быть строго и недвусмысленно определено в каждом случае.

3. Конечность, т. е. каждое действие и алгоритм в целом должны иметь возможность завершения.

4. Массовость, т. е. один и тот же алгоритм можно использовать с разными исходными данными.

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

В мире существует несколько видов алгоритмов:

· Линейный алгоритм (описание действий, которые выполняются однократно в заданном порядке);

· Циклический алгоритм (описание действий, которые должны повторятся указанное число раз или пока не выполнено условие);

· Разветвляющий алгоритм (алгоритм, в котором в зависимости от условия выполняется либо одна, либо другая последовательность действий);

1.2 Создание программы

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

1.2.1 Составление текста программы

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

1.2.2 Синтаксическая отладка программы

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

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

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

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

Тестирование – это динамический контроль программы, т.е. проверка правильности программы при ее выполнении на компьютере.


Введение 2

Определение программирования. Этапы создания программы 3

Отладка программы 6

Задача 2 и 3 9

Задача 4 и 5 12

Заключение 14

Список используемой литературы 15

Введение

Компьютерная техника и компьютерная технология прочно вошли в человеческую жизнь. Развитие научно-технического прогресса невозможно без автоматизации вычислительных процессов. Именно потребность в автоматизации вычислительных процессов стала первоначальным импульсом в развитии программирования.

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

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

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

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

Определение программирования. Этапы создания программы

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

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

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

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

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

2 этап. Анализ задачи и моделирования: целью этого этапа является математическая модель или математическая постановка. На этом этапе выполняются следующие пункты

1) Определяются исходные данные и их типы.

2) Решение задачи описывается в виде аналитических зависимостей (уравнения, функции).

3) Определяются конечные данные и их типы.

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

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

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

5 этап. Отладка и тестирование программы: заключается в поиске и устранении синтаксических и логических ошибок в программе.

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

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

Отладка программы

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

Отладка – это деятельность, направленная на обнаружение и исправление ошибок в программе.

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

Отладка = Тестирование + Поиск ошибок + Редактирование.

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

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

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

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

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

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

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

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

  • Паскаль Отладка программ

    Реферат >> Информатика

    Логические операторы и операторы цикла. Отладка программ . Укороченная форма оператора if В... if. Средства среды программирования для отладки программ Среда Borland Pascal ... несколько встроенных инструментальных средств отладки программ . С некоторыми из них...

  • Программа по начислению заработной платы и налогов работникам фирмы

    Реферат >> Экономика

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

  • Выполнение и отладка программ в интегрированной среде программирования Turbo Pascal (MS-Dos)

    Лабораторная работа >> Информатика, программирование

    Практического использования интегрированных сред программирования с целью выполнения и отладки программ на языке Паскаль. ТЕОРЕТИЧЕСКИЕ... СВЕДЕНИЯ Базовыми компонентами системы программирования Турбо...

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

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

    Чем больше опыта имеет программист, тем меньше ошибок в коде он совершает. Но, хотите верьте, хотите нет, даже самый опытный программист всё же допускает ошибки. И любая современная среда разработки программ должна иметь собственные инструменты для отладки приложений, а также для своевременного обнаружения и исправления возможных ошибок. Программные ошибки на программистском сленге называют багами (англ. bug - жук), а программы отладки кода - дебаггерами (англ. debugger - отладчик). Lazarus, как современная среда разработки приложений, имеет собственный встроенный отладчик, работу с которым мы разберем на этой лекции.

    Ошибки, которые может допустить программист, условно делятся на три группы:

    1. Синтаксические
    2. Времени выполнения (run-time errors)
    3. Алгоритмические

    Синтаксические ошибки

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


    Рис. 27.1.

    Подобные ошибки могут возникнуть при неправильном написании директивы или имени функции (процедуры); при попытке обратиться к переменной или константе, которую не объявляли ( рис. 27.1); при попытке вызвать функцию (процедуру, переменную, константу) из модуля, который не был подключен в разделе uses ; при других аналогичных недосмотрах программиста.

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

    Ошибки времени выполнения

    Ошибки времени выполнения (run-time errors) тоже, как правило, легко устранимы. Они обычно проявляются уже при первых запусках программы, или во время тестирования . Если такую программу запустить из среды Lazarus, то она скомпилируется, но при попытке загрузки, или в момент совершения ошибки, приостановит свою работу, выведя на экран соответствующее сообщение. Например, такое:


    Рис. 27.2.

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

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

    Если программу запустить из самой Windows , при возникновении этой ошибки появится такое же сообщение. При этом если нажать "OK ", программа даже может запуститься, но корректно работать все равно не будет.

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

    begin MySL:= TStringList.Create; MySL.Add("Новая строка"); end;

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

    begin MySL:= TStringList.Create; MySL.Add("Новая строка"); ...; //работа с объектом MySL.Free; //освободили объект end;

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

    begin try MySL:= TStringList.Create; MySL.Add("Новая строка"); ...; //работа с объектом finally MySL.Free; //освободили объект, даже если была ошибка end; end;

    Итак, во избежание ошибок времени выполнения программист должен не забывать делать проверку на правильность ввода пользователем допустимых значений, заключать опасный код в блоки try…finally…end или try…except…end , делать проверку на существование открываемого файла функцией FileExists и вообще соблюдать предусмотрительность во всех слабых местах программы. Не полагайтесь на пользователя, ведь недаром говорят, что если в программе можно допустить ошибку, пользователь эту возможность непременно найдет.

    Алгоритмические ошибки

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

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

    Если программа работает правильно с одними наборами исходных данных, и неправильно с другими, то это свидетельствует о наличии алгоритмической ошибки. Алгоритмические ошибки иногда называют логическими, обычно они связаны с неверной реализацией алгоритма программы: вместо "+" ошибочно поставили "-", вместо "/" - "*", вместо деления значения на 0,01 разделили на 0,001 и т.п. Такие ошибки обычно не обнаруживаются во время компиляции , программа нормально запускается, работает, а при анализе выводимого результата выясняется, что он неверный. При этом компилятор не укажет программисту на ошибку - чтобы найти и устранить её, приходится анализировать код, пошагово "прокручивать" его выполнение, следя за результатом. Такой процесс называется отладкой .

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

    Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

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

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

    Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    B: Integer = 123;

    procedure TForm1.FormCreate(Sender: TObject);

    ShowMessage(IntToStr(A));

    ShowMessage(IntToHex(A, 8));

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

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

    Получается следующая картина: точка установки стоит на строчке Inc(A). В специальном окне «Local Variables», можно видеть значения всех используемых локальных переменных процедуры создания формы, а также переменной Self, передающейся неявно и всегда присутствующей в методах класса и параметра Sender.

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

    Для просмотра и изменения значения переменной в отладчике Delphi существуют два инструмента. Можно вызвать специальное окно «Evaluate/Modify» через меню или с помощью горячей клавиши «Ctrl+F7». Этот инструмент очень простой и используется в большинстве чаще всего. Выглядит он примерно так:

    Чтобы изменить значение переменной A, необходимое нам значение вводится в поле «New value». Далее жмем «Enter» или кнопку «Modify».

    Другой инструмент «Inspect» вызывается из диалога «Evaluate/Modify». Он является уже более продвинутым редактором значений переменных. Вызвать его можно и через меню «Run».

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

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

    Изменив значение переменной A на правильное, можно продолжить выполнение нашей программы нажав «F9» или «Run». После произведенных действий при помощи отладчика, процедура возвратит нужные значения. Теперь можно спокойно исправлять код процедуры, т.е. присвоить переменной A значение 1 - «A:= 1».

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

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

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

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

    Таблица 1

    Наименование команды

    Горячая клавиша

    Действие отладчика

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

    аналогично «Trace Into», но вход в тело вызываемой процедуры не происходит.

    «Trace to Next Source Line»

    полный аналог первой команды, но используется в окне «CPU-View»

    «Run to Cursor»

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

    «Run Until Return»

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

    «Set Next Statement»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Заключение

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

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

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

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

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

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

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

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

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

    Глоссарий

    Определение

    Интеграционное тестирование

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

    Испытание

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

    Комплексное тестирование

    контроль и испытание системы по отношению к исходным целям.

    Контроль

    попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

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

    Приемочное тестирование

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

    Системное тестирование

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

    Тестирование

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

    Тестирование внешних функций

    контроль внешнего поведения системы, определенного внешними спецификациями.

    Тестирование модуля

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

    Тестирование настройки

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

    Тестирование приемлемости

    проверка соответствия программы требованиям пользователя.

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

    1 Глас Р. Руководоство по надежному программированию. М., Финансы и статистика, 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 с.

    Подобные документы

      Отладка - процесс обнаружения, устранения синтаксических и семантических ошибок. Точки отслеживания (трассировки). Выполнение отладки в режиме останова. Мониторинг содержимого переменных. Пошаговое выполнение кода. Разработка тестов для отладки программы.

      презентация , добавлен 09.12.2013

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

      контрольная работа , добавлен 25.10.2010

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

      курсовая работа , добавлен 20.12.2012

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

      курсовая работа , добавлен 21.07.2012

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

      курсовая работа , добавлен 28.11.2010

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

      курсовая работа , добавлен 21.12.2016

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

      курсовая работа , добавлен 22.11.2014

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

      курсовая работа , добавлен 07.12.2016

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

      презентация , добавлен 30.04.2014

      Этапы разработки и отладки приложения "Помощь почтальону". Составление сопроводительной документации. Выбор средств и методов программирования. Анализ проектных данных. Особенности создания базы данных, СУБД. Тестирование созданного программного продукта.

    Отладка (debug, debugging) - этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится: узнавать текущие значения переменных; выяснять, по какому пути выполнялась программа.

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

    Технологии отладки.

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

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

    Инструменты отладки.

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

    2. Профилировщики – позволяют определить сколько времени выполняется тот или иной участок кода, а анализ покрытия позволит выявить неисполняемые участки кода.

    3. API логгеры – позволяют программисту отследить взаимодействие программы и Windows API при помощи записи сообщений Windows в лог.

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

    5. Сниферы помогут программисту проследить сетевой трафик генерируемой программой

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

    7. Логи системы .

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

    Отладка = Тестирование + Поиск ошибок + Редактирование

    Виды отладки ПО, включая тестирование (в нашей стране).

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



    1.2. Комплексная отладка. Тестирование ПО в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах (включая тексты программ ПО), относящихся к ПО в целом. К таким доку-ментам относятся определение требований к ПО, спецификация качества ПО, функциональная спецификация ПО, описание архитектуры П.О. и тексты программ ПО.

    2.1. Синтаксическая отладка. Синтаксические ошибки выявляет компилятор, поэтому исправлять их достаточно легко.

    2.2. Семантическая (смысловая ) отладка. Ее время наступает тогда, когда синтаксических ошибок не осталось, но результаты программа выдает неверные. Здесь компилятор сам ничего выявить не сможет, хотя в среде программирования обычно существуют вспомогательные средства отладки, о которых мы еще поговорим.

    Взаимосвязь процессов тестирования и отладки через алгоритм отладки.

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

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

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

    Средства автоматического тестирования исходного кода программ.

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

    Примерами таких систем могут быть: встроенный модуль doctest в Python и мультиязыковая библиотека тестирования xUnit, распространяемая на условиях GNU/GPL и LGPL. Основа применения всех этих средств и техник это разбиение одной большой задачи на ряд четких и более маленьких задач.


    23. Основные принципы объектно-ориентированного программирования: инкапсуляция, наследование, полиморфизм. Отличие объектно-ориентированного подхода от модульного при разработке программ

    Объектно-ориентированное программирование (ООП) - парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием, - прототипов).

    Прототип - это объект-образец, по образу и подобию которого создаются другие объекты.

    Класс

    Поля , описанные в классе, используют для хранения составляющих состояния объекта, т.е. поля определяют состояние объектов.

    Методы , описанные в классе, определяют поведение объектов. Каждый метод определяет реакцию объекта на некоторое внешнее или внутреннее сообщение.

    Объект - переменная типа класс

    Принципы объектно-ориентированного программирования.

    1. Абстракция. Абстрагирование - это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

    2. Инкапсуляция.

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

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

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

    Наследование - возможность конструирования новых более сложных классов из уже имеющихся посредством добавления полей и определения новых методов (принцип иерархичности ).

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

    4. Полиморфизм. Полиморфизм - это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

    Полиморфизм (“многообразие”) в программировании - возможность изменения кода программы в соответствии со значением некоторых параметров.

    4.1. Чистый полиморфизм - возможность различной интерпретации кода функции в зависимости от типа аргументов.

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

    4.3. Переопределение методов - в ООП - возможность различных определений методов в классе-потомке и классе-родителе; конкретный метод определяется классом объекта, для которого он вызывается. При переопределении методов различают простой и сложный полиморфизм.

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

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

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

    Отличие объектно-ориентированного подхода от модульного.

    1) Объектно-ориентированный подход к проектированию прогр. продуктов основан на:

    − выделении классов объектов;

    − установлении характерных свойств объектов и методов их обработки;

    − создании иерархии классов, наследовании свойств объектов и методов их обработки.

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

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

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


    24. Классы и объекты: их определение, соотношение между ними. Роль составляющих класса – полей, свойств, методов. Спецификаторы доступа published, public, private, protected. Конструкторы и деструкторы, их роль. События и их использование в управлении программой

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

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

    Соотношение класса и объекта:

    Понятие класса является более общим, чем понятие объекта. Объект является экземпляром класса . Класс может рассматриваться как совокупность объектов (подобно тому, как множество есть совокупность элементов). Класс может быть элементарным или подразделяться на подклассы (подобно тому как множество подразделяется на подмножества). Например, класс PERSON содержит подкласс STUDENT, который, в свою очередь, содержит объект John_Smith.

    Классы имеют (например, в Delphi):

    − Поле класса (атрибут ) в ООП - переменная, связанная с классом или объектом. Поля , описанные в классе, используются для хранения составляющих состояния объекта, т.е. поля определяют состояние объектов. Доступ к полям осуществляется по их имени.

    − Методы , описанные в классе (подпрограммы, которые обрабатывают поля и свойства класса), определяют поведение объектов. Каждый метод определяет реакцию объекта на некоторое внешнее или внутреннее сообщение.

    − Свойство - способ доступа к внутреннему состоянию объекта, имитирующий переменную некоторого типа. Обращение к свойству объекта реализовано через вызов функции. При попытке задать значение данного свойства вызывается один метод, а при попытке получить значение данного свойства - другой.

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

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

    Спецификаторы доступа published, public, private, protected.

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

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

    Уровни инкапсуляции (доступность любых членов класса):

    1) Public . Члены класса, находящиеся в данном разделе, доступны из любой точки программы.

    2) Private . Члены класса доступны только в том модуле, где данный класс описан. По умолчанию считается, что все поля класса расположены в разделе private .

    3) Protected . Члены класса доступны в том модуле, где данный класс описан, а также внутри методов классов, являющихся наследниками данного класса и описанных в других модулях.

    4) Published . Члены класса, находящиеся в данном разделе, доступны из любой точки программы. В этом разделе располагаются свойства класса: поля, доступные для редактирования и изменения значений во время проектирования и из Инспектора объектов .

    5) Automated . Члены класса, находящиеся в данном разделе, доступны из любой точки программы. Описания разрешается размещать в этом разделе, только если класс является наследником стандартного класса TAutoObject (в Delphi), предназначенного для создания так называемых серверов автоматизации при использовании технологии СОМ (Competent Object Model).

    Конструкторы и деструкторы.

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

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

    События и их использование в управлении программой.

    Событие в ООП - это сообщение, которое возникает в различных точках исполняемого кода при выполнении определённых условий.

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

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


    25. Основные отличия языка Object Pascal (Delphi) от Turbo Pascal. Динамические массивы в Delphi: описание, особенности, применение

    Turbo Pascal - интегрированная среда разработки для языка программирования Pascal и язык программирования в этой среде, диалект языка Паскаль от фирмы Borland.

    Delphi - среда программирования, в которой используется язык программирования Object Pascal.

    Object Pascal - результат развития языка Turbo Pascal , который, в свою очередь, развился из языка Pascal . Pascal был полностью процедурным языком.

    Turbo Pascal , начиная с версии 5.5, добавил в Pascal объектно-ориентированные свойства, а в Object Pascal - динамическую идентификацию типа данных с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде, также называемом интроспекцией - данная технология получила обозначение RTTI.

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

    Object Pascal (Delphi ) является результатом функционального расширения Turbo Pascal.

    Объектная модель Delphi Pascal по сравнению с моделью, использованной Borland Pascal 7.0, является более полной:

    − ограничение доступа к полям и методам за счет определения собственного интерфейса к каждому полю класса (пять типов секций при объявлении класса, использование свойств);

    − более развитые механизмы реализации полиморфных методов (абстрактные, динамические методы)",

    − средства работы с метаклассами (переменные метаклассов, методы классов, механизм RTTI).

    Динамические массивы в Delphi.

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

    Объявление массива: var My_Array: array of BaseType;

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

    Установка размера массива: SetLength(My_Array,100);

    Получение числа элементов массива: n:=Length(My_Array);

    Обращение к первому элементу массива: My_Array:=10; x:=My_Array;

    Объявление двумерного массива: var A: array of array of BaseType;

    Если присвоить переменной динамический массив, то его содержимое не копируется, присваивается только указатель на массив. А вот если применить к новому массиву SetLength , то тогда и произойдет копирование.


    26. Структура модулей в Delphi. Интерфейсная, исполняемая части, инициирующая и завершающая части. Процедуры и функции: особенности в Delphi

    Проект в Delphi представляет собой набор программных единиц – модулей.

    Delphi позволяет поместить свои функции и процедуры в отдельный модуль (Unit ), а затем использовать процедуры и функции модуля в своих программах, указав имя модуля в списке модулей, необходимых программе (инструкция uses ). Модуль – это файл с расширением *.pas.

    Начинается модуль заголовком - инструкцией unit , в которой указано имя модуля.

    Модуль состоит из последовательности разделов . Каждый раздел начинается ключевым словом и продолжается до начала следующего раздела. В раздел implementation (реализация) нужно поместить процедуры и функции, объявленные в разделе interface .

    Структура модулей в Delphi.

    Unit <имя>;

    Interface <интерфейсная часть>

    Implementation <исполняемая часть>

    initialization <инициирующая часть>

    finalization <завершающая часть>

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

    unit ИмяМодуля;

    interface // раздел интерфейса

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

    const // раздел объявления констант

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

    type // раздал объявления типов

    { Объявления глобальных типов модуля, которые могут использоваться процедурами и функциями модуля }

    var // раздел объявления переменных

    { Объявления глобальных переменных модуля, которые могут использоваться процедурами и функциями модуля}

    implementation // раздел реализации

    { Описания (текст) процедур и функций модуля!}

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

    Процедуры и функции в Delphi.

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

    Процедура - это разновидность подпрограммы. Обычно подпрограмма реализуется как процедура в двух случаях:

    − когда подпрограмма не возвращает в основную программу никаких данных;

    − когда подпрограмма возвращает в вызвавшую ее программу больше чем одно значение.

    Параметры – это входные данные.

    Объявление процедуры

    procedure ИмяПроцедуры {var параметр1: тип1; … var параметр К: тип К);

    Вам также может быть интересно
    Как сделать словарь в word?
    Как сделать словарь в word?
    Excel для Office 365 Word для Office 365 Outlook для Office 365 PowerPoint для Office 365 Publisher...
    Почему свёрнутое окно программы долго разворачивается?
    Почему свёрнутое окно программы долго разворачивается?
    Симптомы: На панели задач видите, что есть открытые окна и они не разворачиваются. Или, например, открываете...