Программная ошибка — это ошибка в компьютерном программном обеспечении .
Компьютерную программу с множеством или серьезных ошибок можно назвать ошибочной .
Последствия программной ошибки варьируются от незначительных (например, слово с ошибкой в пользовательском интерфейсе ) до серьезных (например, частые сбои ).
Ошибки программного обеспечения были связаны с катастрофами. Программные ошибки в аппарате лучевой терапии 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 ):
число с плавающей запятой = "3";
синтаксически правильно, но не проходит проверку типа, поскольку правая часть, строка, не может быть присвоена переменной с плавающей запятой. Сбой компиляции — принудительное исправление этого дефекта до возобновления разработки. При использовании интерпретируемого языка сбой произойдет не раньше, чем во время выполнения.
Некоторые языки исключают функции, которые легко приводят к ошибкам, за счет снижения производительности — принцип заключается в том, что обычно лучше писать более простой, медленный и правильный код, чем сложный код с ошибками. Например, Java не поддерживает арифметику указателей , которая обычно выполняется быстро, но считается опасной; относительно легко вызвать серьезную ошибку.
Некоторые языки включают функции, которые добавляют накладные расходы во время выполнения, чтобы предотвратить некоторые ошибки. Например, многие языки включают проверку границ во время выполнения и способ обработки условий выхода за пределы вместо сбоя.
Компилируемый язык позволяет обнаруживать некоторые опечатки (например, идентификатор с ошибкой) перед выполнением , что происходит на более ранней стадии процесса разработки программного обеспечения, чем в случае интерпретируемого языка.
Такие методы программирования, как стиль программирования и защитное программирование, предназначены для предотвращения опечаток.
Например, ошибка может быть вызвана относительно незначительной типографской ошибкой (опечаткой) в коде. Например, этот код выполняет функцию fooтолько в том случае, если conditionоно истинно.
если (условие) foo();
Но этот код всегда выполняется foo:
если (условие); Фу();
Соглашение, которое имеет тенденцию предотвращать эту конкретную проблему, заключается в необходимости использования фигурных скобок для блока, даже если он состоит только из одной строки.
если (условие) { Фу();}Обеспечение соблюдения соглашений может осуществляться вручную (например, посредством проверки кода ) или с помощью автоматизированных инструментов.
Некоторые утверждают, что написание спецификации программы , описывающей поведение программы, может предотвратить ошибки.
Некоторые утверждают, что формальные спецификации непрактичны для чего-либо, кроме самых коротких программ, из-за проблем комбинаторного взрыва и неопределенности .
Одной из целей тестирования программного обеспечения является поиск ошибок.
Измерения во время тестирования могут дать оценку количества вероятных оставшихся ошибок. Это становится тем более надежным, чем дольше продукт тестируется и разрабатывается. [ нужна цитата ]
Гибкая разработка программного обеспечения может включать частые выпуски программного обеспечения с относительно небольшими изменениями. Дефекты выявляются по отзывам пользователей.
При разработке через тестирование (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, или именованными, например критический , высокий , низкий и отложенный . Значения могут быть аналогичны или идентичны рейтингам серьезности, хотя приоритет является другим аспектом.
Приоритетом может быть сочетание серьезности ошибки и уровня усилий по ее исправлению. Ошибка низкой серьезности, но которую легко исправить, может получить более высокий приоритет, чем ошибка средней серьезности, для исправления которой требуется значительно больше усилий.
Ошибки достаточно высокого приоритета могут потребовать специального выпуска, который иногда называют патчем .
Выпуск программного обеспечения, в котором особое внимание уделяется исправлению ошибок, можно назвать выпуском сопровождения , чтобы отличить его от выпуска, в котором особое внимание уделяется новым функциям или другим изменениям.
Обычной практикой является выпуск программного обеспечения с известными ошибками низкого приоритета или другими проблемами. Возможные причины включают, помимо прочего:
Объем и тип ущерба, который может нанести ошибка в программном обеспечении, влияет на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемый космический полет , авиация , ядерная энергетика , здравоохранение , общественный транспорт или автомобильная безопасность , поскольку недостатки программного обеспечения могут привести к травмам или даже смерти человека, такое программное обеспечение будет подвергаться гораздо большему вниманию и контролю качества, чем, например, сайт интернет-магазинов. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, приложение для редактирования фотографий.
Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, затраченными на их исправление. В 1978 году Лиенц и др. показало, что в среднем 17 процентов усилий по разработке вкладывают в исправление ошибок. [25] В 2020 году исследование репозиториев GitHub показало, что медиана составляет 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]
Чтобы облегчить воспроизводимые исследования по тестированию и отладке, исследователи используют тщательно подобранные тесты ошибок:
Некоторые известные типы ошибок:
Ошибка может быть вызвана недостаточным или неправильным проектированием согласно спецификации. Например, учитывая, что спецификация должна располагать список слов в алфавитном порядке, может возникнуть ошибка проектирования, если в проекте не учитываются символы; что приводит к неправильному алфавитному расположению слов с символами.
Числовые операции могут привести к неожиданному выводу, медленной обработке или сбою. [33] Такая ошибка может возникнуть из-за недостаточной осведомленности о качествах хранилища данных, таких как потеря точности из-за округления , численно нестабильных алгоритмов, арифметического переполнения и потери значения , или из-за незнания того, как вычисления обрабатываются различные языки кодирования программного обеспечения, такие как деление на ноль , которое в некоторых языках может вызывать исключение, а в других может возвращать специальное значение, например NaN или бесконечность .
Ошибка потока управления , также известная как логическая ошибка, характеризуется кодом, который не завершается с ошибкой, но не имеет ожидаемого поведения, например, бесконечный цикл , бесконечная рекурсия , неправильное сравнение в условном выражении , например использование неправильного оператора сравнения , и ошибка отклонения на единицу .
Институт открытых технологий, которым управляет группа New America , [38] в августе 2016 года опубликовал отчет «Ошибки в системе», в котором говорится, что политикам США следует провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». [39] Один из авторов отчета заявил, что Конгресс не сделал достаточно для решения проблемы уязвимости киберпрограммного обеспечения, хотя Конгресс принял ряд законопроектов для борьбы с более широкой проблемой кибербезопасности. [39]
Правительственные исследователи, компании и эксперты по кибербезопасности — это люди, которые обычно обнаруживают недостатки программного обеспечения. В докладе содержится призыв к реформированию законов о компьютерной преступности и авторском праве. [39]
В докладе говорится, что Закон о компьютерном мошенничестве и злоупотреблениях, Закон об авторском праве в цифровую эпоху и Закон о конфиденциальности электронных коммуникаций криминализируют и предусматривают гражданско-правовые наказания за действия, которые исследователи безопасности регулярно совершают при проведении законных исследований безопасности, говорится в докладе. [39]
(Кобб и Миллс, 1990)
