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

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
  • Управление конфигурацией
  • Документация
  • Гарантия качества программного обеспечения
  • Управление проектом
  • Пользовательский опыт
Практики
  • ATDD
  • BDD
  • CCO
  • CI
  • CD
  • DDD
  • ПП
  • SBE
  • Встаньте
  • TDD
Инструменты
  • Компилятор
  • Отладчик
  • Профайлер
  • Дизайнер графического интерфейса
  • Моделирование
  • IDE
  • Автоматизация сборки
  • Автоматизация выпуска
  • Инфраструктура как код
  • Тестирование
Стандарты и свод знаний
  • БАБОК
  • CMMI
  • Стандарты IEEE
  • ISO 9001
  • Стандарты ISO / IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
Глоссарии
  • Искусственный интеллект
  • Информатика
  • Электротехника и электроника
Контуры
  • План разработки программного обеспечения
  • v
  • т
  • е

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

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

Некоторые программные ошибки связаны с катастрофами. Ошибки в коде, который управлял аппаратом лучевой терапии Therac-25, несли прямую ответственность за смерть пациентов в 1980-х годах. В 1996 году Европейское космическое агентство «s US $ 1000000000 прототип Ariane 5 ракеты должны были быть уничтожены менее чем через минуту после запуска из - за ошибки в руководство компьютерной программы на борту. В июне 1994 года вертолет Chinook Королевских ВВС врезался в Малл-оф-Кинтайр , в результате чего погибло 29 человек. Первоначально это было сочтено ошибкой пилота, но расследование Computer Weekly убедило Палату лордов запрос о том, что это могло быть вызвано ошибкой программного обеспечения в компьютере управления двигателем самолета . [2]

В 2002 году исследование по заказу США Департамент торговли «ы Национального института стандартов и технологий пришли к выводу , что«ошибки в программном обеспечении, или ошибки, настолько распространены и так вредны , что они стоят в экономике США оценивается в 59 $ миллиардов долларов в год, или около 0,6 процентов от валового внутреннего продукта ». [3]

История [ править ]

Основная статья: Ошибка (инженерия)

Среднеанглийское слово bugge является основой терминов « bugbear » и « bugaboo » как терминов, используемых для обозначения монстра. [4]

Термин «ошибка» для описания дефектов был частью инженерного жаргона с 1870-х годов и предшествовал электронным компьютерам и компьютерному программному обеспечению; возможно, изначально он использовался в аппаратной инженерии для описания механических неисправностей. Например, Томас Эдисон написал следующие слова в письме своему партнеру в 1878 году: [5]

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

Baffle Ball , первая механическая игра в пинбол , была объявлена ​​«свободной от ошибок» в 1931 году. [7] Проблемы с военным снаряжением во время Второй мировой войны назывались ошибками (или глюками ). [8] В книге, опубликованной в 1942 году, Луиза Дикинсон Рич , говоря о механизированной машине для резки льда , сказала: «Пиление льда было приостановлено до тех пор, пока не появится создатель, чтобы вытащить насекомых из своей любимой». [9]

Айзек Азимов использовал термин «ошибка» для обозначения проблем с роботом в своем рассказе « Поймай этого кролика », опубликованном в 1944 году.

Страница из журнала электромеханического компьютера Harvard Mark II с изображением мертвой бабочки, удаленной с устройства.

Термин «ошибка» использовался в сообщении пионера компьютеров Грейс Хоппер , которая опубликовала причину неисправности в одном из первых электромеханических компьютеров. [10] Типичная версия этой истории:

В 1946 году, когда Хоппер была освобождена от действующей службы, она поступила на Гарвардский факультет в вычислительную лабораторию, где продолжила свою работу над Mark II и Mark III . Операторы связали ошибку в Mark II с мотыльком, застрявшим в реле, придумав термин « ошибка» . Этот баг был аккуратно удален и записан в журнал. Исходя из первой ошибки, сегодня мы называем ошибки или сбои в программе ошибкой . [11]

