Как называется ошибка в программе

Что такое баги, ворнинги и исключения в программировании

Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.

Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.

В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.

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

Ошибки в программировании

Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:

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

Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:

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

После восклицательного знака в треугольнике — количество предупреждений

Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:

Вот результат работы такого кода:

Баги в программах

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

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

Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.

Исключения в программах

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

Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.

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

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

Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:

Вот аналогичный код на языке C#:

Однако сообщение в этот раз более конкретное:

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

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

Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):

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

Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.

Как избежать всех этих ошибок

К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.

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

Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.

Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:

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

Заключение

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

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

Источник

В программировании баг (англ. bug — жук) — жаргонное слово, обычно обозначающее ошибку в компьютерной программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, «глючной», «глюкнутой», «забагованной», «бажной», «баг(а)нутой» (англ. unstable, buggy).

Содержание

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

«Баги» локализуются и устраняются в процессе тестирования и отладки программы.

Багом также называют определённый вид маркера на индикаторах.

Этимология

Легенда о мотыльке и день тестировщика

Широко распространена легенда, что 9 сентября 1945 года учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле, и Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник, с сопроводительной надписью: «First actual case of bug being found» (англ. «первый реальный случай, когда жук был найден»). Считается, что этот забавный факт положил начало использованию слова «debugging» в значении «отладка программы», однако, скорее всего, фраза является каламбуром.

Запись в тех.журнале

В действительности этот случай произошёл 9 сентября 1947, а не 1945, года. Знаменитый мотылек был передан в музей вычислительной техники, где он и хранится до сих пор. Под его стендом имеется надпись, которая гласит, что этот мотылек стал первым из обнаруженных багов в истории компьютерной техники. С тех пор это слово стало широко использоваться компьютерщиками во всем мире. А тот день, когда насекомое было обнаружено, решено было сделать профессиональным праздником всех тестировщиков.

Исторические факты

Между тем, слово «bug» в современном значении употреблялось задолго до этого персоналом телеграфных и телефонных компаний в отношении неполадок с электрооборудованием и радиотехникой. В течение Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой. В 1878 году Томас Эдисон писал:

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

It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that «Bugs»—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached. [1]

Употребление

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

Поиск и исправление ошибок

Для отладки программы (англ. debugging) разработчиками ПО используются специальные программы-отладчики (англ. debugger). Например, в операционной системе Windows можно использовать программу WinDbg из пакета Microsoft Debugging Tools for Windows. Для GNU/Linux и ряда других UNIX-подобных операционных систем существует отладчик GDB (GNU Debugger).

Отчёты об ошибках

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

Источник

Откуда берутся ошибки в ПО?

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

Ошибка (error) – это действие человека, которое порождает неправильный результат.

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

Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.

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

Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).

Сбой в работе программы может являться индикатором наличия в ней дефекта.

Таким образом, баг существует при одновременном выполнении трех условий:

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

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

Всего существует несколько источников дефектов и, соответственно, сбоев:

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

Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.

Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.

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

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

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

Третий вариант хуже – здесь ошибки были допущены на этапе проектирования системы. Заметить это можно лишь проведя тщательную сверку со спецификацией. Исправить такие дефекты тоже непросто – нужно заново перерабатывать дизайн продукта.

В четвертом случае дефекты были заложены еще на этапе формирования требований; вся дальнейшая разработка и даже тестирование пошли по изначально неправильному пути. Во время тестирования мы не найдем багов – программа пройдет все тесты, но может быть забракована заказчиком.

Условно можно выделить пять причин появления дефектов в программном коде.

Источник

СОДЕРЖАНИЕ

История

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

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

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

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

Отчет «Ошибки в системе»

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

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

Терминология

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

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

Профилактика

Индустрия программного обеспечения приложила много усилий для сокращения количества ошибок. Это включает:

Типографические ошибки

Методологии разработки

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

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

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

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

Анализ кода

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

Приборы

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

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

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

Отладка

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

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

Тест ошибок

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

Управление ошибками

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

Строгость

Приоритет

Релизы программного обеспечения

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

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

Арифметика

Логика

Синтаксис

Ресурс

Многопоточность

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

Командная работа

Подразумеваемое

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

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

Известные ошибки

Источник

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

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

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

Содержание

История

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

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

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

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

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

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

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

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

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

Отчет «Ошибки в системе»

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

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

Терминология

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

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

Профилактика

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

Типографические ошибки

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

Методологии разработки

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

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

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

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

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

Анализ кода

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

Приборы

Инструменты для мониторинга производительности программного обеспечения во время его работы, либо специально для поиска таких проблем, как узкие места или чтобы гарантировать правильную работу, может быть встроен в код явно (возможно, так просто, как утверждение, говорящее ПЕЧАТЬ «Я ЗДЕСЬ» ) или предоставлены как инструменты. Часто бывает неожиданностью обнаружить, где большую часть времени занимает фрагмент кода, и это удаление предположений может привести к переписыванию кода.

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

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

Отладка

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

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

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

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

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

Тест ошибок

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

Управление ошибками

Строгость

Приоритет

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

Релизы программного обеспечения

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

Источник