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

     Классификация ошибок с точки  зрения тестировщика

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

     Предлагается  различать.

1. Ошибки кодирования.
2. Ошибки проектирования.
3. Предложения тестировщика по улучшению программы.
4. Расхождение с документацией.
5. Взаимодействие с аппаратурой.
6. Поведение программы, вызывающее вопросы тестировщика.

     Как бы не привлекала такая классификация своей простотой, приведенный выше перечень возможных ошибок, говорит о том, что воспользоваться ею можно только в очень простых и частных случаях. В общем случае у тестировщика нет убедительных оснований отнести ошибку к тому или иному разделу данной классификации, так как обычно проблема носит комплексный характер. Вероятность ошибки такого отнесения также высока. Следствием подобных ошибок в классификации будет увеличение время отладки программы, так как программные ошибки будут направляться на исправление не тем сотрудникам или подразделениям, которые на самом деле должны ими заниматься. Для предотвращения подобных ситуаций могут применяться системы автоматизированной классификации ошибок, позволяющие быстро оценивать серьезность ошибок, информировать об их возникновении нужных специалистов и т.д. Вопросы построения такого рода систем, в основу работы которых положен анализ сообщений об ошибках, рассмотрены в работе [8]. Их функционирование должно опираться на использование методов и моделей искусственного интеллекта (в частности методов классификации текстов).

     Классификация ошибок по степени  их критичности

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

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

     Классификация может быть следующей.

     Разрушение  системы (Causes crash) - Под ним объединяют все те ошибки в программе, которые  могут вызвать крах или зависание  всей системы, нарушить стабильность ее работы.

     Косметические (Cosmetic) - под этим понятием объединяют ошибки дизайна (например, не тот цвет линии или шрифт), пользовательского  интерфейса и т.п., которые не мешают работать программе, но портят ее "товарный вид".

     Критические (Critical) – ошибки, которые приводят к «зависанию» или «падению» самой программы, не затрагивая операционной системы в целом.

     Error Handling - ошибки при обработке ошибок.

     Functional - ошибки функциональности, не относящиеся  к критическим.

     Setup - ошибки инсталляции.

     Minor - малозначимые.

     Suggestion – предложения по улучшению программы (так называемые «фичи» (feature).

     Во  многих отраслевых и корпоративных  стандартах для ответственных систем принят подобный принцип классификации  ошибок, который является главным. Так стандарт DO-178B, предназначенный для сертификации ПО авиационного электронного оборудования, выделяет следующие категории аварийных ситуаций (сбоев, ошибок) по степени их негативного воздействия на самолет, экипаж и пассажиров. Оставлено без перевода, так как нам гораздо важнее принцип классификации, нежели перевод терминов конкретной предметной области.

     Catastrophic - Failure may cause a crash.

     Hazardous - Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the plane due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.

     Major - Failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries).

     Minor - Failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a routine flight plan change)

     No Effect - Failure has no impact on safety, aircraft operation, or crew workload.

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

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

     Классификация ошибок в зависимости от их места в жизненном цикле программного изделия

     Еще одним принципом классификации  ошибок может быть их место в жизненном  цикле программного изделия.

     Можно наметить следующую схему такой классификации. 

1. Ошибки  при постановке задачи и при составлении ТЗ.
2. Ошибки проектирования.
1. Ошибки в структуре ПО.
2. Ошибки функциональности отдельных модулей.
3. Ошибки программных интерфейсов.
4. Ошибки в спецификациях программ.
5. Недостатки программы и методики тестирования.
6. Ошибки при выборе средств разработки и управления проектом.
3. Ошибки кодирования.
1. Опечатки при кодировании.
2. Ошибки при реализации спецификаций.
3. Не выполнение критериев добротности программы.
4. Недостатки оформления и документирования исходных текстов.
4. Ошибки отладки и тестирования.
1. Не реализована полностью программа и методика тестирования.
2. Не все ошибки отражены в отчете.
3. Не все ошибки исправлены.
4. Недостатки в документировании ошибок.
5. Ошибки и недочеты в документации на ПО.
6. Ошибки на этапе эксплуатации и модернизации.
1. Отсутствие системы сбора ошибок и пожеланий пользователей.
2. Не все ошибки фиксируются.
3. Отсутствует единые принципы ведения и форматы документов об ошибках.
4. Ошибки исправляются не оперативно.
5. Обновление системы осуществляется некорректно.
6. Исправление одних ошибок приводит к появлению других.

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

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

     Также заслуживает внимания и п.3.3, приведенной  классификации. Обычно на этом этапе разработки ПО речь идет о плохом стиле программирования. Это понятие до сих пор слабо формализовано и понимается программистами и теоретиками программирования по-разному. Введенное И.В. Поттосиным понятие добротности программы [9] является более емким понятием, характеризующим высококачественное кодирование, нежели, чем понятие стиля программирования. Рассмотрение всего круга вопросов, связанного с добротностью программ и ошибок (недостатков) программы, которые снижают характеристики ее добротности требуют отдельного рассмотрения.

     Классификация программных ошибок (багов) с точки зрения субъективного восприятия их программистами

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

     В Интернете можно найти несколько  вариантов такого рода классификаций программных ошибок. Вот некоторые фрагменты, взятые из классификации статьи [10].

     «Бозебаг - это скопление ошибок в каком-то конкретном месте исполняемого кода, бесконечное их число.

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

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

     Примером  могут являться ошибки, которые проявляются  в окончательном варианте программы (релизе), однако не видны в режиме отладки, или ошибки синхронизации в многопоточном приложении. Данное название является игрой слов и происходит от физического термина «Принцип неопределённости Гейзенберга», который на бытовом уровне понимается как изменение наблюдаемого объекта в результате самого факта наблюдения, происходящее в квантовой механике.

     Дзенбаг - это такая ошибка, которая, в  общем-то, ни на что не влияет, но при  этом ошибкой всё же является.

     Шрёдинбаг - один из самых интересных типов  ошибок, который никак не проявляет  себя, однако внезапно возникает, если кто-то наткнётся на него в исходном коде или попытается использовать программу в необычных условиях и осознаёт, что система вообще не могла работать при наличии такой ошибки. После этого программа перестаёт работать вообще до тех пор, пока ошибка не будет исправлена. Хотя это звучит невероятно, некоторые программы содержат в себе латентные шрёдинбаги. Слово «шрёдинбаг» происходит от мысленного эксперимента с котом Шрёдингера. Забавным примером можно считать историю о старике и бороде (хотя само название «шрёдинбаг» в ней, разумеется, не упомянуто). Некоторого старика с длинной бородой спросили, куда он кладет бороду, когда спит — под одеяло или на одеяло. Он понял, что не знает, а когда лег спать, попытался выяснить это опытным путем. Попробовал положить под одеяло — очень неудобно, на одеяло — тоже очень неудобно. Поскольку оба варианта не подходили, старик больше не мог заснуть, и через некоторое время скончался от недостатка сна».

     В статье [11] дается, например, такое «определение» программных ошибок и весьма оригинальная метрика качества программы: