Алгоритмические и программные ошибки

Цель лекции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2 – последствия и результаты

проявления некоторых внутренних дефектов.

Системные ошибки в большом (сложном) программном обеспечении определяются, прежде всего неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. На начальных стадиях проектирования программного обеспечения не всегда удается точно сформулировать целевую задачу всей системы и требования к ней. В процессе проектирования целевая функция системы уточняется и выявляются отклонения от уточненных требований, которые могут квалифицироваться как системные ошибки. Некачественное определение требований к программе приводит к созданию программы, которая будет правильно решать неверно сформулированную задачу. В таких случаях, как правило, требуется полное перепрограммирование. Признаком того, что создаваемая для заказчика программа может оказаться не соответствующей его истинным потребностям, служит ощущение неясности задачи. Письменная регистрация требований к программе заставляет заказчика собраться с мыслями и дать достаточно точное определение требований. Всякие устные указания являются заведомо ненадежными и часто приводят к взаимному недопониманию. При автономной и в начале комплексной отладки программного обеспечения доля найденных системных ошибок в нем невелика (примерно 10%), но она существенно возрастает (до 35—40%) на завершающих этапах комплексной отладки. В процессе эксплуатации преобладающими являются системные ошибки (примерно 80% всех ошибок). Ошибки в выборе алгоритма. Часто плохой выбор алгоритма становится очевидным лишь после его опробования. Поэтому все же следует уделять внимание и время выбору алгоритма, с тем, чтобы впоследствии не приходилось переделывать каждую программу. Во избежание выбора некорректных алгоритмов, необходимо хорошо ознакомиться с литературой по своей специальности. К алгоритмическим ошибкам следует отнести, прежде всего, ошибки, обусловленные некорректной постановкой функциональных задач, когда в спецификациях не полностью оговорены все условия, необходимые для получения правильного результата. Эти условия формируются и уточняются в значительной части в процессе тестирования и выявления ошибок в результатах функционирования программ. Также следует отнести ошибки связей модулей и функциональных групп программ. Их можно квалифицировать как ошибки некорректной постановки задачи. Алгоритмические ошибки проявляются в неполном учете диапазонов изменения переменных, в неправильной оценке точности используемых и получаемых величин, в неправильном учете связи между различными переменными, в неадекватном представлении формализованных условий решения задачи в спецификациях или схемах, подлежащих программированию и т.д. Эти обстоятельства являются причиной того, что для исправления каждой алгоритмической ошибки приходится изменять иногда целые ветви программного обеспечения, т.е. пока еще существенно больше операторов, чем при исправлении программных ошибок. Алгоритмические ошибки значительно труднее поддаются обнаружению методами формализованного автоматического контроля. Вот почему необходимо тщательным образом продумывать алгоритм прежде, чем транслировать его в программу. Некоторые программисты проверяют алгоритм следующим образом. Через несколько дней после составления алгоритма они повторно обращаются к описанию задачи и составляют алгоритм заново. Затем сличают оба варианта. Такой шаг на первый взгляд может показаться пустой тратой времени, однако всякая ошибка на уровне алгоритма может в дальнейшем обернуться катастрофой и повлечь основательный пересмотр программы. Технологические ошибки— это ошибки документации и фиксирования программ в памяти ЭВМ. Они составляют 5—10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство технологических ошибок выявляются автоматически формализованными методами (например, транслятором). Программные ошибки. Языки программирования — это искусственные языки, созданные человеком для описания алгоритмов. Все предложения таких языков строятся по строгим синтаксическим правилам, обеспечивающим однозначное их понимание, что позволяет поручать расшифровку алгоритма ЭВМ, построенного по правилам семантики. Синтаксис — это набор правил построения из символов алфавита специальных конструкций, с помощью которых можно составлять различные алгоритмы (программы). Эти правила требуют их неукоснительного соблюдения. В противном случае будет нарушен основной принцип — четкая и строгая однозначность в понимании алгоритма.
Семантика языка — это система правил истолкования построений конструкций. Правила семантики конструкций обычно вполне естественны и понятны, но в некоторых случаях их надо специально оговаривать, комментировать. Таким образом, программы, позволяющие однозначно производить процесс переработки данных, составляются с помощью соединения символов из алфавита в предложения в соответствии с синтаксическими правилами, определяющими язык, с учетом правил семантики. Выделяют синтаксические и семантические ошибки. Под синтаксическими ошибками понимается нарушение правил записи программ на данном языке программирования. Они выявляются самой машиной, точнее транслятором, вовремя перевода записи алгоритма на язык машины. Исправление их осуществляется просто — достаточно сравнить формат исправляемой конструкции с синтаксисом в справочнике и исправить его. Семантические (смысловые) ошибки — это применение операторов, которые не дают нужного эффекта (например, а—вместо, а+в), ошибка в структуре алгоритма, в логической взаимосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не формализуемы. Поэтому поиск и устранение семантической ошибки и составляет основу отладки. Каждая программная ошибка влечет за собой необходимость изменения команд существенно меньше, чем при алгоритмических и системных ошибках. На этапах комплексной отладки программного обеспечения и эксплуатации удельный вес программных ошибок падает и составляет примерно 15 и 30 % соответственно от общего количества ошибок, выявляемых в единицу времени.

