Общая классификация ошибок предполагает разделение ошибок на - ErrorsMaster.ru

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

Анализ юридической литературы показывает,
что существует множество классификаций
ошибок. При этом в основу классификаций
ложатся различные признаки.’ Можно,
например, классифицировать ошибки по
источнику их возникновения. По этому
основанию нами выделялись ошибки,
обусловленные: а) внешними, объективными
и б) внутренними, субъективными факторами.²
В.Ф.Кириченко выделил ошибку вследствие
неправильного восприятия и неправильного
заключения.³ Н.С.Таганцев полагал,
что по этому основанию следует различать
ошибку в поведении и ошибку в силу
неправильного представления.⁴ С
учетом уровня отражения действительности
в процессе совершения социально-значимых
действий можно выделить ошибку на уровне
чувственного и рационального отражения
реальности.

Мы видим, что проблемой классификации
ошибок ученые активно занимались и до
1917 года. В дореволюционном уголовном
праве России выделялись многие виды
ошибок. Так, в работах Н.С.Таганцева
выделяются ошибки извинительные и
неизвинительные⁵, случайные®,

‘ См.: Якушин В.А.
Ошибка и ее значение в применении
уголовного закона. В кн.:

Вопросы осуществления
прав и обязанностей в развитом
социалистическом обществе. -Казань,
1983 г., с. — 59-62

²
См.: Якушин В.А. Ошибка и ее уголовно-правовое
значение. — Казань, 1988 г., с. — 48

³
См.: Кириченко
В.Ф. Значение
ошибки по советскому уголовному праву.
— М., 1952 г., с.-17

⁴
См.: Таганцев Н.С. Русское уголовное
право. Лекции. Часть Обшая,
T.I, М., 1994
г., с. -232

⁵
См.: Таганцев Н.С. Русское уголовное
право. — Часть Общая,
T.I —
С.-Петербург, 1902 г., с. — 545

⁶
Там же, с.-581,582

фактические и юридические / По своему
содержанию Н.С.Таганцев выделял ошибку,
относящуюся к деянию и его последствиям,
и ошибку в мотивах, как основе деятельности.²
П.П.Пусторослевым, помимо фактической
и юридической ошибки, выделялась ошибка
в лице или предмете.³ Н-Д.Сергеевский
выделял ошибку в плане и ошибку в
выполнении.⁴

Достаточно большое внимание уделено
классификации ошибок и в послеоктябрьский
период. Так, В.Ф.Кириченко выделял
заблуждения относительно: а) общественной
опасности деяния; б) обстоятельств,
являющихся элементами состава
преступления; в) юридических факторов
или юридическую ошибку (ошибку в праве).⁵
П.С.Дагель классифицировал ошибки по
следующим основаниям: а) по предмету —
ошибка юридическая и фактическая; б) по
причинам возникновения — ошибка
извинительная и неизвинительная; в) по
своей значимости — ошибка существенная
и несущественная; г) ошибка виновная и
невиновная.⁶

В отличии от В.Ф.Кириченко многие ученые
считают, что нужно выделять не три, а
два вида ошибок. При этом одни считают,
что таковыми являются фактическая и
юридическая ошибка⁷, другие
полагают, что ими выступают ошибки в
объекте и в обстоятельствах, относящихся
к

‘ Там же.
с. — 585

²
Там же, с. — 583

³
См.: Пусторослев П.П. Русское уголовное
право. Общая часть. — Юрьев. 1907 г., с. — •
344, 366

⁴
См.: Сергеевский Н.Д. Русское уголовное
право (пособие к лекциям). Часть Общая.
-С.-Петербург, 1910 г., с. — 299

⁵
Кириченко В.Ф. Указ.соч., с. — 18

⁶
См.: Дагель
П.С. Обстоятельства, исключающие
виновность субъекта и влияющие
на форму
вины. — Советская юстиция, 1973 г., №3, с. —
14-16

⁷
См.: Коптякова Л.И. Понятие ошибок в
советском уголовном праве и их
классификация. В кн.: Проблемы права
социалистической государственности и
социального управления. — Свердловск,
1978 г., с. — 107; Уголовное право. Общая часть,
М.: Юрид.лит-ра, 1994 г., с. — 189; Уголовное
право Российской Федерации. Общая часть.
М.: Юрист, 1996 г., с. — 194; Уголовное право
России. Общая часть. Учебное пособие,
М.: Изд-во Юрид.колледж МГУ, 1994 г., с. — 55;
Новое уголовное право России (учебное
пособие). Общая часть, М.: ТЕИС, 1996 г., с.
— 52; Наумов А.В. Уголовное право. Общая
часть. Курс лекций, М.: БЕК, 1996 г., с. — 234

объективной стороне’, по мнению третьих
это ошибка относительно объективных
или субъективных признаков общественно
опасного деяния, которые характеризуют
его как преступление.²

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

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

основаниями.

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

‘ См.: Дурманов Н.Д.
Стадии совершения преступления по
советскому уголовному

праву. М.: Госюриздат,
1956 г., с. — 164

²
См.: Гилязев
Ф.Г. Особенности вины и значение ошибки
в уголовном праве. Уфа, 1993

г.,
с.- 20,25

утверждающий, что юридическая ошибка
это ошибка относительно каких-то
фактических обстоятельств, будет
совершенно прав.’

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

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

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

извинительна, то устраняется всякое
вменение.’ Позднее подобное возражение
было высказано Л.И.Коптяковой.²

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

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

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

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

¹
См.: Таганцев Н.С. Русское уголовное
право. Часть Общая,
T.I,
С.-Петербург, 1902 г., с. — 545

²
См.: Коптякова Л.И. Указ.раб., с. — 107

неправильным их игнорировать,
недооценивать, поскольку они являются
предпосылкой для основных классификаций,
помогают раскрыть те существенные
признаки, на которых они могут строиться,
которые служат их основой и базой. Вот
почему следует согласиться с мнением
Ф Р Сундурова о том, что «нельзя
пренебрегать в качестве первоначальной
стадии исследования сравнительным
анализом на основе тех отдельных, частных
признаков, которые видимы для
исследователя».¹

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

Общеизвестно, что преступление
представляет собой такой акт поведения
человека, в котором диалектически
представлено внешнее и внутреннее,
физическое и психическое, объективное
и субъективное. Именно это единство
объективного и субъективного отражено
в» понятии преступления, данного
законодателем в ст.14 УК России 1996 года.
Оно раскрыто путем указания основных,
существенных признаков преступления.
Преступление это общественно опасное,
противоправное и виновно совершенное
деяние.³

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

‘ Сундуров Ф.Р.
Социально-психологические и правовые
аспекты исправления и перевоспитания
правонарушителей. Казань, 1976г., с. — 38

²
См.: Загородников Н.И., Наумов А.В.
Теоретические основы классификации
преступлений в уголовном праве. —
Правоведение, 1983 г., №2, с. — 56

³
В уголовно-правовой литературе выделяются
и иные признаки преступления.
См.:

Джекебаев У.С. О
социально-психологическом аспекте
преступного поведения. — Алма-ата, 1971
г., с. — 42; Кузнецова
Н.Ф. Преступление
и преступность. — М.:
Изд-во Моск.ун-та,
1969 г., с. — 60, 90, 100

лица общественной опасности и
противоправности совершаемого им деяния
и психическое отношение к обстоятельствам,
определяющим и раскрывающим эту опасность
и противоправность. Такое взаимодействие
внешнего и внутреннего и обусловленность
последнего первым было подмечено еще
В.И.Лениным. Он писал: «Признавать
необходимость природы и из ее выводить
необходимость мышления есть материализм.»’

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

Общественная опасность и противоправность
относятся к комплексным, синтезирующим
признакам преступления. Считается
аксиомой, что характер и степень
общественной опасности, например,
определяется объектом посягательства,
характером и величиной наступивших
последствий, способами и средствами
совершения преступлений и т.д. Из этого
следует, что ошибка возможна в отношении
какого-то из обстоятельств, определяющих
характер и степень общественной
опасности. В свое время это позволило
нам сделать вывод о том, что в рамках
заблуждения относительно характера и
степени общественной опасности можно
выделить ошибки: 1) в объекте, 2) в предмете,
3) в личности потерпевшего, 4) в способе
совершения преступления, 5) в средствах
преступления, 6) в квалифицирующих
обстоятельствах, 7) в характере последствий,
в смягчающих и отягчающих обстоятельствах.³
Кроме того, нами выделялась и ошибка в
развитии причинной связи.⁴

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

‘ Ленин В.И.
Полн.еобр.соч., Т.18, с. — 172

²
См.: Якушин В.А. Ошибка и ее уголовно-правовое
значение. —
Казань, 1988
г., с. — 52

³
Там же, с. — 54

⁴
Там же, с. — 90-94

совершения преступления вряд ли
оправдано, поскольку «они либо представляют
разновидности ошибки в объекте или
объективной стороне, либо вообще не
имеют значения для уголовной
ответственности».¹

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

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

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

‘ Уголовное право.
Общая часть. — М.: Изд-во Юрид.лит-pa, 1994
г., с. — 190. Эта же позиция была высказана
и в учебнике — Уголовное право Российской
Федерации. Общая часть. — М.: Юрист, 1996
г., с. — 195

²
См., например, Курс советского уголовного
права в 6 томах. Т.2. — М., 1970 г., с. — 336-337;
Наумов А.В. Уголовное право. Общая часть.
Курс лекций. — М.:Изд-во БЕК, 1996 г., с. —
234-236; Якушин В.А. Ошибка и ее уголовно-правовое
значение. — Казань, 1988 г., с. — 55-57

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

Мы отмечаем, что приведенная классификация
ошибок позволяет разрешить не только
практические, но и теоретические вопросы
уголовного права. Например, позволяет
показать взаимосвязь и соподчиненность
таких понятий как «преступление» и
«состав преступления», определить, что
является основанием уголовной
ответственности и т.п.¹ Деление
же ошибки на фактическую и юридическую
не позволяет разрешить теоретико-методологические
вопросы подобного рода, поскольку она
представлена как сугубо «внешняя
группировка материала в виде такого
ряда, члены которого прикладываются
один к другому…».²

Приведенная нами классификация ошибок,
с учетом их дальнейшего

‘ См.: Якушин В.А.
Ошибка и ее уголовно-правовое значение.
— Казань, 1988 г., с. — 53-

²
Энгельс Ф. Диалектика природы. — М.:
Политиздат, 1982 г., с. — 216

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

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

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

а) конструктивные признаки состава
преступления;

б) конструктивно-разграничительные
признаки;

в) квалифицирующие признаки состава
преступления;

г) признаки, которые усиливают или
уменьшают наказание;

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

Следует отметить, что еще Н.С.Таганцев
предпринимал попытку в подобном аспекте
рассмотреть неведение и заблуждение.
Он писал, что «…к

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

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

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

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

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

Следовательно, в процессе субъективного
вменения при наличии ошибки лица,
совершающего общественно опасное
деяние, следует выяснить, в отношении
какого из признаков деяния произошла
ошибка, и определить, была ли это:

ошибка в отношении конструктивного
признака состава преступления;

ошибка в отношении конструктивно-разграничительного
признака;

ошибка в отношении квалифицирующих
признаков;

ошибка в отношении смягчающих или
отягчающих наказание обстоятельств;

ошибка в отношении обстоятельств
(признаков), которые не имеют
уголовно-правового значения.

‘ Таганцев Н.С.
Русское уголовное право. Лекции. Часть
Общая,
T.I. — М.,
1994 г., с. —

233

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

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

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

а) ошибки в отношении объективных
признаков совершаемого лицом

I См.:
Костарева Т.А. Указ.соч., с. — 165

деяния и связанных с ним объективных
обстоятельств;

б) ошибки в отношении личностных свойств
и содержания намерений соучастников в
преступлении.

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

Источник

Классификация ошибок

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

№ п/п	Вид ошибки	Примеры
Г1	Ошибочное словообразование. Ошибочное образование форм существительного, прилагательного, числительного, местоимения, глагола (личных форм глаголов, действительных и страдательных причастий, деепричастий).	Благородность, чуда техники, подчерк, надсмехаться; более интереснее, красивше; с пятистами рублями; жонглировал обоими руками, ихнего пафоса, вокруг его ничего нет; сколько нравственных принципов мы лишились из-за утраты духовности; им двигает чувство сострадания; ручейки воды, стекаемые вниз, поразили автора текста; вышев на сцену, певцы поклонились.
Г2	Нарушение норм согласования	Я знаком с группой ребят, серьезно увлекающимися джазом.
Г3	Нарушение норм управления	Нужно сделать природу более красивую. Все удивлялись его силой.
Г4	Нарушение связи между подлежащим и сказуемым или способа выражения сказуемого	Главное, чему теперь я хочу уделить внимание, это художественной стороне произведения. Он написал книгу, которая эпопея. Все были рады, счастливы и веселые.
Г5	Ошибки в построении предложения с однородными членами	Страна любила и гордилась поэтом. В сочинении я хотел сказать о значении спорта и почему я его люблю.
Г6	Ошибки в построении предложения с деепричастным оборотом	Читая текст, возникает такое чувство сопереживания.
Г7	Ошибки в построении предложения с причастным оборотом	Узкая дорожка была покрыта проваливающимся снегом под ногами.
Г8	Ошибки в построении сложного предложения	Эта книга научила меня ценить и уважать друзей, которую я прочитал еще в детстве. Человеку показалось то, что это сон.
Г9	Смешение прямой и косвенной речи	Автор сказал, что я не согласен с мнением рецензента.
Г10	Нарушение границ предложения	Его не приняли в баскетбольную команду. Потому что он был невысокого роста.
Г11	Нарушение видовременной соотнесенности глагольных форм	Замирает на мгновение сердце и вдруг застучит вновь.
Г12	Пропуск члена предложения (эллипсис)	На собрании было принято (?) провести субботник.
Г13	Ошибки, связанные с употреблением частиц: отрыв частицы от того компонента предложения, к которому она относится	Хорошо было бы, если бы на картине стояла бы подпись художника. В тексте всего раскрываются две проблемы.

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

№ п/п	Вид ошибки	Примеры
Р1	Употребление слова в несвойственном ему значении	Мы были шокированы прекрасной игрой актеров. Благодаря пожару, лес сгорел.
Р2	Неоправданное употребление диалектных и просторечных слов	Таким людям всегда удается объегорить других. Обломов ничем не занимался и целыми днями валял дурака.
Р3	Неудачное употребление местоимений	Текст написал В. Белов. Он относится к художественному стилю; У меня сразу же возникла картина в своем воображении.
Р4	Употребление слов иной стилевой окраски; смешение лексики разных эпох; неуместное употребление канцелярита, экспрессивных, эмоционально окрашенных слов, устаревшей лексики, жаргонизмов, неуместное употребление фразеологизмов	По задумке автора, герой побеждает; Молчалин работает секретарем Фамусова; В романе А.С. Пушкина имеют место лирические отступления; Автор то и дело прибегает к употреблению метафор и олицетворений. Если бы я был там, то за такое отношение к матери я бы этому кексу в грызло бы дал; Зощенко палец в рот не клади, а дай только посмешить читателя.
Р5	Неразличение оттенков значения, вносимых в слово приставкой и суффиксом	В таких случаях я взглядываю в словарь.
Р6	Неразличение паронимов, синонимичных слов; ошибки в употреблении антонимов при построении антитезы; разрушение образного значения фразеологизма в неудачно организованном контексте	Были приняты эффектные меры; Имя этого поэта знакомо во многих странах; В третьей части текста не веселый, но и не мажорный мотив заставляет нас задуматься; грампластинка не сказала еще своего последнего слова.
Р7	Нарушение лексической сочетаемости	Автор использует художественные особенности.
Р8	Употребление лишних слов, в том числе плеоназм	Молодой юноша; очень прекрасный.
Р9	Употребление рядом или близко однокоренных слов (тавтология)	В этом рассказе рассказывается о реальных событиях.
Р10	Неоправданное повторение слова	Герой рассказа не задумывается над своим поступком. Герой даже не понимает всей глубины содеянного им.
Р11	Бедность и однообразие синтаксических конструкций	Когда писатель пришел в редакцию, его принял главный редактор. Когда они поговорили, писатель отправился в гостиницу.
Р12	Употребление лишних слов, лексическая избыточность	Тогда о том, чтобы вы могли улыбнуться, об этом позаботится книжный наш магазин.

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

№ п/п	Вид ошибки	Примеры
Л1	Сопоставление (противопоставление) двух логически неоднородных (различных по объему и по содержанию) понятий в предложении, тексте	На уроке присутствовали директор, библиотекарь, а также Анна Петровна Иванова и Зоя Ивановна Петрова; Он облокотился спиной на батарею; За хорошую учебу и воспитание детей родители обучающихся получили благодарственные письма от администрации школы.
Л2	Нарушение причинно-следственных отношений	В последние годы очень много сделано для модернизации образования, однако педагоги работают по-старому, так как вопросы модернизации образования решаются слабо.
Л3	Пропуск звена в объяснении, «логический скачок».	Людской поток через наш двор перекрыть вряд ли возможно. [?] А как хочется, чтобы двор был украшением и школы, и поселка.
Л4	Перестановка частей текста (если она не обусловлена заданием к сочинению или изложению)	Пора вернуть этому слову его истинный смысл! Честь… Но как это сделать?
Л5	Неоправданная подмена лица, от которого ведется повествование (например, сначала от первого, затем от третьего лица)	Автор пишет о природе, описывает природу севера, вижу снега и просторы снежных равнин.
Л6	Сопоставление логически несопоставимых понятий	Синтаксис энциклопедических статей отличен от других научных статей.
Композиционно-текстовые ошибки
Л7	Неудачный зачин	Текст начинается предложением, содержащим указание на предыдущий контекст, который в самом тексте отсутствует, наличием указательных словоформ в первом предложении, например: В этом тексте автор…
Л8	Ошибки в основной части	а) Сближение относительно далеких мыслей в одном предложении. б) Отсутствие последовательности в изложении; бессвязность и нарушение порядка предложений. в) Использование разнотипных по структуре предложений, ведущее к затруднению понимания смысла.
Л9	Неудачная концовка	Дублирование вывода, неоправданное повторение высказанной ранее мысли.

