Назовите типы ошибок которые могут возникнуть в программе

Виды ошибок программного обеспечения. Баги

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

Определение

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

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

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

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

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

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

Как классифицируют

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

1. Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
2. Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
3. Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

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

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

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

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

Разработчики выделяют следующие типы ошибок по уровню сложности:

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

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

Типы багов

Ошибки в программах бывают:

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

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

Ошибки синтаксиса

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

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

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

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

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

Выше – пример логической ошибки в программе. Тут:

1. Происходит сравнение значения i с 15.
2. На экран выводится сообщение, если I = 15.
3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

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

Время выполнения

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

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

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

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

Ресурсные

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

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

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

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

Исключения и как избежать багов

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

1. Программными. Они генерируются приложением или ОС.
2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.

Виды ошибок в программах

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

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

Итак, основных вида всего три:

Синтаксические ошибки в программах

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

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

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

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

Потому что в сообщении чётко сказано:

что можно перевести как

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

Логические ошибки в программах

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

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

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

Пример логической ошибки:

Здесь мы сравниваем значение i с числом 15, и выводим сообщение, если i = 15 . Но фишка в том, что в данном цикле i не будет равно 15 НИКОГДА, потому что в цикле переменной i присваиваются значения от 1 до 10.

Эта ошибка довольно безобидная. Здесь мы имеем просто бессмысленный код, который не причинит никакого вреда. Однако представьте, что программа должна выдавать какой-то сигнал тревоги, если i = 15 . Тогда получится, что никакого сигнала пользователь никогда не услышит, даже если случилось что-то страшное. А всё потому, что программист немного ошибся. Вот так вот и падают ракеты и самолёты…

Распространённые логические ошибки в С++ вы можете посмотреть здесь.

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

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

Одна из самых рапространённых ошибок времени выполнения — это неожиданное деление на ноль. Пример:

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

Но представьте, что пользователь введёт ноль. Что тогда будет? Правильно — попытка деления на ноль. А на ноль делить нельзя. Поэтому во время выполнения этой программы произойдёт ошибка, которая очень расстроит пользователя. Потому что в случае, например, с консольным приложением программа просто закроется, и пользователь не поймёт, что это было. Но зато поймёт, что программа — говно, и программы от этого разработчика лучше больше никогда не использовать.

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

Ну что же. На этом с видами ошибок пока всё. Изучайте программирование и поменьше ошибайтесь.

Программист и ошибки — актуально во все времена

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

Чтобы максимально раскрыть смысл фразы «актуально во все времена«, в качестве иллюстрирующих примеров будут приведены сведения времён старой доброй DOS 🙂, поэтому материал рекомендуется к прочтению любителям ностальгии

Какие же бывают типы ошибок?

Тип №1. Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании

• В «Справочнике Microsoft Works» и интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как
ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина)
Однако в действительности работа данной функции должна иметь следующий вид:
ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь)

В «Руководстве пользователя Microsoft Works для Windows» пакета Works 3.0 эта ошибка исправлена 🙂

• В русифицированном варианте Norton Utilities (версия 7.0, фирма Symantec) в утилите форматирования sformat при задании опции:
Системные файлы: [Не ставить…]
при форматировании выдаётся сообщение:
Системные файлы: Ставить
и наоборот, при задании опции:
Системные файлы: [Ставить…]
при форматировании выдаётся сообщение:
Системные файлы: Не ставить

• Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из-за ошибки в программе – вместо требуемой в операторе запятой программист поставил точку. Вот как был записан этот оператор:
DO 50 I = 12.525
На самом же деле он должен был выглядеть следующим образом:
DO 50 I = 12,525
В программе на Фортране IV требовался цикл, а программист поставил точку, а в результате получилось присваивание значения 12,525 неявной переменной DO50I (пробелы в Фортране игнорируются) [ Спасибо за этот ценный комментарий-поправку хабраюзеру rexxer2 ]