10.1. Общие
особенности дефектов, ошибок и рисков
в сложных программных средствах

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

10.3. Риски
в жизненном цикле сложных программных
средств

10.4. Риски
при формировании требований к
характеристикам сложных программных
средств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица
10.1

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Cтраница 1

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

Алгоритмические ошибки и ошибки кодирования, связанные с некорректной формулировкой и реализацией алгоритмов программным путем.
 [2]

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

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

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

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

С алгоритмическими ошибками дело обстоит иначе. Компиляция программы, в которой есть алгоритмическая ошибка, завершается успешно. При пробных запусках программа ведет себя нормально, однако при анализе результата выясняется, что он неверный. Для того чтобы устранить алгоритмическую ошибку, приходится анализировать алгоритм, вручную прокручивать его выполнение.
 [8]

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

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

В предыдущем параграфе был рассмотрен характер формирования алгоритмической ошибки вычислений при отсутствии искажающих воздействий со стороны окружающей среды и вычислительной системы. В реальных условиях на процесс смены состояний АлСУ и ошибку выходных сигналов существенное влияние оказывают искажающие воздействия, которые по отношению к управляющему объекту могут быть как внешними, так и внутренними. Внешние воздействия, источником которых является внешняя ( по отношению к управляющему объекту) среда, связаны с ошибками определения параметров управляемого процесса, отказами и сбоями в работе датчиков информации, каналов связи и преобразующих устройств. Внутренние воздействия, источниками которых являются ЦВМ или комплексы ЦВМ, используемые для реализации алгоритмической системы, обусловлены сбоями, частичными отказами и прерываниями.
 [11]

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

Однако формула ( 29) позволяет судить о характере формирования алгоритмической ошибки в реальных системах и сделать важный вывод о несостоятельности попыток оценки качества АлСУ всякого рода контрольными просчетами.
 [13]

Защита от перегрузки ЭВМ по пропускной способности предполагает обнаружение и снижение влияния последствий алгоритмических ошибок, обусловленных неправильным определением необходимой пропускной способности ЭВМ для работы в реальном времени. Кроме того, перегрузки могут быть следствием неправильного функционирования источников информации и превышения интенсивности потоков сообщений расчетного, нормального, уровня. Последствия обычно сводятся к прекращению решения некоторых функциональных задач, обладающих низким приоритетом.
 [14]

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

Страницы:  

   1

   2

   3

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

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

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

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

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

1. оценивать реальное
   состояние проекта и планировать
   трудоемкость и длительность до его
   завершения;

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

3. оценивать
   требующиеся ресурсы ЭВМ по памяти и
   производительности с учетом затрат на
   устранение ошибок;

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

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

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

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

Технологические
ошибки
документации и фиксирования программ
в памяти ЭВМ составляют 5…10 % от общего
числа ошибок, обнаруживаемых при отладке
[12]. Большинство технологических ошибок
выявляется автоматически формализованными
методами.

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