Хоппер не нашла ошибки, как она с готовностью признала. Дата в журнале регистрации была 9 сентября 1947 года. [12] [13] [14] Операторы, которые нашли его, в том числе Уильям «Билл» Берк, позже из Лаборатории военно-морского оружия , Дальгрен, Вирджиния , [15] были знакомы. с инженерным термином и забавно сохранил насекомое с пометкой «Первый реальный случай обнаружения ошибки». Хоппер любил пересказывать эту историю. [16] Этот дневник с прикрепленным к нему мотыльком является частью коллекции Смитсоновского национального музея американской истории . [13]

Родственный термин « отладка » также , как представляется , предшествует его использование при вычислении: Оксфордский словарь английского языка " этимология s слова содержит аттестацию с 1945 года, в контексте авиационных двигателей. [17]

Концепция , что программное обеспечение может содержать ошибки даты назад к 1843 примечаниями Ады Лавлейс на аналитическом двигателе , в котором она говорит о возможности программы «карты» для Чарльза Бэббиджа «s аналитическая система является ошибочным:

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

Отчет "Ошибки в системе" [ править ]

Институт открытых технологий, управляемый группой New America, [18] выпустил отчет «Ошибки в системе» в августе 2016 года, в котором говорится, что политики США должны провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». [19] Один из авторов отчета сказал, что Конгресс не сделал достаточно для устранения уязвимости киберпрограмм, даже несмотря на то, что Конгресс принял ряд законопроектов, направленных на борьбу с более серьезной проблемой кибербезопасности. [19]

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

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

Терминология [ править ]

Хотя термин «ошибка» используется для описания ошибок программного обеспечения, многие считают, что от него следует отказаться. Один аргумент состоит в том, что слово «ошибка» не связано с тем, что проблема была вызвана человеком, и вместо этого подразумевает, что дефект возник сам по себе, что привело к необходимости отказаться от термина «ошибка» в пользу таких терминов, как «дефект» с ограниченным успехом. [20] С 1970-х годов Гэри Килдалл с некоторой юмором предложил использовать термин «грубая ошибка». [21] [22]

В программной инженерии метаморфизм ошибки (от греческого meta = «изменение», morph = «форма») относится к развитию дефекта на заключительном этапе развертывания программного обеспечения. Преобразование «ошибки», совершенной аналитиком на ранних стадиях жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительной стадии цикла, было названо «метаморфизмом ошибки». [23]

Различные стадии «ошибки» во всем цикле могут быть описаны как «ошибки», «аномалии», «сбои», «сбои», «ошибки», «исключения», «сбои», «сбои», «ошибки». , «дефекты», «инциденты» или «побочные эффекты». [23]

Профилактика [ править ]

Индустрия программного обеспечения приложила много усилий для сокращения количества ошибок. [24] [25] К ним относятся:

Типографические ошибки [ править ]

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

Методологии разработки [ править ]

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

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

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

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

Разработка с открытым исходным кодом позволяет любому исследовать исходный код. Школа мысли, популяризированная Эриком С. Реймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало ошибок или не иметь их совсем, чем другое программное обеспечение, потому что «при достаточном внимании к ним все ошибки мелкие». [26] Это утверждение, однако, оспаривается: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малоизученном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не так». не означает, что они обладают достаточной квалификацией для этого ". [27] Пример того, что на самом деле произошло случайно,была уязвимость OpenSSL 2008 года в Debian.

Поддержка языков программирования [ править ]