Фактические ошибки (Ф) — разновидность неязыковых ошибок, заключающаяся в том, что пишущий приводит факты, противоречащие действительности, дает неправильную информацию о фактических обстоятельствах, как связанных, так и не связанных с анализируемым текстом (фоновые знания)

№ п/п	Вид ошибки	Примеры
Ф1	Искажение содержания литературного произведения, неправильное толкование, неудачный выбор примеров	Базаров был нигилист и поэтому убил старуху топором; Ленский вернулся в свое имение из Англии; Счастьем для Обломова было одиночество и равнодушие.
Ф2	Неточность в цитате. Отсутствие указания на автора цитаты. Неверно названный автор цитаты.	Книга очень много для меня значит, ведь еще Ленин сказал: «Век живи – век учись!»
Ф3	Незнание исторических и др. фактов, в том числе временное смещение.	Великая Отечественная война 1812 года; Столица США — Нью-Йорк.
Ф4	Неточности в именах, фамилиях, прозвищах литературных героев. Искажения в названиях литературных произведений, их жанров, ошибка в указании автора.	Тургеньев; «Тарас и Бульба»; в повести Тургенева «Преступление и наказание».

ОШИБКИ ОРФОГРАФИЧЕСКИЕ, ПУНКТУАЦИОННЫЕ, ГРАФИЧЕСКИЕ, ОПИСКИ

При проверке грамотности (К7-К8) учитываются ошибки

на изученные правила;
негрубые (две негрубые считаются за одну):

в исключениях из правил;
в написании большой буквы в составных собственных наименованиях;
в случаях раздельного и слитного написания не с прилагательными и причастиями, выступающими в роли сказуемого;
в написании и и ы после приставок;
в трудных случаях различения не и ни (Куда он только не обращался! Куда он ни обращался, никто не мог дать ему ответ. Никто иной не …; не кто иной, как…; ничто иное не …; не что иное, как … и др.);
в случаях, когда вместо одного знака препинания поставлен другой;
в пропуске одного из сочетающихся знаков препинания или в нарушении их последовательности;

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

каждая следующая подобная ошибка учитывается как самостоятельная):

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

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

! Понятие об однотипных ошибках не распространяется на пунктуационные ошибки.

! Ошибки (две и более) в одном непроверяемом слове считаются за одну ошибку.

При проверке грамотности (К7-К8) не учитываются ошибки

орфографические:

в переносе слов;
буквы э/е после согласных в иноязычных словах (рэкет, пленэр) и после гласных в собственных именах (Мариетта);
прописная / строчная буквы

в названиях, связанных с религией: М(м)асленица, Р(р)ождество, Б(б)ог.
при переносном употреблении собственных имен (Обломовы и обломовы).
в собственных именах нерусского происхождения; написание фамилий с первыми частями дон, ван, сент… (дон Педро и Дон Кихот).

слитное / дефисное / раздельное написание

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

пунктуационные ошибки:

тире в неполном предложении;
обособление несогласованных определений, относящихся к нарицательным именам существительным;
запятые при ограничительно-выделительных оборотах;
различение омонимичных частиц и междометий и, соответственно, невыделение или выделение их запятыми;
в передаче авторской пунктуации;

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

— искажение звукового облика слова (рапотает вместо работает, мемля вместо земля);.

— пропуски букв (весь роман стоится на этом конфликте;

— перестановки букв (новые наименования пордуктов);

— замены одних буквенных знаков другими (лешендарное Ледовое побоище);

— добавление лишних букв (в любых, дашже самых сложных условиях).

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

•специфики управления используемыми техническими средствами,

•операционной системы,

•среды и языка программирования,

•реализуемых процессов,

•природы и специфики различных ошибок,

•методик отладки и соответствующих программных средств.

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

Вцелом сложность отладки обусловлена следующими причинами:

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

•психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;

•возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания области памяти одного модуля другим из-за ошибок адресации;

•отсутствуют четко сформулированные методики отладки.

Всоответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):

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

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

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

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

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */

Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

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

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

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

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

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

•несовпадение полученных результатов с ожидаемыми.

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

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

•неверное определение исходных данных,

•логические ошибки,

•накопление погрешностей результатов вычислений (рис. 10.2).

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

Л о г и ч е с к и е о ш и б к и имеют разную природу. Так они могут следовать из ошибок, допущенных при проектировании, например, при выборе методов, разработке алгоритмов или определении структуры классов, а могут быть непосредственно внесены при кодировании модуля.

Кпоследней группе относят:

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

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

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

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

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

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

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску – так называемые стохастические ошибки;

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

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

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

ручного тестирования;

индукции;

дедукции;

обратного прослеживания.

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

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

Данный метод часто используют как составную часть других методов отладки.

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

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

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

Метод дедукции. По методу дедукции вначале формируют множество причин, которые могли бы вызвать данное проявление ошибки. Затем анализируя причины, исключают те, которые противоречат имеющимся данным. Если все причины исключены, то следует выполнить дополнительное тестирование исследуемого фрагмента. В противном случае наиболее вероятную гипотезу пытаются доказать. Если гипотеза объясняет полученные признаки ошибки, то ошибка найдена, иначе — проверяют следующую причину (рис. 10.4).

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

Привет, Вы узнаете про виды ошибок программного обеспечения, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое
виды ошибок программного обеспечения, принципы отладки , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

1. Отладка программы

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

Как бы тщательно мы ни писали, отладка почти всегда занимает больше времени, чем программирование.

2. Локализация ошибок

Локализация — это нахождение места ошибки в программе.

В процессе поиска ошибки мы обычно выполняем одни и те же действия:

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

Способы обнаружения ошибки:

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

Оба способа по-своему удобны и обычно используются совместно.

3.
принципы отладки

Принципы локализации ошибок:

Большинство ошибок обнаруживается вообще без запуска программы — просто внимательным просматриванием текста.
Если отладка зашла в тупик и обнаружить ошибку не удается, лучше отложить программу. Когда глаз «замылен», эффективность работы упорно стремится к нулю.
Чрезвычайно удобные вспомогательные средства — это отладочные механизмы среды разработки: трассировка, промежуточный контроль значений. Можно использовать даже дамп памяти, но такие радикальные действия нужны крайне редко.
Экспериментирования типа «а что будет, если изменить плюс на минус» — нужно избегать всеми силами. Обычно это не дает результатов, а только больше запутывает процесс отладки, да еще и добавляет новые ошибки.

Принципы исправления ошибок еще больше похожи на законы Мерфи:

Там, где найдена одна ошибка, возможно, есть и другие.
Вероятность, что ошибка найдена правильно, никогда не равна ста процентам.
Наша задача — найти саму ошибку, а не ее симптом.

Это утверждение хочется пояснить. Если программа упорно выдает результат 0,1 вместо эталонного нуля, простым округлением вопрос не решить. Если результат получается отрицательным вместо эталонного положительного, бесполезно брать его по модулю — мы получим вместо решения задачи ерунду с подгонкой.
Исправляя одну ошибку, очень легко внести в программу еще парочку. «Наведенные» ошибки — настоящий бич отладки.
Исправление ошибок зачастую вынуждает нас возвращаться на этап составления программы. Это неприятно, но порой неизбежно.

4. Методы отладки

Силовые методы

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

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

С точки зрения «правильного» программирования силовые методы плохи тем, что не поощряют анализ задачи.

Суммируя свойства силовых методов, получаем практические советы:
— использовать трассировку и отслеживание значений переменных для небольших проектов, отдельных подпрограмм;
— использовать отладочную печать в небольших количества и «по делу»;
— оставить дамп памяти на самый крайний случай.

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

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

var
a, b, c: real;
begin
writeln('Программа находит значение максимального из трех введенных чисел');
write('Введите первое число '); readln(a);
write('Введите второе число '); readln(b);
write('Введите третье число '); readln(c);
if (a>b)and(a>c) then
writeln('Наибольшим оказалось первое число ',a:8:2)
else if (b>a)and(a>c) then
writeln('Наибольшим оказалось второе число ',b:8:2)
else
writeln('Наибольшим оказалось третье число ',b:8:2);
end.

Обе выделенные ошибки можно обнаружить невооруженным глазом: первая явно допущена по невнимательности, вторая — из-за того, что скопированную строку не исправили.

Тестовые наборы данных должны учитывать все варианты решения, поэтому выберем следующие наборы чисел:

Данные Ожидаемый результат
a=10; b=-4; c=1 max=a=10
a=-2; b=8; c=4 max=b=8
a=90; b=0; c=90.4 max=c=90.4

В результате выполнения программы мы, однако, получим следующие результаты:
Для a=10; b=-4; c=1:

Наибольшим оказалось первое число 10.00

Для a=-2; b=8; c=4: < pre class=»list»>Наибольшим оказалось третье число 8.00Для a=90; b=0; c=90.4:

Наибольшим оказалось третье число 0.00

Вывод во втором и третьем случаях явно неверен. Будем разбираться.

1. Трассировка и промежуточная наблюдение за переменными

Добавляем промежуточную печать или наблюдение за переменными:

— вывод a, b, c после ввода (проверяем, правильно ли получили данные)
— вывод значения каждого из условий (проверяем, правильно ли записали условия)

Листинг программы существенно увеличился и стал вот таким:

var
a, b, c: real;
begin
writeln(‘Программа находит значение максимального из трех введенных чисел’);
write(‘Введите первое число ‘); readln(a);
writeln(‘Вы ввели число ‘,a:8:2); {отл.печать}
write(‘Введите второе число ‘); readln(b);
writeln(‘Вы ввели число ‘,b:8:2); {отл.печать}
write(‘Введите третье число ‘); readln(c);
writeln(‘Вы ввели число ‘,c:8:2); {отл.печать}
writeln(‘a>b=’,a>b,’, a>c=’,a>c,’, (a>b)and(a>c)=’,(a>b)and(a>c)); {отл.печать}
if (a>b)and(a>c) then
writeln(‘Наибольшим оказалось первое число ‘,a:8:2)
else begin
writeln(‘b>a=’,b>a,’, b>c=’,b>c,’, (b>a)and(b>c)=’,(b>a)and(b>c)); {отл.печать}
if (b>a)and(a>c) then
writeln(‘Наибольшим оказалось второе число ‘,b:8:2)
else
writeln(‘Наибольшим оказалось третье число ‘,b:8:2);
end;
end.

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

Но давайте считать, что глаз «замылен» совершенно, и найти ошибку не удалось.

Вывод для второго случая получается следующим:

Программа находит значение максимального из трех введенных чисел
Введите первое число -2
Вы ввели число -2.00
Введите второе число 8
Вы ввели число 8.00
Введите третье число 4
Вы ввели число 4.00
a>b=FALSE, a>c=FALSE, (a>b)and(a>c)=FALSE
b>a=TRUE, b>c=TRUE, (b>a)and(b>c)=TRUE
Наибольшим оказалось третье число 8.00

Со вводом все в порядке . Об этом говорит сайт https://intellect.icu . Впрочем, в этом сомнений и так было немного. А вот что касается второй группы операторов печати, то картина вышла интересная: в результате выводится верное число (8.00), но неправильное слово («третье», а не «второе»).

Вероятно, проблемы в выводе результатов. Тщательно проверяем текст и обнаруживаем, что действительно в последнем случае выводится не c, а b. Однако к решению текущей проблемы это не относится: исправив ошибку, мы получаем для чисел -2.0, 8.0, 4.0 следующий результат.

Наибольшим оказалось третье число 4.00

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

2. Метод индукции

Судя по результатам, ошибка возникает, когда максимальное число — второе или третье (если максимальное — первое, то определяется оно правильно, для доказательства можно програть еще два-три теста).

Просматриваем все, относящееся к переменным b и с. Со вводом никаких проблем не замечено, а что касается вывода — то мы быстро натыкаемся на замену b на с. Исправляем.

Как видно, невыявленные ошибки в программе остаются. Просматриваем расчетный блок: все, что относится к максимальному b (максимум с получается «в противном случае»), и обнаруживаем пресловутую проблему «a>c» вместо «b>c». Программа отлажена.

3. Метод дедукции

Неверные результаты в нашем случае могут получиться из-за ошибки в:

— вводе данных;
— расчетном блоке;
— собственно выводе.

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

4. Обратное движение по алгоритму

Зная, что ошибка возникает при выводе результатов, рассматриваем код, начиная с операторов вывода. Сразу же находим лишнюю b в операторе writeln.

Далее, смотрим по конкретной ветке условного оператора, откуда взялся результат. Для значений -2.0, 8.0, 4.0 расчет идет по ветке с условием if (b>a)and(a>c) then… где мы тут же обнаруживаем искомую ошибку.

5. Тестирование

В нашей задаче для самого полного набора данных нужно выбрать такие переменные, что
a > b > c
a > c > b
b > a > c
b > c > a
c > a > b
c > b > a

Анализируя получившиеся в каждом из этих случаев результаты, мы приходим к тому, что проблемы возникают при b>c>a и с — максимальном. Зная эти подробности, мы можем заострить внимание на конкретных участках программы.

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

5. Средства отладки

Помимо методик, хорошо бы иметь представление о средствах, которые помогают нам выявлять ошибки. Это:

1) Аварийная печать — вывод сообщений о ненормальном завершении отдельных блоков и всей программы в целом.

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

3) Непосредственное слежение:

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

Нынешние среды разработки часто предлагают нам реагировать на возникающую проблему в диалоговом режиме. При этом можно:

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

Рис Пример отладки приложения

6. Классификация ошибок

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

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

— ошибки обращения к данным,
— ошибки описания данных,
— ошибки вычислений,
— ошибки при сравнении,
— ошибки в передаче управления,
— ошибки ввода-вывода,
— ошибки интерфейса,
и т д

Классификация ошибок по этапу обработки программы

рис Классификация ошибок этапа выполнения по возможным причинам

Синтаксические ошибки

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

Примеры синтаксических ошибок :

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

Ошибки, которые не обнаруживает транслятор

В случае правильного написания операторов в программе может присутствовать большое количество ошибок, которые транслятор не может обнаружить. Рассмотрим примеры таких ошибок:

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

Ошибки в циклах: неправильно указано начало цикла; неправильно указаны условия окончания цикла; неправильно указано количество повторений цикла; использование бесконечного цикла.

Ошибки ввода-вывода; ошибки при работе с данными: неправильно задан тип данных; организовано считывание меньшего или большего объема данных, чем нужно; неправильно отредактированы данные.

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

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

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

ошибки в архитектуре приложения пприводящие к увеличени технического долга

Методы (пути) снижение ошибок в программировании

использование тестиования
использование более простых решений
использование систем с наименьшим числом составлящих
использование ранее использованных и проверенных компонентов
использование более квалифицрованных специалистов

7. Советы отладчику

1) Проверяйте тщательнее: ошибка скорее всего находится не в том месте, в котором кажется.

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

3) Тщательнее следить за объявлениями констант, типов и переменных, входными данными.

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

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

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

7) Ошибка, скорее всего окажется вашей и будет находиться в тексте программы. Гораздо реже она оказывается:

в компиляторе,
операционной системе,
аппаратной части,
электропроводке в здании и т.д.

Но если вы совершенно уверены, что в программе ошибок нет, просмотрите стандартные модули, к которым она обращается, выясните, не менялась ли версия среды разработки, в конце концов, просто перегрузите компьютер — некоторые проблемы (особенно в DOS-средах, запускаемых из-под Windows) возникают из-за некорректной работы с памятью.

Убедитесь, что исходный текст программы соответствует скомпилированному объектному коду (текст может быть изменен, а запускаемый модуль, который вы тестируете — скомпилирован еще из старого варианта).

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

10) Старайтесь не жалеть времени, чтобы уясненить причину ошибки. Это поможет вам:
исправить программу,
обнаружить другие ошибки того же типа,
не делать их в дальнейшем.

11) Если вы уже знаете симптомы ошибки, иногда полезно не исправлять ее сразу, а на фоне известного поведения программы поискать другие ляпы.

12) Самые труднообнаруживаемые ошибки — наведенные, то есть те, что были внесены в код при исправлении других.

8. Тестирование

Тестирование — это выполнение программы для набора проверочных входных значений и сравнение полученных результатов с ожидаемыми.

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

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

2) При прогоне программы по тестовым начальным данным, полученные результаты нужно сверить с эталонными и проанализировать разницу, если она есть.

3) При разработке тестов нужно учитывать не только правильные, но и неверные исходные данные.

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

5) Тестирование нужно планировать: заранее выбрать, что мы контролируем и как это сделать лучше. Обычно тесты планируются на этапе алгоритмизации или выбора численного метода решения. Причем, составляя тесты, мы предполагаем, что ошибки в программе есть.

6) Чем больше ошибок в коде мы уже нашли, тем больше вероятность, что мы обнаружим еще не найденные.
Хорошим называют тест, который с большой вероятностью должен обнаруживать ошибки, а удачным — тот, который их обнаружил.

9. Проектирование тестов

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

Давайте рассмотрим задачу: нужно проверить, попадает ли введенное число в заданный пользователем диапазон.

program Example;
(******************************************************
* Задача: проверить, попадает ли введенное число в *
* заданный пользователем диапазон *
******************************************************)

var
min, max, A, tmp: real;
begin
writeln(‘Программа проверяет, попадают ли введенные пользователем’);
writeln(‘значения в заданный диапазон’);
writeln;
writeln(‘Введите нижнюю границу диапазона ‘); readln(min);
writeln(‘Введите верхнюю границу диапазона ‘); readln(max);
if min>max then begin
writeln(‘Вы перепутали диапазоны, и я их поменяю’);
tmp:=min;
min:=max;
max:=tmp;
end;
repeat
writeln(‘Введите число для проверки (0 — конец работы) ‘); readln(A);
if (A>=min)and(A<=max) then
writeln(‘Число ‘,A,’ попадает в диапазон [‘,min,’..’,max,’]’)
else
writeln(‘Число ‘,A,’ не попадает в диапазон [‘,min,’..’,max,’]’);
until A=0;
writeln;
end.

