Методы поиска ошибок в программах

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

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

В задачи функционального тестирования входят:

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

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

Поиск ошибок в Excel. Подсчет и работа с ошибками

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

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

• корректное оформление требований и ограничений к качеству ПО;
• корректное описание модели функционирования ПО в среде эксплуатации у заказчика;
• адекватность модели ПО заданному классу.

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

Поиск ошибок в программе

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

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

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

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

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

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

Отказ (failure) — это отклонение программы от функционирования или невозможность программы выполнять функции, определенные требованиями и ограничениями, что рассматривается как событие, способствующее переходу программы в неработоспособное состояние из-за ошибок, скрытых в ней дефектов или сбоев в среде функционирования [7.6, 7.11]. Отказ может быть результатом следующих причин:

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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

Источник: intuit.ru

5.18.4. Методы выявления ошибок

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

1) Метод обзора кода.

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

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

Согласно статистике, компилятор языка Си++ не замечает 9,4 % синтаксических ошибок и опечатки. Например, вместо индекса i используется j. И та, и другая переменные описаны в программе, поэтому такая ошибка компилятором не распознается, а на этапе тестирования время на устранение подобных ошибок увеличивается в десятки раз.

По данным разных исследований, при обзоре кода одна ошибка выявляется и ликвидируется в среднем каждые 5 — 20 мин, на этапе тестирования модулей — каждые 15 — 30 мин и на этапе комплексного тестирования — каждые 8 ч.

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

2) Контрольный анализ.

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

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

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

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

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

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

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

3) Метод чтения программы.

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

Является очень эффективным.

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

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

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

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

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

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

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

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

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

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

Источник: libraryno.ru

Методы поиска ошибок (отладки)

Итак, признаком наличия ошибки в программе является неправильное выполнение теста (во время теста выполнение программы завершается аварийно или результаты выполнения программы не совпадают с прогнозируемыми результатами теста). Процесс выявления причин обнаруженной ошибки, определение места (локализация) ошибки в программе и исправление ошибочно реализованного программного кода обычно называется отладкой . Как правило, при отладке существует некоторая предварительная стадия, во время которой программист выдвигает те или иные предложения о причинах ошибочной работы и проводит визуальный анализ ( инспекцию ) программного кода – к сожалению, данной формой отладки многие программисты пренебрегают, хотя эффективность такого способа отладки является достаточно высокой. Если при инспекции кода выявить ошибки не удается, далее наступает основной способ отладки – отладочное выполнение программы (или трассировка ), в ходе которого работа программы может быть приостановлена для просмотра значений тех или иных переменных программы с целью обнаружения ситуаций, когда эти значения не соответствуют предполагаемых. Тем самым, задача трассировки – обнаружения информационных признаков проявления ошибки. Рассмотрим далее возможности среды MS VS .NET для обеспечения трассировки программ при поиске и исправления ошибок.

Пошаговое выполнение программы

Для выполнения программы в пошаговом режиме (в режиме трассировки) используются четыре команды, которые доступны из меню Debug , панели инструментов Debug и клавиш быстрого вызова: − Команда Step Info (клавиша F11 ) обеспечивает последовательное, строка за строкой, выполнение программного кода программы (включая содержимое вызываемых методов), − Команда Step Over (клавиша F10 ) обеспечивает, как и предшествующая команда Step Info , последовательное выполнение программы, но при этом вызов методов рассматривается как один неделимый шаг (т.е. без перехода внутрь вызываемых методов), − Команда Step Out (клавиша Shift+F11 ) обеспечивает выполнение всех оставшихся строк программного кода текущего выполняемого метода без останова, позволяя выполнить быстрый переход в последнюю точку вызова, − Команда Run to Cursor (клавиша Ctrl+F10 ) обеспечивает выполнение без останова программного кода между текущей строки останова и позицией курсора (в зависимости от настроек параметров среды MS VS .NET данная команда может отсутствовать в пункте меню Debug ). Удобным средством указания точек останова процесса выполнения программы является использование контрольных точек (breakpoints). Для определения контрольной точки необходимо щелкнуть мышкой на вертикальной полосе слева от нужной строки программного кода; повторный щелчок отменяет установки контрольной точки. В ходе выполнения программы при попадании на контрольную точку происходит останов; для продолжения работы необходимо выполнить команду Continue пункта меню Debug . Вид окна среды разработки для учебного примера в момент останова после 19 Рис. 1.8. Вид окна среды разработки в момент остановки выполнения программы

выполнения стандартного метода сортировки показан на рис. 1. 8.

Наблюдение значений переменных

Для наблюдения значений переменных в момент останова выполнения программы достаточно расположить указатель мыши на имени переменной – в результате значение переменной появится в виде всплывающей подсказки (пример высветки значения переменной показан на рис. 1.8).

