Программная ошибка
| Часть серии о |
| Разработка программного обеспечения |
|---|
— Программная ошибка это ошибка в компьютерном программном обеспечении .
с Компьютерную программу множеством или серьезных ошибок можно назвать ошибочной .
Последствия программной ошибки варьируются от незначительных (например, слово с ошибкой в пользовательском интерфейсе ) до серьезных (например, частые сбои ).
Ошибки программного обеспечения были связаны с катастрофами. Программные ошибки в Therac-25 аппарате лучевой терапии были прямой причиной смертности пациентов в 1980-х годах. В 1996 году прототип ракеты Ariane 5 Европейского космического агентства стоимостью 1 миллиард долларов США был уничтожен менее чем через минуту после запуска из-за ошибки в бортовой компьютерной программе наведения. [1] В 1994 году разбился вертолет Королевских ВВС «Чинук» , в результате чего погибло 29 человек; Первоначально в этом обвиняли ошибку пилота, но позже было решено, что это произошло из-за ошибки программного обеспечения в компьютере управления двигателем . [2] начала XXI века Программное обеспечение с ошибками стало причиной скандала в Британском почтовом отделении . [3]
В 2002 году исследование, проведенное по заказу торговли Министерства Национального института стандартов и технологий США , пришло к выводу, что «ошибки или ошибки в программном обеспечении настолько распространены и настолько вредны, что они обходятся экономике США примерно в 59 миллиардов долларов в год, или около 0,6 миллиарда долларов США». процентов валового внутреннего продукта». [4]
С 1950-х годов некоторые компьютерные системы были разработаны для обнаружения или автоматического исправления различных ошибок программного обеспечения во время операций.
История [ править ]
Терминология [ править ]
Метаморфизм ошибки (от греческого Meta = «изменение», morph = «форма») относится к развитию дефекта на заключительном этапе развертывания программного обеспечения. Трансформация «ошибки», допущенной аналитиком на ранних этапах жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительном этапе цикла, получила название «метаморфизм ошибки». [5]
Различные этапы ошибки в цикле разработки можно охарактеризовать как ошибку, [6] : 31 аномалия, [6] : 10 вина, [6] : 31 отказ, [6] : 31 ошибка, [6] : 31 исключение, [6] : 31 крушение, [6] : 22 глюк, ошибка, [6] : 14 дефект, инцидент, [6] : 39 или побочный эффект.
Споры [ править ]
Иногда использование ошибки для описания поведения программного обеспечения является спорным из-за восприятия. Некоторые предлагают отказаться от этого термина; заменен с дефектом или ошибкой .
Некоторые утверждают, что ошибка подразумевает, что дефект возник сам по себе, и настаивают на использовании дефекта вместо этого, поскольку он более четко указывает на то, что дефект возник по вине человека. [7]
Некоторые утверждают, что ошибка может быть использована для сокрытия преднамеренного дизайнерского решения. В 2011 году, после проверки со стороны сенатора США Эла Франкена за запись и хранение местонахождения пользователей в незашифрованных файлах, [8] Apple назвала такое поведение ошибкой. Однако Джастин Брукман из Центра демократии и технологий прямо оспорил это представление, заявив: «Я рад, что они исправляют то, что они называют ошибками, но я возражаю против их решительного отрицания того, что они отслеживают пользователей». [9]
Профилактика [ править ]
Предотвращение ошибок как можно раньше в процессе разработки программного обеспечения является целью инвестиций и инноваций. [10] [11]
Языковая поддержка [ править ]
Новые языки программирования, как правило, разрабатываются так, чтобы предотвращать распространенные ошибки, возникающие из-за уязвимостей существующих языков. Уроки, извлеченные из старых языков, таких как BASIC и C, используются при разработке более поздних языков, таких как C# и Rust .
Языки могут включать такие функции, как система статических типов , ограниченные пространства имен и модульное программирование . Например, для типизированного компилируемого языка (например, C ):
float num = "THREE AND A BIT";
синтаксически правильно, но не проходит проверку типа, поскольку правая часть, строка, не может быть присвоена переменной с плавающей запятой. Сбой компиляции — принудительное исправление этого дефекта до возобновления разработки. При использовании интерпретируемого языка сбой произойдет не раньше, чем во время выполнения.
Некоторые языки исключают функции, которые легко приводят к ошибкам, за счет снижения производительности — принцип заключается в том, что обычно лучше писать более простой, медленный и правильный код, чем сложный код с ошибками. Например, Java не поддерживает арифметику указателей , которая обычно выполняется быстро, но считается опасной; относительно легко вызвать серьезную ошибку.
Некоторые языки включают функции, которые добавляют накладные расходы во время выполнения, чтобы предотвратить некоторые ошибки. Например, многие языки включают проверку границ во время выполнения и способ обработки условий выхода за пределы вместо сбоя.
Компилируемый чем язык позволяет обнаруживать некоторые опечатки (например, идентификатор с ошибкой) перед выполнением, что происходит на более ранней стадии процесса разработки программного обеспечения, в случае интерпретируемого языка.
Техники [ править ]
Такие методы программирования, как стиль программирования и защитное программирование, предназначены для предотвращения опечаток.
Например, ошибка может быть вызвана относительно незначительной типографской ошибкой (опечаткой) в коде. Например, этот код выполняет функцию foo только если conditionэто правда.
if (condition) foo();
Но этот код всегда выполняется foo:
if (condition); foo();
Соглашение, которое имеет тенденцию предотвращать эту конкретную проблему, заключается в необходимости использования фигурных скобок для блока, даже если он состоит только из одной строки.
if (condition) {
foo();
}
Обеспечение соблюдения соглашений может осуществляться вручную (например, посредством проверки кода ) или с помощью автоматизированных инструментов.
Спецификация [ править ]
Некоторые утверждают, что написание спецификации программы , описывающей поведение программы, может предотвратить ошибки.
Некоторые утверждают, что формальные спецификации непрактичны для чего-либо, кроме самых коротких программ, из-за проблем комбинаторного взрыва и неопределенности .
Тестирование программного обеспечения [ править ]
Одной из целей тестирования программного обеспечения является поиск ошибок.
Измерения во время тестирования могут дать оценку количества вероятных оставшихся ошибок. Это становится тем более надежным, чем дольше продукт тестируется и разрабатывается. [ нужна ссылка ]
Agile-практики [ править ]
Гибкая разработка программного обеспечения может включать частые выпуски программного обеспечения с относительно небольшими изменениями. Дефекты выявляются по отзывам пользователей.
При разработке через тестирование (TDD) модульные тесты пишутся во время написания производственного кода, и рабочий код не считается завершенным, пока все тесты не завершатся успешно.
Статический анализ [ править ]
Инструменты статического анализа кода помогают разработчикам, проверяя текст программы за пределами возможностей компилятора, чтобы выявить потенциальные проблемы. Хотя в целом проблема обнаружения всех ошибок программирования с учетом спецификации неразрешима (см. « Проблему остановки »), эти инструменты используют тот факт, что программисты-люди склонны часто совершать определенные виды простых ошибок при написании программного обеспечения.
Инструментарий [ править ]
Инструменты для мониторинга производительности программного обеспечения во время его работы, либо специально для обнаружения проблем, таких как узкие места , либо для обеспечения уверенности в правильной работе, могут быть встроены в код явно (возможно, так же просто, как утверждение, говорящее PRINT "I AM HERE") или предоставляются в качестве инструментов. Зачастую бывает неожиданно обнаружить, какой фрагмент кода занимает большую часть времени, и такое исключение предположений может привести к переписыванию кода.
Открытый исходный код [ править ]
Разработка с открытым исходным кодом позволяет любому изучить исходный код. Школа мысли, популяризированная Эриком С. Рэймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало ошибок или вообще не содержать их, чем другое программное обеспечение, потому что «при достаточном количестве глаз все ошибки неглубоки». [12] Однако это утверждение оспаривается: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малопонятном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не значит, что они квалифицированы для этого». [13] Примером ошибки программного обеспечения с открытым исходным кодом была уязвимость OpenSSL 2008 года в Debian .
Отладка [ править ]
Отладка может составлять значительную часть жизненного цикла разработки программного обеспечения . Морис Уилкс , пионер вычислительной техники, описал свое осознание в конце 1940-х годов, что «Большую часть оставшейся жизни мне предстояло потратить на поиск ошибок в моих собственных программах». [14]
Программа, известная как отладчик, может помочь программисту найти ошибочный код, исследуя внутреннюю работу программы, например, построчное выполнение кода и просмотр значений переменных.
В качестве альтернативы использованию отладчика код может быть оснащен логикой для вывода отладочной информации для отслеживания выполнения программы и просмотра значений. Вывод обычно осуществляется на консоль , в окно , в файл журнала или на аппаратный выход (например, светодиод ).
Некоторые утверждают, что обнаружение ошибки — это своего рода искусство.
Нередко ошибка в одном разделе программы приводит к сбоям в другом разделе. [ нужна ссылка ] что затрудняет отслеживание в явно несвязанной части системы. Например, ошибка в процедуре рендеринга графики , приводящая к сбою процедуры файлового ввода-вывода .
Иногда самая сложная часть отладки — это поиск причины ошибки. После обнаружения исправить проблему иногда легко, если не тривиально.
Иногда ошибка не является изолированным недостатком, а представляет собой ошибку мышления или планирования со стороны программистов. Часто такая логическая ошибка требует переделки или переписывания раздела программы.
Некоторые утверждают, что в рамках проверки кода пошаговое выполнение кода и представление или расшифровка процесса выполнения часто могут обнаруживать ошибки, даже не воспроизводя ошибку как таковую.
Обычно первым шагом в обнаружении ошибки является ее надежное воспроизведение. Если не удается воспроизвести проблему, программист не может найти причину ошибки и, следовательно, не может ее исправить.
Некоторые ошибки обнаруживаются при вводе данных, которые программисту может быть сложно воссоздать. Одной из причин гибели радиационной машины Therac-25 была ошибка (в частности, состояние гонки ), которая возникала только тогда, когда оператор машины очень быстро вводил план лечения; чтобы научиться это делать, потребовались несколько дней практики, поэтому ошибка не проявилась ни при тестировании, ни когда производитель пытался ее воспроизвести. Другие ошибки могут перестать возникать всякий раз, когда установка дополняется для поиска ошибки, например, при запуске программы с помощью отладчика; их называют ошибками Гейзенберга (в шутку названными в честь принципа неопределенности Гейзенберга ).
С 1990-х годов, особенно после катастрофы рейса 501 Ariane 5 , возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода посредством абстрактной интерпретации . [15]
Часто ошибки возникают во время кодирования, но ошибка в проектной документации может стать причиной ошибки. В некоторых случаях изменения в коде могут устранить проблему, даже если код больше не соответствует документации.
Во встроенных системах программное обеспечение часто модифицируется для устранения аппаратной ошибки, поскольку это дешевле, чем модификация оборудования.
Управление [ править ]
Ошибки управляются с помощью таких действий, как документирование, категоризация, назначение, воспроизведение, исправление и выпуск исправленного кода.
Инструменты часто используются для отслеживания ошибок и других проблем с программным обеспечением. Обычно разные инструменты используются командой разработчиков программного обеспечения для отслеживания своей рабочей нагрузки , а не службой поддержки клиентов для отслеживания отзывов пользователей . [16]
Отслеживаемый элемент часто называют ошибкой , дефектом , заявкой , проблемой , функцией , а для гибкой разработки программного обеспечения — историей или эпопеей . Элементы часто классифицируются по таким аспектам, как серьезность, приоритет и номер версии .
В процессе, который иногда называют сортировкой , для каждой ошибки делается выбор относительно того, исправлять ли ее и когда, на основе такой информации, как серьезность и приоритет ошибки, а также внешних факторов, таких как графики разработки. Сортировка обычно не включает расследование причин. Сортировка может происходить регулярно. Сортировка обычно состоит из проверки новых ошибок после предыдущей сортировки и, возможно, всех открытых ошибок. В число участников могут входить менеджер проекта, менеджер по разработке, менеджер по тестированию, менеджер по сборке и технические эксперты. [17] [18]
Серьезность [ править ]
Серьезность — это мера воздействия ошибки. [19] Это воздействие может выражаться в потере данных, финансовых потерях, потере репутации и напрасной трате усилий. Уровни серьезности не стандартизированы, но различаются в зависимости от контекста, например, от отрасли и инструмента отслеживания. Например, сбой в видеоигре имеет иные последствия, чем сбой на банковском сервере. Уровнями серьезности могут быть сбой или зависание , отсутствие обходного решения (пользователь не может выполнить задачу), наличие обходного решения (пользователь все еще может выполнить задачу), визуальный дефект (например, орфографическая ошибка) или ошибка документации . Другой пример набора степеней серьезности: критический , высокий , низкий , блокирующий , тривиальный . [20] Серьезность ошибки может быть отдельной категорией по сравнению с приоритетом ее исправления, или же обе категории могут определяться количественно и управляться отдельно.
Ошибка, достаточно серьезная, чтобы задержать выпуск продукта, называется пробкой показа . [21] [22]
Приоритет [ править ]
Приоритет описывает важность устранения ошибки по отношению к другим ошибкам. Приоритеты могут быть числовыми, например от 1 до 5, или именованными, например критический , высокий , низкий и отложенный . Значения могут быть аналогичны или идентичны рейтингам серьезности, хотя приоритет является другим аспектом.
Приоритетом может быть сочетание серьезности ошибки и уровня усилий по ее исправлению. Ошибка с низкой серьезностью, но которую легко исправить, может получить более высокий приоритет, чем ошибка со средней серьезностью, для исправления которой требуется значительно больше усилий.
Патч [ править ]
Ошибки достаточно высокого приоритета могут потребовать специального выпуска, который иногда называют патчем .
Технический выпуск [ править ]
Выпуск программного обеспечения, в котором особое внимание уделяется исправлению ошибок, можно назвать выпуском сопровождения , чтобы отличить его от выпуска, в котором особое внимание уделяется новым функциям или другим изменениям.
Известная проблема [ править ]
Обычной практикой является выпуск программного обеспечения с известными ошибками низкого приоритета или другими проблемами. Возможные причины включают, помимо прочего:
- Срок должен быть соблюден, а ресурсов недостаточно, чтобы исправить все ошибки к сроку. [23]
- Ошибка уже исправлена в следующем выпуске и не имеет высокого приоритета.
- Изменения, необходимые для исправления ошибки, являются слишком дорогостоящими или затрагивают слишком много других компонентов, что требует серьезного тестирования.
- Можно подозревать или знать, что некоторые пользователи полагаются на существующее ошибочное поведение; предлагаемое исправление может привести к критическим изменениям
- Проблема заключается в области, которая устареет с предстоящим выпуском; исправлять это ненужно
- «Это не баг, это фича» [24] Существует недопонимание между ожидаемым и фактическим поведением или недокументированной функцией.
Последствия [ править ]
Объем и тип ущерба, который может нанести ошибка в программном обеспечении, влияет на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемый космический полет , авиация , ядерная энергетика , здравоохранение , общественный транспорт или автомобильная безопасность , поскольку недостатки программного обеспечения могут привести к травмам или даже смерти человека, такое программное обеспечение будет подвергаться гораздо большему вниманию и контролю качества, чем, например, сайт интернет-магазинов. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, приложение для редактирования фотографий.
Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, затраченными на их исправление. В 1978 году Лиенц и др. показало, что в среднем 17 процентов усилий по разработке вкладывают в исправление ошибок. [25] Исследование репозиториев GitHub в 2020 году показало, что медиана составляет 20%. [26]
Стоимость [ править ]
НАСА В 1994 году Центру космических полетов имени Годдарда удалось снизить среднее количество ошибок с 4,5 на 1000 строк кода ( SLOC ) до 1 на 1000 SLOC. [27]
Другое исследование, проведенное в 1990 году, показало, что исключительно хорошие процессы разработки программного обеспечения могут обеспечить уровень неудач при развертывании всего 0,1 на 1000 SLOC. [28] Эта цифра повторяется в такой литературе, как «Code Complete » Стива МакКоннелла , [29] и исследование НАСА по сложности программного обеспечения для полетов . [30] Некоторые проекты даже достигли нулевых дефектов: прошивка пишущей машинки IBM Wheelwriter , состоящая из 63 000 SLOC, и программное обеспечение Space Shuttle с 500 000 SLOC. [28]
Тест [ править ]
Чтобы облегчить воспроизводимые исследования по тестированию и отладке, исследователи используют тщательно подобранные тесты ошибок:
- эталон Сименс
- МногиеОшибки [31] является эталоном 185 ошибок C в девяти программах с открытым исходным кодом.
- Дефекты4J [32] представляет собой тест на 341 ошибку Java из 5 проектов с открытым исходным кодом. Он содержит соответствующие патчи, охватывающие различные типы патчей.
Типы [ править ]
Некоторые известные типы ошибок:
Ошибка проектирования [ править ]
Ошибка может быть вызвана недостаточным или неправильным проектированием согласно спецификации. Например, учитывая, что спецификация должна располагать список слов в алфавитном порядке, может возникнуть ошибка проектирования, если в проекте не учитываются символы; что приводит к неправильному алфавитному расположению слов с символами.
Арифметика [ править ]
Числовые операции могут привести к неожиданному выводу, медленной обработке или сбою. [33] Такая ошибка может быть связана с незнанием качеств хранилища данных, таких как потеря точности из-за округления , численно нестабильных алгоритмов, арифметического переполнения и пропускания , или из-за незнания того, как вычисления обрабатываются различными программными кодами. языки, такие как деление на ноль , которое в некоторых языках может вызывать исключение, а в других может возвращать специальное значение, например NaN или бесконечность .
Поток управления [ править ]
Ошибка потока управления , также известная как логическая ошибка, характеризуется кодом, который не завершается с ошибкой, но не имеет ожидаемого поведения, такого как бесконечный цикл , бесконечная рекурсия , неправильное сравнение в условном выражении , например использование неправильного оператора сравнения , и ошибка отклонения на единицу .
Интерфейс [ править ]
- Неправильное использование API.
- Неправильная реализация протокола.
- Неправильное обращение с оборудованием.
- Неверные предположения о конкретной платформе.
- Несовместимые системы. Может показаться, что новый API или протокол связи работает, когда две системы используют разные версии, но могут возникнуть ошибки, когда функция или функция, реализованная в одной версии, изменяется или отсутствует в другой. В производственных системах, которые должны работать непрерывно, остановка всей системы для масштабного обновления может быть невозможна, например, в телекоммуникационной отрасли. [34] или Интернет. [35] [36] [37] В этом случае меньшие сегменты большой системы обновляются индивидуально, чтобы минимизировать сбои в работе большой сети. Однако некоторые разделы могут быть пропущены и не обновлены, что приведет к ошибкам совместимости, которые может быть сложно найти и исправить.
- Неправильные аннотации кода.
Параллельность [ править ]
- Тупик — задача не может продолжаться, пока не завершится вторая, но в то же время вторая не может продолжаться, пока не завершится первая.
- Состояние гонки — несколько одновременных задач конкурируют за ресурсы.
- Ошибки в критических секциях , взаимные исключения и другие особенности параллельной обработки . Время проверки до времени использования (TOCTOU) — это форма незащищенной критической секции.
Ресурсы [ править ]
- Разыменование нулевого указателя .
- Использование неинициализированной переменной .
- Использование в противном случае допустимой инструкции для неправильного типа данных (см. упакованное десятичное / двоично-десятичное число ).
- Нарушения доступа .
- Утечки ресурсов, когда конечный системный ресурс (например, память или дескрипторы файлов ) исчерпывается в результате повторного выделения без освобождения.
- Переполнение буфера , при котором программа пытается сохранить данные за пределами выделенного хранилища. Это может привести или не привести к нарушению доступа или нарушения хранения . Часто это ошибки безопасности .
- Чрезмерная рекурсия, которая, хотя и логически допустима, вызывает переполнение стека .
- Ошибка использования после освобождения, когда указатель используется после того, как система освободила память, на которую он ссылается.
- Двойная бесплатная ошибка.
Синтаксис [ править ]
- Использование неправильного токена , например, выполнение присваивания вместо проверки на равенство . Например, в некоторых языках x=5 устанавливает значение x равным 5, а x==5 проверяет, равно ли x в данный момент 5 или какому-то другому числу. Интерпретируемые языки допускают сбой такого кода. Скомпилированные языки могут обнаружить такие ошибки еще до начала тестирования.
Работа в команде [ править ]
- Нераспространяемые обновления; например, программист меняет «myAdd», но забывает изменить «mySubtract», который использует тот же алгоритм. Эти ошибки смягчаются философией «Не повторяйся» .
- Комментарии устарели или неверны: многие программисты полагают, что комментарии точно описывают код.
- Различия между документацией и продуктом.
В политике [ править ]
Отчет «Ошибки в системе» [ править ]
Институт открытых технологий, которым управляет группа New America , [38] в августе 2016 года опубликовала отчет «Ошибки в системе», в котором говорится, что политикам США следует провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». [39] Один из авторов отчета заявил, что Конгресс недостаточно сделал для решения проблемы уязвимости киберпрограммного обеспечения, хотя Конгресс принял ряд законопроектов по борьбе с более широкой проблемой кибербезопасности. [39]
Правительственные исследователи, компании и эксперты по кибербезопасности — это люди, которые обычно обнаруживают недостатки программного обеспечения. В докладе содержится призыв к реформированию законов о компьютерной преступности и авторском праве. [39]
В докладе говорится, что Закон о компьютерном мошенничестве и злоупотреблениях, Закон об авторском праве в цифровую эпоху и Закон о конфиденциальности электронных коммуникаций криминализируют и предусматривают гражданско-правовые наказания за действия, которые исследователи безопасности регулярно совершают при проведении законных исследований безопасности, говорится в докладе. [39]
В популярной культуре [ править ]
- В видеоиграх термин « сбой » иногда используется для обозначения ошибки в программном обеспечении. Примером может служить глюк и неофициальный вид покемонов MissingNo.
- И в романе 1968 года « 2001: Космическая одиссея» , и в соответствующем фильме 1968 года « 2001: Космическая одиссея» бортовой компьютер космического корабля HAL 9000 пытается убить всех членов его экипажа. В последующем романе 1982 года « 2010: Одиссея 2» и сопровождающем его фильме 1984 года «2010» раскрывается, что это действие было вызвано тем, что компьютер был запрограммирован на две противоречивые цели: полностью раскрыть всю свою информацию и сохранить истинная цель полета скрыта от экипажа; этот конфликт привел к тому, что HAL стал параноиком и в конечном итоге стал склонен к убийству.
- В английской версии песни Nena 1983 года 99 Luftballons (99 красных воздушных шаров) в результате «ошибок в программном обеспечении» выпуск группы из 99 красных воздушных шаров ошибочно принимается за запуск вражеской ядерной ракеты, что требует эквивалентной реакции на пуск. , что привело к катастрофе.
- В американской комедии 1999 года « Офисное пространство » трое сотрудников пытаются (безуспешно) воспользоваться озабоченностью своей компании компьютерной ошибкой 2000 года, используя компьютерный вирус, который отправляет на их банковский счет округленные доли копейки — давно известный метод, называемый салями . нарезка .
- Роман «Ошибка » Эллен Уллман 2004 года повествует о попытке программиста найти неуловимую ошибку в приложении базы данных. [40]
- Канадский фильм 2008 года «Контроль, альтернатива, удаление» рассказывает о программисте, который в конце 1999 года пытается исправить ошибки в своей компании, связанные с проблемой 2000 года.
См. также [ править ]
- Антипаттерн
- Программа вознаграждения за ошибки
- Удаление глюков
- Аппаратная ошибка
- ISO/IEC 9126 , который классифицирует ошибку как дефект или несоответствие .
- Список ошибок программного обеспечения
- Классификация ортогональных дефектов
- Проблема с гоночной трассой
- Дайджест РИСКИ
- Индикатор дефекта программного обеспечения
- Программная регрессия
- Программное гниение
- Автоматическое исправление ошибок
Ссылки [ править ]
- ^ «Отчет следственной комиссии о сбое рейса 501 ARIANE 5» . Европейское космическое агентство . Отчет комиссии по расследованию Ariane 501 (33–1996). 23 июля 1996 г.
- ^ Саймон Роджерсон (апрель 2002 г.). «Катастрофа вертолета «Чинук»» (PDF) . Журнал ИМИС . 12 (2). Архивировано из оригинала 15 сентября 1993 года . Проверено 27 мая 2024 г.
- ^ «Скандал в почтовом отделении разрушил жизни, сообщает расследование» . Новости Би-би-си . 14 февраля 2022 г.
- ^ «Ошибки в программном обеспечении дорого обходятся экономике США» . 10 июня 2009 года. Архивировано из оригинала 10 июня 2009 года . Проверено 24 сентября 2012 г.
- ^ «Опыт тестирования: т.е. журнал для профессиональных тестировщиков». Опыт тестирования . Германия: опыт тестирования: 42. Март 2012. ISSN 1866-5705 . (требуется подписка)
- ↑ Перейти обратно: Перейти обратно: а б с д и ж г час я 610.12-1990: Стандартный словарь терминологии разработки программного обеспечения IEEE . ИИЭЭ . 31 декабря 1990 г. doi : 10.1109/IEESTD.1990.101064 . ISBN 978-0-7381-0391-4 .
- ^ «Новости ГЭИ за сентябрь 1999 года» . СЭИ Интерактив . 2 (3). Университет Карнеги-Меллона : Институт программной инженерии . 1 сентября 1999 года.
- ^ Грегг Кейзер (21 апреля 2011 г.). «Компания Apple сталкивается с вопросами Конгресса по поводу отслеживания iPhone» . Компьютерный мир .
- ^ Грегг Кейзер (27 апреля 2011 г.). «Apple отрицает отслеживание пользователей iPhone, но обещает перемены» . Компьютерный мир .
- ^ Дорота Хейзинга; Адам Колава (сентябрь 2007 г.). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. ISBN 978-0-470-04212-0 .
- ^ Макдональд, Марк; Муссон, Роберт; Смит, Росс (2007). Практическое руководство по предотвращению дефектов . Майкрософт Пресс. п. 480 . ISBN 978-0-7356-2253-1 .
- ^ «Выпускайте раньше, выпускайте часто». Архивировано 14 мая 2011 года в Wayback Machine , Эрик С. Рэймонд , Собор и базар.
- ^ «Широкий открытый исходный код». Архивировано 29 сентября 2007 г., в Wayback Machine , Элиас Леви , SecurityFocus , 17 апреля 2000 г.
- ^ «Цитаты Мориса Уилкса» . ЦитатаFancy . Проверено 28 апреля 2024 г.
- ^ «История Поликосмических технологий» . christele.faure.pagesperso-orange.fr . Проверено 1 августа 2019 г.
- ^ Аллен, Митч (май – июнь 2002 г.). «Основы отслеживания ошибок: руководство для начинающих по сообщению и отслеживанию дефектов» . Журнал «Тестирование программного обеспечения и инженерия качества» . Том. 4, нет. 3. С. 20–24 . Проверено 19 декабря 2017 г.
- ^ Рекс Блэк (2002). Управление процессом тестирования (2-е изд.). Wiley India Pvt. Ограничено. п. 139. ИСБН 978-8126503131 . Проверено 19 июня 2021 г.
- ^ Крис Вандер Мей (2012). Величие доставки — практические уроки по созданию и запуску выдающегося программного обеспечения, полученные на работе в Google и Amazon . О'Рейли Медиа . стр. 79–81. ISBN 978-1449336608 .
- ^ Сулеймани Нейсиани, Бехзад; Бабамир, Сейед Мортеза; Арицуги, Масаеши (1 октября 2020 г.). «Эффективная модель извлечения функций для повышения производительности проверки при обнаружении повторяющихся отчетов об ошибках в системах сортировки ошибок программного обеспечения» . Информационные и программные технологии . 126 : 106344. doi : 10.1016/j.infsof.2020.106344 . S2CID 219733047 .
- ^ «5.3. Анатомия жука» . bugzilla.org . Архивировано из оригинала 23 мая 2013 года.
- ^ Джонс, Уилбур Д. младший, изд. (1989). «Показать пробку» . Глоссарий: аббревиатуры и термины оборонных закупок (4-е изд.). Форт-Бельвуар, Вирджиния: Министерство обороны, Колледж управления оборонными системами . п. 123. hdl : 2027/mdp.39015061290758 – через Hathitrust.
- ^ Закари, Дж. Паскаль (1994). Шоу-стоппер!: головокружительная гонка за создание Windows NT и следующего поколения в Microsoft . Нью-Йорк: Свободная пресса . п. 158. ИСБН 0029356717 – через archive.org.
- ^ «Лексикон следующего поколения 1996 года от А до Я: выпуск Slipstream». Следующее поколение . № 15. Март 1996. с. 41.
- ^ Карр, Николас (2018). « Это не ошибка, это особенность». Банально – или в самый раз?» . проводной.com .
- ^ Лиенц, БП; Суонсон, Э.Б.; Томпкинс, GE (1978). «Особенности сопровождения прикладного программного обеспечения» . Коммуникации АКМ . 21 (6): 466–471. дои : 10.1145/359511.359522 . S2CID 14950091 .
- ^ Амит, Идан; Фейтельсон, Дрор Г. (2020). «Метрика качества кода вероятности корректирующего фиксации». arXiv : 2007.10912 [ cs.SE ].
- ^ «Обзор лаборатории программной инженерии» (PDF) . Серия лабораторий программной инженерии (SEL-94-005). Декабрь 1994 года.
- ↑ Перейти обратно: Перейти обратно: а б Кобб, Ричард Х.; Миллс, Харлан Д. (1990). «Инженерное программное обеспечение под статистическим контролем качества» . Программное обеспечение IEEE . 7 (6): 46. дои : 10.1109/52.60601 . ISSN 1937-4194 . S2CID 538311 - через Университет Теннесси - Коллекция Харлана Д. Миллса.
- ^ МакКоннелл, Стивен С. (1993). Код завершен . Редмонд, Вашингтон: Microsoft Press. п. 611. ИСБН 978-1556154843 – через archive.org.
(Кобб и Миллс, 1990)
- ^ Джерард Хольцманн (5 марта 2009 г.). «Приложение D – Сложность программного обеспечения» (PDF) . Заключительный отчет: Исследование НАСА сложности программного обеспечения для полетов (Дэниел Л. Дворжак (ред.)) . Программа технического совершенства Управления главного инженера НАСА.
- ^ Ле Гу, Клэр; Холтшульте, Нил; Смит, Эдвард К.; Брун, Юрий; Деванбу, Премкумар; Форрест, Стефани; Веймер, Уэстли (2015). «Бенчмарки ManyBugs и IntroClass для автоматического восстановления программ на языке C» . Транзакции IEEE по разработке программного обеспечения . 41 (12): 1236–1256. дои : 10.1109/TSE.2015.2454513 . ISSN 0098-5589 .
- ^ Просто, Рене; Джалали, Дариуш; Эрнст, Майкл Д. (2014). «Defects4J: база данных существующих неисправностей, позволяющая проводить контролируемые испытания программ Java». Материалы Международного симпозиума по тестированию и анализу программного обеспечения 2014 г. — ISSTA 2014 . стр. 437–440. CiteSeerX 10.1.1.646.3086 . дои : 10.1145/2610384.2628055 . ISBN 9781450326452 . S2CID 12796895 .
- ^ Энтони Ди Франко; Хуэй Го; Синди Рубио-Гонсалес (23 ноября 2017 г.). Всестороннее исследование реальных численных характеристик ошибок . 2017 32-я Международная конференция IEEE / ACM по автоматизированной разработке программного обеспечения (ASE). ИИЭЭ . дои : 10.1109/ASE.2017.8115662 .
- ^ Кимблер, К. (1998). Взаимодействие функций в телекоммуникационных и программных системах V . ИОС Пресс. п. 8. ISBN 978-90-5199-431-5 .
- ^ Сайед, Махбубур Рахман (2001). Мультимедийные сети: технологии, управление и приложения: технологии, управление и приложения . Идея Групп Инк (IGI). п. 398. ИСБН 978-1-59140-005-9 .
- ^ Ву, Чван-Хва (Джон); Ирвин, Дж. Дэвид (2016). Введение в компьютерные сети и кибербезопасность . ЦРК Пресс. п. 500. ИСБН 978-1-4665-7214-0 .
- ^ RFC 1263: Цитата «Расширения TCP считаются вредными»: «Время распространения новой версии протокола на все хосты может быть довольно долгим (фактически навсегда). ... Если есть малейшая несовместимость между старой и новой версиями , может возникнуть хаос».
- ^ Уилсон, Энди; Шульман, Росс; Бэнкстон, Кевин; Герр, Трей. «Ошибки в системе» (PDF) . Институт открытой политики . Архивировано (PDF) из оригинала 21 сентября 2016 г. Проверено 22 августа 2016 г.
- ↑ Перейти обратно: Перейти обратно: а б с д Розенс, Трейси (12 августа 2016 г.). «Киберреформы необходимы для улучшения обнаружения и раскрытия ошибок в программном обеспечении: отчет Новой Америки – Новости национальной готовности» . Проверено 23 августа 2016 г.
- ^ Уллман, Эллен (2004). Ошибка . Пикадор . ISBN 978-1-250-00249-5 .
Внешние ссылки [ править ]
- « Перечисление общих слабостей » - веб-страница экспертов, посвященная ошибкам, на NIST.gov.
- ОШИБКА типа Джима Грея – еще один тип ошибки.
- Изображение «первой компьютерной ошибки» в Wayback Machine (архивировано 12 января 2015 г.)
- « Первая компьютерная ошибка! » - электронное письмо от 1981 года об ошибке адмирала Хоппера.
- « К пониманию ошибок компилятора в GCC и LLVM ». Исследование ошибок в компиляторах 2016 года.
| Базы данных органов управления : Национальные |
|---|