Языки программирования включают функции, помогающие предотвратить ошибки, такие как системы статических типов , ограниченные пространства имен и модульное программирование . Например, когда программист пишет (псевдокод) LET REAL_VALUE PI = "THREE AND A BIT", хотя это может быть синтаксически правильным, код не проходит проверку типа . Скомпилированные языки улавливают это без необходимости запускать программу. Интерпретируемые языки выявляют такие ошибки во время выполнения. Некоторые языки намеренно исключают функции, которые легко приводят к ошибкам, за счет более низкой производительности: общий принцип заключается в том, что почти всегда лучше писать более простой и медленный код, чем непостижимый код, который выполняется немного быстрее, особенно с учетом затрат на обслуживание.существенен. Например, язык программирования Java не поддерживает арифметику указателей ; реализации некоторых языков, таких как Паскаль и языки сценариев, часто имеют проверку границ массивов во время выполнения , по крайней мере, в отладочной сборке.

Анализ кода [ править ]

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

Инструменты [ править ]

Инструменты для мониторинга производительности программного обеспечения во время его работы, либо специально для поиска проблем, таких как узкие места, либо для обеспечения уверенности в правильной работе, могут быть встроены в код явно (возможно, так же просто, как утверждение PRINT "I AM HERE") или предоставлены как инструменты. Часто бывает неожиданно обнаружить, где большую часть времени занимает фрагмент кода, и это удаление предположений может привести к переписыванию кода.

Тестирование [ править ]

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

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

Отладка [ править ]

Типичная история ошибок ( данные проекта GNU Classpath ). Новая ошибка, отправленная пользователем, не подтверждена. Как только он был воспроизведен разработчиком, это подтвержденная ошибка. Подтвержденные ошибки позже исправлены . Ошибки, относящиеся к другим категориям (невоспроизводимые, не будут исправлены и т. Д.), Обычно в меньшинстве.
Основная статья: Отладка

Поиск и исправление ошибок или отладка - важная часть компьютерного программирования . Морис Уилкс , один из первых пионеров вычислительной техники, описал в конце 1940-х годов свое осознание того, что большую часть оставшейся жизни он потратит на поиск ошибок в собственных программах. [28]

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

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

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

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

Некоторые ошибки обнаруживаются при вводе данных, которые программисту может быть трудно воссоздать. Одной из причин смерти радиационной машины Therac-25 была ошибка (в частности, состояние гонки ), которая возникала только тогда, когда оператор машины очень быстро вводил план лечения; На то, чтобы это сделать, потребовались дни практики, поэтому ошибка не проявлялась ни при тестировании, ни при попытке производителя воспроизвести ее. Другие ошибки могут перестать появляться всякий раз, когда установка расширяется, чтобы помочь найти ошибку, например, запуск программы с отладчиком; их называют хайзенбагами (шутливо названными в честь принципа неопределенности Гейзенберга ).

С 1990-х годов, особенно после катастрофы с самолетом Ariane 5 Flight 501 , возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода путем абстрактной интерпретации . [29]

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

Оценка ошибок [ править ]

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

  • эталонный тест Сименс
  • ManyBugs [30] - это тест на 185 ошибок C в девяти программах с открытым исходным кодом.
  • Defects4J [31] - это тест на 341 ошибку Java из 5 проектов с открытым исходным кодом. Он содержит соответствующие патчи, которые охватывают различные типы патчей. [32]
  • BEARS [33] - это эталон сбоев непрерывной интеграции при сборке с упором на сбои тестов. Он был создан путем мониторинга сборок из проектов с открытым исходным кодом на Travis CI .

Управление ошибками [ править ]

Управление ошибками включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении - ошибки, запросы на улучшения и даже целые выпуски - обычно отслеживаются и управляются с помощью систем отслеживания ошибок или систем отслеживания проблем . [34] Добавленные элементы могут называться дефектами, заявками, проблемами или, в соответствии с парадигмой гибкой разработки , рассказами и эпосами. Категории могут быть объективными, субъективными или комбинированными, например номер версии , область программного обеспечения, серьезность и приоритет, а также тип проблемы, такой как запрос функции или ошибка.

Серьезность [ править ]

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

Приоритет [ править ]

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

