К вопросу о классификации программных ошибок 

Березкин  Д.В. 
 

     В качестве введения рассмотрим определения понятия «ошибка». Начнем с наиболее общего трактования этого понятия применительно к некоторым техническим системам.

     По  определению стандарта ISO 9241-13 [1] ошибка это – несоответствие между целями пользователя и ответом системы.

     Определение, приведенное в работе [2], предполагает, что ошибка вызвана не сложностью задачи, а сложностью орудия (напр., компьютерной системы), поэтому она является не ошибкой пользователя, а ошибкой разработчиков этого орудия.

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

     Определение понятия «ошибка  в программе»

     В самом общем случае под ошибкой понимается какой-то сбой в программе на этапе ее выполнения.

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

     Майерс  дает такое нестрогое определение: «Если программа не делает того, чего пользователь от нее вполне обосновано ожидает, значит налицо программная ошибка» [3].

     Автор работы [4] настаивает на субъективном характере программных ошибок: «Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать, насколько программа не справляется со своей задачей, - это исключительно субъективная характеристика».

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

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

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

     Классификация ошибок в книге [5] дается по месту их возникновения. В главе 4 приводится краткая классификация ошибок и в Приложении – более полная, которая, на мой взгляд, не имеет строгих принципов и является скорее перечнем возможных ошибок, чем их классификацией. Авторы исходят из того, что главным критерием программы должно быть ее качество, которое трактуется как отсутствие в ней недостатков, а также сбоев и явных ошибок. Недостатки программы зависят от субъективной оценкой ее качества потенциальным пользователем. При этом авторы скептически относятся к спецификации и утверждают, что даже при ее наличии, выявленные на конечном этапе недостатки говорят о ее низком качестве. При таком подходе преодоление недостатков программы, особенно на заключительном этапе проектирования, может приводить к снижению надежности. Очевидно, что для разработки ответственного и безопасного программного обеспечения (ПО) такой подход не годится, однако проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы. Должна быть разработана система некоторых ограничений, которая бы учитывала эти факторы при разработке и сертификации такого рода ПО. Для обычных программ все проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего неизбежны.

     В краткой классификации выделяются следующие ошибки. 

     Ошибки  пользовательского  интерфейса.

       Функциональность.

       Взаимодействие программы с пользователем.

       Организация программы.

       Пропущенные команды.

       Производительность.

       Выходные данные.

     Обработка ошибок.

     Ошибки, связанные с обработкой граничных условий.

     Ошибки  вычислений.

     Начальное и последующие состояния.

     Ошибки  управления потоком.

     Ошибки  передачи или интерпретации  данных.

     Ситуация  гонок.

     Перегрузки.

     Аппаратное  обеспечение.

     Контроль  версий.

     Документация.

     Ошибки  тестирования. 

     Подробная классификация с небольшой правкой  и моими комментариями приведена ниже.

     Ошибки  пользовательского  интерфейса.

     Многие  из них субъективны, т.к. часто они  являются скорее неудобствами, чем  «чистыми» логическими ошибками. Однако они могут провоцировать  ошибки пользователя программы или  же замедлять время его работы до неприемлемой величины. В результате чего мы будем иметь ошибки информационной системы (ИС) в целом. Основным источником таких ошибок является сложный компромисс между функциональностью программы и простотой обучения и работы пользователя с этой программой. Проблему надо начинать решать при проектировании системы на уровне ее декомпозиции на отдельные модули, исходя из того, что вряд ли удастся спроектировать простой и удобный пользовательский интерфейс для модуля, перегруженного различными функциями. Кроме того, необходимо учитывать рекомендации по проектированию пользовательских интерфейсов, например [7]. В этой книге приводятся простые модели проверки качества интерфейса, которые можно использовать на стадии его проектирования. На этапе тестирования ПО полезно предусмотреть встроенные средства тестирования, которые бы запоминали последовательности действий пользователя, время совершения отдельных операций, расстояния перемещения курсора мыши. Кроме этого возможно применение гораздо более сложных средств психо-физического тестирования на этапе тестирования интерфейса пользователя, которые позволят оценить скорость реакции пользователя, частоту этих реакций, утомляемость и т.п. Необходимо отметить, что такие ошибки очень критичны с точки зрения коммерческого успеха разрабатываемого ПО, т.к. они будут в первую очередь оцениваться потенциальным заказчиком.

     Ошибки  функциональности.

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

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

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

     Неадекватность  реализации базовых  функций. Функция реализована так, что не годится для эксплуатации. Сюда относятся вопросы недостаточной производительности.

     Пропущенная функция. В программе не реализована функция, предусмотренная спецификацией.

     Неверно работающая функция. Функция работает не так, как предусмотрено спецификацией.

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

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

     Взаимодействия  программы и пользователя. Их появление возможно как в интерактивном, так и в пакетном режимах.

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

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

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

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

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

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

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