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

Содержание:

Введение

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

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

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

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

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

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

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

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

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

C учетом поставленной цели будут решены следующие задачи:

- рассмотрено понятие и принципы тестирования;

- проанализирована стратегия и методы тестирования;

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

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

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

1.1 Определение и принципы тестирования

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

Тестирование программ – это составляющая более крупного определения – отладка программ.

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

Процесс отладки включает:

 - действия, которые направлены на цели выявить ошибки (т.е непосредственно тестирование);

-  диагностику и локализацию ошибок (т.е определение характера ошибок и их местонахождение);

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

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

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

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

Рассмотрим особенности тестирования программного средства^[2]:

-  отсутствие эталона (программы), которому должна соответствовать тестируемая программа;

- высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

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

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

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

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

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

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

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

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

1.2 Стратегия проектирования тестов

Рассмотрим два самых противоположных подхода к проектированию тестов.

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

Рис. 1. Взаимосвязь процессов проектирования и тестирования

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

Сторонник второго подхода использует стратегию "белого ящика", или стратегию тестирования, управляемую логикой программы, которая позволяет исследовать внутреннюю структуру программы. В этом случае тестировщик получает тестовые данные путем анализа только логики программы; стремится, чтобы каждая команда была выполнена хотя бы один раз. При достаточной квалификации добивается, чтобы каждая команда условного перехода выполнялась бы в каждом направлении хотя бы один раз. Цикл должен выполняться один раз, ни разу, максимальное число раз. Цель тестирования всех путей извне также недостижима. В программе из двух последовательных циклов внутри каждого из них включено ветвление на десять путей, имеется 10¹⁸ путей расчета. Причем выполнение всех путей расчета не гарантирует выполнения всех спецификаций. Для справки: возраст Вселенной 10¹⁷с.

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

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

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

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

1.3 Сравнение методов тестирования

Рассмотрим с позиций надежности программного обеспечении стратегии тестирования и сравним их по семи критериям (табл.1 ).

Таблица 1

Качественная оценка подхода к сборке

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

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

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

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

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

Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования.

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

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

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

Третий критерий, необходимость драйверов - вес 1 ввиду доступности общих инструментов тестирования.

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

Шестой критерий - вес 3.

Седьмой критерий получает вес 2.

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

Таблица 2

Взвешенная оценка подхода к сборке

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

Глава 2 Отладка программ

2.1 Понятие отладки программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успешность отладки программного средства в немаловажной степени предопределена рациональной и правильной организацией тестирования.

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

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

Для целей оптимизировать набор тестов – а именно подготовить такие тесты, при помощи которых стало бы возможным при конкретном заданном числе тестов, либо же при заданном временном отрезке, которое отводят для процесса тестирования – обнаружить максимально возможное количество ошибок в программном средстве. Для этого необходимо: предварительно продумать и подготовить набор тестов, а также применить оптимальную стратегию планирования тестов (проектирования)^[5].

Проектирование тестов целесообразно начать после завершения внешнего описания программного средства. Существуют разные подходы к созданию стратегии (рис. 4)

Рис. 4. Подходы к проектированию тестов

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

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

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

- применять на каждую использованную функцию либо возможность хотя бы один тест;

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

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

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

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

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

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

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

2.3 Заповеди отладки программного средства

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

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

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

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

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

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Заключение

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

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

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

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

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

1. Ален И. Голуб. С и С. Правила программирования. - М.: БИНОМ, 1996. - 272 с.

2. Б. Керниган, Р. Пайк. Практика программирования. - СПб.: Невский диалект, 2001. - 381 с.

3. В. Даль, Э.. Дейкстра, К. Хоору. Структурное программирование. - М.: Мир, 1973. - 247 с.

4. Г. С. Иванова. Основы программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 416 с.

5. Г. С. Иванова. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

6. Д. Ван Тассель. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - 332 с.

7. М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - 368 с.

8. Н. Вирт. Систематическое программирование. - М.: Мир, 1977. - 183 с.

9. Э.Дейкстра. Дисциплина программирования. - М.: Мир, 1978. - 275 с.

10. Э.. Йодан. Структурное проектирование и конструирование программ. - М.: Мир, 1979. - 415 с.

11. http://digteh.ru/Progr/otladka.php

1. . Ален И. Голуб. С и С. Правила программирования. - М.: БИНОМ, 1996. - 272 с. – С. 43. ↑

2. М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - 368 с. – С. 76. ↑

3. Г. С. Иванова. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с. – С. 36. ↑

4. http://digteh.ru/Progr/otladka.php ↑

5. В. Даль, Э.. Дейкстра, К. Хоору. Структурное программирование. - М.: Мир, 1973. - 247 с. – С 54-56. ↑