• Потеря связи с космической станцией «Фобос-1» (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.

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

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

• Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой» 🙂

Тип №2. Ошибки, возникающие при вводе в компьютер неверных данных

Весьма популярные ошибки, предотвращение которых известно под названием «защита от дурака»

• В 1983 году произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.

• Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами

Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу компьютера и выполняемую им программу.

• Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.

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

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

Тип №5. Выход из строя или сбои в работе измерительных приборов и датчиков, используемых при управлении какими-либо техническими системами и технологическими процессами

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

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

Тип 6. «Злая воля человека», носителем которой чаще всего выступает либо программист, либо оператор

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

• Сборочный конвейер волжского автомобильного завода в городе Тольятти работает под управлением АСУ, которая обеспечивает своевременное поступление деталей на конвейер со складов и из цехов вспомогательных производств. Для выполнения этой задачи информационно-управляющая система хранит информацию о тысячах узлов и деталей, из которых собирается автомобиль, о запасах деталей на складах, об их движении по транспортным линиям и т. д. На основе этой информации АСУ самостоятельно управляет автоматизированными складами, транспортными конвейерами, а также рядом других устройств.
Программист, разрабатывавший программное обеспечение для управления главным конвейером Волжского автозавода, сознательно внёс в программу «логическую бомбу» в знак протеста против низкой зарплаты. Через некоторое время эта «логическая бомба» сработала, и главный конвейер остановился на несколько дней. Ущерб от остановки составил 1 миллион рублей (в ценах 80-х годов), этот ущерб был несопоставим с зарплатой всех программистов ВАЗа, вместе взятых, а программист был дисквалифицирован и переведён в рабочие.

Подводим итоги

• устранение ошибок, допущенных при разработке программного обеспечения (1-й тип ошибок);
• проектирование программного обеспечения с учётом человеческого фактора, то есть таким образом, чтобы оно было защищено от «дурака» (2-й тип ошибок). При этом «свалять дурака» могут не только пользователи, работающие за компьютером, но и приборы и датчики, от которых компьютер принимает информацию при управлении техническими или иными системами (5-й тип ошибок);
• использование известных мер безопасности для снижения вероятности переноса компьютерных вирусов (3-й тип ошибок) с программами, передаваемыми в эксплуатацию (в практике распространения программ известны случаи, когда разработчики этих программ записывают дистрибутивы на заражённых вирусами компьютерах).

Надеюсь, данный материал окажется полезным. Желаю всем делать поменьше ошибок, ведь это особенно актуально в нынешние кризисные времена :^)

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

Ошибка

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

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

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

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

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

оглавление

Определения

Ошибка программы или программного обеспечения, основанная на общем определении слова » ошибка «

«Несоблюдение требования (EN ISO 9000: 2005)».

В частности, ошибка определяется как

«Отклонение ФАКТИЧЕСКИХ (наблюдаемых, определенных, вычисленных состояний или процессов) от ЗАДАЧИ (определенных, правильных состояний и процессов), если оно превышает предварительно определенный предел допуска [который также может быть 0]».

Согласно ISTQB , термин «ошибка» образован из следующих контекстов:

• неисправны действие (английский Error)

• . приводит к состоянию ошибки (англ. Defect)

• эффект вина может (англ. Неудача) приводят к

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

«Ошибка» как синоним ошибки программы

Слово « ошибка» в переводе с английского означает « Schnabelkerf ; Ошибка »и в просторечии« сельское членистоногое »или« (насекомоподобный) паразит ». На жаргоне американских инженеров значение «неисправность» или «ошибка конструкции» засвидетельствовано с конца 19 века; Это использование слова основано на (шутливой) идее о том, что маленький ползающий скот возится с коробкой передач, линией и т. Д. Самым старым свидетельством являются два письма Томаса Эдисона от 1878 года Уильяму Ортону , президенту телеграфной компании Western Union , и Тивадару Пушкашу , изобретателю телефонной станции , в которых говорится:

«[. ] Я обнаружил« жучок »в своем аппарате, но не в самом телефоне. Он был из рода callbellum ».

«[. ] Я нашел« жучок »в своем наборе, но не в самом телефоне. Он был из рода« callbellum »».

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

«Первым шагом [во всех моих изобретениях] является интуитивная мысль, которая приходит во время вспышки болезни, но затем возникают трудности — вещь перестает работать, и тогда [это]« ошибки »- как такие маленькие ошибки и трудности, которые называются — показать себя [. ] «.

Эдисон не изобретатель, но, по крайней мере, ключевой свидетель значения этого слова, которое тогда было в ходу. Связь этого термина с компьютерами, возможно, восходит к пионеру компьютеров Грейс Хоппер . Они распространили историю о том, что 9 сентября 1945 года бабочка вызвала неисправность реле в компьютере- калькуляторе реле Mark II Aiken . Бабочка была удалена, засунута в журнал и сделана следующая запись: « Первый реальный случай обнаружения ошибки. (По-немецки: «Впервые на самом деле был обнаружен« паразит ».»). Легенда о нахождении этого термина сохраняется, хотя запись в журнале указывает, что этот термин уже использовался раньше. Вдобавок Грейс Хоппер ошиблась насчет года: инцидент на самом деле произошел 9 сентября 1947 года. Соответствующая страница журнала хранилась в Компьютерном музее ВМС США в Дальгрене , штат Вирджиния, до начала 1990-х годов . Эта страница журнала регистрации бабочек в настоящее время находится в Смитсоновском институте .

Типы ошибок

В программной инженерии (см. Также) различают следующие типы ошибок в программах:

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

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

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

Прочие условия ошибки

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

Воспроизвести медиафайл

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

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

Конкретные примеры ошибок с определенным влиянием СМИ можно найти в списке примеров ошибок программ .