В комплексе программ
информационно-справочных систем эти
виды ошибок близки по удельному весу,
однако для автоматизации их обнаружений
применяются различные методы. На
начальных этапах разработки и автономной
отладки модулей программные ошибки
составляют около 1/3 всех ошибок. Ошибки
применения операций на начальных этапах
разработки достигают 14 %, а затем быстро
убь-1вают при повышении квалификации
программистов. Ошибки в переменных
составляют около 13 %, а ошибки управления
и организации циклов—около 10 %. Каждая
программная ошибка влечет за собой
необходимость изменения около шести
команд, что существенно меньше, чем при
алгоритмических и системных ошибках.
На этапах комплексной отладки и
эксплуатации удельный вес программных
ошибок падает и составляет около 15 и 3
% соответственно от общего количества
ошибок, выявляемых в единицу времени.

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

К алгоритмическим
ошибкам следует отнести также ошибки
связей модулей и функциональных групп
программ. Этот вид ошибок составляет
6…8 % от общего количества, их можно
квалифицировать как ошибки некорректной
постановки задач. Алгоритмические
ошибки проявляются в неполном учете
диапазонов изменения переменных, в
неправильной оценке точности используемых
и получаемых величин, в неправильном
учете связи между различными переменными,
в неадекватном представлении
формализованных условий решения задачи
в спецификациях или схемах, подлежащих
программированию, и т. д. Эти обстоятельства
являются причиной того, что для исправления
каждой алгоритмической ошибки приходится
изменять в среднем около 14 команд, т. е.
существенно больше, чем при программных
ошибках.

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

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

системные ошибки.

При автономной и
в начале комплексной отладки доля
системных ошибок невелика (около 10 %),
но она существенно возрастает (до 35…40
%) на завершающих этапах комплексной
отладки. В процессе эксплуатации
системные ошибки являются преобладающими
(около 80 % от всех ошибок). Следует также
отметить большое количество команд,
корректируемых при исправлении каждой
ошибки (около 25 команд на одну ошибку).

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

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

Введение

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

Классификация ошибок

Введение

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

• синтаксические;
• ошибки времени выполнения;
• алгоритмические.

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

Синтаксические ошибки, их также называют ошибками времени компиляции (Compile-time error), наиболее легко устранимы. Их обнаруживает компилятор, а программисту остается внести изменения в текст программы и выполнить повторную компиляцию.

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

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

При возникновении ошибки в программе, запущенной из ИСР, среда прерывает работу программы и в окне сообщений дает информацию о типе ошибки.

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

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

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

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

Предотвращение и обработка ошибок

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

FPC и ИСР предоставляют программисту мощные средства:

• Компилятор с регулируемыми опциями.

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

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

Что такое баг?

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

Варианты ошибок:

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

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

Классификация багов

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

Баги делят на категории в зависимости от их критичности:

1. незначительные ошибки,
2. серьезные ошибки,
3. showstopper.

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

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

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

Разновидности ошибок

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

Кодеры делят ошибки по сложности:

1. Борбаг (Bohr Bug) – «стабильная» ошибка, легко выявляемая еще на этапе отладки или при бета-тестировании, когда речь еще не идет о выпуске стабильной версии.
2. Гейзенбаг (Heisenbug) – периодически проявляющиеся, иногда надолго исчезающие баги с меняющимися свойствами, включая зависимость от программной среды, «железа».
3. Мандельбаг (Mandelbug) – ошибка с энтропийным поведением, почти с непредсказуемым результатом.
4. Шрединбаг (Schroedinbug) – критические баги, чаще приводящие к появлению возможности взлома, хотя внешне никак себя не проявляют.

Последняя категория ошибок – одна из основных причин регулярного обновления операционных систем Windows. Вроде бы пользователя все устраивает, а разработчик раз за разом выпускает новые пакеты исправлений. Наиболее известный баг, попортивший нервы многим кодерам, это «ошибка 2000 года» (Y2K Error). Про нее успешно забыли, но уроки извлекли.

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

Логические

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

Синтаксические

Ошибки синтаксиса существуют на уровне конкретного языка программирования: C, Java, Python, Perl и т.д. Что на одной платформе работает максимум с ворнингами, для другой будет серьезной проблемой. Такие баги легко исправить на этапе компиляции, потому что инструмент не позволит «пройти дальше» некорректного участка кода.

Компиляционные

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

Среды выполнения

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

Арифметические

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

Ресурсные

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

Взаимодействия

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

Что такое исключение

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

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

Как избежать ошибок?

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

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

Выводы

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