Если исходить из алгоритма программы, мы должны составить следующие тесты:
ввод границ диапазона
— min< max
— min>max
ввод числа
— A < min (A<>0)
— A > max (A<>0)
— min <= A <= max (A<>0)
— A=0

Как видите, программа очень мала, а тестов для проверки всех ветвей ее алгоритма, требуется довольно много.

10. Стратегии тестирования

1) Тестирование программы как «черного ящика».

Мы знаем только о том, что делает программа, но даже не задумываемся о ее внутренней структуре. Задаем набор входных данных, получаем результаты, сверяем с эталонными.

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

«Черным ящиком» удобно тестировать небольшие подпрограммы.
2) Тестирование программы как «белого ящика».

Здесь перед составлением теста мы изучаем логику программы, ее внутреннюю структуру. Тестирование будет считаться удачным, если проверяет программу по всем направлениям. Однако, как мы уже говорили, это требует огромного количества тестов.

На практике мы, как всегда, совместно используем оба принципа.
3) Тестирование программ модульной структуры.

Мы снова возвращаемся к вопросу о структурном программировании. Если вы помните, программы строятся из модулей не в последнюю очередь для того, чтобы их легко было отлаживать и тестировать. Действительно, структурированную программу мы будем тестировать частями. При этом нам нужно:
строить набор тестов;
комбинировать модули для тестирования.

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

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

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

См. также

ошибки в приложениях , bugs , баг репорт , bug report ,
Фича
GIGO
Патч
тестирование
цикломатическая сложность
баг репорт
качество программного обеспечения

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

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

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

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

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

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

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

Ошибки выполнения можно разделить на три большие группы.

Ошибки определения данных или неверное определение исходных данных. Они могут появиться во время выполнения операций ввода-вывода.

К ним относятся:

ошибки преобразования;
ошибки данных;
ошибки перезаписи.

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

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

В эту группу входят:

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

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

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

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

Вот как выглядит процесс:

Алгоритм отладки по методу индукции

Важно, чтобы выдвинутая гипотеза объясняла все проявления ошибки. Если объясняется только их часть, то либо гипотеза неверна, либо ошибок несколько.

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

Отладка по методу дедукции

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

Ранние отладчики, например gdb, представляли собой отдельные программы с интерфейсами командной строки. Более поздние, например первые версии Turbo Debugger, были автономными, но имели собственный графический интерфейс для облегчения работы. Сейчас большинство IDE имеют встроенный отладчик. Он использует такой же интерфейс, как и редактор кода, поэтому можно выполнять отладку в той же среде, которая используется для написания кода.

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

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

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

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

В отличие от step into и step over, step out выполняет не следующую строку кода, а весь оставшийся код функции, исполняемой в настоящее время. После возврата из функции он возвращает управление разработчику. Эта команда полезна, когда специалист случайно вошел в функцию, которую не нужно отлаживать.

Как правило, при пошаговом выполнении можно идти только вперед. Поэтому легко перешагнуть место, которое нужно проверить. Если это произошло, необходимо перезапустить отладку.

У некоторых отладчиков (таких как GDB 7.0, Visual Studio Enterprise Edition 15.5 и более поздних версий) есть возможность вернуться на шаг назад. Это полезно, если пропущена цель либо нужно повторно проверить выполненную инструкцию.

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

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

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

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

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

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

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

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

Некоторые
выводы 16

Литература 16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перегрузки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потери времени. Имеются в виду потери
времени из-за неудачного интерфейса
программы.

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

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

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

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

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

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

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

Кто здесь главный? В этом пункте
авторы работы [5] опять возвращаются к
ошибкам в сообщениях программ и
недостаткам команд. Получился как бы
еще один раздел «Разное», который
включает следующие ошибки: навязывание
ненужных ограничений, дружественность
к новичкам, создающая неудобства для
опытных пользователей, навязчивая
предупредительность и неудачная попытка
сделать программу интеллектуальной,
запрос информации без необходимости,
ненужное повторение действий, ненужные
ограничения.

Производительность. Авторы отмечают
существование нескольких трактовок
этого понятия: 1) скорость программы, 2)
производительность работы пользователя,
3) субъективное восприятие пользователем
характеристик производительности
программы. В связи с этим возможна
ситуация, когда высокоскоростная
программа с неудачным пользовательским
интерфейсом кажется медленнее, чем на
самом деле. Какая-то логика в этом
безусловно есть, но представляется
более правильным разделить производительность
программы при решении ее основных
функциональных задач, которая в
большинстве случаев не зависит от
пользователей и может быть точно
замерена, и производительность
непосредственно интерфейса. При всей
субъективности этой характеристики
она может быть оценена на стадии
разработки интерфейса, а затем и измерена
специальными средствами.

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

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

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

Предотвращение ошибок. Программа
должна быть защищена от недопустимого
ввода и неправильной эксплуатации.
Должна быть предусмотрена проверка
вводимых данных. Можно использовать
методы аппаратного обнаружения и
исправления ошибок.

Выделяются подпункты:

неверное начальное состояние;

неадекватная проверка пользовательского
ввода;

неадекватная защита от испорченных
данных;

не выполнена проверка переданных
параметров;

недостаточная защита от ошибок
операционной системы;

не выполняется проверка версии;

недостаточная защита от неправильного
использования («защита от дурака»).

Выявление ошибок. Программа должна
контролировать правильность данных.

Выделяются подпункты:

переполнение;

невозможные значения;

непроверенные данные;

флаги ошибок;

аппаратные сбои;

сравнение данных;

восстановление после ошибок;

автоматическое исправление ошибок;

отсутствие сообщения об ошибке;

не установлен флаг ошибки;

куда возвращается управление? (Ошибки
передачи управления после сбоя);

прекращение выполнения программы из-за
ошибки. Имеются в виду возможные ошибки
из-за не корректной обработки такой
ситуации;

обработка аппаратных отказов;

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

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

Выделяют следующие типы таких ошибок:

неправильная обработка граничного
значения;

неверное граничное условие;

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

Выделяются следующие подпункты:

числовые ограничения;

ограничения на равенство;

количественные ограничения;

пространственные ограничения;

ограничения времени (имеются в виду
вопросы, связанные с поведением системы
на границах заданных в программе
временных интервалов);

условия циклов;

ограничения объема памяти;

ограничения, связанные со структурой
данных;

ограничения, связанные с аппаратным
обеспечением;

невидимые границы.

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

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

Авторы работы [5] выделяют следующие
причины возникновения таких ошибок:

неверная логика (может быть следствием,
как ошибок проектирования, так и
кодирования);

неправильно выполняются арифметические
операции (как правило – это ошибки
кодирования);

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

Выделяются подпункты:

устаревшие константы;

ошибки вычислений;

неверно расставленные скобки;

неправильный порядок операторов;

неверно работает базовая функция;

переполнение и потеря значащих разрядов;

ошибки отсечения и округления;

путаница с представлением данных;

неправильное преобразование данных из
одного формата в другой;

неверная формула;

неправильное приближение.

Начальное и последующие состояния
(Ошибки инициализации).

Представляется не очень обоснованным
их выделение в самостоятельный раздел,
хотя они важны.

Выделяются подпункты:

не присвоены начальные значения;

не инициализирована переменная,
управляющая циклом;

не инициализирован указатель;

не очищена строка;

не инициализированы регистры;

не сброшен флаг;

данные должны были инициализироваться
в другом месте;

не выполнена повторная инициализация;

предположение (не верное), что данные
не были инициализированы;

путаница со статическими и динамическими
переменными;

не предполагавшаяся модификация данных,
выполняемая другими подпрограммами;

ошибочная инициализация;

зависимость от инструментальных средств,
которых может не быть.

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

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

Выделяются подпункты:

очевидно неверное поведение программы;

переход по GOTO;

логика, основанная на определении
вызывающей подпрограммы;

использование таблиц переходов;

выполнение данных (вместо команд).
Ситуация возможна из-за ошибок работы
с указателями, отсутствия проверок
границ массивов, ошибок перехода,
вызванных, например, ошибкой в таблице
адресов перехода, ошибок сегментирования
памяти;

переход к подпрограмме, которая
отсутствует в памяти. Ошибки связаны с
ошибками в организации оверлейных
программ;

реентерабельность. Реентерабельная
программа может вызывать сама себя или
быть вызвана несколькими параллельными
процессами одновременно. Такая возможность
может не поддерживаться языком
программирования. Если она поддерживается,
то нужно обеспечить защиту данных,
используемых одним процессом, от их
модификации другим;

путаница имен переменных и команд;

неверное предположение о состоянии
программы или данных после вызова;

обработка ошибок выполнения процедур
(имеются в виду ошибки, когда программист
не предусмотрел такую обработку);