Экономический смысл

Программные ошибки — это гораздо больше, чем просто неприятные сопутствующие обстоятельства для разработчиков программного обеспечения; они вызывают значительные затраты с коммерческой и экономической точки зрения . Исследование IX 1/2006 показало, что z. B. следующие значения, определенные для Германии:

• Ежегодные убытки из-за программных ошибок в средних и крупных компаниях составляют около 84,4 млрд евро.
• Около 14,4 млрд евро ежегодно (35,9% бюджета ИТ) расходуется на устранение программных ошибок ;
• Потери производительности из-за сбоев компьютеров из-за неисправного программного обеспечения составляют около 70 миллиардов евро.

В том же исследовании также исследуется развитие качества программного обеспечения за период с 2002 по 2004 год. Результатом является:

• процент неудачных проектов вырос с 15% до 18%
• процент успешных проектов упал с 34% до 29%
• процент проектов с перерасходом средств увеличился с 43% до 56%
• доля проектов с отставанием в срок выросла с 82% до 84%
• доля проектов с подходящей функциональностью упала с 67% до 64%

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

• 27% оплаченного программного обеспечения так и не были доставлены,
• 52% никогда не работали,
• 18% были использованы только после капитального ремонта.
• Только 3% заказанного программного обеспечения соответствовали согласованным договорным условиям.

Standish Group International заявила: в среднем проекты превышают

• первоначально запланированная стоимость проекта на 89%
• назначенных приемов на 222%.

Евуси-Менах определила следующие факторы как причины отмены проекта из-за низкого качества программного обеспечения:

• Объективно неясно
• Неправильная занятость проектной команды
• Недостаточная гарантия качества
• Отсутствие технических ноу-хау
• Недостаточный учет исходной ситуации
• Отсутствие участия пользователя

Предотвращение и исправление программных ошибок

Как правило, чем раньше ошибка возникает в процессе разработки и чем позже она обнаруживается, тем больше времени потребуется на ее исправление.

Во время планирования

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

На этапе анализа

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

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

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

На этапе проектирования

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

При программировании

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

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

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

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

Оперативный

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

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

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

Безупречность

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

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

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

Классификация дефектов

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

Критерии, по которым можно классифицировать ошибки, включают: (с примерами):

• Тип ошибки: различаются: лексические ошибки (неизвестная ссылка), синтаксические ошибки (забытая точка с запятой), семантические ошибки (неправильное объявление ), ошибки времени выполнения (неверно отформатированные входные данные) и логические ошибки (плюс вместо минуса, цикл ошибки , . )
• причина ошибки: неточная спецификация, повернутые числа, неверная формула, непроверенные (неверные) входные данные .
• момент времени, в который произошла ошибка («неправильное действие»): Уже в спецификации программы, в черновике кода, в кодировке, .
• Время, в которое возникает ошибка («эффект ошибки»): фундаментальное различие возникает в зависимости от того, возникает ли ошибка во время разработки программы, например, во время тестирования (здесь это нормальный случай) или в продуктивной работе (где она часто представляет собой критическую ситуацию). вина).
• момент времени обнаружения: чем больше «время ожидания ошибки», тем больше времени требуется i. A. Корректирующее действие будет продолжено.
• последствия ошибки: ошибки отображения, неверные результаты, завершение программы, внешние эффекты .
• Трудоемкость и продолжительность устранения неполадок: минимальные . очень высокие; немедленно . очень долгое время;
• Статус обработки: выполнено, проверено, исправление выполняется , возможна повторная проверка , . выполнено

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

Для простоты программные ошибки в процессе обработки ошибок часто делятся только на категории / классы, такие как A, B, C . или 1, 2, 3 . и т. Д., В зависимости от серьезности ошибки, который также включает влияние ошибки и усилия, необходимые для ее исправления. Примеры см. В рекомендациях BITKOM, особенно в приложении.

Последствия ошибок программы

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

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

Воспроизводимость программных ошибок

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

Дальнейшие темы

• Чтобы узнать о принципе доставки «незрелого» программного обеспечения, см. Принцип банана # Банановая посуда .

литература

• Уильям Э. Перри: Тестирование программного обеспечения. Mitp-Verlag, Бонн 2002, ISBN 3-8266-0887-9 .
• Эльфрида Дастин, Джефф Рашка, Джон Пол: Автоматическое тестирование программного обеспечения.Порядок действий, обращение и исполнение. Springer, Berlin et al. 2001, ISBN 3-540-67639-2 .
• Джем Канер, Джек Фальк, Хунг Куок Нгуен: Тестирование компьютерного программного обеспечения. 2-е издание. John Wiley & Sons, Нью-Йорк, штат Нью-Йорк и др. 1999, ISBN 0-471-35846-0 .

веб ссылки

Викисловарь: ошибки — объяснение значений, происхождение слов, синонимы, переводы