В истории программирования не всегда все было легко и безоблачно. Ведь любому программисту, вне зависимости от опыта и технического бэкграунда, трудно уберечься от ошибок и порой даже небольшого количества плохого кода хватало, чтобы вызвать серьезную проблему. «Библиотека программиста» немного полистала ИТ-летописи и нашла для вас 10 самых худших ошибок в истории кодинга. Поехали!
1. Ошибка 2000 года
Более двух десятилетий назад, в канун нового 2000 года, весь развитый мир охватила паника из-за проблемы способной привести к сбоям в работе компьютеров, падению самолетов, прекращению работы медицинского оборудования и разрушению глобальной финансовой системы.
Суть проблемы заключалась в том, что большинство устаревших информационных систем, созданных еще в 70-х и 80-х, использовали только две цифры для исчисления года. Это значит, что часы внутри микропроцессоров различного аппаратного ПО регистрировали 1999 год как «99», основываясь на ошибочном предположении разработчиков прошлого, что мы всегда будем жить в 20-м веке и цифра «19» в обозначении года никогда не изменится.
Тогда все полагали, что в 2000 году у всех нас наверняка будут реактивные ранцы, еда в форме таблеток, футуристическая серебристая униформа и человечество к этому времени откажется от старых компьютерных систем середины века. Но чуда не случилось!
И в канун всеми любимого праздника мир охватила полномасштабная паника. Кто-то усердно работал над внедрением обходных путей, выделяя на эти цели колоссальные средства. Другие же вообще не чинили, не исправляли и не обновляли свои системы. Кто из них был прав, сейчас сказать сложно, но когда наступил рубеж тысячелетий, глобальной катастрофы не произошло. Однако у всей этой шумихи, все же был положительный эффект. До общественности наконец начало доходить, как много жизненно важных систем зависит от компьютеров и микропроцессоров и как важно следить за их ПО и своевременно его обслуживать.
2. Терак-25
Плохой код на самом деле может убить. Такая катастрофа произошла с аппаратом лучевой терапии Therac-25, произведенным компанией Atomic Energy of Canada, ставшего причиной гибели не менее шести пациентов. Расследование выявило недоработку системы, вызвавшую передозировку радиацией. Связано это было с трудностью проведения автоматизированных тестов такого специфического программного обеспечения. И поэтому машина, призванная помочь людям, стала машиной для убийств из научной фантастики. Этот случай заставил разработчиков ПО медицинской отрасли крайне ответственно подходить к тестированию такого оборудования.
3. Сеть AT&T выходит из строя
15 января 1990 года около 50 процентов мобильной сети AT&T вышло из строя. За девять часов простоя более 75 миллионов звонков остались без ответа. И хотя в первоначальных отчетах следствия по этому делу значилось хакерская атака, на самом деле, виновником сего происшествия стало стандартное обновление ПО. Ошибка всего в одной строке кода стоила компании огромных денег. Все организации, целиком зависящие от наличия и качества связи, выставили AT&T иски с внушительными суммами. К примеру, крупнейший авиаперевозчик American Airlines, понес колоссальные финансовые убытки из-за того, что получил наполовину меньше звонков своих клиентов из-за сбоя. Авария 1990 года до сих пор служит прекрасным примером важности тестирования программного обеспечения и служит напоминанием о неразрывной связи между технологиями и экономической деятельностью большинства компаний.
4. Досрочное освобождение заключенных
В 2005 году в США штате Мичиган произошел сбой тюремной программы, отвечающей за расчет срока наказания заключенных, в результате чего более 20 заключенных досрочно вышли на свободу. Программа ошибочно посчитала смягчающий коэффициент и снизила срок пребывания отбывающих наказание людей в несколько раз. Ошибку в коде заметили не сразу, а лишь по прошествии некоторого времени. И поэтому меру пресечения счастливчикам никто не пересчитывал. Среди них, к слову, не было матерых гангстеров и маньяков. В основном это были мелкие правонарушители, отбывавшие срок за неуплату алиментов, махинации с налогами и незаконное хранение психотропов.
Произошедшее показывает, что в погоне за автоматизацией процессов и сокращением количества ручных операций программисты зачастую забывают о грамотной настройке разработанной системы и ее тестировании. А мы с вами в очередной раз убеждаемся, что даже незначительная ошибка может привести к серьезным последствиям.
5. Взрыв Ariane 5
Случай произошел 4 июня 1996 года при первом запуске Ariane 5 — одной из самых надежных беспилотных ракетных установок, целью которой было изучение взаимодействия между солнечным ветром и магнитосферой Земли. Через 37 секунд после старта ракета, вылетевшая с космодрома, находящегося на берегах Французской Гвианы, развернулась на 90 градусов и всего через несколько секунд превратилась в огромный огненный шар.
Специальная группа прочесала место происшествия, собирая обломки, чтобы попытаться выяснить, что произошло. Через некоторое время техническая комиссия установила, что авария была вызвана программным сбоем.
Отказ системы произошел из-за полной потери информации о точности наведения ракеты и ориентации ее в пространстве, поступающей в центральный процессор. Потеря — следствие ошибки проектировщиков ПО и вызвана она была некорректным преобразованием 64-битного числа с плавающей запятой в 16-битное целое число.
К слову, целочисленное переполнение является широко распространенной ошибкой в компьютерном программировании.
6. Ошибка Paypal
Что бы вы сделали, если бы PayPal случайно зачислил на ваш счет 92 квадриллиона долларов? Крису Рейнольдсу, 56-летнему американцу, продающему автозапчасти на eBay, не пришлось долго об этом думать. Ведь он даже не успел ощутить себя первым в мире квадриллионером и самым богатым человеком в мире, так как ошибка была устранена в течение нескольких минут. Поэтому, прежде чем мужчина начал мечтать о новом кадиллаке и золотой карте члена королевского яхт-клуба, сумма на его счету вернулась к привычному балансу. Конечно, стоило бы потребовать с компании хотя бы часть этой суммы за моральный ущерб, но, видимо, шок от увиденного не позволил ему сделать это.
7. Калькулятор Windows
Эта ошибка, существующая в большинстве версий Windows (кроме Windows 10), которую вы сможете проверить самостоятельно.
Для этого нужно:
- Открыть калькулятор Windows и ввести 4.
- Извлечь из этого числа квадратный корень и получите 2.
- Вычесть из него 2 и вместо нулевого результата в разных версиях Windows вы увидите разные результаты.
Причиной ошибки является недоработка, вызванная некорректным обращением калькулятора с операциями sqrt. В итоге результаты сохраняются как числа с плавающей запятой, а не целые числа, вызывая ошибку точности при дальнейших вычислениях, которую вы можете видеть.
Microsoft признала эту ошибку в приложении калькулятора и исправила ее в Windows 10.
8. Проблема 2038 года
Ошибка 2038 будет вызвана использованием 32-разрядных процессоров в 32-разрядных системах. Проще говоря, 19 января 2038 года наступит в 03:14:07. Компьютеры, которые все еще используют 32-разрядные системы для управления датой и временем, не смогут справиться с этим изменением. Как и в случае с ошибкой 2000 года, компьютеры не смогут отличить 2038 год от 1970 года.
Однако волноваться не стоит: почти все современные процессоры в настольных ПК имеют 64-битные системы с 64-битным программным обеспечением и в 2038 году само существование 32-битных систем будет под вопросом.
9. Видео Gangnam Style «сломало» YouTube
Счетчик YouTube ранее использовал 32-битное целое число для определения максимального количества просмотров видеоролика, и равно оно было 2 147 483 647.
Однако корейская поп-группа PSY, выложившая на сервис свой клип с зажигательной песней Gangnam Style благополучно его сломала, превысив допустимую планку.
«Когда мы его делали, никогда не думали, что какое-нибудь видео посмотрят столько раз, но это было до Gangman Style», — написал на своей странице в сети один из разработчиков портала.
Клип PSY опубликовали 15 июля 2012 года и к концу мая 2014 года он стал единственным видеороликом, которой просмотрели больше 2 млрд раз.
В настоящее время YouTube использует 64-битное целое число для счетчика видео, что означает, что максимальное количество просмотров видео составляет 9,22 квинтиллиона.
10. Синий экран смерти
BSOD или «Синий экран смерти» — жаргонное название фатальной системной ошибки Windows, показывающей системный сбой, при котором операционка достигала состояния, в котором она больше не могла надежно работать. Как правило, вызывалась она в Windows 95-98 после неожиданного завершения важного процесса или общего сбоя оборудования. Старожилы наверняка помнят этот баг, который довольно часто возникал на заре становления ИТ-культуры.
16 марта 2000 года Microsoft выпустила обновление для системы безопасности, устраняющее эту неполадку, однако и сейчас на форумах изредка можно встретить сообщение от пользователей об этой проблеме.
***
Людям свойственно совершать ошибки. Однако, будьте внимательны — всегда нужно помнить, что даже одна плохо написанная строчка кода может привести к печальным последствиям. Удачи!
Материалы по теме
- ⚠️ 10 самых распространенных ошибок, ежедневно допускаемых каждым программистом
- ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
- 😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase
В истории программирования не всегда все было легко и безоблачно. Ведь любому программисту, вне зависимости от опыта и технического бэкграунда, трудно уберечься от ошибок и порой даже небольшого количества плохого кода хватало, чтобы вызвать серьезную проблему. «Библиотека программиста» немного полистала ИТ-летописи и нашла для вас 10 самых худших ошибок в истории кодинга. Поехали!
1. Ошибка 2000 года
Более двух десятилетий назад, в канун нового 2000 года, весь развитый мир охватила паника из-за проблемы способной привести к сбоям в работе компьютеров, падению самолетов, прекращению работы медицинского оборудования и разрушению глобальной финансовой системы.
Суть проблемы заключалась в том, что большинство устаревших информационных систем, созданных еще в 70-х и 80-х, использовали только две цифры для исчисления года. Это значит, что часы внутри микропроцессоров различного аппаратного ПО регистрировали 1999 год как «99», основываясь на ошибочном предположении разработчиков прошлого, что мы всегда будем жить в 20-м веке и цифра «19» в обозначении года никогда не изменится.
Тогда все полагали, что в 2000 году у всех нас наверняка будут реактивные ранцы, еда в форме таблеток, футуристическая серебристая униформа и человечество к этому времени откажется от старых компьютерных систем середины века. Но чуда не случилось!
И в канун всеми любимого праздника мир охватила полномасштабная паника. Кто-то усердно работал над внедрением обходных путей, выделяя на эти цели колоссальные средства. Другие же вообще не чинили, не исправляли и не обновляли свои системы. Кто из них был прав, сейчас сказать сложно, но когда наступил рубеж тысячелетий, глобальной катастрофы не произошло. Однако у всей этой шумихи, все же был положительный эффект. До общественности наконец начало доходить, как много жизненно важных систем зависит от компьютеров и микропроцессоров и как важно следить за их ПО и своевременно его обслуживать.
2. Терак-25
Плохой код на самом деле может убить. Такая катастрофа произошла с аппаратом лучевой терапии Therac-25, произведенным компанией Atomic Energy of Canada, ставшего причиной гибели не менее шести пациентов. Расследование выявило недоработку системы, вызвавшую передозировку радиацией. Связано это было с трудностью проведения автоматизированных тестов такого специфического программного обеспечения. И поэтому машина, призванная помочь людям, стала машиной для убийств из научной фантастики. Этот случай заставил разработчиков ПО медицинской отрасли крайне ответственно подходить к тестированию такого оборудования.
3. Сеть AT&T выходит из строя
15 января 1990 года около 50 процентов мобильной сети AT&T вышло из строя. За девять часов простоя более 75 миллионов звонков остались без ответа. И хотя в первоначальных отчетах следствия по этому делу значилось хакерская атака, на самом деле, виновником сего происшествия стало стандартное обновление ПО. Ошибка всего в одной строке кода стоила компании огромных денег. Все организации, целиком зависящие от наличия и качества связи, выставили AT&T иски с внушительными суммами. К примеру, крупнейший авиаперевозчик American Airlines, понес колоссальные финансовые убытки из-за того, что получил наполовину меньше звонков своих клиентов из-за сбоя. Авария 1990 года до сих пор служит прекрасным примером важности тестирования программного обеспечения и служит напоминанием о неразрывной связи между технологиями и экономической деятельностью большинства компаний.
4. Досрочное освобождение заключенных
В 2005 году в США штате Мичиган произошел сбой тюремной программы, отвечающей за расчет срока наказания заключенных, в результате чего более 20 заключенных досрочно вышли на свободу. Программа ошибочно посчитала смягчающий коэффициент и снизила срок пребывания отбывающих наказание людей в несколько раз. Ошибку в коде заметили не сразу, а лишь по прошествии некоторого времени. И поэтому меру пресечения счастливчикам никто не пересчитывал. Среди них, к слову, не было матерых гангстеров и маньяков. В основном это были мелкие правонарушители, отбывавшие срок за неуплату алиментов, махинации с налогами и незаконное хранение психотропов.
Произошедшее показывает, что в погоне за автоматизацией процессов и сокращением количества ручных операций программисты зачастую забывают о грамотной настройке разработанной системы и ее тестировании. А мы с вами в очередной раз убеждаемся, что даже незначительная ошибка может привести к серьезным последствиям.
5. Взрыв Ariane 5
Случай произошел 4 июня 1996 года при первом запуске Ariane 5 — одной из самых надежных беспилотных ракетных установок, целью которой было изучение взаимодействия между солнечным ветром и магнитосферой Земли. Через 37 секунд после старта ракета, вылетевшая с космодрома, находящегося на берегах Французской Гвианы, развернулась на 90 градусов и всего через несколько секунд превратилась в огромный огненный шар.
Специальная группа прочесала место происшествия, собирая обломки, чтобы попытаться выяснить, что произошло. Через некоторое время техническая комиссия установила, что авария была вызвана программным сбоем.
Отказ системы произошел из-за полной потери информации о точности наведения ракеты и ориентации ее в пространстве, поступающей в центральный процессор. Потеря — следствие ошибки проектировщиков ПО и вызвана она была некорректным преобразованием 64-битного числа с плавающей запятой в 16-битное целое число.
К слову, целочисленное переполнение является широко распространенной ошибкой в компьютерном программировании.
6. Ошибка Paypal
Что бы вы сделали, если бы PayPal случайно зачислил на ваш счет 92 квадриллиона долларов? Крису Рейнольдсу, 56-летнему американцу, продающему автозапчасти на eBay, не пришлось долго об этом думать. Ведь он даже не успел ощутить себя первым в мире квадриллионером и самым богатым человеком в мире, так как ошибка была устранена в течение нескольких минут. Поэтому, прежде чем мужчина начал мечтать о новом кадиллаке и золотой карте члена королевского яхт-клуба, сумма на его счету вернулась к привычному балансу. Конечно, стоило бы потребовать с компании хотя бы часть этой суммы за моральный ущерб, но, видимо, шок от увиденного не позволил ему сделать это.
7. Калькулятор Windows
Эта ошибка, существующая в большинстве версий Windows (кроме Windows 10), которую вы сможете проверить самостоятельно.
Для этого нужно:
- Открыть калькулятор Windows и ввести 4.
- Извлечь из этого числа квадратный корень и получите 2.
- Вычесть из него 2 и вместо нулевого результата в разных версиях Windows вы увидите разные результаты.
Причиной ошибки является недоработка, вызванная некорректным обращением калькулятора с операциями sqrt. В итоге результаты сохраняются как числа с плавающей запятой, а не целые числа, вызывая ошибку точности при дальнейших вычислениях, которую вы можете видеть.
Microsoft признала эту ошибку в приложении калькулятора и исправила ее в Windows 10.
8. Проблема 2038 года
Ошибка 2038 будет вызвана использованием 32-разрядных процессоров в 32-разрядных системах. Проще говоря, 19 января 2038 года наступит в 03:14:07. Компьютеры, которые все еще используют 32-разрядные системы для управления датой и временем, не смогут справиться с этим изменением. Как и в случае с ошибкой 2000 года, компьютеры не смогут отличить 2038 год от 1970 года.
Однако волноваться не стоит: почти все современные процессоры в настольных ПК имеют 64-битные системы с 64-битным программным обеспечением и в 2038 году само существование 32-битных систем будет под вопросом.
9. Видео Gangnam Style «сломало» YouTube
Счетчик YouTube ранее использовал 32-битное целое число для определения максимального количества просмотров видеоролика, и равно оно было 2 147 483 647.
Однако корейская поп-группа PSY, выложившая на сервис свой клип с зажигательной песней Gangnam Style благополучно его сломала, превысив допустимую планку.
«Когда мы его делали, никогда не думали, что какое-нибудь видео посмотрят столько раз, но это было до Gangman Style», — написал на своей странице в сети один из разработчиков портала.
Клип PSY опубликовали 15 июля 2012 года и к концу мая 2014 года он стал единственным видеороликом, которой просмотрели больше 2 млрд раз.
В настоящее время YouTube использует 64-битное целое число для счетчика видео, что означает, что максимальное количество просмотров видео составляет 9,22 квинтиллиона.
10. Синий экран смерти
BSOD или «Синий экран смерти» — жаргонное название фатальной системной ошибки Windows, показывающей системный сбой, при котором операционка достигала состояния, в котором она больше не могла надежно работать. Как правило, вызывалась она в Windows 95-98 после неожиданного завершения важного процесса или общего сбоя оборудования. Старожилы наверняка помнят этот баг, который довольно часто возникал на заре становления ИТ-культуры.
16 марта 2000 года Microsoft выпустила обновление для системы безопасности, устраняющее эту неполадку, однако и сейчас на форумах изредка можно встретить сообщение от пользователей об этой проблеме.
***
Людям свойственно совершать ошибки. Однако, будьте внимательны — всегда нужно помнить, что даже одна плохо написанная строчка кода может привести к печальным последствиям. Удачи!
Материалы по теме
- ⚠️ 10 самых распространенных ошибок, ежедневно допускаемых каждым программистом
- ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
- 😢 Дорогостоящие ошибки: почему нам пришлось отказаться от Firebase
Ошибки в программировании – дело обычное, хоть и неприятное. В данной статье будет рассказано о том, какими бывают ошибки (баги), а также что собой представляют исключения.
Определение
Ошибка в программировании (или так называемый баг) – это ситуация у разработчиков, при которой определенный код вследствие обработки выдает неверный результат. Причин данному явлению множество: неисправность компилятора, сбои интерфейса, неточности и нарушения в программном коде.
Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:
- Появляется сообщение об ошибке, но приложение продолжает функционировать.
- ПО вылетает или зависает. Никаких предупреждений или предпосылок этому не было. Процедура осуществляется неожиданно для пользователя. Возможен вариант, при котором контент перезапускается самостоятельно и непредсказуемо.
- Одно из событий, описанных ранее, сопровождается отправкой отчетов разработчикам.
Ошибки в программах могут привести соответствующее приложение в негодность, а также к непредсказуемым алгоритмам функционирования. Желательно обнаруживать баги на этапе ранней разработки или тестирования. Лишь в этом случае программист сможет оперативно и относительно недорого внести необходимые изменения в код для отладки ПО.
История происхождения термина
Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:
- 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
- Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.
Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.
Как классифицируют
Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:
- Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
- Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
- Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.
Последний вариант требует особого внимания со стороны программистов. Их стараются обнаружить и устранить в первую очередь. Критические ошибки могут отложить релиз исходной программы на неопределенный срок.
Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.
Иногда может получиться так, что ошибка возникает только на устройстве конкретного пользователя. В данном случае устранение неполадки требует индивидуального подхода. Иногда – полной замены компьютера. Связано это с тем, что никто не будет редактировать исходный код, когда он «глючит» только у одного пользователя.
Виды
Существуют различные типы ошибок в программах в зависимости от типовых условий использования приложений. Пример – сбои, которые возникают при возрастании нагрузки на оперативную память или центральный процессор устройства. Есть баги граничных условий, сбоя идентификаторов, несовместимости с архитектурой процессора (наиболее распространенная проблема на мобильных устройствах).
Разработчики выделяют следующие типы ошибок по уровню сложности:
- «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
- «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
- «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
- «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.
Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.
Типы багов
Ошибки в программах бывают:
- логическими;
- синтаксическими;
- взаимодействия;
- компиляционные;
- ресурсные;
- арифметические;
- среды выполнения.
Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.
Ошибки синтаксиса
Синтаксические баги распространены среди новичков. Они относятся к категории «самых безобидных». С данной категорией ошибок способны справиться компиляторы тех или иных языков. Соответствующие инструменты показывают, где допущена неточность. Остается лишь понять, как исправить ее.
Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:
Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.
Логические
Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».
Логические сбои обычного типа – самые сложные и неприятные. Их тяжелее всего обнаружить и исправить. С точки зрения языка программа может быть написана идеально, но работать неправильно. Подобное явление – следствие логической ошибки. Компиляторы их не обнаруживают.
Выше – пример логической ошибки в программе. Тут:
- Происходит сравнение значения i с 15.
- На экран выводится сообщение, если I = 15.
- В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.
Может показаться, что ошибка безобидная. В приведенном примере так и есть, но в более крупных программах такое явление приводит к серьезным последствиям.
Время выполнения
Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.
Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.
Компиляционный тип
Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.
Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.
Ресурсные
Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.
Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.
Взаимодействие
Подразумевается взаимодействие с аппаратным или программным окружением. Пример – ошибка при использовании веб-протоколов. Это приведет к тому, что облачный сервис не будет нормально функционировать. При постоянном возникновении соответствующей неполадки остается один путь – полностью переписывать «проблемный» участок кода, ответственный за соответствующий баг.
Исключения и как избежать багов
Исключение – событие, при возникновении которых начинается «неправильное» поведение программы. Механизм, необходимый для стабилизации обработки неполадок независимо от типа ПО, платформ и иных условий. Помогают разрабатывать единые концепции ответа на баги со стороны операционной системы или контента.
Исключения бывают:
- Программными. Они генерируются приложением или ОС.
- Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.
Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.
P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.
Дефекты программного обеспечения можно обнаружить на каждом этапе разработки и тестирования продукта. Чтобы гарантировать исправление наиболее серьезных дефектов программного обеспечения, тестировщикам важно иметь хорошее представление о различных типах дефектов, которые могут возникнуть.
В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.
Что такое дефект?
Дефект программного обеспечения — это ошибка, изъян, сбой или неисправность в компьютерной программе, из-за которой она выдает неправильный или неожиданный результат или ведет себя непреднамеренным образом. Программная ошибка возникает, когда фактические результаты не совпадают с ожидаемыми. Разработчики и программисты иногда допускают ошибки, которые создают ошибки, называемые дефектами. Большинство ошибок возникает из-за ошибок, которые допускают разработчики или программисты.
Обязательно прочтите: Разница между дефектом, ошибкой, ошибкой и сбоем
Типы программных ошибок при тестировании программного обеспечения
Существует множество различных типов дефектов программного обеспечения, и тестировщикам важно знать наиболее распространенные из них, чтобы они могут эффективно тестировать их.
Ошибки программного обеспечения подразделяются на три типа:
- Дефекты программного обеспечения по своей природе
- Дефекты программного обеспечения по их приоритету
- Дефекты программного обеспечения по их серьезности
Обычно мы можем видеть приоритет и серьезность классификаторов в большинстве инструментов отслеживания ошибок. Если мы настроим классификатор в соответствии с характером ошибки, а также приоритетом и серьезностью, это поможет легко управлять распределением обязанностей по исправлению ошибок соответствующим командам.
#1. Дефекты программного обеспечения по своей природе
Ошибки в программном обеспечении имеют широкий спектр природы, каждая из которых имеет свой собственный набор симптомов. Несмотря на то, что таких багов много, сталкиваться с ними можно не часто. Вот наиболее распространенные ошибки программного обеспечения, классифицированные по характеру, с которыми вы, скорее всего, столкнетесь при тестировании программного обеспечения.
#1. Функциональные ошибки
Как следует из названия, функциональные ошибки — это те, которые вызывают сбои в работе программного обеспечения. Хорошим примером этого может служить кнопка, при нажатии на которую должно открываться новое окно, но вместо этого ничего не происходит.
Функциональные ошибки можно исправить, выполнив функциональное тестирование.
#2. Ошибки на уровне модуля
Ошибки на уровне модуля — это дефекты, связанные с функциональностью отдельного программного модуля. Программный модуль — это наименьшая тестируемая часть приложения. Примеры программных модулей включают классы, методы и процедуры. Ошибки на уровне подразделения могут существенно повлиять на общее качество программного обеспечения.
Ошибки на уровне модуля можно исправить, выполнив модульное тестирование.
#3. Ошибки уровня интеграции
Ошибки уровня интеграции — это дефекты, возникающие при объединении двух или более программных модулей. Эти дефекты может быть трудно найти и исправить, потому что они часто требуют координации между несколькими командами. Однако они могут оказать существенное влияние на общее качество программного обеспечения.
Ошибки интеграции можно исправить, выполнив интеграционное тестирование.
#4. Дефекты юзабилити
Ошибки юзабилити — это дефекты, влияющие на работу пользователя с программным обеспечением и затрудняющие его использование. Дефект юзабилити — это дефект пользовательского опыта программного обеспечения, который затрудняет его использование. Ошибки юзабилити — это такие ошибки, как если веб-сайт сложен для доступа или обойти, или процесс регистрации сложен для прохождения.
Во время тестирования удобства использования тестировщики программного обеспечения проверяют приложения на соответствие требованиям пользователей и Руководству по доступности веб-контента (WCAG) для выявления таких проблем. Однако они могут оказать существенное влияние на общее качество программного обеспечения.
Ошибки, связанные с удобством использования, можно исправить, выполнив тестирование удобства использования.
#5. Дефекты производительности
Ошибки производительности — это дефекты, влияющие на производительность программного обеспечения. Это может включать в себя такие вещи, как скорость программного обеспечения, объем используемой памяти или количество потребляемых ресурсов. Ошибки уровня производительности сложно отследить и исправить, поскольку они могут быть вызваны рядом различных факторов.
Ошибки юзабилити можно исправить, выполнив тестирование производительности.
#6. Дефекты безопасности
Ошибки безопасности — это тип дефекта программного обеспечения, который может иметь серьезные последствия, если его не устранить. Эти дефекты могут позволить злоумышленникам получить доступ к конфиденциальным данным или системам или даже позволить им получить контроль над уязвимым программным обеспечением. Таким образом, очень важно, чтобы ошибкам уровня безопасности уделялось первоочередное внимание и устранялись как можно скорее.
Ошибки безопасности можно исправить, выполнив тестирование безопасности.
#7. Дефекты совместимости
Дефекты совместимости — это те ошибки, которые возникают, когда приложение несовместимо с оборудованием, на котором оно работает, или с другим программным обеспечением, с которым оно должно взаимодействовать. Несовместимость программного и аппаратного обеспечения может привести к сбоям, потере данных и другому непредсказуемому поведению. Тестировщики должны знать о проблемах совместимости и проводить соответствующие тесты. Программное приложение, имеющее проблемы с совместимостью, не работает последовательно на различных видах оборудования, операционных системах, веб-браузерах и устройствах при подключении к определенным программам или работе в определенных сетевых условиях.
Ошибки совместимости можно исправить, выполнение тестирования совместимости.
#8. Синтаксические ошибки
Синтаксические ошибки являются самым основным типом дефекта. Они возникают, когда код нарушает правила языка программирования. Например, использование неправильной пунктуации или забывание закрыть скобку может привести к синтаксической ошибке. Синтаксические ошибки обычно мешают запуску кода, поэтому их относительно легко обнаружить и исправить.
#9. Логические ошибки
Логические ошибки — это дефекты, из-за которых программа выдает неправильные результаты. Эти ошибки может быть трудно найти и исправить, потому что они часто не приводят к каким-либо видимым ошибкам. Логические ошибки могут возникать в любом типе программного обеспечения, но они особенно распространены в приложениях, требующих сложных вычислений или принятия решений.
Общие симптомы логических ошибок включают:
- Неверные результаты или выходные данные
- Неожиданное поведение
- Сбой или зависание программного обеспечения
Чтобы найти и исправить логические ошибки, тестировщикам необходимо иметь четкое представление о коде программы и о том, как она должна работать. Часто лучший способ найти такие ошибки — использовать инструменты отладки или пошаговое выполнение, чтобы отслеживать выполнение программы и видеть, где что-то идет не так.
#2. Дефекты программного обеспечения по степени серьезности
Уровень серьезности присваивается дефекту по его влиянию. В результате серьезность проблемы отражает степень ее влияния на функциональность или работу программного продукта. Дефекты серьезности классифицируются как критические, серьезные, средние и незначительные в зависимости от степени серьезности.
#1. Критические дефекты
Критический дефект — это программная ошибка, имеющая серьезные или катастрофические последствия для работы приложения. Критические дефекты могут привести к сбою, зависанию или некорректной работе приложения. Они также могут привести к потере данных или уязвимостям в системе безопасности. Разработчики и тестировщики часто придают первостепенное значение критическим дефектам, поскольку их необходимо исправить как можно скорее.
#2. Серьезные дефекты
Серьезный дефект — это программная ошибка, существенно влияющая на работу приложения. Серьезные дефекты могут привести к замедлению работы приложения или другому неожиданному поведению. Они также могут привести к потере данных или уязвимостям в системе безопасности. Разработчики и тестировщики часто придают первостепенное значение серьезным дефектам, поскольку их необходимо исправить как можно скорее.
#3. Незначительные дефекты
Незначительный дефект — это программная ошибка, которая оказывает небольшое или незначительное влияние на работу приложения. Незначительные дефекты могут привести к тому, что приложение будет работать немного медленнее или демонстрировать другое неожиданное поведение. Разработчики и тестировщики часто не придают незначительным дефектам приоритет, потому что их можно исправить позже.
#4. Тривиальные дефекты
Тривиальный дефект – это программная ошибка, не влияющая на работу приложения. Тривиальные дефекты могут привести к тому, что приложение отобразит сообщение об ошибке или проявит другое неожиданное поведение. Разработчики и тестировщики часто присваивают тривиальным дефектам самый низкий приоритет, потому что они могут быть исправлены позже.
#3. Дефекты программного обеспечения по приоритету
#1. Дефекты с низким приоритетом
Дефекты с низким приоритетом, как правило, не оказывают серьезного влияния на работу программного обеспечения и могут быть отложены для исправления в следующей версии или выпуске. В эту категорию попадают косметические ошибки, такие как орфографические ошибки, неправильное выравнивание и т. д.
#2. Дефекты со средним приоритетом
Дефекты со средним приоритетом — это ошибки, которые могут быть исправлены после предстоящего выпуска или в следующем выпуске. Приложение, возвращающее ожидаемый результат, которое, однако, неправильно форматируется в конкретном браузере, является примером дефекта со средним приоритетом.
#3. Дефекты с высоким приоритетом
Как следует из названия, дефекты с высоким приоритетом — это те, которые сильно влияют на функционирование программного обеспечения. В большинстве случаев эти дефекты необходимо исправлять немедленно, так как они могут привести к серьезным нарушениям нормального рабочего процесса. Дефекты с высоким приоритетом обычно классифицируются как непреодолимые, так как они могут помешать пользователю продолжить выполнение поставленной задачи.
Некоторые распространенные примеры дефектов с высоким приоритетом включают:
- Дефекты, из-за которых приложение не работает. сбой
- Дефекты, препятствующие выполнению задачи пользователем
- Дефекты, приводящие к потере или повреждению данных
- Дефекты, раскрывающие конфиденциальную информацию неавторизованным пользователям
- Дефекты, делающие возможным несанкционированный доступ к системе
- Дефекты, приводящие к потере функциональности
- Дефекты, приводящие к неправильным результатам или неточным данным
- Дефекты, вызывающие проблемы с производительностью, такие как чрезмерное использование памяти или медленное время отклика
#4. Срочные дефекты
Срочные дефекты — это дефекты, которые необходимо устранить в течение 24 часов после сообщения о них. В эту категорию попадают дефекты со статусом критической серьезности. Однако дефекты с низким уровнем серьезности также могут быть классифицированы как высокоприоритетные. Например, опечатка в названии компании на домашней странице приложения не оказывает технического влияния на программное обеспечение, но оказывает существенное влияние на бизнес, поэтому считается срочной.
#4. Дополнительные дефекты
#1. Отсутствующие дефекты
Отсутствующие дефекты возникают из-за требований, которые не были включены в продукт. Они также считаются несоответствиями спецификации проекта и обычно негативно сказываются на пользовательском опыте или качестве программного обеспечения.
#2. Неправильные дефекты
Неправильные дефекты — это те дефекты, которые удовлетворяют требованиям, но не должным образом. Это означает, что хотя функциональность достигается в соответствии с требованиями, но не соответствует ожиданиям пользователя.
#3. Дефекты регрессии
Дефект регрессии возникает, когда изменение кода вызывает непреднамеренное воздействие на независимую часть программного обеспечения.
Часто задаваемые вопросы — Типы программных ошибок< /h2>
Почему так важна правильная классификация дефектов?
Правильная классификация дефектов важна, поскольку она помогает эффективно использовать ресурсы и управлять ими, правильно приоритизировать дефекты и поддерживать качество программного продукта.
Команды тестирования программного обеспечения в различных организациях используют различные инструменты отслеживания дефектов, такие как Jira, для отслеживания дефектов и управления ими. Несмотря на то, что в этих инструментах есть несколько вариантов классификации дефектов по умолчанию, они не всегда могут наилучшим образом соответствовать конкретным потребностям организации.
Следовательно, важно сначала определить и понять типы дефектов программного обеспечения, которые наиболее важны для организации, а затем соответствующим образом настроить инструмент управления дефектами.
Правильная классификация дефектов также гарантирует, что команда разработчиков сможет сосредоточиться на критических дефектах и исправить их до того, как они повлияют на конечных пользователей.
Кроме того, это также помогает определить потенциальные области улучшения в процессе разработки программного обеспечения, что может помочь предотвратить появление подобных дефектов в будущих выпусках.
Таким образом, отслеживание и устранение дефектов программного обеспечения может показаться утомительной и трудоемкой задачей. , правильное выполнение может существенно повлиять на качество конечного продукта.
Как найти лежащие в основе ошибки программного обеспечения?
Определение основной причины программной ошибки может быть сложной задачей даже для опытных разработчиков. Чтобы найти лежащие в основе программные ошибки, тестировщики должны применять систематический подход. В этот процесс входят различные этапы:
1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.
Заключение
В индустрии программного обеспечения дефекты — неизбежная реальность. Однако благодаря тщательному анализу и пониманию их характера, серьезности и приоритета дефектами можно управлять, чтобы свести к минимуму их влияние на конечный продукт.
Задавая правильные вопросы и применяя правильные методы, тестировщики могут помочь обеспечить чтобы дефекты обнаруживались и исправлялись как можно раньше в процессе разработки.
TAG: qa
Годы бегут, компьютеры становятся мощнее, листинги программ длиннее, а программисты всё ещё допускают те же самые ошибки (или же сталкиваются с ними)… Предлагаю разобраться с основными типами ошибок и причинами, по которым они происходят
Чтобы максимально раскрыть смысл фразы «актуально во все времена«, в качестве иллюстрирующих примеров будут приведены сведения времён старой доброй DOS , поэтому материал рекомендуется к прочтению любителям ностальгии
Какие же бывают типы ошибок?
Тип №1. Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании
• В «Справочнике Microsoft Works» и интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как
ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина)
Однако в действительности работа данной функции должна иметь следующий вид:
ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь)
В «Руководстве пользователя Microsoft Works для Windows» пакета Works 3.0 эта ошибка исправлена
• В русифицированном варианте Norton Utilities (версия 7.0, фирма Symantec) в утилите форматирования sformat при задании опции:
Системные файлы: [Не ставить…]
при форматировании выдаётся сообщение:
Системные файлы: Ставить
и наоборот, при задании опции:
Системные файлы: [Ставить…]
при форматировании выдаётся сообщение:
Системные файлы: Не ставить
• Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из-за ошибки в программе – вместо требуемой в операторе запятой программист поставил точку. Вот как был записан этот оператор:
DO 50 I = 12.525
На самом же деле он должен был выглядеть следующим образом:
DO 50 I = 12,525
В программе на Фортране IV требовался цикл, а программист поставил точку, а в результате получилось присваивание значения 12,525 неявной переменной DO50I (пробелы в Фортране игнорируются) [ Спасибо за этот ценный комментарий-поправку хабраюзеру rexxer2 ]
• Потеря связи с космической станцией «Фобос-1» (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.
• Причиной осложнений, возникших при возвращении на Землю из космической экспедиции советско-афганского и советско-французского экипажей, явились ошибки, допущенные в программном обеспечении бортовых компьютеров.
К данному типу относятся ошибки в алгоритмах, когда алгоритм неверный или создан на основе неправильных представлений о действительности:
• Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой»
Тип №2. Ошибки, возникающие при вводе в компьютер неверных данных
Весьма популярные ошибки, предотвращение которых известно под названием «защита от дурака»
• В 1983 году произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.
• Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами
Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу компьютера и выполняемую им программу.
• Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.
Тип 4. Выход из строя элементов компьютера и обслуживающих его систем
Тут, в принципе, всё обстоит точно так же, как и 20 лет назад: в процессе эксплуатации компьютерной системы возможно физическое повреждение накопителя, выход из строя блока питания, отключение электроэнергии, колебание напряжения в электрической сети и др. Результатом такого рода неисправностей может быть полная потеря информации, хранящейся на жёстком диске, частичная или полная потеря информации в файлах баз данных, нарушение работы систем, управляемых компьютером и многое другое. Для предотвращения ошибок данного типа используют системы, в которых одновременно работают несколько компьютеров, дублирующих друг друга, в компьютеры устанавливают два и более параллельно работающих накопителя (вспоминаем RAID-массивы), аппаратуру подключают к источникам бесперебойного питания, которые обеспечивают его работу при отключении электроэнергии или колебаниях напряжения электрической сети и т.д. и т.п.
Тип №5. Выход из строя или сбои в работе измерительных приборов и датчиков, используемых при управлении какими-либо техническими системами и технологическими процессами
• В июле 1985 года произошло преждевременное отключение компьютера одного из основных двигателей американского космического корабля «Челленджер» (Шаттл), едва не закончившееся катастрофой. Положение спас командир корабля, сумевший на двух работающих основных двигателях и двух менее мощных двигателях для маневрирования вывести «Челленджер» на орбиту. Причина же заключалась в том, что один из трёх бортовых компьютеров, управляющих двигателями (на каждый двигатель по компьютеру), был «обманут» вышедшим из строя датчиком, измеряющим температуру газа в двигателе. Для устранения подобных неполадок в будущем на следующих космических кораблях серии Шаттл были установлены датчики изменённой конструкции.
• При запуске французской ракеты нового поколения «Ариан-5» примерно на 37-й секунде полёта компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты. Исходя из этой информации, компьютер начал корректировать траекторию полёта для того, чтобы компенсировать не существующую на самом деле погрешность. Ракета стала отклоняться от курса, что привело к возрастанию нагрузок на её корпус. В результате чрезмерных нагрузок верхняя часть ракеты отвалилась, и по команде с земли ракета была взорвана.
Тип 6. «Злая воля человека», носителем которой чаще всего выступает либо программист, либо оператор
Программист, создавая программу, может специально внести в неё ошибку . Другим вариантом проявления «злой воли программиста» является включение в программу «логической бомбы», срабатывающей, например, после определённого числа запусков программы, определённых значениях входных данных и др. Оператор, обслуживающий компьютер, может сознательно ввести в компьютер неверные данные, которые и будут обработаны компьютером, выдавая неверные выходные данные в соответствии с принципом «мусор на входе – мусор на выходе».
• Сборочный конвейер волжского автомобильного завода в городе Тольятти работает под управлением АСУ, которая обеспечивает своевременное поступление деталей на конвейер со складов и из цехов вспомогательных производств. Для выполнения этой задачи информационно-управляющая система хранит информацию о тысячах узлов и деталей, из которых собирается автомобиль, о запасах деталей на складах, об их движении по транспортным линиям и т. д. На основе этой информации АСУ самостоятельно управляет автоматизированными складами, транспортными конвейерами, а также рядом других устройств.
Программист, разрабатывавший программное обеспечение для управления главным конвейером Волжского автозавода, сознательно внёс в программу «логическую бомбу» в знак протеста против низкой зарплаты. Через некоторое время эта «логическая бомба» сработала, и главный конвейер остановился на несколько дней. Ущерб от остановки составил 1 миллион рублей (в ценах 80-х годов), этот ущерб был несопоставим с зарплатой всех программистов ВАЗа, вместе взятых, а программист был дисквалифицирован и переведён в рабочие.
Подводим итоги
Анализ приведённых типов ошибок показывает, что основными задачами, стоящими перед разработчиками программного обеспечения в плане повышения его надёжности, является:
- устранение ошибок, допущенных при разработке программного обеспечения (1-й тип ошибок);
- проектирование программного обеспечения с учётом человеческого фактора, то есть таким образом, чтобы оно было защищено от «дурака» (2-й тип ошибок). При этом «свалять дурака» могут не только пользователи, работающие за компьютером, но и приборы и датчики, от которых компьютер принимает информацию при управлении техническими или иными системами (5-й тип ошибок);
- использование известных мер безопасности для снижения вероятности переноса компьютерных вирусов (3-й тип ошибок) с программами, передаваемыми в эксплуатацию (в практике распространения программ известны случаи, когда разработчики этих программ записывают дистрибутивы на заражённых вирусами компьютерах).
Таким образом, программный продукт в обязательном порядке должен проходить тщательное тестирование и отладку (выявление ошибок 1-го и 2-го типов). Выявление возможных ошибок 5-го типа производится с помощью имитации отказа приборов и датчиков на прошедших тестирование программных комплексах.
Надеюсь, данный материал окажется полезным. Желаю всем делать поменьше ошибок, ведь это особенно актуально в нынешние кризисные времена :^)
PS: сведения предоставляются по данным из этих источников, множество важных дополнений и опровержений представлены ниже в комментариях, особенно от хабраюзера scoon. Однако оригинальный текст не изменяю
From Wikipedia, the free encyclopedia
Many software bugs are merely annoying or inconvenient but some can have extremely serious consequences – either financially or as a threat to human well-being.[1] The following is a list of software bugs with significant consequences.
Space[edit]
- A booster went off course during launch, resulting in the destruction of NASA Mariner 1. This was the result of the failure of a transcriber to notice an overbar in a written specification for the guidance program, resulting in the coding of an incorrect formula in its FORTRAN software. (July 22, 1962).[2] The initial reporting of the cause of this bug was incorrect.[3]
- NASA’s 1965 Gemini 5 mission landed 80 miles (130 km) short of its intended splashdown point when the pilot compensated manually for an incorrect constant for the Earth’s rotation rate. A 360-degree rotation corresponding to the Earth’s rotation relative to the fixed stars was used instead of the 360.98-degree rotation in a 24-hour solar day. The shorter length of the first three missions and a computer failure on Gemini 4 prevented the bug from being detected earlier.[4]
- The Russian Space Research Institute’s Phobos 1 (Phobos program) deactivated its attitude thrusters and could no longer properly orient its solar arrays or communicate with Earth, eventually depleting its batteries. (September 10, 1988).[5]
- The European Space Agency’s Ariane flight V88 was destroyed 40 seconds after takeoff (June 4, 1996). The US$1 billion prototype rocket self-destructed due to a bug in the on-board guidance software.[6][7]
- In 1997, the Mars Pathfinder mission was jeopardised by a bug in concurrent software shortly after the rover landed, which was found in preflight testing but given a low priority as it only occurred in certain unanticipated heavy-load conditions.[8] The problem, which was identified and corrected from Earth, was due to computer resets caused by priority inversion.[9]
- In 2000, a Zenit 3SL launch failed due to faulty ground software not closing a valve in the rocket’s second stage pneumatic system.[10]
- The European Space Agency’s CryoSat-1 satellite was lost in a launch failure in 2005 due to a missing shutdown command in the flight control system of its Rokot carrier rocket.[11]
- NASA Mars Polar Lander was destroyed because its flight software mistook vibrations caused by the deployment of the stowed legs for evidence that the vehicle had landed and shut off the engines 40 meters from the Martian surface (December 3, 1999).[12]
- Its sister spacecraft Mars Climate Orbiter was also destroyed, due to software on the ground generating commands based on parameters in pound-force (lbf) rather than newtons (N).
- A mis-sent command from Earth caused the software of the NASA Mars Global Surveyor to incorrectly assume that a motor had failed, causing it to point one of its batteries at the sun. This caused the battery to overheat (November 2, 2006).[13][14]
- NASA’s Spirit rover became unresponsive on January 21, 2004, a few weeks after landing on Mars. Engineers found that too many files had accumulated in the rover’s flash memory. It was restored to working condition after deleting unnecessary files.[15]
- Japan’s Hitomi astronomical satellite was destroyed on March 26, 2016, when a thruster fired in the wrong direction, causing the spacecraft to spin faster instead of stabilize.[16]
- Israel’s first attempt to land an unmanned spacecraft on the moon with the Beresheet was rendered unsuccessful on April 11, 2019, due to a software bug with its engine system, which prevented it from slowing down during its final descent on the moon’s surface. Engineers attempted to correct this bug by remotely rebooting the engine, but by the time they regained control of it, Beresheet could not slow down in time to avert a hard, crash landing that disintegrated it.[17]
Medical[edit]
- A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of beta radiation.[18][19][20]
- Radiation therapy planning software RTP/2 created by Multidata Systems International could incorrectly double the dosage of radiation depending on how the technician entered data into the machine. At least eight patients died, while another 20 received overdoses likely to cause significant health problems (November 2000).[21] See also Instituto Oncológico Nacional#Accident
- A Medtronic heart device was found vulnerable to remote attacks (2008-03).[22]
- The Becton Dickinson Alaris Gateway Workstation allows unauthorized arbitrary remote execution (2019).[23][24]
- The CareFusion Alaris pump module (8100) will not properly delay an Infusion when the «Delay Until» option or «Multidose» feature is used (2015).[25]
Tracking years[edit]
- The year 2000 problem spawned fears of worldwide economic collapse and an industry of consultants providing last-minute fixes.[26]
- A similar problem will occur in 2038 (the year 2038 problem), as many Unix-like systems calculate the time in seconds since 1 January 1970, and store this number as a 32-bit signed integer, for which the maximum possible value is 231 − 1 (2,147,483,647) seconds.[27]
- An error in the payment terminal code for Bank of Queensland rendered many devices inoperable for up to a week. The problem was determined to be an incorrect hexadecimal number conversion routine. When the device was to tick over to 2010, it skipped six years to 2016, causing terminals to decline customers’ cards as expired.[28]
Electric power transmission[edit]
- The Northeast blackout of 2003 was triggered by a local outage that went undetected due to a race condition in General Electric Energy’s XA/21 monitoring software.[29]
Administration[edit]
- The software of the A2LL system for handling unemployment and social services in Germany presented several errors with large-scale consequences, such as sending the payments to invalid account numbers in 2004.[citation needed]
Telecommunications[edit]
- AT&T long-distance network crash (January 15, 1990), in which the failure of one switching system would cause a message to be sent to nearby switching units to tell them that there was a problem. Unfortunately, the arrival of that message would cause those other systems to fail too – resulting in a cascading failure that rapidly spread across the entire AT&T long-distance network.[30][31]
- In January 2009, Google’s search engine erroneously notified users that every web site worldwide was potentially malicious, including its own.[32]
- In May 2015, iPhone users discovered a bug where sending a certain sequence of characters and Unicode symbols as a text to another iPhone user would crash the receiving iPhone’s SpringBoard interface,[33] and may also crash the entire phone, induce a factory reset, or disrupt the device’s connectivity to a significant degree,[34] preventing it from functioning normally. The bug persisted for weeks, gained substantial notoriety and saw a number of individuals using the bug to play pranks on other iOS users,[citation needed] before Apple eventually patched it on June 30, 2015, with iOS 8.4.
Military[edit]
- The software error of a MIM-104 Patriot caused its system clock to drift by one third of a second over a period of one hundred hours – resulting in failure to locate and intercept an incoming Iraqi Al Hussein missile, which then struck Dharan barracks, Saudi Arabia (February 25, 1991), killing 28 Americans.[35][36]
- A Royal Air Force Chinook helicopter crashed into the Mull of Kintyre in June 1994, killing 29. Initially, the crash was dismissed as pilot error, but an investigation by Computer Weekly uncovered sufficient evidence to convince a House of Lords inquiry that it may have been caused by a software bug in the aircraft’s engine control computer.[37]
- Smart ship USS Yorktown was left dead in the water in September 1997 for nearly 3 hours after a divide by zero error.[38]
- In April 1992 the first Lockheed YF-22 crashed while landing at Edwards Air Force Base, California. The cause of the crash was found to be a flight control software error that failed to prevent a pilot-induced oscillation.[39]
- While attempting its first overseas deployment to the Kadena Air Base in Okinawa, Japan, on 11 February 2007, a group of six F-22 Raptors flying from Hickam AFB, Hawaii, experienced multiple computer crashes coincident with their crossing of the 180th meridian of longitude (the International Date Line). The computer failures included at least navigation (completely lost) and communication. The fighters were able to return to Hawaii by following their tankers, something that might have been problematic had the weather not been good. The error was fixed within 48 hours, allowing a delayed deployment.[40]
Media[edit]
- In the Sony BMG copy protection rootkit scandal (October 2005), Sony BMG produced a Van Zant music CD that employed a copy protection scheme that covertly installed a rootkit on any Windows PC that was used to play it. Their intent was to hide the copy protection mechanism to make it harder to circumvent. Unfortunately, the rootkit inadvertently opened a security hole resulting in a wave of successful trojan horse attacks on the computers of those who had innocently played the CD.[41] Sony’s subsequent efforts to provide a utility to fix the problem actually exacerbated it.[42]
Video gaming[edit]
- Eve Online‘s deployment of the Trinity patch erased the boot.ini file from several thousand users’ computers, rendering them unable to boot. This was due to the usage of a legacy system within the game that was also named boot.ini. As such, the deletion had targeted the wrong directory instead of the /eve directory.[43]
- The Corrupted Blood incident was a software bug in World of Warcraft that caused a deadly, debuff-inducing virtual disease that could only be contracted during a particular raid to be set free into the rest of the game world, leading to numerous, repeated deaths of many player characters. This caused players to avoid crowded places in-game, just like in a «real world» epidemic, and the bug became the center of some academic research on the spread of infectious diseases.[44]
- On June 6, 2006, the online game RuneScape suffered from a bug that enabled certain player characters to kill and loot other characters, who were unable to fight back against the affected characters because the game still thought they were in player-versus-player mode even after they were kicked out of a combat ring from the house of a player who was suffering from lag while celebrating an in-game accomplishment. Players who were killed by the glitched characters lost many items, and the bug was so devastating that the players who were abusing it were soon tracked down, caught and banned permanently from the game, but not before they had laid waste to the region of Falador, thus christening the bug «Falador Massacre».[45]
- In the 256th level of Pac-Man, a bug results in a kill screen. The maximum number of fruit available is seven and when that number rolls over, it causes the entire right side of the screen to become a jumbled mess of symbols while the left side remains normal.[46]
- Upon initial release, the ZX Spectrum game Jet Set Willy was impossible to complete because of a severe bug that corrupted the game data, causing enemies and the player character to be killed in certain rooms of the large mansion where the entire game takes place.[47] The bug, known as «The Attic Bug», would occur when the player entered the mansion’s attic, which would then cause an arrow to travel offscreen, overwriting the contents of memory and altering crucial variables and behavior in an undesirable way. The game’s developers initially excused this bug by claiming that the affected rooms were death traps, but ultimately owned up to it and issued instructions to players on how to fix the game itself.[48]
- One of the free demo discs issued to PlayStation Underground subscribers in the United States contained a serious bug, particularly in the demo for Viewtiful Joe 2, that would not only crash the PlayStation 2, but would also unformat any memory cards that were plugged into that console, erasing any and all saved data onto them.[49] The bug was so severe that Sony had to apologize for it and send out free copies of other PS2 games to affected players as consolation.[50]
- Due to a severe programming error, much of the Nintendo DS game Bubble Bobble Revolution is unplayable because a mandatory boss fight failed to trigger in the 30th level.[51]
- An update for the Xbox 360 version of Guitar Hero II, which was intended to fix some issues with the whammy bar on that game’s guitar controllers, came with a bug that caused some consoles to freeze, or even stop working altogether, producing the infamous «red ring of death».[52]
- Valve’s Steam client for Linux could accidentally delete all the user’s files in every directory on the computer. This happened to users that had moved Steam’s installation directory.[53] The bug is the result of unsafe shellscript programming:
-
STEAMROOT="$(cd "${0%/*}" && echo $PWD)" # Scary! rm -rf "$STEAMROOT/"*
- The first line tries to find the script’s containing directory. This could fail, for example if the directory was moved while the script was running, invalidating the «selfpath» variable
$0. It would also fail if$0contained no slash character, or contained a broken symlink, perhaps mistyped by the user. The way it would fail, as ensured by the&&conditional, and not havingset -ecause termination on failure, was to produce the empty string. This failure mode was not checked, only commented as «Scary!». Finally, in the deletion command, the slash character takes on a very different meaning from its role of path concatenation operator when the string before it is empty, as it then names the root directory.
- Minus World is an infamous glitch level from the 1985 game Super Mario Bros., accessed by using a bug to clip through walls in level 1–2 to reach its «warp zone», which leads to the said level.[54] As this level is endless, triggering the bug that takes the player there will make the game impossible to continue until the player resets the game or runs out of lives.
- «MissingNo.» is a glitch Pokémon species present in Pokémon Red and Blue, which can be encountered by performing a particular sequence of seemingly unrelated actions. Capturing this Pokémon may corrupt the game’s data, according to Nintendo[55][56][57] and some of the players who successfully attempted this glitch. This is one of the most famous bugs in video game history, and continues to be well-known.[58]
Encryption[edit]
- In order to fix a warning issued by Valgrind, a maintainer of Debian patched OpenSSL and broke the random number generator in the process. The patch was uploaded in September 2006 and made its way into the official release; it was not reported until April 2008. Every key generated with the broken version is compromised (as the «random» numbers were made easily predictable), as is all data encrypted with it, threatening many applications that rely on encryption such as S/MIME, Tor, SSL or TLS protected connections and SSH.[59]
- Heartbleed, an OpenSSL vulnerability introduced in 2012 and disclosed in April 2014, removed confidentiality from affected services, causing among other things the shut down of the Canada Revenue Agency’s public access to the online filing portion of its website[60] following the theft of social insurance numbers.[61]
- The Apple «goto fail» bug was a duplicated line of code which caused a public key certificate check to pass a test incorrectly.
- The GnuTLS «goto fail» bug was similar to the Apple bug and found about two weeks later. The GnuTLS bug also allowed attackers to bypass SSL/TLS security. [62]
Transportation[edit]
- By some accounts Toyota’s electronic throttle control system (ETCS) had bugs that could cause sudden unintended acceleration.[63]
- The Boeing 787 Dreamliner experienced an integer overflow bug which could shut down all electrical generators if the aircraft was on for more than 248 days.[64] A similar problem was found in Airbus A350 which need to be powered down before reaching 149 hours of continuous power-on time, otherwise certain avionics systems or functions would partially or completely fail.[65]
- In early 2019, the transportation-rental firm Lime discovered a firmware bug with its electric scooters that can cause them to brake very hard unexpectedly, which may hurl and injure riders.[66]
- Boeing 737 NG had all cockpit displays go blank if a specific type of instrument approach to any one of seven specific airports was selected in the flight management computer.[67]
- Bombardier CRJ-200 equipped with flight management systems by Collins Aerospace would make wrong turns during missed approach procedures executed by the autopilot in some specific cases when temperature compensation was activated in cold weather.[68]
Finance[edit]
- The Vancouver Stock Exchange index had large errors due to repeated rounding. In January 1982 the index was initialized at 1000 and subsequently updated and truncated to three decimal places on each trade. This was done about 3000 times a day. The accumulated truncations led to an erroneous loss of around 25 points per month. Over the weekend of November 25–28, 1983, the error was corrected, raising the value of the index from its Friday closing figure of 524.811 to 1098.892.[69][70]
- Knight Capital Group lost $440 million in 45 minutes due to the improper deployment of software on servers and the re-use of a critical software flag that caused old unused software code to execute during trading.[71]
- Post Office Limited Between 2000 and 2015, 736 subpostmasters were prosecuted by the UK Post Office, with many falsely convicted and sent to prison. This was a result of failure to recognize defects in the Horizon financial software, the subpostmasters were blamed for financial shortfalls which were actually software defects.[72]
Blockchain[edit]
- Ethereum The DAO (organization) bug — 3.6M ETH[73]
See also[edit]
- London Ambulance Service § Innovation
References[edit]
- ^ «Why Software fails». IEEE Spectrum: Technology, Engineering, and Science News. 2 September 2005. Retrieved 2021-03-20.
- ^ «Space FAQ 08/13 — Planetary Probe History». faqs.org. 17 Sep 1996.
- ^ Hoare, C. A. R. Hints on Programming Language Design. in Sigact/Sigplan Symposium on Principles of Programming Languages. October 1973., reprinted in Horowitz. Programming Languages, A Grand Tour, 3rd ed.. See «Mariner 1». RISKS Digest. 9 (54). 12 Dec 1989. and Neumann, Peter G. (30 May 1989). «Mariner I — no holds BARred». The RISKS Digest. 8 (75). Retrieved 2008-01-07.
- ^ «Gemini 5». On The Shoulders of Titans: A History of Project Gemini.
- ^ Sagdeev, R. Z.; Zakharov, A. V. (1989). «Brief history of the Phobos mission». Nature. 341 (6243): 581–585. Bibcode:1989Natur.341..581S. doi:10.1038/341581a0. S2CID 41464654.
- ^ Dowson, M. (March 1997). «The Ariane 5 Software Failure». Software Engineering Notes. 22 (2): 84. doi:10.1145/251880.251992. S2CID 43439273.
- ^ Jézéquel JM, Meyer B (January 1997). «Design by Contract: The Lessons of Ariane» (PDF). IEEE Computer. 30 (1): 129–130. doi:10.1109/2.562936.
- ^ Heaven, Douglas (2013). «Parallel sparking: Many chips make light work». New Scientist. Elsevier BV. 219 (2930): 42–45. doi:10.1016/s0262-4079(13)62046-1. ISSN 0262-4079.
- ^ Reeves, Glenn E (15 Dec 1997). «What really happened on Mars? — Authoritative Account». research.microsoft.com. Archived from the original on 30 December 2016.
{{cite web}}: CS1 maint: unfit URL (link) - ^ «Spaceflight Now | Breaking News | Sea Launch malfunction blamed on software glitch». spaceflightnow.com. Retrieved January 2, 2022.
- ^ «CryoSat Mission lost due to launch failure». European Space Agency. 8 October 2005. Retrieved 19 July 2010.
- ^ «Mars Polar Lander». Archived from the original on 2012-09-27. Retrieved 2008-01-07.
- ^ «Report Reveals Likely Causes of Mars Spacecraft Loss». Retrieved 2008-01-07.
- ^ «Faulty Software May Have Doomed Mars Orbiter». Space.com. Archived from the original on July 24, 2008. Retrieved January 11, 2007.
- ^ «Out of memory problem caused Mars rover’s glitch». computerworld.com. February 3, 2004.
- ^ Witze, Alexandra (2016). «Software error doomed Japanese Hitomi spacecraft». Nature. 533 (7601): 18–19. Bibcode:2016Natur.533…18W. doi:10.1038/nature.2016.19835. PMID 27147012. S2CID 4451754.
- ^ Weitering, Hanneke (12 April 2019). «Israeli Moon Lander Suffered Engine Glitch Before Crash». Space.com. Retrieved 29 May 2019.
- ^ «The Therac-25 Accidents (PDF), by Nancy Leveson» (PDF). Retrieved 2008-01-07.
- ^ «An Investigation of the Therac-25 Accidents (IEEE Computer)». Retrieved 2008-01-07.
- ^ «Computerized Radiation Therapy (PDF) reported by TROY GALLAGHER» (PDF). Retrieved 2011-12-12.
- ^ Garfinkel, Simson (November 8, 2005). «History’s Worst Software Bugs». Wired. Retrieved September 6, 2020.
- ^ Feder, Barnaby J. (2008-03-12). «A Heart Device Is Found Vulnerable to Hacker Attacks». The New York Times. Retrieved 2008-09-28.
- ^ «ICS Advisory (ICSMA-19-164-01)» (Press release). Cybersecurity and Infrastructure Security Agency. 2019-06-13. Retrieved 2019-11-15.
- ^ Newman, Lily Hay (2019-10-01). «Decades-Old Code Is Putting Millions of Critical Devices at Risk». Wired. Retrieved 2019-11-15.
- ^ «Urgent: Medical Device Recall Notification, AFFECTED DEVICE: Alaris® Pump module (Model 8100)»Delay Until» Option and «Multidose» Feature» (PDF) (Press release). CareFusion. 2014-04-23. Archived from the original (PDF) on 2015-06-12. Retrieved 2019-11-15.
- ^ «Looking at the Y2K bug, portal on CNN.com». Archived from the original on 2007-12-27. Retrieved 2008-01-07.
- ^ «The year 2038 bug». Retrieved 2008-01-12.
- ^ Stafford, Patrick. «Businesses hit by Bank of Queensland EFTPOS bug». Archived from the original on 7 April 2014. Retrieved 1 April 2014.
- ^ «Software Bug Contributed to Blackout». Retrieved 2008-01-07.
- ^ Sterling, Bruce (1993). The Hacker Crackdown: Law and Disorder on the Electronic Frontier. Spectra Books. ISBN 0-553-56370-X.
- ^ «The Crash of the AT&T Network in 1990». Retrieved 2008-05-15.
- ^ Metz, Cade (January 31, 2009). «Google mistakes entire web for malware». The Register. Retrieved December 20, 2010.
- ^ «Bug in iOS Unicode handling crashes iPhones with a simple text». Apple Insider. 26 May 2015. Retrieved 29 May 2015.
- ^ Clover, Juli (26 May 2015). «New iOS Bug Crashing iPhones Simply by Receiving a Text Message». MacRumors. Retrieved 29 May 2015.
- ^ «Patriot missile defense, Software problem led to system failure at Dharhan, Saudi Arabia; GAO report IMTEC 92-26». US Government Accounting Office.
- ^ Skeel, Robert. «Roundoff Error and the Patriot Missile». SIAM News, volume 25, nr 4. Archived from the original on 2008-08-01. Retrieved 2008-09-30.
- ^ Rogerson, Simon (April 2002). «The Chinook Helicopter Disaster». IMIS Journal. 12 (2). Archived from the original on 2012-07-17.
- ^ «Software glitches leave Navy Smart Ship dead in the water». gcn.com. 13 Jul 1998. Archived from the original on 8 February 2006.
- ^ «F/A-22 Program History». f-22raptor.com. Archived from the original on 25 August 2009.
- ^ «Lockheed’s F-22 Raptor Gets Zapped by International Date Line». DailyTech. 26 Feb 2007. Archived from the original on 16 March 2007.
- ^ Borland, John (11 November 2005). «FAQ: Sony’s ‘rootkit’ CDs — CNET News». news.com. Archived from the original on 5 December 2008.
{{cite web}}: CS1 maint: unfit URL (link) - ^ Russinovich, Mark (4 Nov 2005). «Mark’s Blog : More on Sony: Dangerous Decloaking Patch, EULAs and Phoning Home». blogs.technet.com. Archived from the original on 3 January 2007.
- ^ «About the boot.ini issue (Dev Blog)». Retrieved 2014-09-30.
- ^ Balicer, Ran (2005-10-05). «Modeling Infectious Diseases Dissemination Through Online Role-Playing Games». Epidemiology. 18 (2): 260–261. doi:10.1097/01.ede.0000254692.80550.60. PMID 17301707. S2CID 20959479.
- ^ Bishop, Sam (8 June 2016). «Runescape marks the anniversary of the Falador Massacre». GameFactor. Retrieved 9 August 2018.
- ^ «Pac Man’S Split Screen Level Analyzed And Fixed». Donhodges.Com. Retrieved 2012-09-19.
- ^ Langshaw, Mark (30 September 2010). «Retro Corner: ‘Jet Set Willy’ (Spectrum)». Digital Spy. Retrieved 30 May 2018.
- ^ «Jet Set Willy Solved!». Personal Computer Games (8): 21. July 1984. Retrieved 2014-04-19.
- ^ Krotoski, Aleks (2004-11-30). «Viewtiful Joe 2 demo deletes memory cards». The Guardian. Retrieved 2009-11-10.
- ^ Bramwell, AleksTom (2004-12-07). «Sony to replace defective demo discs with games». Eurogamer. Retrieved 2009-11-10.
- ^ «Bubble Bobble Revolution DS production issues confirmed *UPDATE*». GoNintendo. 14 Oct 2006.
- ^ Bramwell, Tom (2007-04-16). «RedOctane admits to Guitar Hero II patch problem». Eurogamer. Retrieved 2016-12-02.
- ^ Paul, Ian (17 Jan 2015). «Scary Steam for Linux bug erases all the personal files on your PC». PCWorld.
- ^ Gach, Ethan (14 November 2016). «The NES Classic Carries Over Classic Glitches». Kotaku Australia. Retrieved 8 March 2017.
- ^ Nintendo. «Customer Service — Specific GamePak Troubleshooting». Archived from the original on January 27, 2008. Retrieved June 7, 2009.
- ^ «Pokechat». Nintendo Power. Vol. 120. May 1999. p. 101.
- ^ Loe, Casey (1999). Pokémon Perfect Guide Includes Red-Yellow-Blue. Versus Books. p. 125. ISBN 1-930206-15-1.
- ^ «Gaming’s Top 10 Easter Eggs». IGN. IGN Entertainment. April 9, 2009. p. 2. Archived from the original on June 5, 2010. Retrieved June 7, 2009.
- ^ «DSA-1571-1 openssl — predictable random number generator». Retrieved 2008-04-16.
- ^ «Heartbleed bug may shut Revenue Canada website until weekend». CBC News. 2014-04-09.
- ^ «Heartbleed bug: 900 SINs stolen from Revenue Canada — Business — CBC News». CBC News. Retrieved 2014-04-14.
- ^ Goodin, Dan (March 4, 2014). «Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping». Ars Technica. Retrieved September 7, 2020.
- ^ Dunn, Michael (28 Oct 2013). «Toyota’s killer firmware: Bad design and its consequences». EDN.
- ^ «To keep a Boeing Dreamliner flying, reboot once every 248 days». Engadget. 1 Apr 2015.
- ^ Corfield, Gareth (25 Jul 2019). «Airbus A350 software bug forces airlines to turn planes off and on every 149 hours». The Register. Retrieved 2021-02-04.
- ^ Roy, Eleanor Ainge (21 February 2019). «Auckland threatens to eject Lime scooters after wheels lock at high speed». The Guardian. Retrieved 2019-02-20.
- ^ Corfield, Gareth (8 Jan 2020). «Blackout Bug: Boeing 737 cockpit screens go blank if pilots land on specific runways». The Register. Retrieved 2021-02-04.
- ^ Corfield, Gareth (29 May 2020). «Software bug in Bombardier airliner made planes turn the wrong way». The Register. Retrieved 2021-02-04.
- ^ Quinn, Kevin (November 8, 1983). «Ever Had Problems Rounding Off Figures? This Stock Exchange Has». The Wall Street Journal. p. 37.
- ^ Wayne, Lilley (November 29, 1983). «Vancouver stock index has right number at last». The Toronto Star.
- ^ Popper, Nathaniel (2 August 2012). «Knight Capital Says Trading Glitch Cost It $440 Million». New York Times.
- ^ Flinders, Karl (3 March 2022). «Post Office warned of software flaw in 2006, but failed to alert subpostmaster network». Computer Weekly.
- ^ «Once hailed as unhackable, blockchains are now getting hacked». MIT Technology Review. Retrieved January 2, 2022.
External links[edit]
- Forum on Risks to the Public in Computers and Related Systems
From Wikipedia, the free encyclopedia
Many software bugs are merely annoying or inconvenient but some can have extremely serious consequences – either financially or as a threat to human well-being.[1] The following is a list of software bugs with significant consequences.
Space[edit]
- A booster went off course during launch, resulting in the destruction of NASA Mariner 1. This was the result of the failure of a transcriber to notice an overbar in a written specification for the guidance program, resulting in the coding of an incorrect formula in its FORTRAN software. (July 22, 1962).[2] The initial reporting of the cause of this bug was incorrect.[3]
- NASA’s 1965 Gemini 5 mission landed 80 miles (130 km) short of its intended splashdown point when the pilot compensated manually for an incorrect constant for the Earth’s rotation rate. A 360-degree rotation corresponding to the Earth’s rotation relative to the fixed stars was used instead of the 360.98-degree rotation in a 24-hour solar day. The shorter length of the first three missions and a computer failure on Gemini 4 prevented the bug from being detected earlier.[4]
- The Russian Space Research Institute’s Phobos 1 (Phobos program) deactivated its attitude thrusters and could no longer properly orient its solar arrays or communicate with Earth, eventually depleting its batteries. (September 10, 1988).[5]
- The European Space Agency’s Ariane flight V88 was destroyed 40 seconds after takeoff (June 4, 1996). The US$1 billion prototype rocket self-destructed due to a bug in the on-board guidance software.[6][7]
- In 1997, the Mars Pathfinder mission was jeopardised by a bug in concurrent software shortly after the rover landed, which was found in preflight testing but given a low priority as it only occurred in certain unanticipated heavy-load conditions.[8] The problem, which was identified and corrected from Earth, was due to computer resets caused by priority inversion.[9]
- In 2000, a Zenit 3SL launch failed due to faulty ground software not closing a valve in the rocket’s second stage pneumatic system.[10]
- The European Space Agency’s CryoSat-1 satellite was lost in a launch failure in 2005 due to a missing shutdown command in the flight control system of its Rokot carrier rocket.[11]
- NASA Mars Polar Lander was destroyed because its flight software mistook vibrations caused by the deployment of the stowed legs for evidence that the vehicle had landed and shut off the engines 40 meters from the Martian surface (December 3, 1999).[12]
- Its sister spacecraft Mars Climate Orbiter was also destroyed, due to software on the ground generating commands based on parameters in pound-force (lbf) rather than newtons (N).
- A mis-sent command from Earth caused the software of the NASA Mars Global Surveyor to incorrectly assume that a motor had failed, causing it to point one of its batteries at the sun. This caused the battery to overheat (November 2, 2006).[13][14]
- NASA’s Spirit rover became unresponsive on January 21, 2004, a few weeks after landing on Mars. Engineers found that too many files had accumulated in the rover’s flash memory. It was restored to working condition after deleting unnecessary files.[15]
- Japan’s Hitomi astronomical satellite was destroyed on March 26, 2016, when a thruster fired in the wrong direction, causing the spacecraft to spin faster instead of stabilize.[16]
- Israel’s first attempt to land an unmanned spacecraft on the moon with the Beresheet was rendered unsuccessful on April 11, 2019, due to a software bug with its engine system, which prevented it from slowing down during its final descent on the moon’s surface. Engineers attempted to correct this bug by remotely rebooting the engine, but by the time they regained control of it, Beresheet could not slow down in time to avert a hard, crash landing that disintegrated it.[17]
Medical[edit]
- A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of beta radiation.[18][19][20]
- Radiation therapy planning software RTP/2 created by Multidata Systems International could incorrectly double the dosage of radiation depending on how the technician entered data into the machine. At least eight patients died, while another 20 received overdoses likely to cause significant health problems (November 2000).[21] See also Instituto Oncológico Nacional#Accident
- A Medtronic heart device was found vulnerable to remote attacks (2008-03).[22]
- The Becton Dickinson Alaris Gateway Workstation allows unauthorized arbitrary remote execution (2019).[23][24]
- The CareFusion Alaris pump module (8100) will not properly delay an Infusion when the «Delay Until» option or «Multidose» feature is used (2015).[25]
Tracking years[edit]
- The year 2000 problem spawned fears of worldwide economic collapse and an industry of consultants providing last-minute fixes.[26]
- A similar problem will occur in 2038 (the year 2038 problem), as many Unix-like systems calculate the time in seconds since 1 January 1970, and store this number as a 32-bit signed integer, for which the maximum possible value is 231 − 1 (2,147,483,647) seconds.[27]
- An error in the payment terminal code for Bank of Queensland rendered many devices inoperable for up to a week. The problem was determined to be an incorrect hexadecimal number conversion routine. When the device was to tick over to 2010, it skipped six years to 2016, causing terminals to decline customers’ cards as expired.[28]
Electric power transmission[edit]
- The Northeast blackout of 2003 was triggered by a local outage that went undetected due to a race condition in General Electric Energy’s XA/21 monitoring software.[29]
Administration[edit]
- The software of the A2LL system for handling unemployment and social services in Germany presented several errors with large-scale consequences, such as sending the payments to invalid account numbers in 2004.[citation needed]
Telecommunications[edit]
- AT&T long-distance network crash (January 15, 1990), in which the failure of one switching system would cause a message to be sent to nearby switching units to tell them that there was a problem. Unfortunately, the arrival of that message would cause those other systems to fail too – resulting in a cascading failure that rapidly spread across the entire AT&T long-distance network.[30][31]
- In January 2009, Google’s search engine erroneously notified users that every web site worldwide was potentially malicious, including its own.[32]
- In May 2015, iPhone users discovered a bug where sending a certain sequence of characters and Unicode symbols as a text to another iPhone user would crash the receiving iPhone’s SpringBoard interface,[33] and may also crash the entire phone, induce a factory reset, or disrupt the device’s connectivity to a significant degree,[34] preventing it from functioning normally. The bug persisted for weeks, gained substantial notoriety and saw a number of individuals using the bug to play pranks on other iOS users,[citation needed] before Apple eventually patched it on June 30, 2015, with iOS 8.4.
Military[edit]
- The software error of a MIM-104 Patriot caused its system clock to drift by one third of a second over a period of one hundred hours – resulting in failure to locate and intercept an incoming Iraqi Al Hussein missile, which then struck Dharan barracks, Saudi Arabia (February 25, 1991), killing 28 Americans.[35][36]
- A Royal Air Force Chinook helicopter crashed into the Mull of Kintyre in June 1994, killing 29. Initially, the crash was dismissed as pilot error, but an investigation by Computer Weekly uncovered sufficient evidence to convince a House of Lords inquiry that it may have been caused by a software bug in the aircraft’s engine control computer.[37]
- Smart ship USS Yorktown was left dead in the water in September 1997 for nearly 3 hours after a divide by zero error.[38]
- In April 1992 the first Lockheed YF-22 crashed while landing at Edwards Air Force Base, California. The cause of the crash was found to be a flight control software error that failed to prevent a pilot-induced oscillation.[39]
- While attempting its first overseas deployment to the Kadena Air Base in Okinawa, Japan, on 11 February 2007, a group of six F-22 Raptors flying from Hickam AFB, Hawaii, experienced multiple computer crashes coincident with their crossing of the 180th meridian of longitude (the International Date Line). The computer failures included at least navigation (completely lost) and communication. The fighters were able to return to Hawaii by following their tankers, something that might have been problematic had the weather not been good. The error was fixed within 48 hours, allowing a delayed deployment.[40]
Media[edit]
- In the Sony BMG copy protection rootkit scandal (October 2005), Sony BMG produced a Van Zant music CD that employed a copy protection scheme that covertly installed a rootkit on any Windows PC that was used to play it. Their intent was to hide the copy protection mechanism to make it harder to circumvent. Unfortunately, the rootkit inadvertently opened a security hole resulting in a wave of successful trojan horse attacks on the computers of those who had innocently played the CD.[41] Sony’s subsequent efforts to provide a utility to fix the problem actually exacerbated it.[42]
Video gaming[edit]
- Eve Online‘s deployment of the Trinity patch erased the boot.ini file from several thousand users’ computers, rendering them unable to boot. This was due to the usage of a legacy system within the game that was also named boot.ini. As such, the deletion had targeted the wrong directory instead of the /eve directory.[43]
- The Corrupted Blood incident was a software bug in World of Warcraft that caused a deadly, debuff-inducing virtual disease that could only be contracted during a particular raid to be set free into the rest of the game world, leading to numerous, repeated deaths of many player characters. This caused players to avoid crowded places in-game, just like in a «real world» epidemic, and the bug became the center of some academic research on the spread of infectious diseases.[44]
- On June 6, 2006, the online game RuneScape suffered from a bug that enabled certain player characters to kill and loot other characters, who were unable to fight back against the affected characters because the game still thought they were in player-versus-player mode even after they were kicked out of a combat ring from the house of a player who was suffering from lag while celebrating an in-game accomplishment. Players who were killed by the glitched characters lost many items, and the bug was so devastating that the players who were abusing it were soon tracked down, caught and banned permanently from the game, but not before they had laid waste to the region of Falador, thus christening the bug «Falador Massacre».[45]
- In the 256th level of Pac-Man, a bug results in a kill screen. The maximum number of fruit available is seven and when that number rolls over, it causes the entire right side of the screen to become a jumbled mess of symbols while the left side remains normal.[46]
- Upon initial release, the ZX Spectrum game Jet Set Willy was impossible to complete because of a severe bug that corrupted the game data, causing enemies and the player character to be killed in certain rooms of the large mansion where the entire game takes place.[47] The bug, known as «The Attic Bug», would occur when the player entered the mansion’s attic, which would then cause an arrow to travel offscreen, overwriting the contents of memory and altering crucial variables and behavior in an undesirable way. The game’s developers initially excused this bug by claiming that the affected rooms were death traps, but ultimately owned up to it and issued instructions to players on how to fix the game itself.[48]
- One of the free demo discs issued to PlayStation Underground subscribers in the United States contained a serious bug, particularly in the demo for Viewtiful Joe 2, that would not only crash the PlayStation 2, but would also unformat any memory cards that were plugged into that console, erasing any and all saved data onto them.[49] The bug was so severe that Sony had to apologize for it and send out free copies of other PS2 games to affected players as consolation.[50]
- Due to a severe programming error, much of the Nintendo DS game Bubble Bobble Revolution is unplayable because a mandatory boss fight failed to trigger in the 30th level.[51]
- An update for the Xbox 360 version of Guitar Hero II, which was intended to fix some issues with the whammy bar on that game’s guitar controllers, came with a bug that caused some consoles to freeze, or even stop working altogether, producing the infamous «red ring of death».[52]
- Valve’s Steam client for Linux could accidentally delete all the user’s files in every directory on the computer. This happened to users that had moved Steam’s installation directory.[53] The bug is the result of unsafe shellscript programming:
-
STEAMROOT="$(cd "${0%/*}" && echo $PWD)" # Scary! rm -rf "$STEAMROOT/"*
- The first line tries to find the script’s containing directory. This could fail, for example if the directory was moved while the script was running, invalidating the «selfpath» variable
$0. It would also fail if$0contained no slash character, or contained a broken symlink, perhaps mistyped by the user. The way it would fail, as ensured by the&&conditional, and not havingset -ecause termination on failure, was to produce the empty string. This failure mode was not checked, only commented as «Scary!». Finally, in the deletion command, the slash character takes on a very different meaning from its role of path concatenation operator when the string before it is empty, as it then names the root directory.
- Minus World is an infamous glitch level from the 1985 game Super Mario Bros., accessed by using a bug to clip through walls in level 1–2 to reach its «warp zone», which leads to the said level.[54] As this level is endless, triggering the bug that takes the player there will make the game impossible to continue until the player resets the game or runs out of lives.
- «MissingNo.» is a glitch Pokémon species present in Pokémon Red and Blue, which can be encountered by performing a particular sequence of seemingly unrelated actions. Capturing this Pokémon may corrupt the game’s data, according to Nintendo[55][56][57] and some of the players who successfully attempted this glitch. This is one of the most famous bugs in video game history, and continues to be well-known.[58]
Encryption[edit]
- In order to fix a warning issued by Valgrind, a maintainer of Debian patched OpenSSL and broke the random number generator in the process. The patch was uploaded in September 2006 and made its way into the official release; it was not reported until April 2008. Every key generated with the broken version is compromised (as the «random» numbers were made easily predictable), as is all data encrypted with it, threatening many applications that rely on encryption such as S/MIME, Tor, SSL or TLS protected connections and SSH.[59]
- Heartbleed, an OpenSSL vulnerability introduced in 2012 and disclosed in April 2014, removed confidentiality from affected services, causing among other things the shut down of the Canada Revenue Agency’s public access to the online filing portion of its website[60] following the theft of social insurance numbers.[61]
- The Apple «goto fail» bug was a duplicated line of code which caused a public key certificate check to pass a test incorrectly.
- The GnuTLS «goto fail» bug was similar to the Apple bug and found about two weeks later. The GnuTLS bug also allowed attackers to bypass SSL/TLS security. [62]
Transportation[edit]
- By some accounts Toyota’s electronic throttle control system (ETCS) had bugs that could cause sudden unintended acceleration.[63]
- The Boeing 787 Dreamliner experienced an integer overflow bug which could shut down all electrical generators if the aircraft was on for more than 248 days.[64] A similar problem was found in Airbus A350 which need to be powered down before reaching 149 hours of continuous power-on time, otherwise certain avionics systems or functions would partially or completely fail.[65]
- In early 2019, the transportation-rental firm Lime discovered a firmware bug with its electric scooters that can cause them to brake very hard unexpectedly, which may hurl and injure riders.[66]
- Boeing 737 NG had all cockpit displays go blank if a specific type of instrument approach to any one of seven specific airports was selected in the flight management computer.[67]
- Bombardier CRJ-200 equipped with flight management systems by Collins Aerospace would make wrong turns during missed approach procedures executed by the autopilot in some specific cases when temperature compensation was activated in cold weather.[68]
Finance[edit]
- The Vancouver Stock Exchange index had large errors due to repeated rounding. In January 1982 the index was initialized at 1000 and subsequently updated and truncated to three decimal places on each trade. This was done about 3000 times a day. The accumulated truncations led to an erroneous loss of around 25 points per month. Over the weekend of November 25–28, 1983, the error was corrected, raising the value of the index from its Friday closing figure of 524.811 to 1098.892.[69][70]
- Knight Capital Group lost $440 million in 45 minutes due to the improper deployment of software on servers and the re-use of a critical software flag that caused old unused software code to execute during trading.[71]
- Post Office Limited Between 2000 and 2015, 736 subpostmasters were prosecuted by the UK Post Office, with many falsely convicted and sent to prison. This was a result of failure to recognize defects in the Horizon financial software, the subpostmasters were blamed for financial shortfalls which were actually software defects.[72]
Blockchain[edit]
- Ethereum The DAO (organization) bug — 3.6M ETH[73]
See also[edit]
- London Ambulance Service § Innovation
References[edit]
- ^ «Why Software fails». IEEE Spectrum: Technology, Engineering, and Science News. 2 September 2005. Retrieved 2021-03-20.
- ^ «Space FAQ 08/13 — Planetary Probe History». faqs.org. 17 Sep 1996.
- ^ Hoare, C. A. R. Hints on Programming Language Design. in Sigact/Sigplan Symposium on Principles of Programming Languages. October 1973., reprinted in Horowitz. Programming Languages, A Grand Tour, 3rd ed.. See «Mariner 1». RISKS Digest. 9 (54). 12 Dec 1989. and Neumann, Peter G. (30 May 1989). «Mariner I — no holds BARred». The RISKS Digest. 8 (75). Retrieved 2008-01-07.
- ^ «Gemini 5». On The Shoulders of Titans: A History of Project Gemini.
- ^ Sagdeev, R. Z.; Zakharov, A. V. (1989). «Brief history of the Phobos mission». Nature. 341 (6243): 581–585. Bibcode:1989Natur.341..581S. doi:10.1038/341581a0. S2CID 41464654.
- ^ Dowson, M. (March 1997). «The Ariane 5 Software Failure». Software Engineering Notes. 22 (2): 84. doi:10.1145/251880.251992. S2CID 43439273.
- ^ Jézéquel JM, Meyer B (January 1997). «Design by Contract: The Lessons of Ariane» (PDF). IEEE Computer. 30 (1): 129–130. doi:10.1109/2.562936.
- ^ Heaven, Douglas (2013). «Parallel sparking: Many chips make light work». New Scientist. Elsevier BV. 219 (2930): 42–45. doi:10.1016/s0262-4079(13)62046-1. ISSN 0262-4079.
- ^ Reeves, Glenn E (15 Dec 1997). «What really happened on Mars? — Authoritative Account». research.microsoft.com. Archived from the original on 30 December 2016.
{{cite web}}: CS1 maint: unfit URL (link) - ^ «Spaceflight Now | Breaking News | Sea Launch malfunction blamed on software glitch». spaceflightnow.com. Retrieved January 2, 2022.
- ^ «CryoSat Mission lost due to launch failure». European Space Agency. 8 October 2005. Retrieved 19 July 2010.
- ^ «Mars Polar Lander». Archived from the original on 2012-09-27. Retrieved 2008-01-07.
- ^ «Report Reveals Likely Causes of Mars Spacecraft Loss». Retrieved 2008-01-07.
- ^ «Faulty Software May Have Doomed Mars Orbiter». Space.com. Archived from the original on July 24, 2008. Retrieved January 11, 2007.
- ^ «Out of memory problem caused Mars rover’s glitch». computerworld.com. February 3, 2004.
- ^ Witze, Alexandra (2016). «Software error doomed Japanese Hitomi spacecraft». Nature. 533 (7601): 18–19. Bibcode:2016Natur.533…18W. doi:10.1038/nature.2016.19835. PMID 27147012. S2CID 4451754.
- ^ Weitering, Hanneke (12 April 2019). «Israeli Moon Lander Suffered Engine Glitch Before Crash». Space.com. Retrieved 29 May 2019.
- ^ «The Therac-25 Accidents (PDF), by Nancy Leveson» (PDF). Retrieved 2008-01-07.
- ^ «An Investigation of the Therac-25 Accidents (IEEE Computer)». Retrieved 2008-01-07.
- ^ «Computerized Radiation Therapy (PDF) reported by TROY GALLAGHER» (PDF). Retrieved 2011-12-12.
- ^ Garfinkel, Simson (November 8, 2005). «History’s Worst Software Bugs». Wired. Retrieved September 6, 2020.
- ^ Feder, Barnaby J. (2008-03-12). «A Heart Device Is Found Vulnerable to Hacker Attacks». The New York Times. Retrieved 2008-09-28.
- ^ «ICS Advisory (ICSMA-19-164-01)» (Press release). Cybersecurity and Infrastructure Security Agency. 2019-06-13. Retrieved 2019-11-15.
- ^ Newman, Lily Hay (2019-10-01). «Decades-Old Code Is Putting Millions of Critical Devices at Risk». Wired. Retrieved 2019-11-15.
- ^ «Urgent: Medical Device Recall Notification, AFFECTED DEVICE: Alaris® Pump module (Model 8100)»Delay Until» Option and «Multidose» Feature» (PDF) (Press release). CareFusion. 2014-04-23. Archived from the original (PDF) on 2015-06-12. Retrieved 2019-11-15.
- ^ «Looking at the Y2K bug, portal on CNN.com». Archived from the original on 2007-12-27. Retrieved 2008-01-07.
- ^ «The year 2038 bug». Retrieved 2008-01-12.
- ^ Stafford, Patrick. «Businesses hit by Bank of Queensland EFTPOS bug». Archived from the original on 7 April 2014. Retrieved 1 April 2014.
- ^ «Software Bug Contributed to Blackout». Retrieved 2008-01-07.
- ^ Sterling, Bruce (1993). The Hacker Crackdown: Law and Disorder on the Electronic Frontier. Spectra Books. ISBN 0-553-56370-X.
- ^ «The Crash of the AT&T Network in 1990». Retrieved 2008-05-15.
- ^ Metz, Cade (January 31, 2009). «Google mistakes entire web for malware». The Register. Retrieved December 20, 2010.
- ^ «Bug in iOS Unicode handling crashes iPhones with a simple text». Apple Insider. 26 May 2015. Retrieved 29 May 2015.
- ^ Clover, Juli (26 May 2015). «New iOS Bug Crashing iPhones Simply by Receiving a Text Message». MacRumors. Retrieved 29 May 2015.
- ^ «Patriot missile defense, Software problem led to system failure at Dharhan, Saudi Arabia; GAO report IMTEC 92-26». US Government Accounting Office.
- ^ Skeel, Robert. «Roundoff Error and the Patriot Missile». SIAM News, volume 25, nr 4. Archived from the original on 2008-08-01. Retrieved 2008-09-30.
- ^ Rogerson, Simon (April 2002). «The Chinook Helicopter Disaster». IMIS Journal. 12 (2). Archived from the original on 2012-07-17.
- ^ «Software glitches leave Navy Smart Ship dead in the water». gcn.com. 13 Jul 1998. Archived from the original on 8 February 2006.
- ^ «F/A-22 Program History». f-22raptor.com. Archived from the original on 25 August 2009.
- ^ «Lockheed’s F-22 Raptor Gets Zapped by International Date Line». DailyTech. 26 Feb 2007. Archived from the original on 16 March 2007.
- ^ Borland, John (11 November 2005). «FAQ: Sony’s ‘rootkit’ CDs — CNET News». news.com. Archived from the original on 5 December 2008.
{{cite web}}: CS1 maint: unfit URL (link) - ^ Russinovich, Mark (4 Nov 2005). «Mark’s Blog : More on Sony: Dangerous Decloaking Patch, EULAs and Phoning Home». blogs.technet.com. Archived from the original on 3 January 2007.
- ^ «About the boot.ini issue (Dev Blog)». Retrieved 2014-09-30.
- ^ Balicer, Ran (2005-10-05). «Modeling Infectious Diseases Dissemination Through Online Role-Playing Games». Epidemiology. 18 (2): 260–261. doi:10.1097/01.ede.0000254692.80550.60. PMID 17301707. S2CID 20959479.
- ^ Bishop, Sam (8 June 2016). «Runescape marks the anniversary of the Falador Massacre». GameFactor. Retrieved 9 August 2018.
- ^ «Pac Man’S Split Screen Level Analyzed And Fixed». Donhodges.Com. Retrieved 2012-09-19.
- ^ Langshaw, Mark (30 September 2010). «Retro Corner: ‘Jet Set Willy’ (Spectrum)». Digital Spy. Retrieved 30 May 2018.
- ^ «Jet Set Willy Solved!». Personal Computer Games (8): 21. July 1984. Retrieved 2014-04-19.
- ^ Krotoski, Aleks (2004-11-30). «Viewtiful Joe 2 demo deletes memory cards». The Guardian. Retrieved 2009-11-10.
- ^ Bramwell, AleksTom (2004-12-07). «Sony to replace defective demo discs with games». Eurogamer. Retrieved 2009-11-10.
- ^ «Bubble Bobble Revolution DS production issues confirmed *UPDATE*». GoNintendo. 14 Oct 2006.
- ^ Bramwell, Tom (2007-04-16). «RedOctane admits to Guitar Hero II patch problem». Eurogamer. Retrieved 2016-12-02.
- ^ Paul, Ian (17 Jan 2015). «Scary Steam for Linux bug erases all the personal files on your PC». PCWorld.
- ^ Gach, Ethan (14 November 2016). «The NES Classic Carries Over Classic Glitches». Kotaku Australia. Retrieved 8 March 2017.
- ^ Nintendo. «Customer Service — Specific GamePak Troubleshooting». Archived from the original on January 27, 2008. Retrieved June 7, 2009.
- ^ «Pokechat». Nintendo Power. Vol. 120. May 1999. p. 101.
- ^ Loe, Casey (1999). Pokémon Perfect Guide Includes Red-Yellow-Blue. Versus Books. p. 125. ISBN 1-930206-15-1.
- ^ «Gaming’s Top 10 Easter Eggs». IGN. IGN Entertainment. April 9, 2009. p. 2. Archived from the original on June 5, 2010. Retrieved June 7, 2009.
- ^ «DSA-1571-1 openssl — predictable random number generator». Retrieved 2008-04-16.
- ^ «Heartbleed bug may shut Revenue Canada website until weekend». CBC News. 2014-04-09.
- ^ «Heartbleed bug: 900 SINs stolen from Revenue Canada — Business — CBC News». CBC News. Retrieved 2014-04-14.
- ^ Goodin, Dan (March 4, 2014). «Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping». Ars Technica. Retrieved September 7, 2020.
- ^ Dunn, Michael (28 Oct 2013). «Toyota’s killer firmware: Bad design and its consequences». EDN.
- ^ «To keep a Boeing Dreamliner flying, reboot once every 248 days». Engadget. 1 Apr 2015.
- ^ Corfield, Gareth (25 Jul 2019). «Airbus A350 software bug forces airlines to turn planes off and on every 149 hours». The Register. Retrieved 2021-02-04.
- ^ Roy, Eleanor Ainge (21 February 2019). «Auckland threatens to eject Lime scooters after wheels lock at high speed». The Guardian. Retrieved 2019-02-20.
- ^ Corfield, Gareth (8 Jan 2020). «Blackout Bug: Boeing 737 cockpit screens go blank if pilots land on specific runways». The Register. Retrieved 2021-02-04.
- ^ Corfield, Gareth (29 May 2020). «Software bug in Bombardier airliner made planes turn the wrong way». The Register. Retrieved 2021-02-04.
- ^ Quinn, Kevin (November 8, 1983). «Ever Had Problems Rounding Off Figures? This Stock Exchange Has». The Wall Street Journal. p. 37.
- ^ Wayne, Lilley (November 29, 1983). «Vancouver stock index has right number at last». The Toronto Star.
- ^ Popper, Nathaniel (2 August 2012). «Knight Capital Says Trading Glitch Cost It $440 Million». New York Times.
- ^ Flinders, Karl (3 March 2022). «Post Office warned of software flaw in 2006, but failed to alert subpostmaster network». Computer Weekly.
- ^ «Once hailed as unhackable, blockchains are now getting hacked». MIT Technology Review. Retrieved January 2, 2022.
External links[edit]
- Forum on Risks to the Public in Computers and Related Systems
Типы ошибок в программном обеспечении
Существуют три
типа ошибок программирования:
–
синтаксические
ошибки,
–
ошибки
выполнения,
–
семантические
ошибки.
В
любом языке программирования каждое
предложение (оператор) строится по
определенным правилам. Когда
в программе встречается предложение,
которое нарушает эти правила, то говорят
о наличии синтаксической ошибки.
Синтаксическая ошибка легко обнаруживается
компиляторами и интерпретаторами
языка и легко исправляется.
Второй
тип ошибок
обычно возникает во время выполнения
программы (их принято называть
исключительными ситуациями). Такие
ошибки имеют другую причину. Если в
программе возникает исключение, то это
означает, что случилось непредвиденное:
например, программе передали
некорректное значение или программа
попыталась разделить какое-то значение
на ноль, что недопустимо с точки зрения
математики. Если операционная система
присылает запрос на немедленное
завершение программы, то также
возникает исключение. Ошибки выполнения
легко обнаруживаются, однако устранение
их причин может оказаться нетривиальной
задачей.
Семантические
(смысловые) ошибки
– это
применение операторов, которые не
дают нужного эффекта (например, (a–b)
вместо (a+b)),
ошибка в структуре алгоритма, в логической
взаимосвязи его частей, в применении
алгоритма к тем данным, к которым он
неприменим и т.д. Правила семантики
не формализуемы. Поэтому поиск и
устранение семантической ошибки и
составляет основу отладки.
3.1.2. Причины появления ошибок в программном обеспечении
Прежде всего
необходимо понять первопричины ошибок
программного обеспечения и связать
их с процессом создания программных
комплексов. В данном учебном пособии
считается, что создание программного
обеспечения можно описать как ряд
процессов перевода, начинающихся с
постановки задачи и заканчивающихся
большим набором подробных инструкций,
управляющих ЭВМ при решении этой задачи.
Создание программного обеспечения
в этом случае – просто совокупность
процессов трансляции, т.е. перевода
исходной задачи в различные промежуточные
решения, пока наконец не будет получен
подробный набор машинных команд [1].
Когда не удается полно и точно перевести
некоторое представление задачи или
решения в другое, более детальное, тогда
и возникают ошибки в программном
обеспечении.
Для того чтобы
подробнее исследовать проблему ошибок
в программном обеспечении (ПО),
рассмотрим различные типы процессов
перевода при его создании.
Создание ПО
начинается с формирования требований
пользователя, т.е. с разработки описания
решаемой задачи. Такое описание имеет
вид перечня требований пользователя.
В некоторых случаях пользователь
составляет этот перечень сам. В других
случаях это делает разработчик ПО в
беседе с пользователем, либо исследуя
его потребности, либо самостоятельно
оценивая эти потребности в будущем,
либо комбинируя перечисленные методы.
В данном учебном пособии будем считать,
что на данном этапе ошибки не вносятся.
1. Первый процесс
– перевод требований пользователя в
цели программы. Хотя на этом шаге
объем перевода невелик, здесь требуется
явно выделить и оценить довольно много
компромиссных решений, которые будут
рассмотрены в дальнейшем. Ошибки на
этом шаге возникают, когда неверно
интерпретируются требования, не удается
выявить все требующие компромиссных
решений проблемы или приняты неправильные
решения, а также в случае, когда не
сформулированы цели, необходимые, но
не поставленные явно в требованиях
пользователя.
2. Второй процесс
связан с преобразованием целей программы
в ее внешние спецификации, т.е. точное
описание поведения всей системы с точки
зрения пользователя. По объему перевода
это самый сложный шаг в разработке ПО,
поэтому он больше всего подвержен
ошибкам – они бывают и наиболее
серьезными и наиболее многочисленными.
3. Далее следуют
несколько последовательных процессов
перевода – от внешнего описания готового
продукта до получения детального
проекта, описывающего множество
составляющих программу предложений,
выполнение которых должно обеспечить
поведение системы, соответствующее
внешним спецификациям. Сюда включаются
такие процессы, как перевод внешнего
описания в структуру компонент программы
(например, модулей) и перевод каждой из
этих компонент в описание процедурных
шагов (например, в блок-схемы). Поскольку
нам приходится иметь дело со все большими
объемами информации, шансы внесения
ошибок становятся чрезвычайно высокими.
4. Последний процесс
– перевод описания логики программы в
предложения языка программирования.
Хотя на этом шаге часто делается много
ошибок, они обычно незначительные, легко
обнаруживаются и корректируются.
Кроме процессов
перевода имеются и другие источники
ошибок, которые будут кратко рассмотрены
ниже. Однако в данном учебном пособии
мы сосредоточимся на ошибках, возникающих
в четырех вышеназванных процессах
перевода.
В результате работы
над программным проектом возникают как
само ПО, так и документы, описывающие
правила пользования им. Последние обычно
имеют вид печатных руководств или
встроенной в программу помощи и носят
название публикаций. Эти руководства
обычно получаются переводом внешних
спецификаций в материалы, ориентированные
на конкретные группы пользователей.
Публикации
определенным образом влияют на надежность
программного обеспечения. Если при
их подготовке возникает ошибка, то они
не будут точно описывать поведение
программы. Если прочитав руководство,
пользователь начнет работать с программой
и обнаружит, что она ведет себя не так,
как он ожидал, то решит, что это ошибка
в программе, т.е. придет к неправильному
заключению.
Другие источники
ошибок – это неправильное понимание
спецификаций используемой в системе
аппаратуры, базового ПО (операционной
системы), синтаксиса и семантики языка
программирования.
И наконец, при
непосредственном взаимодействии
пользователя с ПО, если слабо разработан
диалог человек – машина (отсутствие
«дружественного интерфейса»),
вероятность ошибки пользователя
увеличивается. Ошибки пользователя же
ставят систему в новые, непредвиденные
обстоятельства, увеличивая таким
образом шансы проявления оставшихся в
программе ошибок.
Эта модель описывает
происхождение большинства ошибок в ПО.
Нередко считается, что ошибки в программе
– это те ошибки, которые делает
программист, когда пишет программу на
языке программирования. Здесь и
проявляется важность модели, поскольку
она более полно описывает причины,
лежащие в основе ненадежности. Благодаря
ей нам стал известен перечень
подлежащих решению задач, способствующих
созданию надежного ПО.
Соседние файлы в папке Надежность
- #
- #
- #
- #
- #
- #
Содержание:
Введение
Программное обеспечение, согласно ГОСТ 19781-90, – совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации.
Существует и другое, более простое определение, согласно которому программное обеспечение представляет собой совокупность компьютерных инструкций. Оно охватывает программы, подпрограммы (разделы программы) и данные. Таким образом, программное обеспечение указывает компьютеру, что делать, как, когда, в какой последовательности и как часто. Нередко программное обеспечение называют просто программой.
Проблема надежности программного обеспечения относится, похоже, к категории «вечных». В посвященной ей монографии Г.Майерса, выпущенной в 1980 году (американское издание — в 1976), отмечается, что, хотя этот вопрос рассматривался еще на заре применения вычислительных машин, в 1952 году, он не потерял актуальности до настоящего времени. Отношение к проблеме довольно выразительно сформулировано в книге Р.Гласса: «Надежность программного обеспечения — беспризорное дитя вычислительной техники». Следует далее отметить, что сама проблема надежности программного обеспечения имеет, по крайней мере, два аспекта: обеспечение и оценка (измерение) надежности. Практически вся имеющаяся литература на эту тему, включая упомянутые выше монографии, посвящена первому аспекту, а вопрос оценки надежности компьютерных программ оказывается еще более «беспризорным». Вместе с тем очевидно, что надежность программы гораздо важнее таких традиционных ее характеристик, как время исполнения или требуемый объем оперативной памяти, однако никакой общепринятой количественной меры надежности программ до сих пор не существует.
Для обеспечения надежности программ предложено множество подходов, включая организационные методы разработки, различные технологии и технологические программные средства, что требует, очевидно, привлечения значительных ресурсов. Однако отсутствие общепризнанных критериев надежности не позволяет ответить на вопрос, насколько надежнее становится программное обеспечение при соблюдении данных процедур и технологий и в какой степени оправданы расходы. Получается, что таким образом, приоритет задачи оценки надежности должен быть выше приоритета задачи ее обеспечения, чего на самом деле не наблюдается.
Цель данной работы – рассмотреть классификацию ошибок программного обеспечения для обеспечения его надежности.
Надежность программного обеспечения
Показатели качества программного обеспечения
Оценка качества программного обеспечения могут проводиться с двух позиций: с позиции положительной эффективности и непосредственной адекватности их характеристик назначению, целям создания и применения, а также с негативной позиции, возможного при этом ущерба – риска от пользования ПС или системы. Показатели качества преимущественно отражают положительный эффект от применения программного обеспечения и основная задача разработчиков проекта состоит в обеспечении высоких значений качества. Риски характеризуют возможные негативные последствия проявившихся в ходе эксплуатации ошибок или ущерб для пользователя при применении и функционировании программного обеспечения.
Согласно ГОСТ 9126[2], качество программного обеспечения – это весь объем признаков и характеристик программного обеспечения, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.
Качество программного обеспечения оценивается следующими характеристиками:
- Функциональные возможности (Functionality). Набор атрибутов, относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности.
- Надежность (Reliability). Набор атрибутов относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени.
- Практичность (Usability). Набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным и предполагаемым кругом пользователей.
- Эффективность (Efficiencies). Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
- Сопровождаемость (Maintainability). Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).
- Мобильность (Portability). Набор атрибутов, относящихся к способности программного обеспечения быть перенесенным из одного окружения в другое.
В общем случае под ошибкой подразумевается неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании или применении программы. При этом предполагается, что известно правильное, эталонное состояние объекта или процесса по отношению к которому может быть определено наличие отклонения. Исходным эталоном для любого программного обеспечения являются спецификации требований заказчика или потенциального пользователя, предъявляемых к программам и ожидаемый пользователем или заказчиком эффект от использования программного обеспечения. Важной особенностью при этом является отсутствие полностью определенной программы – эталона, которой должны соответствовать текст и результаты функционирования разрабатываемой программы. Поэтому определить качество программного обеспечения и наличие ошибок в нем путем сравнения разрабатываемой программы с эталонной программой невозможно.
Риски проявляются как негативные последствия проявления ошибок в программном обеспечении в ходе его пользования и функционирования, которые могут нанести ущерб системе, в которой используется это программное обеспечение, внешней среде или пользователям этой системы в результате отклонения характеристик программного обеспечения заданных или ожидаемых пользователем или заказчиком.
Исходя из определения ошибки в программном обеспечении, приведенном выше, можно сделать вывод, что ошибки, возникающие в ходе использования программного обеспечения, могут изменять некоторые или все показатели качества. В работе рассматриваются ошибки, изменения которых влияют на надежность использования программного обеспечения.
По правилу, установленному в [2], надежность – свойство объекта осуществлять заданные функции, храня во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующим заданным режимам и условиям использования, ремонта, технического обслуживания, хранения, транспортирования.
Рис. 1. Надежность по ГОСТ 27.002 – 89
При этом надежность является комплексным свойством, которое в зависимости от функции объекта и условий его использования может включать безотказность, ремонтопригодность, долговечность, сохраняемость или некоторые сочетания данных свойств (рис. 1). Так как программное обеспечение в процессе эксплуатации не изнашивается, его поломка и ремонт в общепринятом смысле не делается, то надежность программного обеспечения имеет смысл характеризовать только с точки зрения безотказности его функционирования и возможности исправления функционирования после отказов по вызванных проявлениями ошибок.
В [3] надежность программного обеспечения предлагается характеризовать с помощью следующих характеристик (рис. 2): стабильность, устойчивость и восстанавливаемость.
Рис. 2. Надежность программного обеспечения
В этом случае стабильность и устойчивость характеризуют безотказность программного обеспечения, а восстанавливаемость – возможность восстановления функционирования программного обеспечения после его отказа. Для количественной оценки надежности программного обеспечения необходимо определить показатели надежности для каждого свойства и методику их определения (оценки).
Для оценки стабильности программного обеспечения возможно использование показателей характеризующих безотказность технических устройств [2] (рис. 3).
Рис. 3. Показатели безотказности
В большинстве случаев поток программных ошибок может быть описан негомогенным процессом Пуассона [4]. Это означает, что программные ошибки происходят в статистически независимые моменты времени, наработки подчиняются экспоненциальному распределению, а интенсивность проявления ошибок изменяется во времени. Обычно используют убывающую интенсивность проявления ошибок. Это означает, что ошибки, как только они выявлены, эффективно устраняются без введения новых ошибок. Главная цель анализа надежности программного обеспечения заключается в том, чтобы определить форму функции интенсивности проявления ошибок и оценить ее параметры по наблюдаемым данным. Как только функция интенсивности проявления ошибок определена, могут быть найдены такие показатели надежности как:
- общее количество ошибок;
- количество остающихся ошибок;
- время до проявления следующей ошибки;
- вероятность безошибочной работы;
- интенсивность проявления ошибок;
- остаточное время испытаний (до принятия решения);
- максимальное количество ошибок (относительно срока службы).
При этом следует различать понятия ошибка и отказ. Применительно к надежности программного обеспечения ошибка это погрешность или искажение кода программы, неумышленно внесенные в нее в процессе разработки, которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования. Под отказом в общем случае понимают событие, заключающееся в нарушении работоспособности объекта [2]. Состояние объекта, при котором значения всех параметров характеризующих способность выполнять заданные функции, соответствуют требованиям нормативно – технической и (или) конструкторской (проектной) документации – называется работоспособным. При этом критерии отказов, как признаки или совокупность признаков нарушения работоспособного состояния программного обеспечения, должны определяться исходя из его предназначения в нормативно – технической и (или) конструкторской (проектной) документации.
В общем случае отказ программного обеспечения можно определить как:
- прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) на время превышающее заданный порог;
- прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) на время не превышающее заданный порог, но с потерей всех или части обрабатываемых данных;
- прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) потребовавшее перезагрузки ЭВМ, на которой функционирует программное обеспечение.
При этом исходя из [2], все отказы в программном обеспечении следует трактовать как сбои (самоустраняющиеся отказы или однократные отказы, устраняемые незначительным вмешательством оператора), поскольку восстановление работоспособного состояния программного обеспечения может произойти без вмешательства оператора (перезагрузка ЭВМ не требуется), либо при участии оператора или эксплуатирующего персонала (перезагрузка ЭВМ необходима).
Приведенные выше критерии отказов приводят к необходимости анализа временных характеристик функционирования программы и динамических характеристик потребителей данных, полученных в ходе функционирования программного обеспечения. Временная зона перерыва нормальной выдачи информации и потери работоспособности, которую следует рассматривать как зону сбоя (отказа), тем шире, чем более инертный объект находится под воздействием данных, полученным в ходе работы программы. Пороговое время восстановления работоспособного состояния системы, при превышении которого следует соответствующему потребителю (абоненту).
Для любого потребителя данных существует допустимое время отсутствия данных от программы, при котором его характеристики находятся в допустимых пределах. Исходя из этого времени, можно установить границы временной зоны, которая разделяет работоспособное и неработоспособное состояние программного обеспечения и позволяет использовать данные критерии отказов.
Из приведенного выше определения программной ошибки с точки зрения надежности, можно сделать вывод о том, что ошибки, при их проявлении, не всегда вызывают отказ программного обеспечения и каждую ошибку можно характеризовать условной вероятностью возникновения отказа при проявлении этой ошибки. Следует также отметить, что само по себе наличие ошибки в исходном коде не определяет надежность программы до тех пор, пока не произойдет проявления этой ошибки, поэтому пользоваться для оценки надежности программного обеспечения только показателями характеризующие общее количество ошибок в программе, количество оставшихся ошибок и максимального количества ошибок нельзя.
В [5] стабильность предлагается оценивать вероятностью безотказной работы, которая оценивается исходя из модели относительной частоты, при этом применение ее ограничено периодом эксплуатации программного обеспечения, что не всегда приемлемо, поскольку надежность объекта, как правило, необходимо оценивать не только в процессе его эксплуатации, но и до начала эксплуатации этого объекта. Ограничение модели относительной частоты вызвано тем, что в этой модели не учитываются процессы тестирования и отладки, а конкретно то, что при возникновении отказа программного обеспечения, ошибка, вызвавшая этот отказ, исправляется.
Наиболее приемлемыми показателями характеризующими стабильность (безотказность) программного обеспечения представляются показатели сходные с показателями безотказности технических систем: вероятность безотказной работы, интенсивность отказов, и среднее время наработки на отказ. Эти показатели взаимосвязаны и, зная один из них, можно определить другие [2]. При определении этих показателей в большинстве случаев можно исходить из модели надежности, предполагающей, что интенсивность проявления ошибок убывает по мере исправления этих ошибок, время между проявлениями ошибок распределено экспоненциально, а интенсивность проявления ошибок постоянна между двумя соседними проявлениями ошибок. Применение такой модели надежности программного обеспечения позволит оценить надежность программного обеспечения во время тестирования и отладки.
Устойчивость, как свойство или совокупность свойств программного обеспечения, характеризующие его возможность поддерживать приемлемый уровень функционирования при проявлениях ошибок в нем, можно оценивать условной вероятностью безотказной работы при проявлении ошибки. Согласно [5] устойчивость оценивается с помощью трех метрик, включающих двадцать оценочных элементов (рис. 4). Результаты оценки каждой метрики определяются результатами оценки определяющих ее оценочных элементов, а результат оценки устойчивости определяются результатами соответствующих ему метрик. Программное обеспечение по каждому из оценочных элементов оценивается группой экспертов – специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Для оценочных элементов принимается единая шкала оценки от 0 до 1.
Недостатком такого подхода является одинаковая оценка устойчивости для всех возможных ошибок. Поскольку вероятность возникновения отказа при проявлении разных ошибок может быть разной, возникает необходимость разделения ошибок на несколько категорий. Признаком, по которому в этом случае можно относить ошибки к той или иной категории, можно считать тяжесть ошибки. Под тяжестью ошибки в этом случае следует понимать количественную или качественную оценку вероятного ущерба при проявлении этой ошибки [6], а если говорить о надежности, то оценку вероятности возникновения отказа при проявлении ошибки. При этом категорией тяжести последствий ошибки будет являться классификационная группа ошибок по тяжести их последствий, характеризуемая определенным сочетанием качественных и/или количественных учитываемых составляющих ожидаемого (вероятного) отказа или нанесенного отказом ущерба.
Рис. 4. Метрики и оценочные элементы устойчивости программного обеспечения по ГОСТ 28195 – 89
В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки целесообразно использовать условную вероятность отказа и его возможных последствий при проявлении ошибок разных категорий. Для программного обеспечения, создаваемого для систем управления, потеря работоспособности которых может повлечь за собой катастрофические последствия, возможные категории тяжести ошибок приведены в таблице 1.
Таблица 1. Категории тяжести ошибки в программном обеспечении, нарушение работоспособности которого могут привести к катастрофическим последствиям
Для программного обеспечения общего применения или программного обеспечения систем, нарушение работоспособности которых не представляет угрозы жизни людей и не приводит к разрушению самой системы, возможные категории тяжести приведены в таблице 2.
Таблица 2. Категории тяжести ошибки в программном обеспечении, нарушение работоспособности которого не приводят к катастрофическим последствиям
Оценку степени тяжести ошибки как условной вероятности возникновения отказа (последствий этого отказа), можно производить согласно [5], используя метрики и оценочные элементы, характеризующие устойчивость программного обеспечения. При этом оценка производится для каждой ошибки в отдельности, а не для всего программного обеспечения. Далее исходя из проведенных оценок возможно определение устойчивости программного обеспечения к проявлениям ошибок каждой из категорий.
Восстанавливаемость программного обеспечения, как свойство или совокупность свойств характеризующих способность программного обеспечения восстановления своего уровня пригодности и восстановления данных, непосредственно поврежденных вследствии проявлении ошибки (отказа), характеризуется полнотой и длительностью восстановления функционирования программ в процессе перезапуска или перезагрузки ЭВМ. В [5] восстанавливаемость предлагается оценивать по среднему времени восстановления. При этом следует учитывать, что время восстановления функционирования программного обеспечения складывается не только из времени потребного для перезагрузки ЭВМ и загрузки самого программного обеспечения, но и из времени необходимого для восстановления данных и это время в ряде случаев может значительно превышать время перезагрузки.
Показатели надежности программного обеспечения в значительной степени адекватны аналогичным характеристикам, принятых для других технических систем. Наиболее широко используется показатель наработки на отказ. Наработка на отказ – это отношение суммарной наработки объекта к математическому ожиданию числа его отказов в течении этой наработки. Для программного обеспечения использование данного показателя затруднено, в силу особенностей тестирования и отладки программного обеспечения (ошибка вызвавшая отказ, как правило, исправляется и больше не повторяется). Поэтому целесообразно использовать показатель средней наработки до отказа – математического ожидания времени функционирования программного обеспечения до отказа. При использовании модели надежности программного обеспечения предполагающей экспоненциальное распределение времени между отказами, среднее время наработки до отказа равно величине обратной интенсивности отказов. Интенсивность отказов можно оценить исходя из оценок стабильности и устойчивости программного обеспечения. Обобщение характеристик отказов и восстановлений производится в показателе коэффициент готовности [2]. Коэффициент готовности программного обеспечения это вероятность того, что программное обеспечение окажется в работоспособном состоянии в произвольный момент времени. Значение коэффициента готовности соответствует доле времени полезной работы программного обеспечения на достаточно большом интервале времени, содержащем отказы и восстановления.
Источники ошибок программного обеспечения
Источниками ошибок в программном обеспечении являются специалисты – конкретные люди с их индивидуальными особенностями, квалификацией, талантом и опытом. Вследствие этого плотность потоков ошибок и размеры необходимых корректировок в модулях и компонентах при разработке и сопровождении программного обеспечения могут различаться в десятки раз. Однако в крупных комплексах программ статистика и распределение ошибок и типов выполняемых изменений, необходимых для их исправления, для коллективов разных специалистов нивелируются и проявляются общие закономерности, которые могут использоваться как ориентиры при выявлении ошибок и их систематизации. Этому могут помогать оценки типовых ошибок, модификаций и корректировок путем их накопления и обобщения по опыту создания определенных классов программного обеспечения.
Основными причинами ошибок программного обеспечения являются:
- Большая сложность программного обеспечения, например, по сравнению с аппаратурой ЭВМ.
- Неправильный перевод информации из одного представления в другое на макро и микро уровнях. На макро уровне, уровне проекта, осуществляется передача и преобразование различных видов информации между организациями, подразделениями и конкретными исполнителями на всех этапах жизненного цикла ПО. На микро уровне, уровне исполнителя, производится преобразование информации по схеме: получить информацию, запомнить, выбрать из памяти, воспроизвести информацию.
Источниками ошибок программного обеспечения являются:
Внутренние: ошибки проектирования, ошибки алгоритмизации, ошибки программирования, недостаточное качество средств защиты, ошибки в документации.
Внешние: ошибки пользователей, сбои и отказы аппаратуры ЭВМ, искажение информации в каналах связи, изменения конфигурации системы.
- Признаками выявления ошибок являются:
- Преждевременное окончание программы.
- Увеличение времени выполнения программы.
- Нарушение последовательности вызова отдельных подпрограмм.
Ошибки выхода информации, поступающей от внешних источников, между входной информацией возникает не соответствие из-за: искажение данных на первичных носителях, сбои и отказы в аппаратуре, шумы и сбои в каналах связи, ошибки в документации.
Ошибки, скрытые в самой программе: ошибка вычислений, ошибка ввода-вывода, логические ошибки, ошибка манипулирования данными, ошибка совместимости, ошибка сопряжения.
Искажения входной информации, подлежащей обработке: искажения данных на первичных носителях информации; сбои и отказы в аппаратуре ввода данных с первичных носителей информации; шумы и сбои в каналах связи при передачи сообщений по линиям связи; сбои и отказы в аппаратуре передачи или приема информации; потери или искажения сообщений в буферных накопителях вычислительных систем; ошибки в документировании; используемой для подготовки ввода данных; ошибки пользователей при подготовки исходной информации.
Неверные действия пользователя:
- Неправильная интерпретация сообщений.
- Неправильные действия пользователя в процессе диалога с программным обеспечением.
- Неверные действия пользователя или по-другому, их можно назвать ошибками пользователя, которые возникают вследствие некачественной программной документации: неверные описания возможности программ; неверные описания режимов работы; неверные описания форматов входной и выходной информации; неверные описания диагностических сообщений.
Неисправности аппаратуры установки: приводят к нарушениям нормального хода вычислительного процесса; приводят к искажениям данных и текстов программ в основной и внешней памяти.
Итак, при рассмотрении основных причин возникновения отказа и сбоев программного обеспечения можно сказать, что эти знания позволяют своевременно принимать необходимые меры по недопущению отказов и сбоев программного обеспечения.
Виды ошибок программного обеспечения
Характеристика основных видов ошибок программного обеспечения
Рассмотрим классификацию ошибок по месту их возникновения, которая рассмотрена в книге С. Канера «Тестирование программного обеспечения». Фундаментальные концепции менеджмента бизнес-приложений. Главным критерием программы должно быть ее качество, которое трактуется как отсутствие в ней недостатков, а также сбоев и явных ошибок. Недостатки программы зависят от субъективной оценкой ее качества потенциальным пользователем. При этом авторы скептически относятся к спецификации и утверждают, что даже при ее наличии, выявленные на конечном этапе недостатки говорят о ее низком качестве. При таком подходе преодоление недостатков программы, особенно на заключительном этапе проектирования, может приводить к снижению надежности. Очевидно, что для разработки ответственного и безопасного программного обеспечения (ПО) такой подход не годится, однако проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы. Должна быть разработана система некоторых ограничений, которая бы учитывала эти факторы при разработке и сертификации такого рода ПО. Для обычных программ все проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего неизбежны.
В краткой классификации выделяются следующие ошибки.
- ошибки пользовательского интерфейса.
- ошибки вычислений.
- ошибки управления потоком.
- ошибки передачи или интерпретации данных.
- перегрузки.
- контроль версий.
- ошибка выявлена и забыта.
- ошибки тестирования.
1. Ошибки пользовательского интерфейса.
Многие из них субъективны, т.к. часто они являются скорее неудобствами, чем «чистыми» логическими ошибками. Однако они могут провоцировать ошибки пользователя программы или же замедлять время его работы до неприемлемой величины. В результате чего мы будем иметь ошибки информационной системы (ИС) в целом. Основным источником таких ошибок является сложный компромисс между функциональностью программы и простотой обучения и работы пользователя с этой программой. Проблему надо начинать решать при проектировании системы на уровне ее декомпозиции на отдельные модули, исходя из того, что вряд ли удастся спроектировать простой и удобный пользовательский интерфейс для модуля, перегруженного различными функциями. Кроме того, необходимо учитывать рекомендации по проектированию пользовательских интерфейсов. На этапе тестирования ПО полезно предусмотреть встроенные средства тестирования, которые бы запоминали последовательности действий пользователя, время совершения отдельных операций, расстояния перемещения курсора мыши. Кроме этого возможно применение гораздо более сложных средств психо-физического тестирования на этапе тестирования интерфейса пользователя, которые позволят оценить скорость реакции пользователя, частоту этих реакций, утомляемость и т.п. Необходимо отметить, что такие ошибки очень критичны с точки зрения коммерческого успеха разрабатываемого ПО, т.к. они будут в первую очередь оцениваться потенциальным заказчиком.
2.Ошибки вычислений.
Выделяют следующие причины возникновения таких ошибок:
- неверная логика (может быть следствием, как ошибок проектирования, так и кодирования);
- неправильно выполняются арифметические операции (как правило — это ошибки кодирования);
- неточные вычисления (могут быть следствием, как ошибок проектирования, так и кодирования). Очень сложная тема, надо выработать свое отношение к ней с точки зрения разработки безопасного ПО.
Выделяются подпункты: устаревшие константы; ошибки вычислений; неверно расставленные скобки; неправильный порядок операторов; неверно работает базовая функция; переполнение и потеря значащих разрядов; ошибки отсечения и округления; путаница с представлением данных; неправильное преобразование данных из одного формата в другой; неверная формула; неправильное приближение.
3.Ошибки управления потоком.
В этот раздел относится все то, что связано с последовательностью и обстоятельствами выполнения операторов программы.
Выделяются подпункты:
- очевидно неверное поведение программы;
- переход по GOTO;
- логика, основанная на определении вызывающей подпрограммы;
- использование таблиц переходов;
- выполнение данных (вместо команд). Ситуация возможна из-за ошибок работы с указателями, отсутствия проверок границ массивов, ошибок перехода, вызванных, например, ошибкой в таблице адресов перехода, ошибок сегментирования памяти.
4.Ошибки обработки или интерпретации данных.
Выделяются подпункты:
- проблемы при передаче данных между подпрограммами (сюда включены несколько видов ошибок: параметры указаны не в том порядке или пропущены, несоответствие типов данных, псевдонимы и различная интерпретация содержимого одной и той же области памяти, неправильная интерпретация данных, неадекватная информация об ошибке, перед аварийным выходом из подпрограммы не восстановлено правильное состояние данных, устаревшие копии данных, связанные переменные не синхронизированы, локальная установка глобальных данных (имеется в виду путаница локальных и глобальных переменных), глобальное использование локальных переменных, неверная маска битового поля, неверное значение из таблицы);
- границы расположения данных (сюда включены несколько видов ошибок: не обозначен конец нуль-терминированной строки, неожиданный конец строки, запись/чтение за границами структуры данных или ее элемента, чтение за пределами буфера сообщения, чтение за пределами буфера сообщения, дополнение переменных до полного слова, переполнение и выход за нижнюю границу стека данных, затирание кода или данных другого процесса);
- проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных).
5.Повышенные нагрузки.
При повышенных нагрузках или нехватке ресурсов могут возникнуть дополнительные ошибки. Выделяются подпункты: требуемый ресурс недоступен; не освобожден ресурс; нет сигнала об освобождении устройства; старый файл не удален с накопителя; системе не возвращена неиспользуемая память; лишние затраты компьютерного времени; нет свободного блока памяти достаточного размера; недостаточный размер буфера ввода или очереди; не очищен элемент очереди, буфера или стека; потерянные сообщения; снижение производительности; повышение вероятности ситуационных гонок; при повышенной нагрузке объем необязательных данных не сокращается; не распознается сокращенный вывод другого процесса при повышенной загрузке; не приостанавливаются задания с низким приоритетом.
7.Ошибки тестирования.
Являются ошибками сотрудников группы тестирования, а не программы. Выделяются подпункты:
- пропущенные ошибки в программе;
- не замечена проблема (отмечаются следующие причины этого: тестировщик не знает, каким должен быть правильный результат, ошибка затерялась в большом объеме выходных данных, тестировщик не ожидал такого результата теста, тестировщик устал и невнимателен, ему скучно, механизм выполнения теста настолько сложен, что тестировщик уделяет ему больше внимания, чем результатам);
- пропуск ошибок на экране;
- не документирована проблема (отмечаются следующие причины этого: тестировщик неаккуратно ведет записи, тестировщик не уверен в том, что данные действия программы являются ошибочными, ошибка показалась слишком незначительной, тестировщик считает, что ошибку не будет исправлена, тестировщика просили не документировать больше подобные ошибки).
8.Ошибка выявлена и забыта.
Описываются ошибки использования результатов тестирования. По-моему, раздел следует объединить с предыдущим. Выделяются подпункты: не составлен итоговый отчет; серьезная проблема не документирована повторно; не проверено исправление; перед выпуском продукта не проанализирован список нерешенных проблем.
Необходимо заметить, что изложенные в 2-х последних разделах ошибки тестирования требуют для устранения средств автоматизации тестирования и составления отчетов. В идеальном случае, эти средства должны быть проинтегрированы со средствами и технологиями проектирования ПО. Они должны стать важными инструментальными средствами создания высококачественного ПО. При разработке средств автоматизированного тестирования следует избегать ошибок, которые присущи любому ПО, поэтому нужно потребовать, чтобы такие средства обладали более высокими характеристиками надежности, чем проверяемое с их помощью ПО.
Меры по повышению надежности программного обеспечения
Лучшим и самым оптимальным способом (если не брать во внимание научно-технический прогресс и постоянное развитие IT-технологий, которые способствуют повышению качества характеристик программ) повышения надёжности программного обеспечения является строжайший контроль продукции на выходе с предприятия.
В последние годы сформировалась комплексная система управления качеством продукции TQM (Totaly Quality Management), которая концептуально близка к предшествующей более общей системе на основе стандартов ИСО серии 9000. Система ориентирована на удовлетворение требований потребителя, на постоянное улучшение процессов производства или проектирования, на управление процессами со стороны руководства предприятия на основе фактического состояния проекта. Основные достижения TQM состоят в углублении и дифференциации требований потребителей по реализации процессов, их взаимодействию и обеспечению качества продукции. Системный подход поддержан рядом специализированных инструментальных средств, ориентированных на управление производством продукции. Поэтому эта система пока не находит применения в области обеспечения качества жизненного цикла программных средств.
Применение этого комплекса может служить основой для систем обеспечения качества программных средств, однако требуется корректировка, адаптация или исключение некоторых положений стандартов применительно к принципиальным особенностям технологий и характеристик этого вида продукции. Кроме того, при реализации систем качества необходимо привлечение ряда стандартов, формально не относящихся к этой серии и регламентирующих показатели качества, жизненный цикл, верификацию и тестирование, испытания, документирование и другие особенности комплексов программ.
Активные методы повышения надежности ПС совершенствуются за счет развития средств автоматизации тестирования программ. Сложность ПС и высокие требования по их надежности требуют выработки принципов структурного построения сложных программных средств, обеспечивающих гибкость модификации ПС и эффективность их отладки. К таким принципам в работе относят:
- модульность и строгую иерархию в структурном построении программ;
- унификацию правил проектирования, структурного построения и взаимодействия компонент ПС;
- унификацию правил организации межмодульного интерфейса;
- поэтапный контроль полноты и качества решения функциональных задач.
Заключение
Несмотря на очевидную актуальность, вопрос надежности программного обеспечения не привлекает должного внимания. Вместе с тем, даже поверхностный анализ проблемы с теоретико-вероятностной точки зрения позволяет выявить некоторые закономерности.
В заключение можно подвести итог:
- В программном обеспечении имеется ошибка, если оно не выполняет того, что пользователю разумно от него ожидать;
- Отказ программного обеспечения — это появление в нем ошибки;
- Надежность программного обеспечения — есть вероятность его работы без отказов в течении определенного периода времени, рассчитанного с учетом стоимости для пользователя каждого отказа.
Из данных определений можно сделать важные выводы:
- Надежность программного обеспечения является не только внутренним свойством программы;
- Надежность программного обеспечения — это функция как самого ПО, так и ожиданий (действий) его пользователей.
Основными причинами ошибок программного обеспечения являются:
- большая сложность ПО, например, по сравнению с аппаратурой ЭВМ;
- неправильный перевод информации из одного представления в другое.
Список использованной литературы
- ГОСТ 27.002 – 89. Надежность в технике. Основные понятия. Термины и определения. // М.: Издательство стандартов, 1990.
- ГОСТ Р ИСО/МЭК 9126 – 93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. // М.: Издательство стандартов, 1994.
- ГОСТ 51901.5 – 2005. Менеджмент риска. Руководство по применению методов анализа надежности. // М.: Издательство стандартов, 2007.
- ГОСТ 28195 – 89. Оценка качества программных средств. Общие положения. // М.: Издательство стандартов, 1989.
- ГОСТ 27.310 – 95. Надежность в технике. Анализ видов, последствий и критичности отказов. // М.: Издательство стандартов, 1995.
- ГОСТ 51901.12 – 2007. Менеджмент риска. Метод анализа видов и последствий отказов. // М.: Издательство стандартов, 2007.
- Братчиков И.Л. «Синтаксис языков программирования» Наука, М.:Инси, 2005. — 344 с.
- Дейкстра Э. Заметки по структурному программированию.- М.:Дрофа, 2006, — 455 с.
- Ершов А.П. Введение в теоретическое программирование.- М.:РОСТО, 2008, — 288 с.
- Кнут Д. Искусство программирования для ЭВМ, т.1. М.: 2006, 735 с.
- Коган Д.И., Бабкина Т.С. «Основы теории конечных автоматов и регулярных языков. Учебное пособие» Издательство ННГУ, 2002. — 97 с.
- Липаев В. В. / Программная инженерия. Методологические основы. // М.: ТЕИС, 2006.
- Майерс Г. Надежность программного обеспечения.- М.:Дрофа, 2008, — 360 с.
- Рудаков А. В. Технология разработки программных продуктов. М.:Издательский центр «Академия», 2006. — 306 с.
- Тыугу, Э.Х. Концептуальное программирование. — М.: Наука, 2001, — 256 с.
- Хьюз Дж., Мичтом Дж. Структурный подход к программированию.-М.:Мир, 2000, — 278 с.
- Разработка клиент-серверного приложения по работе с базой данных «Локомотивное депо «
- Анализ особенности управления мотивацией сотрудников на предприятиях гостиничного и ресторанного бизнеса на примере АО ТГК «Вега»
- СУЩНОСТЬ И СОДЕРЖАНИЕ БАНКОВСКОГО МАРКЕТИНГА
- Оформление и ведение учета операций с сомнительными, неплатежеспособными и имеющими признаки подделки денежными знаками
- Виды, понятия, задачи оплаты труда на предприятии
- ценообразование на услуги фитнес-клубов (Российский рынок фитнес-услуг)
- Место и роль спортивной индустрии в экономике России (Теоретические аспекты индустрии спорта)
- Влияние кадровой стратегии на работу службы персонала. (СОДЕРЖАНИЕ И СУЩНОСТЬ КАДРОВОЙ СТРАТЕГИИ)
- Эффективный лидер и его команда (Виды лидерства)
- Межфирменная научно-техническая кооперация
- Прогнозирование эффективности реальных инвестиций коммерческого банка. Анализ инвестиционной деятельности ПАО «Сбербанк»
- Страхование и его государственное регулирование в РФ
#Руководства
- 30 июн 2020
-
14
Что такое баги, ворнинги и исключения в программировании
Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.
vlada_maestro / shutterstock
Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.
В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.
Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:
//В конце команды забыли поставить точку с запятой (;) int a = 5
Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.
Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:
int main() { //Мы создаём две переменные, которые просто занимают память и никак не используются int a, b; }
Мы можем попросить компилятор показать нам все предупреждения с помощью флага -Wall:
Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.
После восклицательного знака в треугольнике — количество предупреждений
Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:
//Создаём константный массив символов const char * s = "Hello World"; //Если мы попытаемся перезаписать значение константы, компилятор выдаст ошибку //Но с помощью указателей мы можем обойти её, поэтому программа успешно скомпилируется //Однако во время работы она будет выдавать ошибку сегментации * (char *) s = 'H';
Вот результат работы такого кода:
Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:
Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.
Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.
Также во время работы программы могут возникать ситуации, которые мешают корректной работе программы. Например, если вы просите пользователя ввести число, а он вводит строку.
Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.
Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.
Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.
int main() { //Бесконечная рекурсия - одна из причин переполнения стека вызовов main(); }
Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:
Вот аналогичный код на языке C#:
class Program { static void Main(string[] args) { Main(args); } }
Однако сообщение в этот раз более конкретное:
В обоих случаях программа завершается, потому что не может дальше корректно работать.
Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.
//Пробуем записать в переменную типа int значение, которое превышает лимит //Константа INT_MAX находится в библиотеке climits int a = INT_MAX + 1;
Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):
Тем не менее программа скомпилировалась. Если же такая ситуация возникнет во время вычислений, то мы можем не получить предупреждения.
Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.
К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.
Один из таких инструментов — отладчик. Он помогает контролировать ход работы программы, чтобы отслеживать разные показатели.
Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.
Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:
| Входные данные | Ожидаемый результат |
|---|---|
| 5, 10 | 15 |
| 99, 99 | 198 |
| 8, -9 | -1 |
| -1, -1 | -2 |
| fff, 8 | IllegalArgumentException |
Если какой-то из этих тестов не пройден, вы узнаете об этом и сможете всё исправить. Это намного быстрее, чем проверять всё вручную.
Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.
Учись бесплатно:
вебинары по программированию, маркетингу и дизайну.
Участвовать
Школа дронов для всех
Учим программировать беспилотники и управлять ими.
Узнать больше
Ошибки в программировании – дело обычное, хоть и неприятное. В данной статье будет рассказано о том, какими бывают ошибки (баги), а также что собой представляют исключения.
Определение
Ошибка в программировании (или так называемый баг) – это ситуация у разработчиков, при которой определенный код вследствие обработки выдает неверный результат. Причин данному явлению множество: неисправность компилятора, сбои интерфейса, неточности и нарушения в программном коде.
Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:
- Появляется сообщение об ошибке, но приложение продолжает функционировать.
- ПО вылетает или зависает. Никаких предупреждений или предпосылок этому не было. Процедура осуществляется неожиданно для пользователя. Возможен вариант, при котором контент перезапускается самостоятельно и непредсказуемо.
- Одно из событий, описанных ранее, сопровождается отправкой отчетов разработчикам.
Ошибки в программах могут привести соответствующее приложение в негодность, а также к непредсказуемым алгоритмам функционирования. Желательно обнаруживать баги на этапе ранней разработки или тестирования. Лишь в этом случае программист сможет оперативно и относительно недорого внести необходимые изменения в код для отладки ПО.
История происхождения термина
Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:
- 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
- Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.
Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.
Как классифицируют
Ошибки работы программ разделяются по разным факторам. Классификация у рядовых пользователей и разработчиков различается. То, что для первых – «просто программа вылетела» или «глючит», для вторых – огромная головная боль. Но существует и общепринятая классификация ошибок. Пример – по критичности:
- Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
- Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
- Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.
Последний вариант требует особого внимания со стороны программистов. Их стараются обнаружить и устранить в первую очередь. Критические ошибки могут отложить релиз исходной программы на неопределенный срок.
Также существуют различные виды сбоев в плане частоты проявления: постоянные и «разовые». Вторые встречаются редко, чаще – при определенных настройках и действиях со стороны пользователя. Первые появляются независимо от используемой платформы и выполненных клиентом манипуляций.
Иногда может получиться так, что ошибка возникает только на устройстве конкретного пользователя. В данном случае устранение неполадки требует индивидуального подхода. Иногда – полной замены компьютера. Связано это с тем, что никто не будет редактировать исходный код, когда он «глючит» только у одного пользователя.
Виды
Существуют различные типы ошибок в программах в зависимости от типовых условий использования приложений. Пример – сбои, которые возникают при возрастании нагрузки на оперативную память или центральный процессор устройства. Есть баги граничных условий, сбоя идентификаторов, несовместимости с архитектурой процессора (наиболее распространенная проблема на мобильных устройствах).
Разработчики выделяют следующие типы ошибок по уровню сложности:
- «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
- «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
- «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
- «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.
Также есть классификация «по критичности». Тут всего два варианта – warning («варнинги») и критические весомые сбои. Первые сопровождаются характерными сообщениями и отчетами для разработчиков. Они не представляют серьезной опасности для работоспособности приложения. При компилировании такие сбои легко исправляются. В отдельных случаях компилятор справляется с этой задачей самостоятельно. А вот критические весомые сбои говорят сами за себя. Они приводят к серьезным нарушениям ПО. Исправляются обычно путем проработки логики и значительных изменений программного кода.
Типы багов
Ошибки в программах бывают:
- логическими;
- синтаксическими;
- взаимодействия;
- компиляционные;
- ресурсные;
- арифметические;
- среды выполнения.
Это – основная классификация сбоев в приложениях и операционных системах. Логические, синтаксические и «среды выполнения» встречаются в разработке чаще остальных. На них будет сделан основной акцент.
Ошибки синтаксиса
Синтаксические баги распространены среди новичков. Они относятся к категории «самых безобидных». С данной категорией ошибок способны справиться компиляторы тех или иных языков. Соответствующие инструменты показывают, где допущена неточность. Остается лишь понять, как исправить ее.
Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:
Код написан неверно. Согласно действующим синтаксическим нормам, в Pascal в первой строчке нужно в конце поставить точку с запятой.
Логические
Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».
Логические сбои обычного типа – самые сложные и неприятные. Их тяжелее всего обнаружить и исправить. С точки зрения языка программа может быть написана идеально, но работать неправильно. Подобное явление – следствие логической ошибки. Компиляторы их не обнаруживают.
Выше – пример логической ошибки в программе. Тут:
- Происходит сравнение значения i с 15.
- На экран выводится сообщение, если I = 15.
- В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.
Может показаться, что ошибка безобидная. В приведенном примере так и есть, но в более крупных программах такое явление приводит к серьезным последствиям.
Время выполнения
Run-time сбои – это ошибка времени выполнения программы. Встречается даже когда исходный код лишен логических и синтаксических ошибок. Связаны такие неполадки с ходом выполнения программного продукта. Пример – в процессе функционирования ПО был удален файл, считываемый программой. Если игнорировать подобные неполадки, можно столкнуться с аварийным завершением работы контента.
Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.
Компиляционный тип
Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.
Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.
Ресурсные
Ресурсный тип ошибок – это сбои вроде «переполнение буфера» или «нехватка памяти». Тесно связаны с «железом» устройства. Могут быть вызваны действиями пользователя. Пример – запуск «свежих» игр на стареньких компьютерах.
Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.
Взаимодействие
Подразумевается взаимодействие с аппаратным или программным окружением. Пример – ошибка при использовании веб-протоколов. Это приведет к тому, что облачный сервис не будет нормально функционировать. При постоянном возникновении соответствующей неполадки остается один путь – полностью переписывать «проблемный» участок кода, ответственный за соответствующий баг.
Исключения и как избежать багов
Исключение – событие, при возникновении которых начинается «неправильное» поведение программы. Механизм, необходимый для стабилизации обработки неполадок независимо от типа ПО, платформ и иных условий. Помогают разрабатывать единые концепции ответа на баги со стороны операционной системы или контента.
Исключения бывают:
- Программными. Они генерируются приложением или ОС.
- Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.
Исключения нужны для охвата критических багов. Избежать неполадок помогут отладчики на этапе разработки. А еще – своевременное поэтапное тестирование программы.
P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.
Программист и ошибки — актуально во все времена
Время на прочтение
6 мин
Количество просмотров 8.8K
Годы бегут, компьютеры становятся мощнее, листинги программ длиннее, а программисты всё ещё допускают те же самые ошибки (или же сталкиваются с ними)… Предлагаю разобраться с основными типами ошибок и причинами, по которым они происходят
Чтобы максимально раскрыть смысл фразы «актуально во все времена«, в качестве иллюстрирующих примеров будут приведены сведения времён старой доброй DOS 
, поэтому материал рекомендуется к прочтению любителям ностальгии
Какие же бывают типы ошибок?
Тип №1. Ошибки в программном комплексе, допущенные при разработке и не обнаруженные при его тестировании
• В «Справочнике Microsoft Works» и интерактивной помощи пакета интегрированной обработки информации Works 2.0 функция ЕСЛИ описана как
ЕСЛИ (Условие, ЗначениеЛожь, ЗначениеИстина)
Однако в действительности работа данной функции должна иметь следующий вид:
ЕСЛИ (Условие, ЗначениеИстина, ЗначениеЛожь)
В «Руководстве пользователя Microsoft Works для Windows» пакета Works 3.0 эта ошибка исправлена
• В русифицированном варианте Norton Utilities (версия 7.0, фирма Symantec) в утилите форматирования sformat при задании опции:
Системные файлы: [Не ставить…]
при форматировании выдаётся сообщение:
Системные файлы: Ставить
и наоборот, при задании опции:
Системные файлы: [Ставить…]
при форматировании выдаётся сообщение:
Системные файлы: Не ставить
• Неудача при запуске первого американского спутника к Венере случилась, вероятнее всего, из-за ошибки в программе – вместо требуемой в операторе запятой программист поставил точку. Вот как был записан этот оператор:
DO 50 I = 12.525
На самом же деле он должен был выглядеть следующим образом:
DO 50 I = 12,525
В программе на Фортране IV требовался цикл, а программист поставил точку, а в результате получилось присваивание значения 12,525 неявной переменной DO50I (пробелы в Фортране игнорируются) [ Спасибо за этот ценный комментарий-поправку хабраюзеру rexxer2 ]
• Потеря связи с космической станцией «Фобос-1» (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.
• Причиной осложнений, возникших при возвращении на Землю из космической экспедиции советско-афганского и советско-французского экипажей, явились ошибки, допущенные в программном обеспечении бортовых компьютеров.
К данному типу относятся ошибки в алгоритмах, когда алгоритм неверный или создан на основе неправильных представлений о действительности:
• Одна из первых компьютерных систем противовоздушной обороны США (60-е годы) в первое же дежурство подняла тревогу, приняв восходящую из-за горизонта Луну за вражескую ракету, поскольку этот «объект» приближался к территории США и не подавал сигналов, что он «свой»
Тип №2. Ошибки, возникающие при вводе в компьютер неверных данных
Весьма популярные ошибки, предотвращение которых известно под названием «защита от дурака»
• В 1983 году произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.
• Ещё один печальный пример: в восьмидесятые годы прошлого века в Антарктиде разбился самолёт с туристами на борту, поскольку в управляющую полётом систему были заложены неверные координаты аэропорта взлёта и система ошибочно рассчитала высоту полёта над горами
Тип 3. Компьютерные вирусы, «вмешивающиеся» в работу компьютера и выполняемую им программу.
• Летом 1988 года в Мичиганском госпитале компьютерный вирус инфицировал три компьютера, которые обрабатывали информацию о пациентах. Вирус перемешал фамилии пациентов в базе данных. В результате данного «вмешательства» диагностические сведения одних пациентов оказались приписанными другим пациентам.
Тип 4. Выход из строя элементов компьютера и обслуживающих его систем
Тут, в принципе, всё обстоит точно так же, как и 20 лет назад: в процессе эксплуатации компьютерной системы возможно физическое повреждение накопителя, выход из строя блока питания, отключение электроэнергии, колебание напряжения в электрической сети и др. Результатом такого рода неисправностей может быть полная потеря информации, хранящейся на жёстком диске, частичная или полная потеря информации в файлах баз данных, нарушение работы систем, управляемых компьютером и многое другое. Для предотвращения ошибок данного типа используют системы, в которых одновременно работают несколько компьютеров, дублирующих друг друга, в компьютеры устанавливают два и более параллельно работающих накопителя (вспоминаем RAID-массивы), аппаратуру подключают к источникам бесперебойного питания, которые обеспечивают его работу при отключении электроэнергии или колебаниях напряжения электрической сети и т.д. и т.п.
Тип №5. Выход из строя или сбои в работе измерительных приборов и датчиков, используемых при управлении какими-либо техническими системами и технологическими процессами
• В июле 1985 года произошло преждевременное отключение компьютера одного из основных двигателей американского космического корабля «Челленджер» (Шаттл), едва не закончившееся катастрофой. Положение спас командир корабля, сумевший на двух работающих основных двигателях и двух менее мощных двигателях для маневрирования вывести «Челленджер» на орбиту. Причина же заключалась в том, что один из трёх бортовых компьютеров, управляющих двигателями (на каждый двигатель по компьютеру), был «обманут» вышедшим из строя датчиком, измеряющим температуру газа в двигателе. Для устранения подобных неполадок в будущем на следующих космических кораблях серии Шаттл были установлены датчики изменённой конструкции.
• При запуске французской ракеты нового поколения «Ариан-5» примерно на 37-й секунде полёта компьютер, находившийся на борту ракеты, получил от датчиков системы управления неверную информацию о пространственной ориентации ракеты. Исходя из этой информации, компьютер начал корректировать траекторию полёта для того, чтобы компенсировать не существующую на самом деле погрешность. Ракета стала отклоняться от курса, что привело к возрастанию нагрузок на её корпус. В результате чрезмерных нагрузок верхняя часть ракеты отвалилась, и по команде с земли ракета была взорвана.
Тип 6. «Злая воля человека», носителем которой чаще всего выступает либо программист, либо оператор
Программист, создавая программу, может специально внести в неё ошибку . Другим вариантом проявления «злой воли программиста» является включение в программу «логической бомбы», срабатывающей, например, после определённого числа запусков программы, определённых значениях входных данных и др. Оператор, обслуживающий компьютер, может сознательно ввести в компьютер неверные данные, которые и будут обработаны компьютером, выдавая неверные выходные данные в соответствии с принципом «мусор на входе – мусор на выходе».
• Сборочный конвейер волжского автомобильного завода в городе Тольятти работает под управлением АСУ, которая обеспечивает своевременное поступление деталей на конвейер со складов и из цехов вспомогательных производств. Для выполнения этой задачи информационно-управляющая система хранит информацию о тысячах узлов и деталей, из которых собирается автомобиль, о запасах деталей на складах, об их движении по транспортным линиям и т. д. На основе этой информации АСУ самостоятельно управляет автоматизированными складами, транспортными конвейерами, а также рядом других устройств.
Программист, разрабатывавший программное обеспечение для управления главным конвейером Волжского автозавода, сознательно внёс в программу «логическую бомбу» в знак протеста против низкой зарплаты. Через некоторое время эта «логическая бомба» сработала, и главный конвейер остановился на несколько дней. Ущерб от остановки составил 1 миллион рублей (в ценах 80-х годов), этот ущерб был несопоставим с зарплатой всех программистов ВАЗа, вместе взятых, а программист был дисквалифицирован и переведён в рабочие.
Подводим итоги
Анализ приведённых типов ошибок показывает, что основными задачами, стоящими перед разработчиками программного обеспечения в плане повышения его надёжности, является:
- устранение ошибок, допущенных при разработке программного обеспечения (1-й тип ошибок);
- проектирование программного обеспечения с учётом человеческого фактора, то есть таким образом, чтобы оно было защищено от «дурака» (2-й тип ошибок). При этом «свалять дурака» могут не только пользователи, работающие за компьютером, но и приборы и датчики, от которых компьютер принимает информацию при управлении техническими или иными системами (5-й тип ошибок);
- использование известных мер безопасности для снижения вероятности переноса компьютерных вирусов (3-й тип ошибок) с программами, передаваемыми в эксплуатацию (в практике распространения программ известны случаи, когда разработчики этих программ записывают дистрибутивы на заражённых вирусами компьютерах).
Таким образом, программный продукт в обязательном порядке должен проходить тщательное тестирование и отладку (выявление ошибок 1-го и 2-го типов). Выявление возможных ошибок 5-го типа производится с помощью имитации отказа приборов и датчиков на прошедших тестирование программных комплексах.
Надеюсь, данный материал окажется полезным. Желаю всем делать поменьше ошибок, ведь это особенно актуально в нынешние кризисные времена :^)
PS: сведения предоставляются по данным из этих источников, множество важных дополнений и опровержений представлены ниже в комментариях, особенно от хабраюзера scoon. Однако оригинальный текст не изменяю
Готовая программа не всегда работает как надо. Бывает, возникают баги, предупреждения, исключения. В итоге программа зависает, дает сбой или вылетает. Но это не конец света. Любую ошибку в коде можно исправить, если знать, почему она возникла.
Программная ошибка: что это и почему возникает
Программная ошибка — это дефект в коде. Из-за него программа сбоит или выдает неверные результаты. Некоторые ошибки серьезные — например, блокируют логин и пароль, из-за чего пользователь не может попасть в личный кабинет. А другие незаметны. Некоторое время программа работает как будто бы исправно — и только потом начинает глючить.
Ошибка в программировании — это зачастую ошибки разработчиков, которые находят тестировщики. Запускают разные тесты и отладку, чтобы определить источники проблемы.
Научитесь находить ошибки в приложениях и на сайтах до того, как ими начнут пользоваться клиенты. Для этого освойте профессию «Инженер по тестированию». Изучать язык программирования необязательно. Тестировщик работает с готовыми сайтами, приложениями, сервисами, а не с кодом. В программе от Skypro: четыре проекта для портфолио, практика с обратной связью, все основные инструменты тестировщика.
Ошибки часто называют багами, но подразумевают под ними разное, например:
❗ Ворнинги, или предупреждения. Возникают, когда программа начинает вести себя не так, как задумывалось. Не являются критичными ошибками. Программа с ворнингами работает, но с аномалиями.
❗ Исключения. Это не ошибки, а особые ситуации, которые нужно обработать.
❗ Синтаксические ошибки. Это ошибка в программе, связанная с написанием кода. Пример: программист забыл поставить точку или неверно написал название оператора. Если не исправить, код программы не запустится, а останется просто текстом.
Классификация багов
У багов есть два атрибута — серьезности (Severity) и приоритета (Priority). Серьезность касается технической стороны, а приоритет — организационной.
🚨 По серьезности. Атрибут показывает, как сильно ошибка влияет на общую функциональность программы. Чем выше значение атрибута, тем хуже.
По серьезности баги классифицируют так:
- Blocker — блокирующий баг. Программа запускается, но спустя время баг останавливает ее выполнение. Чтобы снова пользоваться программой, блокирующую ошибку в коде устраняют.
- Critical — критический баг. Нарушает функциональность программы. Появляется в разных частях кода, из-за этого основные функции не выполняются.
- Major — существенный баг. Не нарушает, но затрудняет работу основного функционала программы либо не дает функциям выполняться так, как задумано.
- Minor — незначительный баг. Слабо влияет на функционал программы, но может нарушать работу некоторых дополнительных функций.
- Trivial — тривиальный баг. На работу программы не влияет, но ухудшает общее впечатление. Например, на экране появляются посторонние символы или всё рябит.
🚦 По приоритету. Атрибут показывает, как быстро баг необходимо исправить, пока он не нанес программе приличный ущерб. Бывает таким:
- Top — наивысший. Такой баг — суперсерьезный, потому что может обвалить всю программу. Его устраняют в первую очередь.
- High — высокий. Может затруднить работу программы или ее функций, устраняют как можно скорее.
- Normal — обычный. Баг программу не ломает, просто где-то что-то будет работать не совсем верно. Устраняют в штатном порядке.
- Low — низкий. Баг не влияет на программу. Исправляют, только если у команды есть на это время.
Типы ошибок в программе
🧨 Логические. Приводят к тому, что программа зависает, работает не так, как надо, или выдает неожиданные результаты — например, не записывает файл, а стирает.
Логические ошибки коварны: их трудно обнаружить. Программа выглядит так, будто в ней всё правильно, но при этом работает некорректно. Чтобы победить логические ошибки, специалист должен хорошо ориентироваться в коде программы.
🧨 Синтаксические. Это опечатки в названиях операторов, пропущенные запятые или кавычки. Безобидные ошибки: их обнаруживают и подсвечивают в коде компиляторы, а программисту остается исправить.
🧨 Взаимодействия. Это ошибка в участке кода, который отвечает за взаимодействие с аппаратным или программным окружением. Такая ошибка возникает, например, если неправильно использовать веб-протоколы. Исправляется элементарно: разработчик переписывает нужный кусок кода.
🧨 Компиляционные. Любая программа — это текст. Чтобы он заработал как программа, используют компилятор. Он преобразует программный код в машинный, но одновременно может вызывать ошибки.
Компиляционные баги появляются, если что-то не так с компилятором или в коде есть синтаксические ошибки. Компилятор будто ругается: «Не понимаю, что тут написано. Не знаю, как обработать».
🧨 Ошибки среды выполнения. Возникают, когда программа скомпилирована и уже выглядит как файл — жми и работай. Юзер запускает файл, а программа тормозит и виснет. Причина — нехватка ресурсов, например памяти или буфера.
Такой баг — ошибка разработчика. Он не предвидел реальные условия развертывания программы. Теперь ему надо вернуться в исходный код и поправить фрагмент.
🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг. Надо лезть в код и проверять математику.
Инженер-тестировщик: новая работа через 9 месяцев
Получится, даже если у вас нет опыта в IT
Узнать больше
Что такое исключения в программах
Это механизм, который помогает программе обрабатывать нестандартную ситуацию и при этом не вылетать. Идеально, если программист предусмотрел все возможные ситуации. Но так бывает редко, поэтому лучше использовать специальный обработчик. Он обработает исключения так, что программа продолжит работать.
Как это происходит:
- Когда программист кодит, то продумывает, в какой части программы может вылезти ошибка.
- В этой части пишет специальный фрагмент, который предупредит компьютер, что ошибка — вполне ожидаемое явление и резко обрывать программу не нужно.
- Когда юзер запустит программу и появится ошибка, компьютер увидит заранее подготовленное предупреждение программиста. Продолжит выполнять алгоритм так, словно никакого бага и не было.
Исключения бывают программными и аппаратными:
- Аппаратные создает процессор. К ним относят деление на ноль, выход за границы массива, обращение к невыделенной памяти.
- Программные создает операционка и приложения. Возникают, когда программа их инициирует: аномальная ситуация возникла — программа создала исключение.
Как контролировать баги в программе
🔧 Следите за компилятором. Когда компилятор преобразует текст программы в машинный код, то подсвечивает в нём сомнительные участки, которые способны вызывать баги. Некоторые предупреждения не обозначают баг как таковой, а только говорят: «Тут что-то подозрительное». Всё подозрительное надо изучать и прорабатывать, чтобы не было проблемы в будущем.
🔧 Используйте отладчик. Это программа, которая без участия айтишника проверяет, исправно ли работает алгоритм. В случае чего сообщает об ошибках. Например, отладчик используют для построчного выполнения программы. Вместе с тем проверяют значения переменных: фактические сравнивают с ожидаемыми. Если что-то не сходится, ищут баги и исправляют.
🔧 Проводите юнит-тесты. Это когда разработчик или тестировщик описывает ситуации для каждого компонента и указывает, к какому результату должна привести программа. Потом запускает проверку. Если результат не совпадает с ожидаемым, появляется предупреждение. Дальше программисты находят и устраняют проблему.
Ключевое: что такое ошибки в программировании
- Ошибка в программировании — это дефект кода, баг, который может вызывать в программе сбои и неожиданное поведение.
- По серьезности баги делятся на блокирующие, критические, существенные, незначительные, тривиальные. По приоритету — на наивысший, высокий, обычный, низкий.
- Ошибки в коде могут быть разными, например связанные с логикой программы. Или с математическими вычислениями — логические. Еще бывают синтаксические, ошибки взаимодействия, компиляционные и ошибки среды выполнения.
- Некоторые ошибки помогают ловить обработчики исключений.
- Чтобы находить ошибки в коде, тестировщики используют компиляторы, отладчики и пишут юнит-тесты.