возврат не в ту точку кода (сюда включены
несколько видов ошибок: испорченный
стек, переполнение и выход за нижнюю
границу стека, выход из подпрограммы
по GOTO вместо RETURN);

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

завершение работы программы;

«зависание» компьютера;

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

ожидание невозможных условий или
комбинаций условий (примерами таких
ошибок являются: проблемы ввода/вывода,
взаимная блокировка, простая логическая
ошибка в условиях);

неверный приоритет пользователя или
процесса;

циклы (сюда включены несколько видов
ошибок: бесконечный цикл, неверное
начальное значение переменной управления
циклом, случайное изменение переменной
управления циклом, ошибочный критерий
выхода из цикла, команды, которые должны
или не должны выполняться внутри цикла,
ошибка вложенности циклов);

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

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

Выделяются подпункты:

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

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

проблемы с обменом сообщений (сюда
включены несколько видов ошибок: отправка
сообщения не тому процессу или не в тот
порт, ошибка распознавания полученного
сообщения, недостающие или
несинхронизированные сообщения,
сообщение передано только N
процессам из N+1, порча
данных, хранящихся на внешнем устройстве,
потеря изменений, не сохранены введенные
данные, объем данных слишком велик для
процесса-получателя, неудачная попытка
отмены записи данных).

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

Выделяются подпункты:

гонки при обновлении данных;

предположение, что одно задание завершится
до начала другого;

предположение, что в течение определенного
короткого интервала времени не будет
ввода данных;

предположение, что в течение определенного
короткого интервала времени не будет
прерываний;

ресурс только что стал недоступен;

предположение, что человек, устройство
или процесс ответят быстро;

реальный набор опций в процессе
перерисовки экрана;

задание начинается до того, как выполнены
подготовительные действия;

сообщения приходят одновременно или
не в том порядке, в котором они были
отправлены.

Повышенные нагрузки.

При повышенных нагрузках или нехватке
ресурсов могут возникнуть дополнительные
ошибки. Выделяются подпункты:

требуемый ресурс недоступен;

не освобожден ресурс;

нет сигнала об освобождении устройства;

старый файл не удален с накопителя;

системе не возвращена неиспользуемая
память;

лишние затраты компьютерного времени;

нет свободного блока памяти достаточного
размера;

недостаточный размер буфера ввода или
очереди;

не очищен элемент очереди, буфера или
стека;

потерянные сообщения;

снижение производительности;

повышение вероятности ситуационных
гонок;

при повышенной нагрузке объем
необязательных данных не сокращается;

не распознается сокращенный вывод
другого процесса при повышенной загрузке;

не приостанавливаются задания с низким
приоритетом;

задания с низким приоритетом вообще не
выполняются.

В этом разделе хотелось бы обратить
внимание на следующее:

1) Часть ошибок из этого раздела могут
проявляться и при не очень высоких
нагрузках, но, возможно, они будут
проявляться реже и через более длительные
интервалы времени;

2) Многие ошибки из 2-х предыдущих разделов
уже в своей формулировке носят
вероятностный характер, поэтому следует
предположить возможность использования
вероятностных моделей и методов для их
выявления.

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

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

неверное устройство;

неверный адрес устройства;

устройство недоступно;

устройство возвращено не в тот пул;

данному пользователю или программе
использование устройства запрещено;

данный уровень привилегий не позволяет
получить доступ к устройству;

шумы;

прерывание связи;

проблемы тайм-аута;

неверный накопитель;

не проверяется содержимое текущего
диска;

не закрыт файл;

неожиданный конец файла;

ошибки, связанные с длиной файлов и
дисковыми секторами;

неверный код операции или команды;

неверно интерпретирован код состояния
или возврата;

ошибка протокола обмена с устройством;

неполное использование возможностей
устройства;

игнорирование или неправильно используется
механизм страничного управления памятью;

игнорирование ограничений канала;

предположения о наличии или отсутствии
устройства или его инициализации;

программируемые функциональные клавиши.

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

Контроль версий и идентификаторов.

Выделяются подпункты:

таинственным образом появляются старые
ошибки;

обновление не всех копий данных или
программных файлов;

отсутствие заголовка;

отсутствие номера версии;

неверный номер версии в заголовке
экрана;

отсутствующая или неверная информация
об авторских правах;

программа, скомпилированная из архивной
копии, не соответствует проданному
варианту;

готовые диски содержат неверный код
или данные.

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

Являются ошибками сотрудников группы
тестирования, а не программы. Выделяются
подпункты:

пропущенные ошибки в программе;

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

пропуск ошибок на экране;

не документирована проблема (отмечаются
следующие причины этого: тестировщик
неаккуратно ведет записи, тестировщик
не уверен в том, что данные действия
программы являются ошибочными, ошибка
показалась слишком незначительной,
тестировщик считает, что ошибку не будет
исправлена, тестировщика просили не
документировать больше подобные ошибки);

не выполнен запланированный тест
(отмечаются следующие причины этого:
тестовые материалы и записи плохо
организованы, тестировщику скучно
выполнять однотипные примеры, в одном
тесте объединено слишком много действий);

не описаны временные зависимости
появления ошибок;

слишком сложный тест (не позволяет
ошибку и добиться ее воспроизведения);

преувеличения;

личные выпады.

Ошибка выявлена и забыта.

Описываются ошибки использования
результатов тестирования. По-моему,
раздел следует объединить с предыдущим.
Выделяются подпункты:

не составлен итоговый отчет;

серьезная проблема не документирована
повторно;

не проверено исправление;

перед выпуском продукта не проанализирован
список нерешенных проблем.

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

Содержание:

Введение

Программное обеспечение, согласно ГОСТ 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 с.

Разработка клиент-серверного приложения по работе с базой данных «Локомотивное депо «
Анализ особенности управления мотивацией сотрудников на предприятиях гостиничного и ресторанного бизнеса на примере АО ТГК «Вега»
СУЩНОСТЬ И СОДЕРЖАНИЕ БАНКОВСКОГО МАРКЕТИНГА
Оформление и ведение учета операций с сомнительными, неплатежеспособными и имеющими признаки подделки денежными знаками
Виды, понятия, задачи оплаты труда на предприятии
ценообразование на услуги фитнес-клубов (Российский рынок фитнес-услуг)
Место и роль спортивной индустрии в экономике России (Теоретические аспекты индустрии спорта)
Влияние кадровой стратегии на работу службы персонала. (СОДЕРЖАНИЕ И СУЩНОСТЬ КАДРОВОЙ СТРАТЕГИИ)
Эффективный лидер и его команда (Виды лидерства)
Межфирменная научно-техническая кооперация
Прогнозирование эффективности реальных инвестиций коммерческого банка. Анализ инвестиционной деятельности ПАО «Сбербанк»
Страхование и его государственное регулирование в РФ

Общая классификация ошибок.
При оценке знаний, умений, навыков следует учитывать все ошибки (грубые и негрубые),
недочёты в соответствии с возрастом учащихся.
Грубыми считаются  ошибки:
незнание определения основных понятий, законов, правил, основных положений   , теории, незнание
формул, общепринятых символов обозначений величин, единиц их измерения, наименований этих
единиц;
неумение выделить в ответе главное; обобщить результаты изучения;
неумение применить знания для решения задач, объяснения явления;
неумение читать и строить графики, принципиальные схемы;
неумение подготовить установку или лабораторное оборудование, провести опыт, ,, наблюдение,
сделать необходимые расчёты или использовать полученные данные для выводов;
неумение пользоваться первоисточниками, учебником, справочником;
нарушение техники безопасности, небрежное отношение к оборудованию, приборам, материалам.
К негрубым относятся ошибки:
неточность формулировок, определений, понятий, законов, теорий, вызванная неполнотой охвата
основных признаков определяемого понятия или заменой  1 3 из этих признаков второстепенными;
ошибки при снятии показаний с измерительных приборов, не связанные с определением
цены деления шкалы;
ошибки, вызванные несоблюдением условий проведения опыта, наблюдения, условий работы
прибора, оборудования;
ошибки в условных обозначениях на схемах, неточность графика;
нерациональный метод решения задачи, выполнения части практической работы, недостаточно
продуманный план устного ответа (нарушение логики изложения, подмена отдельных основных
вопросов второстепенными);
нерациональные методы работы со справочной литературой;

неумение решать задачи, выполнять задания в общем виде.
Недочётам и являются:

нерациональные приёмы вычислений и преобразований, выполнения опытов, наблюдений,
практических заданий;
арифметические ошибки в вычислениях;
небрежное выполнение записей, чертежей, схем, графиков, таблиц;
орфографические и пунктационные ошибки.
Требования к написанию школьного реферата. Зашита реферата одна из форм проведения устной итоговой аттестации учащихся. Она
предполагает предварительный выбор выпускником интересующей его проблемы, ее глубокое изучение,
изложение результатов и выводов.
Термин «реферат» имеет латинские корни и в дословном переводе означает «докладываю,
сообщаю». Словари определяют его значение как «краткое изложение в письменном виде или в форме
публичного доклада содержания книги, учения, научной проблемы, результатов научного исследования;
доклад на определенную тему, освещающий ее на основе обзора литературы и других источников». Од
нако выпускники школы не всегда достаточно хорошо подготовлены к зтой форме работы и
осведомлены о тех требованиях, которые предъявляются к ее выполнению
1. Тема р е ф е р а т а и ее выбор
Основные требования к этой части реферата:



тема должна быть сформулирована грамотно с литературной точки зрения
в названии реферата следует определить четкие рамки рассмотрения темы, которые не должны
быть слишком широкими или слишком узкими
следует по возможности воздерживаться от использования в названии спорных с научной точки
зрения терминов, излишней наукообразности, а также от чрезмерного упрощения формулировок,
желательно избегать длинных названий.
2. Требования к оформлению титульного листа
В правом верхнем углу указывается название учебного заведения, в центре тема реферата, ниже
темы справа Ф.И.О. учащегося, класс. Ф.И.О. руководителя, внизу – населенный пункт и год
написания.
3.     Оглавление
Следующим после титульного листа должно идти оглавление. К сожалению, очень часто
учителя*не настаивают на этом кажущемся им формальном требовании, а ведь именно с подобных
«мелочей» начинается культура научного труда.
Школьный реферат следует составлять из четырех основных частей: введения, основной части,
заключения и списка литературы.
4. Основные требования к введению
Введение должно включать в себя краткое обоснование актуальности темы реферата, которая
может рассматриваться в связи с невыясненностью вопроса в науке, с его объективной сложностью для
изучения, а также в связи с многочисленными теориями и спорами, которые вокруг нее возникают. В
этой части необходимо также показать, почему данный вопрос может представлять научный интерес и
какое может иметь практическое значение. Таким образом, тема реферата должна быть актуальна либо
с научной точки зрения, либо из практических соображений.
Очень важно, чтобы школьник умел выделить цель (или несколько целей), а также задачи, которые
требуется решить для реализации цели. Например, целью может быть показ разных точек зрения на ту
или иную личность, а задачами могут выступать описание ее личностных качеств с позиций ряда
авторов, освещение ее общественной деятельности и т.д. Обычно одна задача ставится на один парграф
реферата.
1. Т р е б о в а н и я к о с н о в н о й ч а с т и р е ф е р а т а Основная часть реферата содержит материал, который отобран учеником для рассмотрения
проблемы. Не стоит требовать от школьников очень объемных рефератов, превращая их труд в
механическое переписывание из различных источников первого попавшегося материала. Средний объем
основной части реферата 10 страниц. Учителю при рецензии, а ученику при написании необходимо
обратить внимание на обоснованное распределение материала на параграфы, умение формулировать их
название, соблюдение логики изложения.
Основная часть реферата, кроме содержания, выбранного из разных литературных источников,
также должна включать в себя собственное мнение учащегося и сформулированные самостоятельные
выводы, опирающиеся на приведенные факты.
6. Требования к заключению
Заключение часть реферата, в которой формулируются выводы по параграфам, обращается
внимание на выполнение поставленных во введении задач и целей (или цели). Заключение должно быть
четким, кратким, вытекающим из основной части. Очень часто ученики (да и учителя) путают
заключение с литературным послесловием, где пытаются представить материал, продолжающий
изложение проблемы. Объем заключения  23 страницы.
7. Основные требования к СПИСКУ изученной литературы
Источники должны быть перечислены в алфавитной последовательности (по первым буквам
фамилий авторов или по названиям сборников). Необходимо указать место издания, название
издательства, год издания.
8. Основные требования к написанию реферата
Основные требования к написанию реферата следующие:
 Должна соблюдаться определенная форма (титульный лист,оглавление и т.д.)
 Выбранная тема должна содержать определенную проблему и быть адекватной школьному
уровню по объему и степени научности.
 Не следует требовать написания очень объемных по количеству страниц рефератов.
 Введение и заключение должны быть осмыслением основной части реферата.
9. Выставление оценки за реферат
В итоге оценка складывается из ряда моментов:
• соблюдения формальных требований к реферату.
• грамотного раскрытия темы:
• умения четко рассказать о представленном реферате

способности понять суть задаваемых по работе вопросов и сформулировать точные ответы
на них.

Источник

Классификация ошибок

Грамматические ошибки

Грамматическая ошибка – ошибка в структуре языковой единицы: словосочетания или предложения; нарушение какой-либо грамматической нормы – словообразовательной, морфологической, синтаксической и др.

№ п/п	Вид ошибки	Примеры
1	Ошибочное словообразование	Трудолюбимый, надсмехаться
2	Ошибочное образование формы существительного	Многие чуда техники, не хватает время
3	Ошибочное образование формы прилагательного	Более интереснее
4	Ошибочное образование формы числительного	С пятистами рублями
5	Ошибочное образование формы местоимения	Ихнего пафоса
6	Ошибочное образование формы глагола	Они хочут, пиша о жизни
7	Нарушение согласования	Я знаком с группой ребят, увлекающимися джазом
8	Нарушение управления	Повествует читателей. Нужно сделать свою природу более красивую.
9	Нарушение связи между подлежащим и сказуемым
10	Нарушение способа выражения сказуемого в отдельных конструкциях	Он написал книгу, которая эпопея. Мы были рады, счастливы и веселые.
11	Ошибки в построении предложения с однородными членами	Страна любила и гордилась поэтом.
12	Ошибки в построении предложения с деепричастным оборотом	Читая текст, возникает такое чувство …
13	Ошибки в построении предложения с причастным оборотом	Узкая дорожка была покрыта проваливающимся снегом под ногами.
14	Ошибки в построении сложного предложения	Эта книга научила меня ценить и уважать друзей, которую я прочла еще в детстве.
15	Смешение прямой и косвенной речи	Автор сказал, что я не согласен с мнением рецензента.
16	Нарушение границ предложения	Когда герой опомнился. Было уже поздно.
17	Нарушение видовременной соотнесенности глагольных форм	Замирает на мгновение сердце и вдруг застучит вновь.
18	Неудачное употребление местоимений	Данный текст написал В.Белов. Он относится к художественному стилю. У меня сразу же возникла картина в своем воображении.

Речевые ошибки

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

№ п/п	Вид ошибки	Примеры
1	Употребление слова в несвойственном ему значении	Мы были шокированы прекрасной игрой актеров. Мысль развивается на продолжении всего текста.
2	Неразличение оттенков значения, вносимых в слово приставкой и суффиксом	Мое отношение к этой проблеме не поменялось. Были приняты эффектные меры.
3	Неразличение синонимичных слов	В конечном предложении автор употребляет градацию.
4	Употребление слов иной стилевой окраски	Автор, обращаясь к этой проблеме, пытается направить людей немного в другую колею.
5	Неуместное употребление эмоционально-окрашенных слов и фразеологизмов	Астафьев то и дело прибегает к употреблению метафор и олицетворений.
6	Неоправданное употребление просторечных слов	Таким людям всегда удается объегорить других.
7	Нарушение лексической сочетаемости	Автор увеличивает впечатление. Автор использует художественные особенности.
8	Употребление лишних слов, в том числе плеоназм	Молодой юноша, очень прекрасный
9	Употребление рядом или близко однокоренных слов (тавтология)	В этом рассказе рассказывается о реальных событиях.
10	Неоправданное повторение слова	Герой рассказа не задумывается под своим поступком. Герой даже не понимает всей глубины содеянного.
11	Бедность и однообразие синтаксических конструкций	Когда писатель пришел в редакцию, его принял главный редактор. Когда они поговорили, писатель отправился в гостиницу.

Орфографические и пунктуационные ошибки

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

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

К негрубым ошибкам относятся:

— в исключениях из правил

— в написании большой буквы в составных собственных наименованиях

— в случаях раздельного и слитного написания НЕ с прилагательными и причастиями, выступающими в роли сказуемого

— в написании И и Ы после приставок

— в трудных случаях различения НЕ и НИ (Куда он только не обращался! Куда он ни обращался! Никто иной не… Не кто иной, как Не что иное, как и др)

— в случаях, когда вместо одного знака поставлен другой

— в пропуске одного из сочетающихся знаков препинания или в нарушении их последовательности

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

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

Не считаются однотипными ошибки на такое правило, в котором для выяснения правильного написания слова требуется подобрать другое (опорное) слово или его форму (вода – воды, грустить – грусть)

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

Понятие об однотипных ошибках не распространяется на пунктуационные ошибки.

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

К числу наиболее распространенных относятся:

— пропуски букв

— перестановки букв

— замены одних буквенных знаков другими

— добавление лишних букв

Орфографические и пунктуационные ошибки,

не влияющие на оценку работы

Орфография

— в переносе слов

— буквы э/е после согласных в иноязычных словах (рэкет, пленэр) и после гласных в собственных именах (Мариетта)

— прописная /строчная буквы в названиях, связанных с религией (М(м)асленица, Р(р)ождество, Б(б)ог)

— прописная /строчная буквы в собственных именах нерусского происхождения; написание фамилий с первыми частями дон, Ван, сент .. (дон Педро и Дон Кихот)

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

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

