9.5 Баг, дефект и ошибки в программировании, баг-трекеры

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

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

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

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

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

Этимология термина «баг»

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

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

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

Baffle Ball , первая механическая игра в пинбол , рекламировалась как «свободная от ошибок» в 1931 году. Проблемы с военной экипировкой во время Второй мировой войны назывались ошибками (или сбоями ). В книге, опубликованной в 1942 году, Луиза Дикинсон Рич , говоря о механизированной машине для резки льда , сказала: «Распиловка льда была приостановлена ​​до тех пор, пока не появится создатель, который выведет жуков из его любимой машины».

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

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

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

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

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

Значение и классификация ошибок программного обеспечения

В зависимости от этапа разработки ПО, на котором выявляется ошибка выделяют:

• синтаксические ошибки (распознаваемые в качестве таковых транслятором и делающие компиляцию невозможной) — например отсутствие или несоответствие открывающей и закрывающей скобок;
• предупреждения (warnings) компилятора — например, использование неинициализированной переменной. В этом случае компилятор может заметить, что программист делает что-то необычное (вероятно неверное), и сообщает об этом, однако программист сам принимает решение игнорировать сообщение или нет;
• ошибки времени исполнения, смысловые ошибки (семантические) — например вычитание переменных вместо сложения или ошибка сегментации.

Также баги делят на следующие категории

• Арифметические ошибки (деление на 0, переполнение)
• Логические ошибки (бесконечные циклы, бесконечная рекурсия)
• Ошибки работы с ресурсами (null pointer, access violation, переполнение буфера)
• Ошибки синхронизации многопоточности (дедлок, race condition)

По размеру:

• Showstoppers;
• Серьезные;
• Незначительные баги;

По времени появления:

• Постоянно, при каждом запуске;
• Иногда («плавающий» тип);
• Только на машине у клиента (зависит от локальных настроек у клиента);

По месту и направлению:

• Ошибки пользовательского интерфейса;
• Системы обработки ошибок;
• Ошибки, связанные с граничными условиями;
• Ошибки вычислений;
• Ошибки управления потоком;
• Ошибки обработки или интерпретации данных;
• При ситуации "гонок";
• Повышение нагрузки;
• Ошибки контроля версии и индентификаторов;
• Ошибки тестирования;

Разновидности по типу обнаруения и выявления

• Борбаг — легко обнаруживаемая стабильная ошибка
• Гейзенбаг — сложно обнаруживаемая, периодически исчезающая и меняющая свойства, при попытке обнаружения, ошибка
• Мандельбаг — ошибка с очень сложным, хаотичным, поведением
• Шрединбаг — критическая ошибка, которая не проявляется, пока кто-нибудь на нее не наткнется в исходном коде, после чего программа совершенно перестает работать

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

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

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

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

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

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

Например, в операционную систему Windows встроена утилита Dr. Watson, которая по умолчанию отлавливает ошибки в приложениях пользователя и отправляет отчет на специальный Сервер компании Microsoft. Также в качестве примера можно привести аналогичные библиотеки Breakpad и CrashRpt

система отслеживания ошибок ( баг-трекер )

Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

Состав информации о дефекте

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

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

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

Жизненный цикл дефекта

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

Типичный жизненный цикл дефекта:

1. новый — дефект зарегистрирован тестировщиком
2. назначен — назначен ответственный за исправление дефекта
3. разрешен — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например:
   • исправлено (исправления включены в версию такую-то)
   • дубль (повторяет дефект, уже находящийся в работе).
   • не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т. п.)
   • невоспроизводимо (запрос дополнительной информации об условиях, в которых дефект проявляется).
4. далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус назначен (если он описан как исправленный, но не исправлен), либо в статус закрыт.
5. открыт повторно — дефект вновь найден в другой версии.

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

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

Примеры систем отслеживания ошибок

Свободно распространяемые

• Redmine — не относится к системам отслеживания ошибок, но многие компании его используют.
• BUGS - the Bug Genie http://www.thebuggenie.com/
• Bugzilla http://www.bugzilla.org/features/
• eTraxis https://www.etraxis.com/
• GNATS
• Launchpad
• Mantis bug tracking system
• Trac
• EmForge
• Picket
• Flyspray
• DEVPROM

Проприетарные

• Atlassian JIRA
• Bontq
• PVCS Tracker
• Project Kaiser
• TrackStudio Enterprise
• YouTrack
• Яндекс.Трекер

Разное

• BugTracker.NET
• BugNet
• ClearQuest
• Intland CodeBeamer
• LifeTask.ru
• FlySpray
• StarTeam

Вау!! 😲 Ты еще не читал? Это зря!

• ошибки в приложениях , bugs ,
• основы qa , тестовые артефакты ,
• метрики по обеспечению качества , метрики тестирования ,
• причины появления ошибок , ошибки ,
• try-catch , исключения ,
• виды ошибок программного обеспечения , принципы отладки ,
• Отчет об ошибке
• Система отслеживания ошибок
• Фича
• Борбаг — легко обнаруживаемый стабильный баг
• Гейзенбаг — сложно обнаруживаемый, периодически исчезающий и меняющий свойства баг при попытке его обнаружения
• Мандельбаг — баг с очень сложным, хаотичным, поведением
• Шрединбаг — критическая ошибка , которая не проявляется пока кто-нибудь на нее не наткнется в исходном коде, после чего программа совершенно перестает работать
• GIGO
• Катастрофа Ariane 5 (4 июня 1996) — один из самых дорогостоящих компьютерных багов в истории.
• Ошибки в программном обеспечении медицинского ускорителя Therac-25 привели к превышению доз облучения нескольких людей.
• Багтрак
• Книга жалоб и предложений
• канбан доска
• профессии для создания и обслуживания веб сайтов , верстальщик ,
• психология тестирования , мифы о тестировании ,
• спеациальность qa , тестировщик ,
• типы тестирования , уровни тестирования ,
• тестировщик , qa ,