Релизы программного обеспечения [ править ]

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

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

  • Должен быть соблюден крайний срок, а ресурсов недостаточно для исправления всех ошибок к этому сроку. [36]
  • Ошибка уже исправлена ​​в следующем выпуске, и она не является приоритетной.
  • Изменения, необходимые для исправления ошибки, слишком дороги или влияют на слишком много других компонентов, что требует серьезного тестирования.
  • Можно подозревать или знать, что некоторые пользователи полагаются на существующее поведение с ошибками; Предлагаемое исправление может привести к критическому изменению .
  • Проблема в том, что в следующем выпуске будет устаревшим; исправлять это не нужно.
  • Это «не ошибка». Возникло недопонимание между ожидаемым и предполагаемым поведением, когда такое недопонимание не связано с путаницей, возникшей из-за недостатков дизайна или ошибочной документации.

Типы [ править ]

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

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

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

Арифметика [ править ]

  • Деление на ноль .
  • Арифметическое переполнение или потеря значимости .
  • Потеря арифметической точности из-за округления или числовой нестабильности алгоритмов.

Логика [ править ]

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

Синтаксис [ править ]

  • Использование неправильного оператора, например, выполнение присваивания вместо проверки на равенство . Например, в некоторых языках x = 5 установит значение x равным 5, а x == 5 будет проверять, равно ли x в настоящее время 5 или какому-либо другому числу. Интерпретируемые языки допускают сбой такого кода. Скомпилированные языки могут обнаруживать такие ошибки еще до начала тестирования.

Ресурс [ править ]

  • Разыменование нулевого указателя .
  • Использование неинициализированной переменной .
  • Использование в противном случае действительной инструкции для неправильного типа данных (см. Упакованное десятичное / двоично-десятичное число ).
  • Нарушения доступа .
  • Утечки ресурсов, когда конечный системный ресурс (например, память или дескрипторы файлов ) исчерпывается из-за повторного выделения без освобождения.
  • Переполнение буфера , при котором программа пытается сохранить данные за пределами выделенного хранилища. Это может привести, а может и не привести к нарушению доступа или хранилища . Они известны как ошибки безопасности .
  • Чрезмерная рекурсия, которая - хотя и допустима с логической точки зрения - вызывает переполнение стека .
  • Ошибка использования после освобождения, когда указатель используется после того, как система освободила память, на которую он ссылается.
  • Двойная бесплатная ошибка.

Многопоточность [ править ]

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

Взаимодействие [ править ]

  • Неправильное использование API. [37]
  • Неправильная реализация протокола.
  • Неправильное обращение с оборудованием.
  • Неправильные предположения о конкретной платформе.
  • Несовместимые системы. Может показаться, что новый API или протокол связи работают, когда две системы используют разные версии, но могут возникать ошибки, когда функция или функция, реализованная в одной версии, изменяется или отсутствует в другой. В производственных системах, которые должны работать постоянно, отключение всей системы для серьезного обновления может оказаться невозможным, например, в телекоммуникационной отрасли [38] или в Интернете. [39] [40] [41] В этом случае меньшие сегменты большой системы обновляются индивидуально, чтобы минимизировать нарушение работы большой сети. Однако некоторые разделы могут быть пропущены и не обновлены, что может вызвать ошибки совместимости, которые может быть трудно найти и исправить.
  • Неправильные аннотации кода [42]

Работа в команде [ править ]

  • Нераспространяемые обновления; например, программист изменяет myAdd, но забывает изменить mySubtract, который использует тот же алгоритм. Эти ошибки смягчаются философией « Не повторяйся» .
  • Комментарии устарели или неверны: многие программисты считают, что комментарии точно описывают код.
  • Различия между документацией и продуктом.

Последствия [ править ]