Пунктуация

— тире в неполном предложении

— обособление несогласованных определений, относящихся к нарицательным именам существительным

— запятые при ограничительно-выделительных оборотов

— различение омонимичных частиц и междометий и, соответственно, невыделение и выделение их запятыми

— в передаче авторской пунктуации

Этические ошибки

Соблюдение этических норм

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

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

Например: «Этот текст меня бесит», «Судя по тому, что говорит автор, он маньяк», «Михалков в своем репертуаре! Пишет детские книги, поэтому и требует, чтобы читали именно в детстве. Это настоящий пиар! Нечего морочить людям мозги устаревшими истинами»

Источник

•специфики управления используемыми техническими средствами,

•операционной системы,

•среды и языка программирования,

•реализуемых процессов,

•природы и специфики различных ошибок,

•методик отладки и соответствующих программных средств.

Вцелом сложность отладки обусловлена следующими причинами:

•отсутствуют четко сформулированные методики отладки.

Всоответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):

Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

•несовпадение полученных результатов с ожидаемыми.

•неверное определение исходных данных,

•логические ошибки,

•накопление погрешностей результатов вычислений (рис. 10.2).

Кпоследней группе относят:

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

ручного тестирования;

индукции;

дедукции;

обратного прослеживания.

Данный метод часто используют как составную часть других методов отладки.

1. Отладка программы

Как бы тщательно мы ни писали, отладка почти всегда занимает больше времени, чем программирование.

2. Локализация ошибок

Локализация — это нахождение места ошибки в программе.

В процессе поиска ошибки мы обычно выполняем одни и те же действия:

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

Способы обнаружения ошибки:

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

Оба способа по-своему удобны и обычно используются совместно.

3.
принципы отладки

Принципы локализации ошибок:

Большинство ошибок обнаруживается вообще без запуска программы — просто внимательным просматриванием текста.
Если отладка зашла в тупик и обнаружить ошибку не удается, лучше отложить программу. Когда глаз «замылен», эффективность работы упорно стремится к нулю.
Чрезвычайно удобные вспомогательные средства — это отладочные механизмы среды разработки: трассировка, промежуточный контроль значений. Можно использовать даже дамп памяти, но такие радикальные действия нужны крайне редко.
Экспериментирования типа «а что будет, если изменить плюс на минус» — нужно избегать всеми силами. Обычно это не дает результатов, а только больше запутывает процесс отладки, да еще и добавляет новые ошибки.

Принципы исправления ошибок еще больше похожи на законы Мерфи:

Там, где найдена одна ошибка, возможно, есть и другие.
Вероятность, что ошибка найдена правильно, никогда не равна ста процентам.
Наша задача — найти саму ошибку, а не ее симптом.

4. Методы отладки

Силовые методы

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

С точки зрения «правильного» программирования силовые методы плохи тем, что не поощряют анализ задачи.

var
a, b, c: real;
begin
writeln('Программа находит значение максимального из трех введенных чисел');
write('Введите первое число '); readln(a);
write('Введите второе число '); readln(b);
write('Введите третье число '); readln(c);
if (a>b)and(a>c) then
writeln('Наибольшим оказалось первое число ',a:8:2)
else if (b>a)and(a>c) then
writeln('Наибольшим оказалось второе число ',b:8:2)
else
writeln('Наибольшим оказалось третье число ',b:8:2);
end.

Тестовые наборы данных должны учитывать все варианты решения, поэтому выберем следующие наборы чисел:

Данные Ожидаемый результат
a=10; b=-4; c=1 max=a=10
a=-2; b=8; c=4 max=b=8
a=90; b=0; c=90.4 max=c=90.4

В результате выполнения программы мы, однако, получим следующие результаты:
Для a=10; b=-4; c=1:

Наибольшим оказалось первое число 10.00

Для a=-2; b=8; c=4: < pre class=»list»>Наибольшим оказалось третье число 8.00Для a=90; b=0; c=90.4:

Наибольшим оказалось третье число 0.00

Вывод во втором и третьем случаях явно неверен. Будем разбираться.

1. Трассировка и промежуточная наблюдение за переменными

Добавляем промежуточную печать или наблюдение за переменными:

— вывод a, b, c после ввода (проверяем, правильно ли получили данные)
— вывод значения каждого из условий (проверяем, правильно ли записали условия)

Листинг программы существенно увеличился и стал вот таким:

Но давайте считать, что глаз «замылен» совершенно, и найти ошибку не удалось.

Вывод для второго случая получается следующим:

Наибольшим оказалось третье число 4.00

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

2. Метод индукции

3. Метод дедукции

Неверные результаты в нашем случае могут получиться из-за ошибки в:

— вводе данных;
— расчетном блоке;
— собственно выводе.

4. Обратное движение по алгоритму

5. Тестирование

5. Средства отладки

Помимо методик, хорошо бы иметь представление о средствах, которые помогают нам выявлять ошибки. Это:

1) Аварийная печать — вывод сообщений о ненормальном завершении отдельных блоков и всей программы в целом.

3) Непосредственное слежение:

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

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

Рис Пример отладки приложения

6. Классификация ошибок

— ошибки обращения к данным,
— ошибки описания данных,
— ошибки вычислений,
— ошибки при сравнении,
— ошибки в передаче управления,
— ошибки ввода-вывода,
— ошибки интерфейса,
и т д

Классификация ошибок по этапу обработки программы

рис Классификация ошибок этапа выполнения по возможным причинам

Синтаксические ошибки

Примеры синтаксических ошибок :

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

Ошибки, которые не обнаруживает транслятор

ошибки в архитектуре приложения пприводящие к увеличени технического долга

Методы (пути) снижение ошибок в программировании

использование тестиования
использование более простых решений
использование систем с наименьшим числом составлящих
использование ранее использованных и проверенных компонентов
использование более квалифицрованных специалистов

7. Советы отладчику

1) Проверяйте тщательнее: ошибка скорее всего находится не в том месте, в котором кажется.

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

3) Тщательнее следить за объявлениями констант, типов и переменных, входными данными.

7) Ошибка, скорее всего окажется вашей и будет находиться в тексте программы. Гораздо реже она оказывается:

в компиляторе,
операционной системе,
аппаратной части,
электропроводке в здании и т.д.

12) Самые труднообнаруживаемые ошибки — наведенные, то есть те, что были внесены в код при исправлении других.

8. Тестирование

3) При разработке тестов нужно учитывать не только правильные, но и неверные исходные данные.

9. Проектирование тестов

Давайте рассмотрим задачу: нужно проверить, попадает ли введенное число в заданный пользователем диапазон.

Как видите, программа очень мала, а тестов для проверки всех ветвей ее алгоритма, требуется довольно много.

10. Стратегии тестирования

1) Тестирование программы как «черного ящика».

«Черным ящиком» удобно тестировать небольшие подпрограммы.
2) Тестирование программы как «белого ящика».

На практике мы, как всегда, совместно используем оба принципа.
3) Тестирование программ модульной структуры.

См. также

ошибки в приложениях , bugs , баг репорт , bug report ,
Фича
GIGO
Патч
тестирование
цикломатическая сложность
баг репорт
качество программного обеспечения

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

Ошибки выполнения можно разделить на три большие группы.

К ним относятся:

ошибки преобразования;
ошибки данных;
ошибки перезаписи.

В эту группу входят:

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

Вот как выглядит процесс:

Алгоритм отладки по методу индукции

Отладка по методу дедукции

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

Источник

Методы отладки программного обеспечения

1. Отладка программы

2. Локализация ошибок

3. принципы отладки

4. Методы отладки

1. Трассировка и промежуточная наблюдение за переменными

2. Метод индукции

3. Метод дедукции

4. Обратное движение по алгоритму

5. Тестирование

5. Средства отладки

6. Классификация ошибок

Синтаксические ошибки

Ошибки, которые не обнаруживает транслятор

Методы (пути) снижение ошибок в программировании

7. Советы отладчику

8. Тестирование

9. Проектирование тестов

10. Стратегии тестирования

См. также

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

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

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

Введение

Надежность программного обеспечения

Показатели качества программного обеспечения

Источники ошибок программного обеспечения

Неверные действия пользователя:

Виды ошибок программного обеспечения

Характеристика основных видов ошибок программного обеспечения

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

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

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

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

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

5.Повышенные нагрузки.

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

8.Ошибка выявлена и забыта.

Меры по повышению надежности программного обеспечения

Заключение

Список использованной литературы

Методы отладки программного обеспечения

1. Отладка программы

2. Локализация ошибок

3. принципы отладки

4. Методы отладки

1. Трассировка и промежуточная наблюдение за переменными

2. Метод индукции

3. Метод дедукции

4. Обратное движение по алгоритму

5. Тестирование

5. Средства отладки

6. Классификация ошибок

Синтаксические ошибки

Ошибки, которые не обнаруживает транслятор

Методы (пути) снижение ошибок в программировании

7. Советы отладчику

8. Тестирование

9. Проектирование тестов

10. Стратегии тестирования

См. также

3.
принципы отладки

3.
принципы отладки