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

В Главе 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.

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

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