Вчера всё работало, а сегодня не работает / Код не работает как задумано
Привет, Вы узнаете про виды ошибок программного обеспечения, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое
виды ошибок программного обеспечения, принципы отладки , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
подготовленный комплект тестов может проверить основные режимы работы программы
выявить большинство имеющихся ошибок в программе,
Подготавливаемые тесты должны проверять основные варианты выполнения программы и должны быть в максимальной степени направлены на выявление ошибочных ситуаций в реализованных алгоритмах решения поставленной задачи (хороший тест – это тест, выявляющий наличие ошибки в программе (!) ),
Тест должен быть достаточно небольшим (по объему исходных данных), быстро выполняемым и желательно должен иметь значения не только результирующих, но и промежуточных данных,
Тест желательно должен иметь средства автоматической проверки результатов выполнения (как, например, в учебном примере результаты алгоритма пузырьковой сортировки можно было сравнить с результатами метода стандартной сортировки).
Методы поиска ошибок (отладки)
Итак, признаком наличия ошибки в программе является неправильное выполнение теста (во время теста выполнение программы завершается аварийно или результаты выполнения программы не совпадают с прогнозируемыми результатами теста). Процесс выявления причин обнаруженной ошибки, определение места (локализация) ошибки в программе и исправление ошибочно реализованного программного кода обычно называется . Как правило, при отладке существует некоторая предварительная стадия, во время которой программист выдвигает те или иные предложения о причинах ошибочной работы и проводит визуальный анализ () программного кода – к сожалению, данной формой отладки многие программисты пренебрегают, хотя эффективность такого способа отладки является достаточно высокой. Если при инспекции кода выявить ошибки не удается, далее наступает основной способ отладки – отладочное выполнение программы (или ), в ходе которого работа программы может быть приостановлена для просмотра значений тех или иных переменных программы с целью обнаружения ситуаций, когда эти значения не соответствуют предполагаемых. Тем самым, задача трассировки – обнаружения информационных признаков проявления ошибки.
Рассмотрим далее возможности среды MS VS .NET для обеспечения трассировки программ при поиске и исправления ошибок.
Методы отладки
Сложности возникают, когда приходится отслеживать слишком большие структуры данных или огромное их число. Еще проблематичнее трассировать проект, где выполнение каждой подпрограммы приводит к вызову пары десятков других. Но для небольших программ трассировки вполне достаточно.
С точки зрения «правильного» программирования силовые методы плохи тем, что не поощряют анализ задачи.
Суммируя свойства силовых методов, получаем практические советы:
— использовать трассировку и отслеживание значений переменных для небольших проектов, отдельных подпрограмм;
— использовать отладочную печать в небольших количества и «по делу»;
— оставить дамп памяти на самый крайний случай.
Метод индукции — анализ программы от частного к общему.
Просматриваем симптомы ошибки и определяем данные, которые имеют к ней хоть какое-то отношение. Затем, используя тесты, исключаем маловероятные гипотезы, пока не остается одна, которую мы пытаемся уточнить и доказать.
Метод дедукции — от общего к частному.
Выдвигаем гипотезу, которая может объяснить ошибку, пусть и не полностью. Затем при помощи тестов эта гипотеза проверяется и доказывается.
Обратное движение по алгоритму.
Отладка начинается там, где впервые встретился неправильный результат. Затем работа программы прослеживается (мысленно или при помощи тестов) в обратном порядке, пока не будет обнаружено место возможной ошибки.
Метод тестирования.
Давайте рассмотрим процесс локализации ошибки на конкретном примере. Пусть дана небольшая программа, которая выдает значение максимального из трех введенных пользователем чисел.
Обе выделенные ошибки можно обнаружить невооруженным глазом: первая явно допущена по невнимательности, вторая — из-за того, что скопированную строку не исправили.
Тестовые наборы данных должны учитывать все варианты решения, поэтому выберем следующие наборы чисел:
Данные Ожидаемый результат
a=10; b=-4; c=1 max=a=10
a=-2; b=8; c=4 max=b=8
a=90; b=0; c=90.4 max=c=90.4
В результате выполнения программы мы, однако, получим следующие результаты:
Для a=10; b=-4; c=1:
Наибольшим оказалось первое число 10.00
Наибольшим оказалось третье число 0.00
Вывод во втором и третьем случаях явно неверен. Будем разбираться.
Отладка
программы является итеративным процессом
обнаружения и исправления ошибок и
обычно требует последовательного
выполнения четырех этапов:
Некоторые
ошибки проявляются после первого же
запуска программы на выполнение, и для
их обнаружения не надо прибегать ни к
каким специальным средствам. Некоторые
ошибки проявляются в случайные моменты
работы программы. С такими ошибками
справиться труднее всего – зафиксировать
условия возникновения ошибки, понять
причину ошибки и устранить ее. С целью
обнаружения подобных ошибок осуществляется
тестирование
программы–
ее выполнение для специально подобранных
представительных контрольных примеров
– тестов. Тест
– это такой
набор исходных данных, для которого
вручную или другим способом просчитаны
промежуточные и конечные результаты и
который может быть использован для
получения информации о надежности
проверяемой программы.
Тестирование
программы должно включать в себя прогон
трех видов контрольных примеров:
нормальных ситуаций, граничных ситуаций
и случаев неправильных данных.
Нормальные
случаи –
это примеры с правильными входными
данными. Если программа не работает в
подобных случаях, она требует серьезных
переделок. Граничные контрольные примеры
помогают установить, способна ли
программа нормально реагировать на
особые случаи во входных данных. Граничные
примеры
представляют собой данные, которые,
будучи математически корректными,
приводят программу к необходимости
работать особым образом. Неправильными
являются
такие данные,
которые расположены вне допустимого
диапазона. Примеры с неправильными
данными должны быть обработаны
соответствующим образом, поскольку в
повседневной эксплуатации программе
придется иметь дело и с неверными
входными данными.
После того как
ошибка обнаружена, необходимо найти в
исходном тексте программы то место, в
котором она возникала, – локализовать
ошибку. Можно
использовать ряд различных методов
отладки, позволяющих обнаружить
расположение ошибки; выбор существенно
зависит от особенностей ситуации.
Большинство программистов начинают с
неформального метода, известного под
названием проверка
за столом. Используя
контрольный пример, который привел к
ошибке в программе, программист
аналитически трассирует листинг
программы в надежде локализовать ошибку.
Проверка за столом – это хороший метод,
поскольку он заставляет программиста
детально понять работу программы. Если
применение метода проверки за столом
оказалось бесплодным, нужно использовать
специальные методы и способы отладки,
позволяющие наблюдать за передачей
управления в программе и за изменением
значений наиболее важных переменных.
Полученная отладочная информация
позволит локализовать подозрительные
ситуации, провести анализ и выявить
причину ошибки, устранить ее, а затем
продолжить поиск других ошибок.
В общем случае
ошибки могут возникать на любом этапе
разработки программы, причина ошибок
может быть связана с недопониманием
сути задачи, недостатками проектирования
алгоритма, неправильным использованием
языковых средств. При выполнении
программы ошибки разного типа проявляют
себя различным образом, и их принято
подразделять на следующие группы:
Синтаксические
ошибки –
это ошибки, проявляющиеся на этапе
компиляции программы и возникающие в
связи с нарушением синтаксических
правил написания предложений используемого
языка программирования (к таким ошибкам
относятся
пропущенные точки с запятой, ссылки на
неописанные переменные, присваивание
переменной значений неверного типа и
т. д.). Если компилятор встречает в
тексте программы оператор или описание,
которые
он не может интерпретировать, то он
позиционирует курсор на место обнаруженной
ошибки и
в строку статуса выводит сообщение,
содержащее номер ошибки и ее краткое
описание.
Семантические
ошибки – это
ошибки, проявляющиеся на этапе
выполнения программы при ее попытке
вычислить недопустимые значения
параметров или выполнить недопустимые
действия. Причина возникновения ошибок
данного типа связана с нарушением
семантических правил написания программ
(примером являются ситуации
попытки
открыть несуществующий файл или выполнить
деление на нуль). Если программа
обнаруживает ошибку такого типа, то она
завершает свое выполнение
и
выводит
соответствующее сообщение в окне Build,
содержащее номер строки с ошибкой и ее
возможный характер. Список сообщений
можно просмотреть с помощью команды
меню View/Debug
Windows/Event
Log.
При выполнении программы из среды Delphi
автоматически выбирается соответствующий
исходный файл и в нем находится
местоположение ошибки. Если же программа
выполнялась вне среды и в ней появилась
ошибка данного типа, то необходимо
запустить
среду и найти вызвавший ошибку оператор.
Логические
(смысловые) ошибки – самые
сложные и трудноуловимые, связанные с
неправильным применением тех или иных
алгоритмических конструкций. Эти ошибки
при выполнении программы могут проявиться
явно (выдано сообщение об ошибке, нет
результата или выдан неверный результат,
программа «зацикливается»), но чаще
они проявляют себя только при определенных
сочетаниях параметров или вообще не
вызывают нарушения работы программы,
которая в этом случае выдает правдоподобные,
но неверные результаты.
Ошибки первого
типа легко выявляются самим компилятором.
Обычно устранение синтаксических ошибок
не вызывает особых трудностей. Более
сложно выявить ошибки второго и особенно
третьего типа. Для обнаружения и
устранения ошибок второго и третьего
типа обычно применяют специальные
способы и средства отладки программ.
Выявлению ошибок второго типа часто
помогает использование контролирующих
режимов компиляции с проверкой допустимых
значений тех или иных параметров (границ
индексов элементов массивов, значений
переменных типа диапазона, ситуаций
переполнения, ошибок ввода-вывода).
Устанавливаются эти режимы с помощью
ключей
компилятора,
задаваемых либо в программе, либо в меню
Project/Options/Compiler
среды
Delphi, либо
в
меню
Options/Compiler Турбо-среды.
Соседние файлы в папке крутые билеты по инфе
Метод дедукции
Неверные результаты в нашем случае могут получиться из-за ошибки в:
Для доказательства мы можем пользоваться отладочной печатью, трассировкой или просто набором тестов. В любом случае мы выявляем одну ошибку в расчете и одну в выводе.
Ошибки, которые не обнаруживает транслятор
В случае правильного написания операторов в программе может присутствовать большое количество ошибок, которые транслятор не может обнаружить. Рассмотрим примеры таких ошибок:
Логические ошибки: после проверки заданного условия неправильно указана ветвь алгоритма; неполный перечень возможных условий при решении задачи; один или более блоков алгоритма в программе пропущен.
Ошибки в циклах: неправильно указано начало цикла; неправильно указаны условия окончания цикла; неправильно указано количество повторений цикла; использование бесконечного цикла.
Ошибки ввода-вывода; ошибки при работе с данными: неправильно задан тип данных; организовано считывание меньшего или большего объема данных, чем нужно; неправильно отредактированы данные.
Ошибки в использовании переменных: используются переменных, для которых не указаны начальные значения; ошибочно указана одна переменная вместо другой. Ошибки при работе с массивами: пропущено предварительное обнуление массивов; неправильное описание массивов; индексы массивов следуют в ошибочном порядке.
ошибки безопасности, умышленные и не умышленные уязвимости в системе, открытость к отказам в обслуживании. несанкционированном доступе. екхолы
Ошибки в арифметических операциях: неправильное использование типа переменной (например, для сохранения результата деления используется целочисленная переменная); неправильно определен порядок действий; выполняется деление на нуль; при расчете выполняется попытка извлечения квадратного корня из отрицательного числа; не учитываются значащие разряды числа.
ошибки в архитектуре приложения пприводящие к увеличени технического долга
Проектирование тестов
Тесты просчитываются вручную, значит, они должны быть достаточно просты для этого.
Тесты должны проверять каждую ветку алгоритма. По возможности, конечно. Так что количество и сложность тестов зависит от сложности программы.
Тесты составляются до кодирования и отладки: во время разработки алгоритма или даже составления математической модели.
Обычно для экономии времени сначала пропускают более простые тесты, а затем более сложные.
Давайте рассмотрим задачу: нужно проверить, попадает ли введенное число в заданный пользователем диапазон.
program Example;
(******************************************************
* Задача: проверить, попадает ли введенное число в *
* заданный пользователем диапазон *
******************************************************)
Как видите, программа очень мала, а тестов для проверки всех ветвей ее алгоритма, требуется довольно много.
Пошаговое выполнение программы
Для выполнения программы в пошаговом режиме (в режиме трассировки) используются четыре команды, которые доступны из меню , панели инструментов и клавиш быстрого вызова:
(клавиша ) обеспечивает последовательное, строка за строкой, выполнение программного кода программы (включая содержимое вызываемых методов),
(клавиша ) обеспечивает, как и предшествующая команда , последовательное выполнение программы, но при этом вызов методов рассматривается как один неделимый шаг (т.е. без перехода внутрь вызываемых методов),
(клавиша ) обеспечивает выполнение всех оставшихся строк программного кода текущего выполняемого метода без останова, позволяя выполнить быстрый переход в последнюю точку вызова,
Run to Cursor (клавиша ) обеспечивает выполнение без останова программного кода между текущей строки останова и позицией курсора (в зависимости от настроек параметров среды MS VS .NET данная команда может отсутствовать в пункте меню ).
Удобным средством указания точек останова процесса выполнения программы является использование (breakpoints). Для определения контрольной точки необходимо щелкнуть мышкой на вертикальной полосе слева от нужной строки программного кода; повторный щелчок отменяет установки контрольной точки. В ходе выполнения программы при попадании на контрольную точку происходит останов; для продолжения работы необходимо выполнить команду пункта меню .
Вид окна среды разработки для учебного примера в момент останова после
Рис. 1.8. Вид окна среды разработки в момент остановки выполнения программы
выполнения стандартного метода сортировки показан на рис. 1. 8.
Debugging (Отладка)
В чем заключается процесс отладки? Что это такое?
Процесс отладки состоит в том, что мы останавливаем выполнения скрипта в любом месте, смотрим, что находится в переменных, в функциях, анализируем и переходим в другие места; ищем те места, где поведение отклоняется от правильного.
Заметка: Отладка производится как правило в IDE (Интегрированная среда разработки). Что это такое можно чуть подробнее ознакомиться в вопросе
Какие есть способы предупреждения ошибок, их нахождения и устранения?
В данном случае будет рассмотрен пример с Visual Studio, но отладить код можно и в любой другой IDE.
Обратное движение по алгоритму
Зная, что ошибка возникает при выводе результатов, рассматриваем код, начиная с операторов вывода. Сразу же находим лишнюю b в операторе writeln.
Синтаксические ошибки
Синтаксические ошибки зачастую выявляют уже на этапе трансляции. К сожалению, многие ошибки других видов транслятор выявить не в силах, т.к. ему не известен задуманный или требуемый результат работы программы. Отсутствие сообщений транслятора о наличии синтаксических ошибок является необходимым условием правильности программы, но не может свидетельствовать о том, что она даст правильный результат.
Примеры синтаксических ошибок :
Процесс
Для самого процесса используются элементы управления (см. изображение выше, выделено зеленым прямоугольником)
(F8) — продолжить выполнение. Продолжает выполнения скрипта с текущего момента. Если больше нет других точек останова, то отладка заканчивается и скрипт продолжает работу. В ином случае работа прерывается на следующей точке останова.
(F10) — делает один шаг не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.
(F11) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.
(Shift+F11) — выполняет команды до завершения текущей функции. Удобна, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.
— отключить/включить все точки останова
— включить/отключить автоматическую остановку при ошибке. Если включена, то при ошибке в коде он скрипт остановится автоматически и можно посмотреть в отладчике текущие значения переменных, проанализировать и принять меры по устранению.
Итак, в текущем коде видно значение входного параметра:
Если теперь нажмем F11, то попадем внутрь функции-замыкания nums.forEach
Нажимая теперь F10 пока не окончится цикл, можно будет наблюдать, как на каждой итерации цикла постоянно изменяются значения num и sum. Тем самым мы можем проследить шаг за шагом весь процесс изменения любых переменных и значений на любом этапе, который интересует.
Дальнейшие нажатия F10 переместит линию кода на строки 11, 12 и, наконец, 15.
Дополнительно
Больше информации о возможностях инструментов например Chrome — можно прочитать здесь
Дополнительно 2
Принудительную отладку можно инициировать событием, происходящим на странице/элементах. Это полезно, если не знаешь где обрабатывающая функция находится.
Пример для Chrome:
Нажимаем F12, заходим на вкладку Sources и в функциях контроля видим вкладку Event Listener Breakpoints, в которой можно назначить в качестве триггера любые события, при которых исполнение скрипта будет остановлено.
На изображении ниже выбран пункт на событие onchange элементов.
Если функция инлайновая, например
то можно зайти в Инспектор, найти тот самый элемент, в котором прописано событие и обнаружить рядом значок em:
Кликнув на него, как утверждает developer.mozilla.org/ru/docs можно увидеть строчки:
где можно увидеть события, навешанные на элемент, скрипт, строку, возможность нажать на паузу и т.д.
В других случаях, а также если кнопка паузы не обнаружена, то на вкладке Debugger(отладчик) надо найти стрелку, при наведении на которую будет написано «Events». Там должно быть событие выделенного элемента.
А вот таких полезных вкладок как у Chrome к сожалению у Firefox там нет.
Классификация ошибок
Ошибки в программах могут допускаться от самого начального этапа составления алгоритма решения задачи до окончательного оформления программы. Разновидностей ошибок достаточно много. Рассмотрим некоторые группы ошибок и соответствующие примеры:
Если вы удручены тем, что насажали в текст программы глупых ошибок — не расстраивайтесь. Ошибки вообще не бывают умными, хотя и могут относиться к самым разным частям кода:
Классификация ошибок по этапу обработки программы
рис Классификация ошибок этапа выполнения по возможным причинам
Подготовка
Достаточно иметь в наличии IDE, например Intellij IDEA
Средства отладки
Помимо методик, хорошо бы иметь представление о средствах, которые помогают нам выявлять ошибки. Это:
1) Аварийная печать — вывод сообщений о ненормальном завершении отдельных блоков и всей программы в целом.
2) Печать в узлах программы — вывод промежуточных значений параметров в местах, выбранных программистом. Обычно, это критичные участки алгоритма (например, значение, от которого зависит дальнейший ход выполнения) или составные части сложных формул (отдельно просчитать и вывести числитель и знаменатель большой дроби).
3) Непосредственное слежение:
Нынешние среды разработки часто предлагают нам реагировать на возникающую проблему в диалоговом режиме. При этом можно:
Рис Пример отладки приложения
Стратегии тестирования
1) Тестирование программы как «черного ящика».
Мы знаем только о том, что делает программа, но даже не задумываемся о ее внутренней структуре. Задаем набор входных данных, получаем результаты, сверяем с эталонными.
При этом обнаружить все ошибки мы можем только если составили тесты для всех возможных наборов данных. Естественно, это противоречит экономическим принципам, да и просто достаточно глупо.
«Черным ящиком» удобно тестировать небольшие подпрограммы.
2) Тестирование программы как «белого ящика».
Здесь перед составлением теста мы изучаем логику программы, ее внутреннюю структуру. Тестирование будет считаться удачным, если проверяет программу по всем направлениям. Однако, как мы уже говорили, это требует огромного количества тестов.
На практике мы, как всегда, совместно используем оба принципа.
3) Тестирование программ модульной структуры.
Мы снова возвращаемся к вопросу о структурном программировании. Если вы помните, программы строятся из модулей не в последнюю очередь для того, чтобы их легко было отлаживать и тестировать. Действительно, структурированную программу мы будем тестировать частями. При этом нам нужно:
строить набор тестов;
комбинировать модули для тестирования.
Такое комбинирование может строиться двумя способами:
Пошаговое тестирование — тестируем каждый модуль, присоединяя его к уже оттестированным. При этом можем соединять части программы сверху вниз (нисходящий способ) или снизу вверх (восходящий).
Монолитное тестирование — каждый модуль тестируется отдельно, а затем из них формируется готовая рабочая программа и тестируется уже целиком.
Чтобы протестировать отдельный модуль, нужен модуль-драйвер (всегда один) и модул и-заглушки (этих может быть несколько).
Модуль-драйвер содержит фиксированные исходные данные. Он вызывает тестируемый модуль и отображает (а возможно, и анализирует) результаты.
Модуль-заглушка нужен, если в тестируемом модуле есть вызовы других. Вместо этого вызова управление передается модулю-заглушке, и уже он имитирует необходимые действия.
К сожалению, мы опять сталкиваемся с тем, что драйверы и заглушки сами могут оказаться источником ошибок. Поэтому создаваться они должны с большой осторожностью.
Если нажать на View Breakpoints в левой панели, то можно не только посмотреть все брейкпойнты, но в появившемся окно можно еще более тонко настроить условие, при котором на данной отметке надо остановиться. В методе выше, например, нужно остановиться только когда sum превысит значение 20.
Это удобно, если останов нужен только при определённом значении, а не всегда (особенно в случае с циклами).
Больше информации об отладке можно посмотреть в http://learn.javajoy.net/debug-intellij-idea, а также в официальной документации к IDE
Пример выполнения отладки
Перечисленных набор средств среды разработки MS VS .NET достаточно для организации быстрой и эффективной отладки. Для успешного освоения этих средств необходима понимание принципов отладки и практика по их использованию для поиска и исправления ошибок при разработке достаточно сложных программ.
Приведем пример проведения процесса отладки с использованием нашей учебной программы. Внесем ошибку в программу – заменим оператор
в методе пузырьковой сортировки на оператор
(такой прием, конечно, дает достаточно слабое представление о процедуре отладки – больший эффект можно получить, если внесение ошибки произвольного вида (!) будет выполнено кем то другим).
Выполнение программы с внесенной ошибкой приведет к тому, что результирующий массив не будет являться отсортированным – возможная схема отладки может состоять в следующем:
Можно попытаться проверить, наблюдается ли ошибочный эффект при меньшем размере сортируемого набора данных (меньший объем информации упростит проведение трассировки программы); установим для этого значения константы N=3 и повторим выполнение программы – массив по прежнему остается неотсортированным;
Попытаемся определить причину ошибки – проблема может состоять или в неправильной работе алгоритма сортировки или ошибочными являются операторы вывода значений массива; однако вывод результатов стандартной сортировки сработал правильно и, кроме того, автоматическая проверка результатов сортировки тоже подтвердила, что результат пузырьковой сортировки является неправильным; как результат, можно сделать вывод, что ошибки содержатся в методе пузырьковой сортировки ;
Установим контрольную точку на внутреннем операторе цикла в методе (см. рис. 1.9) и запустим программу на выполнение; после останова добавим массив в окно наблюдения и запомним исходное значение сортируемого массива;
Выполнение внешней итерации алгоритма пузырьковой сортировки должно привести к «всплыванию» максимального значения в последний элемент массива; выполним команду пункта меню – результат выполнения не привел к желаемому эффекту, состояние сортируемого массива не изменилось и, как результат, можно сделать вывод, что внешняя итерация алгоритма сортировки работает неправильно;
Поскольку сортируемый массив состоит только из трех элементов, следующая итерация алгоритма сортировки должна оказаться последней; в ходе ее выполнения значения двух первых элементов должно поменяться местами (на примере значений из рис. 1.9); выполним трассировку – нажмем дважды клавишу и перейдем на операторы перестановки значений, т.е. сравнение пары значений выполняется корректно; однако последующее выполнение операторов перестановки не приводит к нужному результату (значения не перестанавливаются) – отсюда следует, что ошибка содержится в алгоритме перестановки пары значений; анализ данного участка программного кода позволяет определить, что индекс элемента массива в последнем операторе должен быть ; для исправления ошибки вносим необходимые изменения, выполняем программу и достигаем требуемого результата (!!!) – программа начинает работать правильно.
Рис. 1.9. Состояние упорядочиваемого массива перед началом сортировки
Соседние файлы в папке Книги
Советы отладчику
1) Проверяйте тщательнее: ошибка скорее всего находится не в том месте, в котором кажется.
2) Часто оказывается легче выделить те места программы, ошибок в которых нет, а затем уже искать в остальных.
3) Тщательнее следить за объявлениями констант, типов и переменных, входными данными.
4) При последовательной разработке приходится особенно аккуратно писать драйверы и заглушки — они сами могут быть источником ошибок.
5) Анализировать код, начиная с самых простых вариантов. Чаще всего встречаются ошибки:
— значения входных аргументов принимаются не в том порядке,
— переменная не проинициализирована,
— при повторном прохождении модуля, перемен ная повторно не инициализируется,
— вместо предполагаемого полного копирования структуры данных, копируется только верхний уровень (например, вместо создания новой динамической переменной и присваивания ей нужного значения, адрес тупо копируется из уже существующей переменной),
— скобки в сложном выражении расставлены неправильно.
6) При упорной длительной отладке глаз «замыливается». Хороший прием — обратиться за помощью к другому лицу, чтобы не повторять ошибочных рассуждений. Правда, частенько остается проблемой убедить это другое лицо помочь вам.
7) Ошибка, скорее всего окажется вашей и будет находиться в тексте программы. Гораздо реже она оказывается:
Но если вы совершенно уверены, что в программе ошибок нет, просмотрите стандартные модули, к которым она обращается, выясните, не менялась ли версия среды разработки, в конце концов, просто перегрузите компьютер — некоторые проблемы (особенно в DOS-средах, запускаемых из-под Windows) возникают из-за некорректной работы с памятью.
8) Убедитесь, что исходный текст программы соответствует скомпилированному объектному коду (текст может быть изменен, а запускаемый модуль, который вы тестируете — скомпилирован еще из старого варианта).
9) Навязчивый поиск одной ошибки почти всегда непродуктивен. Не получается — отложите задачу, возьмитесь за написание следующего модуля, на худой конец займитесь документированием.
10) Старайтесь не жалеть времени, чтобы уясненить причину ошибки. Это поможет вам:
исправить программу,
обнаружить другие ошибки того же типа,
не делать их в дальнейшем.
11) Если вы уже знаете симптомы ошибки, иногда полезно не исправлять ее сразу, а на фоне известного поведения программы поискать другие ляпы.
12) Самые труднообнаруживаемые ошибки — наведенные, то есть те, что были внесены в код при исправлении других.
Тестирование
Конечно, в реальной работе мы не расписываем так занудно каждый шаг, не прибегаем исключительно к одной методике, да и вообще частенько не задумываемся, каким образом искать ляпы. Теперь, когда мы разобрались со всеми подходами, каждый волен выбрать те из них, которые кажутся самыми удобными.
Для самого процесса используются элементы управления (см. изображение выше, выделено зеленым прямоугольником) и немного из дополнительно (см. изображение выше, выделено оранжевым прямоугольником)
Show Execution Point (Alt+F10) — переносит в файл и текущую линию отлаживаемого скрипта. Например если файлов много, решили посмотреть что в других вкладках, а потом забыли где у вас отладка 🙂
Step Over (F8) — делает один шаг не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.
Step Into (F7) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.
Step Out (Shift+F8) — выполняет команды до завершения текущей функции. Удобна, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.
Rerun (Ctrl+F5) — Перезапустить отладку
Resume Program(F9) — Продолжает выполнения скрипта с текущего момента. Если больше нет других точек останова, то отладка заканчивается и скрипт продолжает работу. В ином случае работа прерывается на следующей точке останова.
Stop (Ctrl+F2) — Завершить отладку
View Breakpoints (Ctrl+Shift+F8) — Посмотреть все установленные брейкпойнты
Mute Breakpoints — Отключить брейкпойнты.
Если теперь нажмем F8, то попадем внутрь цикла for и нажимая теперь F8 пока не окончится цикл, можно будет наблюдать на каждой итерации, как значение num и sum постоянно изменяются. Тем самым мы можем проследить шаг за шагом весь процесс изменения любых переменных и значений на любом этапе, который интересует.
Дальнейшие нажатия F8 переместит линию кода на строки 31, 32 и, наконец, 36.
Локализация ошибок
Локализация — это нахождение места ошибки в программе.
В процессе поиска ошибки мы обычно выполняем одни и те же действия:
Способы обнаружения ошибки:
Оба способа по-своему удобны и обычно используются совместно.
Show Next Statement (Alt+Num *) — переносит в файл и текущую линию отлаживаемого скрипта. Например если файлов много, решили посмотреть что в других вкладках, а потом забыли где у вас отладка 🙂
Step Over (F10) — делает один шаг не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.
Step Into (F11) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.
Step Out (Shift+F11) — выполняет команды до завершения текущей функции. Удобна, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.
Restart (Ctrl+Shift+F5) — Перезапустить отладку
Continue (F5) — Продолжает выполнения скрипта с текущего момента. Если больше нет других точек останова, то отладка заканчивается и скрипт продолжает работу. В ином случае работа прерывается на следующей точке останова.
Stop Debugging (Shift+F5) — Завершить отладку
Если теперь нажмем F10, то попадем внутрь цикла foreach и нажимая теперь F10 пока не окончится цикл, можно будет наблюдать на каждой итерации, как значение num и sum постоянно изменяются. num теперь можно будет наблюдать во вкладке Watch, потому что сейчас она доступна внутри цикла. Тем самым мы можем проследить шаг за шагом весь процесс изменения любых переменных и значений на любом этапе, который интересует.
Дальнейшие нажатия F10 переместит линию кода на строки 15, 16 и, наконец, 20.
Будет рассмотрен пример с Сhrome, но отладить код можно и в любом другом браузере и даже в IDE.
В секции №2 в левой части на любой строке можно кликнуть ЛКМ, тем самым поставив точку останова (breakpoint — брейкпойнт). Это то место, где отладчик автоматически остановит выполнение JavaScript, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много. На изображении выше отмечен зеленым цветом.
В остановленном коде можно посмотреть текущие значения переменных, выполнять различные команды и др.
А во вкладке Breakpoints можно:
Метод индукции
Судя по результатам, ошибка возникает, когда максимальное число — второе или третье (если максимальное — первое, то определяется оно правильно, для доказательства можно програть еще два-три теста).
Просматриваем все, относящееся к переменным b и с. Со вводом никаких проблем не замечено, а что касается вывода — то мы быстро натыкаемся на замену b на с. Исправляем.
Запускаем отладку
В данном случае, т.к. функция выполняется сразу при загрузке страницы, то для активации отладчика достаточно её перезагрузить. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку, заполнение инпута данными, движение мыши и другие действия)
В данном случае после перезагрузки страницы выполнение «заморозится» на 4 строке:
В Local показываются переменные функции: объявленные через var и параметры.
В Global – глобальные переменные и функции.
В данном случае будет рассмотрен пример с Intellij IDEA, но отладить код можно и в любой другой IDE.
Для начала в левой части панели с кодом на любой строке можно кликнуть ЛКМ, тем самым поставив точку останова (breakpoint — брейкпойнт). Это то место, где отладчик автоматически остановит выполнение C#, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много.
В данном случае, т.к. функция вызывается сразу на той же странице, то при нажатии кнопки Debug — отладчик моментально вызовет метод, выполнение «заморозится» на первом же брейкпойнте. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку в UI, передача POST запроса с данными и прочие другие действия)
Вау!! 😲 Ты еще не читал? Это зря!
К сожалению, в одной статье не просто дать все знания про виды ошибок программного обеспечения. Но я — старался.
Если ты проявишь интерес к раскрытию подробностей,я обязательно напишу продолжение! Надеюсь, что теперь ты понял что такое виды ошибок программного обеспечения, принципы отладки
и для чего все это нужно, а если не понял, или есть замечания,
то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории
Качество и тестирование программного обеспечения. Quality Assurance.
Принципы локализации ошибок:
Принципы исправления ошибок еще больше похожи на законы Мерфи:
Это утверждение хочется пояснить. Если программа упорно выдает результат 0,1 вместо эталонного нуля, простым округлением вопрос не решить. Если результат получается отрицательным вместо эталонного положительного, бесполезно брать его по модулю — мы получим вместо решения задачи ерунду с подгонкой.
Исправляя одну ошибку, очень легко внести в программу еще парочку. «Наведенные» ошибки — настоящий бич отладки.
Исправление ошибок зачастую вынуждает нас возвращаться на этап составления программы. Это неприятно, но порой неизбежно.
Для начала в левой части панели с кодом на любой строке можно кликнуть ЛКМ, тем самым поставив точку останова (breakpoint — брейкпойнт). Это то место, где отладчик автоматически остановит выполнение Java, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много.
Отладка программы
Отладка, как мы уже говорили, бывает двух видов:
Синтаксическая отладка. Синтаксические ошибки выявляет компилятор, поэтому исправлять их достаточно легко.
Семантическая (смысловая) отладка. Ее время наступает тогда, когда синтаксических ошибок не осталось, но результаты программа выдает неверные. Здесь компилятор сам ничего выявить не сможет, хотя в среде программирования обычно существуют вспомогательные средства отладки, о которых мы еще поговорим.
Отладка — это процесс локализации и исправления ошибок в программе.
Как бы тщательно мы ни писали, отладка почти всегда занимает больше времени, чем программирование.
Если перейти во вкладку Breakpoints в нижней панели, то можно посмотреть все брейкпойнты, удалить все брейкпойнты, включить/выключить, а также еще более тонко настроить условие, при котором на данной отметке надо остановиться. В методе выше, например, нужно остановиться только когда sum превысит значение 20.
Больше информации об отладке можно посмотреть в Сведения об отладке кода C# с помощью Visual Studio.
Трассировка и промежуточная наблюдение за переменными
Добавляем промежуточную печать или наблюдение за переменными:
Листинг программы существенно увеличился и стал вот таким:
В принципе, еще при наборе у нас неплохой шанс отловить ошибку в условии: подобные кусочки кода обычно не перебиваются, а копируются, и если дать себе труд слегка при этом задуматься, ошибку найти легко.
Но давайте считать, что глаз «замылен» совершенно, и найти ошибку не удалось.
Вывод для второго случая получается следующим:
Со вводом все в порядке . Об этом говорит сайт https://intellect.icu . Впрочем, в этом сомнений и так было немного. А вот что касается второй группы операторов печати, то картина вышла интересная: в результате выводится верное число (8.00), но неправильное слово («третье», а не «второе»).
Вероятно, проблемы в выводе результатов. Тщательно проверяем текст и обнаруживаем, что действительно в последнем случае выводится не c, а b. Однако к решению текущей проблемы это не относится: исправив ошибку, мы получаем для чисел -2.0, 8.0, 4.0 следующий результат.
Наибольшим оказалось третье число 4.00
Теперь ошибка локализована до расчетного блока и, после некоторых усилий, мы ее находим и исправляем.
Тестирование — это выполнение программы для набора проверочных входных значений и сравнение полученных результатов с ожидаемыми.
Цель тестирования — проверка и доказательство правильности работы программы. В противном случае — выявление того, что в ней есть ошибки. Тестирование само не показывает местонахождение ошибки и не указывает на ее причины.
Принципы тестирования.
1) Тест — просчитанный вручную пример выполнения программы от исходных данных до ожидаемых результатов расчета. Эти результаты считаются эталонными.
Полномаршрутным будет такое тестирование, при котором каждый линейный участок программы будет пройден хотя бы при выполнении одного теста.
2) При прогоне программы по тестовым начальным данным, полученные результаты нужно сверить с эталонными и проанализировать разницу, если она есть.
3) При разработке тестов нужно учитывать не только правильные, но и неверные исходные данные.
4) Мы должны проверить программу на нежелательные побочные эффекты при задании некоторых исходных данных (деление на ноль, попытка считывания из несуществующего файла и т.д.).
5) Тестирование нужно планировать: заранее выбрать, что мы контролируем и как это сделать лучше. Обычно тесты планируются на этапе алгоритмизации или выбора численного метода решения. Причем, составляя тесты, мы предполагаем, что ошибки в программе есть.
6) Чем больше ошибок в коде мы уже нашли, тем больше вероятность, что мы обнаружим еще не найденные.
Хорошим называют тест, который с большой вероятностью должен обнаруживать ошибки, а удачным — тот, который их обнаружил.
Наблюдение значений переменных
Для наблюдения значений переменных в момент останова выполнения программы достаточно расположить указатель мыши на имени переменной – в результате значение переменной появится в виде всплывающей подсказки (пример высветки значения переменной показан на рис. 1.8).
Дополнительная возможность для наблюдения значений переменных состоит в использовании специальных окон наблюдения:
отображает значения всех переменных, используемых в текущей и предшествующей строках точки останова программы; в окне отображаются названия переменных, их тип и значения; окно обычно располагается в нижней левой части экрана (см. рис. 1.8) и для его высветки необходимо щелкнуть мышью на ярлычке с названием окна;
отличается от предшествующего окна тем, что отображает значения всех переменных текущей области видимости (т.е. переменных текущего выполняемого метода или его локального блока);
Близким по назначению к окнам является окно , которое дополнительно позволяет изменять значения наблюдаемых переменных; для высветки окна необходимо выделить нужную переменную и выполнить команду пункта меню .
Кроме перечисленных окон, может быть использовано окно для наблюдения за значениями полей объекта, метод которого выполняется в текущий момент времени, а также окно , в котором отображается последовательность вызова методов, приведшая к обращению к текущему исполняемому методу.
Достаточно иметь в наличии IDE, например Visual Studio