Размер и тип ущерба, который может вызвать программная ошибка, естественным образом влияют на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемые космические путешествия или автомобильная безопасность , поскольку недостатки программного обеспечения могут привести к травмам человека или даже смерти, такое программное обеспечение будет подвергаться гораздо более тщательной проверке и контролю качества, чем, например, веб-сайт онлайн-покупок. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, приложение для редактирования фотографий. Технологическому центру NASA Software Assurance удалось снизить количество ошибок до менее 0,1 на 1000 строк кода ( SLOC ).[ необходима цитата ], но это не было сочтено возможным для проектов в деловом мире.

Согласно исследованию НАСА « Сложность программного обеспечения для полета », «исключительно хороший процесс разработки программного обеспечения может снизить количество дефектов до 1 дефекта на 10 000 строк кода». [43]

Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, вложенными в их исправление. В 1978 году Линц и др. показал, что в среднем по проектам 17% усилий по разработке вкладывается в исправление ошибок. [44] Исследование репозиториев GitHub в 2020 году показало, что медиана составляет 20%. [45]

Известные ошибки [ править ]

Основная статья: Список ошибок программного обеспечения

Многие программные ошибки стали широко известными, как правило, из-за их серьезности: примеры включают крушения различных космических и военных самолетов. Возможно, самой известной ошибкой является проблема 2000 года , также известная как ошибка 2000 года, в которой опасались, что мировой экономический коллапс случится в начале 2000 года из-за того, что компьютеры думают, что это был 1900 год. , никаких серьезных проблем не возникло.) Срыв биржевой торговли 2012 года был связан с одной такой несовместимостью между старым API и новым API.

В популярной культуре [ править ]

  • В романе « 2001: Космическая одиссея» 1968 года и соответствующем фильме 1968 года « 2001: Космическая одиссея » бортовой компьютер космического корабля HAL 9000 пытается убить всех членов экипажа. В последующем романе 1982 года, 2010: Одиссея-2 , и сопутствующем фильме 1984 года, 2010 , раскрывается, что это действие было вызвано тем, что компьютер был запрограммирован с двумя конфликтующими целями: полностью раскрыть всю свою информацию и сохранить истинная цель полета секретна от экипажа; этот конфликт привел к тому, что HAL стал параноиком и в конечном итоге стал смертоносным.
  • В английской версии песни Nena 1983 года 99 Luftballons (99 Red Balloons) из-за «ошибок в программном обеспечении» выпуск группы из 99 красных воздушных шаров ошибочно принимается за запуск вражеской ядерной ракеты, что требует эквивалентной реакции на запуск. , что привело к катастрофе.
  • В американской комедии « Офисное пространство» 1999 года трое сотрудников пытаются использовать озабоченность своей компании исправлением компьютерной ошибки 2000 года, заражая компьютерную систему компании вирусом, который отправляет округленные пенни на отдельный банковский счет. Этот план имеет неприятные последствия, поскольку у самого вируса есть собственная ошибка, которая преждевременно отправляет большие суммы денег на счет.
  • 2004 роман Bug , по Эллен Ульмана , о попытке программиста найти неуловимую ошибку в базе данных приложения. [46]
  • Канадский фильм 2008 года « Control Alt Delete» рассказывает о программисте в конце 1999 года, который пытается исправить ошибки в своей компании, связанные с проблемой 2000 года.

См. Также [ править ]

  • Анти-шаблон
  • Программа Bug Bounty
  • Удаление глюков
  • ISO / IEC 9126 , в котором ошибка классифицируется как дефект или несоответствие.
  • Классификация ортогональных дефектов
  • Проблема с ипподромом
  • Дайджест РИСКОВ
  • Индикатор дефекта программного обеспечения
  • Программная регрессия
  • Программная гниль
  • Автоматическое исправление ошибок