Дополнительная возможность для наблюдения значений переменных состоит в использовании специальных окон наблюдения: − Окно Autos отображает значения всех переменных, используемых в текущей и предшествующей строках точки останова программы; в окне отображаются названия переменных, их тип и значения; окно Autos обычно располагается в нижней левой части экрана (см. рис. 1.8) и для его высветки необходимо щелкнуть мышью на ярлычке с названием окна; − Окно Locals отличается от предшествующего окна Autos тем, что отображает значения всех переменных текущей области видимости (т.е. переменных текущего выполняемого метода или его локального блока); − Окна Watch (таких окон в момент выполнения 4) отличаются тем, что состав отображаемых в них переменных может формироваться непосредственно программистом. Для высветки нужного окна нужно последовательно выполнить команды DebugWindowsWatchWatch , где N есть номер высвечиваемого окна. Для добавления переменной в окно для наблюдения нужно указать мышкой необходимую переменную, нажать правую кнопку мыши и появившемся контекстном меню выполнить команду Add Watch (такая же команда может иметься в пункте меню Debug , ее наличие в меню зависит от настроек параметров среды MS VS .NET). Удобный способ добавления переменных в окна наблюдения состоит в использовании техники «Взять и перенести» (выделить имя переменной, нажать левую кнопку мыши и, не отпуская ее, переместить указатель мыши в окно наблюдения, после чего отпустить конку мыши). Для удаления переменных из окна наблюдения достаточно выделить соответствующую строку и нажать клавишу < Delete >; − Близким по назначению к окнам Watch является окно Quick Watch , которое дополнительно позволяет изменять значения наблюдаемых переменных; для высветки окна необходимо выделить нужную переменную и выполнить команду Quick Watch пункта меню Debug .

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

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

Перечисленных набор средств среды разработки MS VS .NET достаточно для организации быстрой и эффективной отладки. Для успешного освоения этих средств необходима понимание принципов отладки и практика по их использованию для поиска и исправления ошибок при разработке достаточно сложных программ. Приведем пример проведения процесса отладки с использованием нашей учебной программы. Внесем ошибку в программу – заменим оператор Vals[j+1] = temp; в методе пузырьковой сортировки BubbleSort на оператор Vals[j] = temp; (такой прием, конечно, дает достаточно слабое представление о процедуре отладки – больший эффект можно получить, если внесение ошибки произвольного вида (!) будет выполнено кем то другим). Выполнение программы с внесенной ошибкой приведет к тому, что результирующий массив не будет являться отсортированным – возможная схема отладки может состоять в следующем: − Можно попытаться проверить, наблюдается ли ошибочный эффект при меньшем размере сортируемого набора данных (меньший объем информации упростит проведение трассировки программы); установим для этого значения константы N=3 и повторим выполнение программы – массив по прежнему остается неотсортированным; − Попытаемся определить причину ошибки – проблема может состоять или в неправильной работе алгоритма сортировки или ошибочными являются операторы вывода значений массива; однако вывод результатов стандартной сортировки сработал правильно и, кроме того, автоматическая проверка результатов сортировки тоже подтвердила, что результат пузырьковой сортировки является неправильным; как результат, можно сделать вывод, что ошибки содержатся в методе пузырьковой сортировки BubbleSort ; − Установим контрольную точку на внутреннем операторе цикла в методе BubbleSort (см. рис. 1.9) и запустим программу на выполнение; после останова добавим массив Vals в окно наблюдения Watch 1 и запомним исходное значение сортируемого массива;

− Выполнение внешней итерации алгоритма пузырьковой сортировки должно привести к «всплыванию» максимального значения в последний элемент массива; выполним команду Continue пункта меню Debug – результат выполнения не привел к желаемому эффекту, состояние сортируемого массива не изменилось и, как результат, можно сделать вывод, что внешняя итерация алгоритма сортировки работает неправильно; − Поскольку сортируемый массив состоит только из трех элементов, следующая итерация алгоритма сортировки должна оказаться последней; в ходе ее выполнения значения двух первых элементов должно поменяться местами (на примере значений из рис. 1.9); выполним трассировку – нажмем дважды клавишу F10 и перейдем на операторы перестановки значений, т.е. сравнение пары значений выполняется корректно; однако последующее выполнение операторов перестановки не приводит к нужному результату (значения не перестанавливаются) – отсюда следует, что ошибка содержится в алгоритме перестановки пары значений; анализ данного участка программного кода позволяет определить, что индекс элемента массива в последнем операторе должен быть j+1 ; для исправления ошибки вносим необходимые изменения, выполняем программу и достигаем требуемого результата (. ) – программа начинает работать правильно. Рис. 1.9. Состояние упорядочиваемого массива перед началом сортировки

Источник: studfile.net