Ошибка программного обеспечения — это ошибка, изъян или сбой в проектировании, разработке или работе компьютерного программного обеспечения , из-за которого оно дает неправильный или неожиданный результат или ведет себя непредусмотренным образом. Процесс поиска и исправления ошибок называется « отладкой » и часто использует формальные методы или инструменты для выявления ошибок. С 1950-х годов некоторые компьютерные системы были разработаны для обнаружения или автоматического исправления различных ошибок программного обеспечения во время операций.
Ошибки в программном обеспечении могут возникать из-за ошибок и ошибок, допущенных при интерпретации и извлечении требований пользователей, планировании дизайна программы , написании ее исходного кода , а также в результате взаимодействия с людьми, оборудованием и программами, такими как операционные системы или библиотеки . Программу с множеством или серьезных ошибок часто называют ошибочной . Ошибки могут вызывать ошибки, которые могут иметь волновой эффект . Последствия ошибок могут быть как незаметными, например непреднамеренное форматирование текста, так и более очевидными, такими как сбой программы , зависание компьютера или повреждение оборудования. Другие ошибки квалифицируются как ошибки безопасности и могут, например, позволить злоумышленнику обойти контроль доступа для получения несанкционированных привилегий . [1]
Некоторые программные ошибки были связаны с катастрофами. Ошибки в коде, управлявшем аппаратом лучевой терапии Therac-25, были прямой причиной смерти пациентов в 1980-х годах. В 1996 году прототип ракеты Ariane 5 Европейского космического агентства стоимостью 1 миллиард долларов США был уничтожен менее чем через минуту после запуска из-за ошибки в бортовой компьютерной программе наведения. [2] В 1994 году разбился вертолет ВВС Великобритании «Чинук» , в результате чего погибло 29 человек; Первоначально в этом обвиняли ошибку пилота, но позже предполагалось, что это было вызвано ошибкой программного обеспечения в компьютере управления двигателем . [3] Программное обеспечение с ошибками стало причиной скандала в Британском почтовом отделении в начале XXI века , самой распространенной судебной ошибки в истории британского права. [4]
В 2002 году исследование, проведенное по заказу Национального института стандартов и технологий Министерства торговли США , пришло к выводу, что «ошибки или ошибки в программном обеспечении настолько распространены и настолько вредны, что они обходятся экономике США примерно в 59 миллиардов долларов в год, или около 0,6 миллиарда долларов США». процентов валового внутреннего продукта». [5]
Среднеанглийское слово bugge является основой терминов «bugbear» и «bugaboo», обозначающих монстров. [6]
Термин «ошибка» для описания дефектов стал частью инженерного жаргона с 1870-х годов [7] и появился еще до появления электроники и компьютеров; Возможно, изначально он использовался в аппаратной инженерии для описания механических неисправностей. Например, Томас Эдисон написал в письме своему коллеге в 1878 году: [8]
... возникают трудности - эта штука выходит из строя, и [именно] тогда «Ошибки» - как называются такие маленькие неисправности и трудности - проявляют себя [9]
Baffle Ball , первая механическая игра в пинбол , рекламировалась как «без ошибок» в 1931 году. [10] Проблемы с военным снаряжением во время Второй мировой войны назывались ошибками (или сбоями ). [11] В книге, опубликованной в 1942 году, Луиза Дикинсон Рич , говоря об электрической машине для резки льда , сказала: «Распиловка льда была приостановлена до тех пор, пока не появится создатель, который избавит свою любимицу от жуков». [12]
Айзек Азимов использовал термин «жук» для обозначения проблем с роботом в своем рассказе « Поймай этого кролика », опубликованном в 1944 году.
Термин «ошибка» был использован в отчете пионера компьютеров Грейс Хоппер , которая обнародовала причину неисправности раннего электромеханического компьютера. [13] Типичная версия этой истории:
В 1946 году, когда Хоппер была освобождена от действительной военной службы, она поступила на факультет Гарвардского университета в вычислительную лабораторию, где продолжила работу над Mark II и Mark III . Операторы связали ошибку в Mark II с молью , застрявшей в реле, и придумали термин «ошибка» . Эта ошибка была тщательно удалена и записана в бортовой журнал. Исходя из первой ошибки, сегодня мы называем ошибки или сбои в программе ошибкой . [14]
Хоппер не присутствовала при обнаружении жука, но эта история стала одной из ее любимых. [15] Дата в бортовом журнале — 9 сентября 1947 года. [16] [17] [18] Операторы, нашедшие его, в том числе Уильям «Билл» Берк, позже работавший в Лаборатории военно-морского вооружения , Дальгрен, Вирджиния , [19] ] были знакомы с этим инженерным термином и забавно держали насекомое с пометкой «Первый реальный случай обнаружения ошибки». Этот бортовой журнал с прикрепленной к нему молью является частью коллекции Смитсоновского национального музея американской истории . [17]
Родственный термин « отладка », по-видимому, также появился раньше, чем его использование в вычислительной технике: этимология этого слова в Оксфордском словаре английского языка содержит подтверждение 1945 года в контексте авиационных двигателей. [20]
Представление о том, что программное обеспечение может содержать ошибки, восходит к заметкам Ады Лавлейс об аналитической машине 1843 года , в которых она говорит о возможности ошибочности программных «карт» для аналитической машины Чарльза Бэббиджа :
... в равной степени должен быть выполнен процесс анализа, чтобы предоставить аналитической машине необходимые оперативные данные; и это также может быть возможным источником ошибки. Учитывая, что реальный механизм безошибочен в своих процессах, карты могут давать ему неправильные приказы.
Хотя использование термина «ошибка» для описания ошибок программного обеспечения является обычным явлением, многие полагают, что от него следует отказаться. Один из аргументов состоит в том, что слово «ошибка» не связано с ощущением, что проблему вызвал человек, и вместо этого подразумевает, что дефект возник сам по себе, что приводит к отказу от термина «ошибка» в пользу таких терминов, как «дефект» с ограниченным успехом. [21]
Термин «ошибка» также может использоваться для прикрытия преднамеренного дизайнерского решения. В 2011 году, после проверки со стороны сенатора США Эла Франкена за запись и хранение местонахождения пользователей в незашифрованных файлах, [22] Apple назвала такое поведение ошибкой. Однако Джастин Брукман из Центра демократии и технологий прямо оспорил это представление, заявив: «Я рад, что они исправляют то, что они называют ошибками, но я возражаю против их решительного отрицания того, что они отслеживают пользователей». [23]
В разработке программного обеспечения метаморфизм ошибок (от греческого « meta» = «изменение», morph = «форма») относится к развитию дефекта на заключительном этапе развертывания программного обеспечения. Трансформация «ошибки», допущенной аналитиком на ранних этапах жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительном этапе цикла, получила название «метаморфизма ошибки». [24]
Различные этапы «ошибки» во всем цикле можно охарактеризовать как «ошибки», «аномалии», «неисправности», «сбои», «ошибки», «исключения», «сбои», «сбои», «баги». , «дефекты», «инциденты» или «побочные эффекты». [24]
Индустрия программного обеспечения приложила немало усилий для сокращения количества ошибок. [25] [26] К ним относятся:
Баги обычно появляются, когда программист допускает логическую ошибку . Различные инновации в стиле программирования и защитном программировании призваны сделать эти ошибки менее вероятными или их легче обнаружить. Некоторые опечатки, особенно символов или операторов , приводят к неправильной работе программы, тогда как другие, такие как отсутствующий символ или неправильное написание имени, могут помешать работе программы. Скомпилированные языки могут обнаружить некоторые опечатки при компиляции исходного кода .
Несколько схем помогают управлять деятельностью программистов, чтобы создавать меньше ошибок. Разработка программного обеспечения (которая также решает проблемы проектирования программного обеспечения) применяет множество методов для предотвращения дефектов. Например, формальные спецификации программ определяют точное поведение программ, чтобы можно было исключить ошибки проектирования. Формальные спецификации непрактичны для чего-либо, кроме самых коротких программ, из-за проблем комбинаторного взрыва и неопределенности .
Модульное тестирование предполагает написание теста для каждой функции (модуля), которую должна выполнять программа.
При разработке через тестирование модульные тесты пишутся перед кодом, и код не считается завершенным до тех пор, пока все тесты не завершатся успешно.
Гибкая разработка программного обеспечения предполагает частые выпуски программного обеспечения с относительно небольшими изменениями. Дефекты выявляются по отзывам пользователей.
Разработка с открытым исходным кодом позволяет любому изучить исходный код. Школа мысли, популяризированная Эриком С. Рэймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало ошибок или вообще не содержать их, чем другое программное обеспечение, потому что «при достаточном количестве глаз все ошибки являются поверхностными». [27] Однако это утверждение оспаривается: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малопонятном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не Это не значит, что они имеют на это право». [28] Примером ошибки в программном обеспечении с открытым исходным кодом была уязвимость OpenSSL 2008 года в Debian .
Языки программирования включают функции, помогающие предотвратить ошибки, такие как системы статических типов , ограниченные пространства имен и модульное программирование . Например, когда программист пишет ( псевдокод ) LET REAL_VALUE PI = "THREE AND A BIT", хотя это может быть синтаксически правильно, код не проходит проверку типа . Скомпилированные языки улавливают это без необходимости запуска программы. Интерпретируемые языки улавливают такие ошибки во время выполнения. Некоторые языки намеренно исключают функции, которые легко приводят к ошибкам, за счет снижения производительности: общий принцип заключается в том, что почти всегда лучше писать более простой и медленный код, чем непонятный код, который работает немного быстрее, особенно если учесть, что затраты на обслуживание значительны. . Например, язык программирования Java не поддерживает арифметику указателей ; реализации некоторых языков, таких как Pascal и языки сценариев, часто имеют проверку границ массивов во время выполнения, по крайней мере, в отладочной сборке.
Инструменты анализа кода помогают разработчикам, проверяя текст программы за пределами возможностей компилятора, чтобы выявить потенциальные проблемы. Хотя в целом проблема обнаружения всех ошибок программирования с учетом спецификации неразрешима (см. « Проблему остановки» ), эти инструменты используют тот факт, что программисты-люди склонны часто совершать определенные виды простых ошибок при написании программного обеспечения.
Инструменты для мониторинга производительности программного обеспечения во время его работы, либо специально для поиска проблем, таких как узкие места , либо для обеспечения уверенности в правильной работе, могут быть встроены в код явно (возможно, так же просто, как оператор, говорящий PRINT "I AM HERE"), или предоставляться как инструменты. Зачастую бывает неожиданно обнаружить, какой фрагмент кода занимает большую часть времени, и такое исключение предположений может привести к переписыванию кода.
Тестировщики программного обеспечения — это люди, основной задачей которых является поиск ошибок или написание кода для поддержки тестирования. В некоторых случаях на тестирование может быть потрачено больше ресурсов, чем на разработку программы.
Измерения во время тестирования могут дать оценку количества вероятных оставшихся ошибок; Чем дольше продукт тестируется и разрабатывается, тем надежнее он становится. [ нужна цитата ]
Поиск и исправление ошибок, или отладка , является основной частью компьютерного программирования . Морис Уилкс , пионер вычислительной техники, описал, как в конце 1940-х годов он осознал, что большая часть оставшейся жизни будет потрачена на поиск ошибок в собственных программах. [29]
Обычно самая сложная часть отладки — это поиск ошибки. Как только ошибка обнаружена, исправить ее обычно относительно легко. Программы, известные как отладчики , помогают программистам находить ошибки, выполняя код построчно, отслеживая значения переменных и используя другие функции для наблюдения за поведением программы. Без отладчика можно добавить код, чтобы сообщения или значения можно было записывать в консоль, окно или файл журнала для отслеживания выполнения программы или отображения значений.
Однако даже с помощью отладчика обнаружение ошибок — это своего рода искусство. Нередко ошибка в одном разделе программы приводит к сбоям в совершенно другом разделе, что особенно затрудняет отслеживание (например, ошибка в процедуре рендеринга графики , вызывающая файловый ввод-вывод). рутина, приводящая к сбою), в явно несвязанной части системы.
Иногда ошибка не является изолированным недостатком, а представляет собой ошибку мышления или планирования со стороны программиста. Такие логические ошибки требуют пересмотра или переписывания раздела программы. В рамках проверки кода пошаговое выполнение кода и представление или расшифровка процесса выполнения часто могут обнаруживать ошибки, даже не воспроизводя ошибку как таковую.
Чаще всего первым шагом в обнаружении ошибки является ее надежное воспроизведение. Как только ошибка становится воспроизводимой, программист может использовать отладчик или другой инструмент при воспроизведении ошибки, чтобы найти точку, в которой программа сбилась с пути.
Некоторые ошибки обнаруживаются при вводе данных, которые программисту может быть сложно воссоздать. Одной из причин гибели радиационной машины Therac-25 была ошибка (в частности, состояние гонки ), которая возникала только тогда, когда оператор машины очень быстро вводил план лечения; чтобы научиться это делать, потребовались несколько дней практики, поэтому ошибка не проявилась ни при тестировании, ни когда производитель пытался ее воспроизвести. Другие ошибки могут перестать возникать всякий раз, когда установка дополняется для поиска ошибки, например, при запуске программы с помощью отладчика; их называют ошибками Гейзенберга (в шутку названными в честь принципа неопределенности Гейзенберга ).
С 1990-х годов, особенно после катастрофы рейса 501 Ariane 5 , возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода посредством абстрактной интерпретации . [30]
Некоторые классы ошибок не имеют ничего общего с кодом. Неверная документация или оборудование могут привести к проблемам в использовании системы, даже если код соответствует документации. В некоторых случаях изменения в коде устраняют проблему, даже если код больше не соответствует документации. Встроенные системы часто устраняют аппаратные ошибки, поскольку сделать новую версию ПЗУ гораздо дешевле, чем восстанавливать оборудование, особенно если оно является товарным изделием .
Чтобы облегчить воспроизводимые исследования по тестированию и отладке, исследователи используют тщательно подобранные тесты ошибок:
Управление ошибками включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении – ошибки, а также запросы на улучшения и даже целые выпуски – обычно отслеживаются и управляются с помощью систем отслеживания ошибок или систем отслеживания проблем . [33] Добавленные элементы можно назвать дефектами, заявками, проблемами или, следуя парадигме гибкой разработки , историями и эпопеями. Категории могут быть объективными, субъективными или комбинированными, например номер версии , область программного обеспечения, серьезность и приоритет, а также тип проблемы, например запрос функции или ошибка.
Сортировка ошибок рассматривает ошибки и решает, нужно ли их исправлять и когда. Решение основывается на приоритете ошибки и таких факторах, как графики разработки. Сортировка предназначена не для расследования причин ошибок, а для определения стоимости их исправления. Сортировка происходит регулярно и проверяет ошибки, открытые или повторно открытые после предыдущей встречи. В процессе сортировки обычно участвуют руководитель проекта, руководитель разработки, руководитель тестирования, руководитель сборки и технические эксперты. [34] [35]
Серьезность — это интенсивность влияния ошибки на работу системы. [36] Это воздействие может выражаться в потере данных, финансовых потерях, потере репутации и напрасной трате усилий. Уровни серьезности не стандартизированы. Последствия различаются в разных отраслях. Сбой в видеоигре имеет совершенно иное воздействие, чем сбой в веб-браузере или системе мониторинга в реальном времени. Например, уровни серьезности ошибки могут быть следующими: «сбой или зависание», «нет обходного пути» (означает, что клиент не может выполнить данную задачу), «имеется обходной путь» (означает, что пользователь все еще может выполнить задачу), «визуальный дефект» (например, отсутствующее изображение или смещенная кнопка или элемент формы) или «ошибка документации». Некоторые издатели программного обеспечения используют более точные уровни серьезности, такие как «критический», «высокий», «низкий», «блокирующий» или «тривиальный». [37] Серьезность ошибки может быть отдельной категорией по сравнению с приоритетом ее исправления, и эти две категории могут определяться количественно и управляться отдельно.
Приоритет определяет, где ошибка попадает в список запланированных изменений. Приоритет определяется каждым производителем программного обеспечения. Приоритеты могут быть числовыми, например от 1 до 5, или именованными, например «критический», «высокий», «низкий» или «отложенный». Эти рейтинговые шкалы могут быть аналогичны или даже идентичны рейтингам серьезности , но оцениваются как комбинация серьезности ошибки и предполагаемых усилий по ее исправлению; ошибка низкой серьезности, но которую легко исправить, может получить более высокий приоритет, чем ошибка средней серьезности, исправление которой требует чрезмерных усилий. Рейтинги приоритета могут быть привязаны к выпускам продукта, например, «критический» приоритет указывает на все ошибки, которые необходимо исправить до следующего выпуска программного обеспечения.
Ошибка, достаточно серьезная, чтобы задержать или остановить выпуск продукта, называется «show stopper» [38] или «showstopper bug». [39] Он назван так потому, что «останавливает представление» – приводит к неприемлемому отказу продукта. [39]
Обычной практикой является выпуск программного обеспечения с известными ошибками низкого приоритета. Ошибки достаточно высокого приоритета могут потребовать специального выпуска части кода, содержащей только модули с этими исправлениями. Они известны как патчи . Большинство выпусков включают в себя изменения поведения и многочисленные исправления ошибок. Выпуски, в которых особое внимание уделяется исправлению ошибок, называются выпусками обслуживания , чтобы отличать их от основных выпусков, в которых особое внимание уделяется добавлению или изменению функций.
Причины, по которым издатель программного обеспечения предпочитает не исправлять или даже не исправлять конкретную ошибку, включают:
В разработке программного обеспечения ошибка или ошибка могут быть допущены на любом этапе. Ошибки возникают из-за недосмотра или недопонимания со стороны команды разработчиков программного обеспечения во время спецификации, проектирования, кодирования, настройки, ввода данных или документации. Например, в относительно простой программе для упорядочения списка слов по алфавиту может не учитываться, что должно произойти, если слово содержит дефис . Или при преобразовании абстрактного проекта в код кодировщик может непреднамеренно создать ошибку отклонения на единицу , которая может быть знаком «<», где предполагалось «<=", и не суметь отсортировать последнее слово в списке.
Другая категория ошибок называется состоянием гонки , которое может возникнуть, когда в программе одновременно выполняются несколько компонентов. Если компоненты взаимодействуют в порядке, отличном от задуманного разработчиком, они могут мешать друг другу и мешать программе выполнять свои задачи. Эти ошибки может быть трудно обнаружить или предвидеть, поскольку они могут не возникать во время каждого выполнения программы.
Концептуальные ошибки — это непонимание разработчиком того, что должно делать программное обеспечение. Полученное программное обеспечение может работать в соответствии с пониманием разработчика, но не в соответствии с тем, что действительно необходимо. Другие типы:
При операциях с числовыми значениями могут возникнуть проблемы, которые приводят к неожиданному выводу, замедлению процесса или сбою. [42] Это может быть из-за недостаточной осведомленности о качествах хранилища данных, таких как потеря точности из-за округления , численно нестабильных алгоритмов, арифметического переполнения и потери значения , или из-за незнания того, как вычисления обрабатываются различным программным обеспечением. языки кодирования, такие как деление на ноль , которое в некоторых языках может вызывать исключение, а в других может возвращать специальное значение, например NaN или бесконечность .
Ошибки потока управления — это те, которые обнаруживаются в процессах с допустимой логикой, но приводят к непредвиденным результатам, таким как бесконечные циклы и бесконечная рекурсия , неправильные сравнения для условных операторов , такие как использование неправильного оператора сравнения , и ошибки отклонения на единицу (считая один слишком много или слишком мало итераций при цикле).
Объем и тип ущерба, который может нанести ошибка в программном обеспечении, естественным образом влияет на принятие решений, процессы и политику в отношении качества программного обеспечения. В таких приложениях, как пилотируемый космический полет , авиация , ядерная энергетика , здравоохранение , общественный транспорт или автомобильная безопасность , поскольку недостатки программного обеспечения могут привести к травмам или даже смерти человека, такое программное обеспечение будет подвергаться гораздо большему вниманию и контролю качества, чем, например, сайт интернет-магазинов. В таких приложениях, как банковское дело, где недостатки программного обеспечения могут нанести серьезный финансовый ущерб банку или его клиентам, контроль качества также более важен, чем, скажем, в приложении для редактирования фотографий.
Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, затраченными на их исправление. В 1978 году Лиенц и др. показало, что в среднем 17 процентов усилий по разработке вкладывается в исправление ошибок. [47] В 2020 году исследование репозиториев GitHub показало, что медиана составляет 20%. [48]
В 1994 году Центру космических полетов Годдарда НАСА удалось снизить среднее количество ошибок с 4,5 на 1000 строк кода ( SLOC ) до 1 на 1000 SLOC. [49]
Другое исследование, проведенное в 1990 году, показало, что исключительно хорошие процессы разработки программного обеспечения могут обеспечить уровень неудач при развертывании всего 0,1 на 1000 SLOC. [50] Эта цифра повторяется в такой литературе, как «Code Complete » Стива МакКоннелла [51] и в исследовании НАСА « Сложность программного обеспечения для полетов ». [52] Некоторые проекты даже достигли нулевых дефектов: прошивка пишущей машинки IBM Wheelwriter , состоящая из 63 000 SLOC, и программное обеспечение Space Shuttle с 500 000 SLOC. [50]
Ряд программных ошибок стал широко известен, как правило, из-за их серьезности: примеры включают в себя различные крушения космических и военных самолетов. Возможно, самой известной ошибкой является проблема 2000 года или ошибка 2000 года, из-за которой многие программы, написанные задолго до перехода с дат 19xx на 20xx, работали неправильно, например, такая дата, как «25 декабря 2004 года», рассматривалась как 1904 год, отображая « 19100» вместо «2000» и так далее. Огромные усилия в конце 20-го века разрешили самые серьезные проблемы и не имели серьезных последствий.
Сбой в торговле акциями в 2012 году был связан с одной из таких несовместимостей между старым API и новым API.
Институт открытых технологий, которым управляет группа New America , [53] в августе 2016 года опубликовал отчет «Ошибки в системе», в котором говорится, что политикам США следует провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». [54] Один из авторов отчета заявил, что Конгресс не сделал достаточно для решения проблемы уязвимости киберпрограммного обеспечения, хотя Конгресс принял ряд законопроектов для борьбы с более широкой проблемой кибербезопасности. [54]
Правительственные исследователи, компании и эксперты по кибербезопасности — это люди, которые обычно обнаруживают недостатки программного обеспечения. В докладе содержится призыв к реформированию законов о компьютерной преступности и авторском праве. [54]
В докладе говорится, что Закон о компьютерном мошенничестве и злоупотреблениях, Закон об авторском праве в цифровую эпоху и Закон о конфиденциальности электронных коммуникаций криминализируют и предусматривают гражданско-правовые санкции за действия, которые исследователи безопасности регулярно совершают при проведении законных исследований безопасности, говорится в докладе. [54]
{{cite web}}: CS1 maint: unfit URL (link)(См. изображение рекламы в ссылочной записи)
(Кобб и Миллс, 1990)