Ссылки [ править ]

  1. ^ Миттал, Варун; Адитья, Шивам (1 января 2015 г.). «Последние разработки в области исправления ошибок» . Процедуры информатики . Международная конференция по компьютерам, коммуникациям и конвергенции (ICCC 2015). 48 : 288–297. DOI : 10.1016 / j.procs.2015.04.184 . ISSN  1877-0509 .
  2. ^ Проф. Саймон Роджерсон . "Катастрофа с вертолетом Чинук" . Ccsr.cse.dmu.ac.uk. Архивировано из оригинала 17 июля 2012 года . Проверено 24 сентября 2012 года .
  3. ^ "Программные ошибки дорого обходятся экономике США" . 10 июня 2009 года. Архивировано 10 июня 2009 года . Проверено 24 сентября 2012 года .CS1 maint: неподходящий URL ( ссылка )
  4. ↑ Сотрудники Computerworld (3 сентября 2011 г.). «Мотылек в машине: Устранение причин« ошибки » » . Компьютерный мир . Архивировано 25 августа 2015 года.
  5. ^ «Знаете ли вы? Эдисон ввел термин« ошибка » » . 1 августа 2013 . Проверено 19 июля 2019 года .
  6. Перейти ↑ Edison to Puskas, 13 ноября 1878 г., документы Эдисона, Национальная лаборатория Эдисона, Служба национальных парков США, Вест-Ориндж, штат Нью-Джерси, цитируется по Hughes, Thomas Parke (1989). Американский генезис: век изобретений и технологического энтузиазма, 1870-1970 . Книги пингвинов. п. 75. ISBN 978-0-14-009741-2.
  7. ^ "Baffle Ball" . База данных Интернет-пинбол. (См. Изображение рекламы в справочной записи)
  8. ^ «Современные авианосцы - результат 20 лет умных экспериментов» . Жизнь . 29 июня 1942 г. с. 25. Архивировано 4 июня 2013 года . Проверено 17 ноября 2011 года .
  9. Перейти ↑ Dickinson Rich, Louise (1942), We Took to the Woods , JB Lippincott Co, p. 93, LCCN 42024308 , OCLC 405243 , заархивировано из оригинала 16 марта 2017 г.  
  10. ^ FCAT НЕТ Test , Харкорт, 18 марта 2008
  11. ^ «Дэнис, Шаррон Энн:« Контр-адмирал Грейс Мюррей Хоппер » » . ei.cs.vt.edu. 16 февраля 1997 . Проверено 31 января 2010 года .
  12. ^ « Ошибка, заархивированная 23 марта 2017 г., на Wayback Machine », The Jargon File , ver. 4.4.7. Проверено 3 июня 2010 года.
  13. ^ a b « Журнал регистрации компьютерных ошибок, архивный 23 марта 2017 г. в Wayback Machine », Национальный музей американской истории, Смитсоновский институт.
  14. ^ " Первая" компьютерная ошибка ", Военно-морской исторический центр. Но обратите внимание, чтокомпьютер Harvard Mark II не был готов до лета 1947 года.
  15. ^ IEEE Annals of the History of Computing, Vol 22 Issue 1, 2000 г.
  16. ^ Джеймс С. Хаггинс. «Первая компьютерная ошибка» . Jamesshuggins.com. Архивировано из оригинального 16 августа 2000 года . Проверено 24 сентября 2012 года .
  17. ^ Журнал Королевского авиационного общества . 49, 183/2, 1945 «Он проходил ... через этап типовых и летных испытаний и« отладку »...»
  18. ^ Уилсон, Энди; Шульман, Росс; Банкстон, Кевин; Герр, Трей. «Ошибки в системе» (PDF) . Институт открытой политики . Архивировано 21 сентября 2016 года (PDF) . Проверено 22 августа 2016 года .
  19. ^ a b c d Розенс, Трейси (12 августа 2016 г.). «Киберреформы необходимы для улучшения обнаружения и раскрытия ошибок программного обеспечения: отчет New America - Homeland Preparedness News» . Проверено 23 августа 2016 года .
  20. ^ "Новости в архиве SEI 1999" . cmu.edu . Архивировано 26 мая 2013 года.
  21. ^ Shustek, Len (2 августа 2016). «Его собственными словами: Гэри Килдалл» . Замечательные люди . Музей истории компьютеров . Архивировано 17 декабря 2016 года.
  22. ^ Kildall, Гэри Арлен (2 августа 2016) [1993]. Килдалл, Скотт ; Килдалл, Кристин (ред.). «Компьютерные связи: люди, места и события в развитии индустрии персональных компьютеров» (Рукопись, часть 1). Семья Килдалл: 14–15. Архивировано 17 ноября 2016 года . Проверено 17 ноября, 2016 . Цитировать журнал требует |journal=( помощь )
  23. ^ a b «Опыт тестирования: т. е .: журнал для профессиональных тестировщиков». Опыт тестирования . Германия: опыт тестирования: 42. Март 2012 г. ISSN 1866-5705 .  (требуется подписка)
  24. ^ Хейзинга, Дорота; Колава, Адам (2007). Автоматическое предотвращение дефектов: передовой опыт управления программным обеспечением . Пресса компьютерного общества Wiley-IEEE. п. 426. ISBN. 978-0-470-04212-0. Архивировано 25 апреля 2012 года.
  25. ^ Макдональд, Марк; Муссон, Роберт; Смит, Росс (2007). Практическое руководство по предотвращению дефектов . Microsoft Press. п. 480 . ISBN 978-0-7356-2253-1.
  26. ↑ «Выпускать раньше, выпускать часто». Архивировано 14 мая 2011 года в Wayback Machine , Эрик С. Реймонд , Собор и базар.
  27. ^ "Wide Open Source" Архивировано 29 сентября 2007 г., в Wayback Machine , Элиас Леви , SecurityFocus , 17 апреля 2000 г.
  28. ^ Цитаты Мориса Уилкса
  29. ^ "История PolySpace Technologies" . christele.faure.pagesperso-orange.fr . Проверено 1 августа 2019 года .
  30. ^ Ле Гуэ, Клэр; Хольтшульте, Нил; Смит, Эдвард К .; Брун, Юрий; Деванбу, Премкумар; Форрест, Стефани; Веймер, Уэстли (2015). «Тесты ManyBugs и IntroClass для автоматического восстановления программ на языке C» . IEEE Transactions по разработке программного обеспечения . 41 (12): 1236–1256. DOI : 10.1109 / TSE.2015.2454513 . ISSN 0098-5589 . 
  31. ^ Просто, Рене; Джалали, Дариуш; Эрнст, Майкл Д. (2014). «Defects4J: база данных существующих неисправностей, позволяющая проводить контролируемое тестирование программ Java». Материалы Международного симпозиума по тестированию и анализу программного обеспечения 2014 г. - ISSTA 2014 . С. 437–440. CiteSeerX 10.1.1.646.3086 . DOI : 10.1145 / 2610384.2628055 . ISBN  9781450326452. S2CID  12796895 .
  32. ^ Собрейра, Виктор; Дюрье, Томас; Мадейраль, Фернанда; Монперрус, Мартин; де Алмейда Майя, Марсело (2018). «Анализ набора данных об ошибках: анатомия 395 патчей от Defects4J». 2018 25-я Международная конференция по анализу, эволюции и реинжинирингу программного обеспечения (SANER), IEEE . С. 130–140. arXiv : 1801.06393 . DOI : 10,1109 / SANER.2018.8330203 . ISBN 978-1-5386-4969-5. S2CID  4607810 .
  33. ^ Madeiral Фернанда; Урли, Саймон; Майя, Марсело; Монперрус, Мартин; Майя, Марсело А. (2019). "BEARS: расширяемый тест на ошибки Java для исследований автоматического исправления программ". 2019 IEEE 26 -я Международная конференция по разработке программного обеспечения анализа, эволюции и реинжинирингу (Санер) . С. 468–478. arXiv : 1901.06024 . DOI : 10,1109 / SANER.2019.8667991 . ISBN 978-1-7281-0591-8. S2CID  58028949 .
  34. ↑ Аллен, Митч (май – июнь 2002 г.). «Основы отслеживания ошибок: руководство для новичков по созданию отчетов и отслеживанию дефектов» . Журнал "Тестирование программного обеспечения и инженерия качества" . Vol. 4 шт. 3. С. 20–24 . Проверено 19 декабря 2017 года .
  35. ^ «5.3. Анатомия ошибки» . bugzilla.org . Архивировано 23 мая 2013 года.
  36. ^ "Новое поколение 1996 Лексикон от А до Я: Выпуск Slipstream". Следующее поколение . № 15. Imagine Media . Март 1996. с. 41.
  37. ^ Монперрус, Мартин; Брух, Марсель; Мезини, Мира (2010). «Обнаружение отсутствующих вызовов методов в объектно-ориентированном программном обеспечении» . ECOOP 2010 - Объектно-ориентированное программирование (PDF) . Конспект лекций по информатике. 6183 . С. 2–25. DOI : 10.1007 / 978-3-642-14107-2_2 . ISBN  978-3-642-14106-5. S2CID  16724498 .
  38. ^ Kimbler, К. (1998). Характеристика взаимодействия в области электросвязи и программного обеспечения систем V . IOS Press. п. 8. ISBN 978-90-5199-431-5.
  39. ^ Сайед, Махбабер Рахман (1 июля 2001). Мультимедийные сети: технологии, управление и приложения: технологии, управление и приложения . Idea Group Inc (IGI). п. 398. ISBN 978-1-59140-005-9.
  40. ^ Ву, Чван-Хва (Джон); Ирвин, Дж. Дэвид (19 апреля 2016 г.). Введение в компьютерные сети и кибербезопасность . CRC Press. п. 500. ISBN 978-1-4665-7214-0.
  41. ^ RFC 1263: Цитата «Расширения TCP считаются вредными»: «время распространения новой версии протокола на все хосты может быть довольно долгим (фактически навсегда). ... Если есть малейшая несовместимость между старой и новой версиями , может возникнуть хаос ".
  42. ^ Ю, Чжунсин; Бай, Ченган; Сейнтюрье, Лайонел; Монперрус, Мартин (2019). «Описание использования, развития и влияния аннотаций Java на практике» . IEEE Transactions по разработке программного обеспечения : 1. arXiv : 1805.01965 . DOI : 10.1109 / TSE.2019.2910516 . S2CID 102351817 . 
  43. ^ Дворжак, Дэниел Л. 1 Исследование НАСА по сложности программного обеспечения полета .
  44. ^ Lientz, BP; Swanson, EB; Томпкинс, GE (1978). «Характеристики сопровождения прикладного программного обеспечения». Коммуникации ACM . 21 (6): 466–471. DOI : 10.1145 / 359511.359522 . S2CID 14950091 . 
  45. ^ Амит, Идан; Фейтельсон, Дрор Г. (2020). «Метрика качества корректирующего кода вероятности». arXiv : 2007.10912 [ cs.SE ].
  46. ^ Ульман, Эллен (2004). Ошибка . Пикадор . ISBN 978-1-250-00249-5.

Внешние ссылки [ править ]

  • " Common Weakness Enumeration " - экспертная веб-страница, посвященная ошибкам, на NIST.gov.
  • Тип ошибки Джима Грея - еще один тип ошибки
  • Изображение «первой компьютерной ошибки» на Wayback Machine (архивировано 12 января 2015 г.)
  • « Первая компьютерная ошибка! » - электронное письмо от 1981 года об ошибке адмирала Хоппера.
  • « На пути к пониманию ошибок компилятора в GCC и LLVM ». Исследование ошибок в компиляторах 2016 г.