Виды ошибок информационной системы

Дефекты. Ошибки, сбои, отказы

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

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

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

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

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

Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.

Дефекты могут быть в документации, настройках, входных данных и т.д.

Сбой или отказ — отклонение поведения системы от ожидаемого.

В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :

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

Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

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

Отчёт о дефекте и его жизненный цикл

При обнаружении дефекта тестировщик создаёт отчёт о дефекте .

Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению

Отчёт о дефекте пишется со следующими основными целями:

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

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

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

• Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
• Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил.
• Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
• Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.

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

Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями

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

• Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.

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

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

• В некоторых средствах одного из состояний нет (оно поглощается другим)

В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состояний с резолюциями наподобие:

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

• Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
• Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
• Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
• Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).

Атрибуты (поля) отчёта о дефекте

Общий вид всей структуры отчёта о дефекте представлен на рисунке

• Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
• Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».

Например: «Отсутствует логотип на странице приветствия, если пользователь

является администратором»:

— Что произошло? Отсутствует логотип.

— Где это произошло? На странице приветствия.

— При каких условиях это произошло? Если пользователь является

администратором.

Заполнение поля « краткое описание », которое одновременно должно:

— содержать предельно краткую, но в то же время достаточную для

понимания сути проблемы информацию о дефекте;

— быть достаточно коротким, чтобы полностью помещаться на экране;

— при необходимости содержать информацию об окружении, под

которым был обнаружен дефект;

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

дефектов (и даже не быть похожими на них), чтобы дефекты

было сложно перепутать или посчитать дубликатами друг друга;

— быть законченным предложением русского или английского (или

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

грамматики.

Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:

• Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
• Сформулировать подробное описание
• 3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.

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

5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.

6. Если предложение получилось слишком длинным, переформулировать

его, сократив длину (за счёт подбора синонимов, использования

общепринятых аббревиатур и сокращений). К слову, в английском языке

предложение почти всегда будет короче русского аналога.

Пример применения этого алгоритма.

Тестированию подвергается некое веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого ограничения нет.

• Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
• Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.

• Конечный вариант подробного описания:

— Фактический результат: в описании товара (поле «О товаре»,

http://testapplication/admin/goods/edit/) отсутствуют проверка и

ограничение длины вводимого текста (MAX=250 символов).

— Ожидаемый результат: в случае попытки ввода 251+ символов

выводится сообщение об ошибке.

• Определение «что, где и при каких условиях случилось»:

— Что: отсутствуют проверка и ограничение длины вводимого текста.

— Где: описание товара, поле «О товаре»,

http://testapplication/admin/goods/edit/.

— При каких условиях: – (в данном случае дефект присутствует всегда, вне

зависимости от каких бы то ни было особых условий).

• Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
• Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.

• Подробное описание представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно).

Пример подробного описания :

Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы. Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b.

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

• Шаги по воспроизведению описывают действия, которые необходимо выполнить для воспроизведения дефекта.

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

Пример шагов воспроизведения :

• Открыть http://testapplication/admin/login/.
• Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).

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

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

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

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

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

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

— Средняя — существование дефекта слабо влияет на типичные

сценарии работы пользователей, и/или существует обходной путь

достижения цели, например: диалоговое окно не закрывается

автоматически после нажатия кнопок «OK»/«Cancel», при распечатке

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

«Двусторонняя печать», перепутаны направления сортировок по

некоему полю таблицы.

— Низкая — существование дефекта редко обнаруживается

незначительным процентом пользователей и (почти) не влияет на их

работу, например: опечатка в глубоко вложенном пункте меню

настроек, некоторое окно при отображении расположено неудобно

(нужно перетянуть его в удобное место), неточно отображается время

до завершения операции копирования файлов.

• Срочность показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие виды срочности:

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

• С имптом — позволяет классифицировать дефекты по их типичному проявлению. Не существует никакого общепринятого списка симптомов.

В качестве примера рассмотрим следующие значения симптомов дефекта.

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

• Проблема масштабируемости — при увеличении количества доступных приложению ресурсов не происходит ожидаемого прироста производительности приложения
• Низкая производительность — выполнение неких операций занимает недопустимо большое время
• Крах системы — приложение прекращает работу или теряет способность выполнять свои ключевые функции
• Неожиданное поведение — в процессе выполнения некоторой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой записи активной становится не новая запись, а первая в списке).
• Недружественное поведение — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалоговых окнах в разном порядке расположены кнопки «OK» и «Cancel»).
• Расхождение с требованиями — этот симптом указывают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях.
• Предложение по улучшению — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный вид отчёта

Часто у одного дефекта может быть сразу несколько симптомов.

• Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
• Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
• Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

В работе [Тайер,
Липов, Нельсон] отмечается, что для
разработки надежного программного
обеспечения необходимо знать не только
тип ошибок, но и распределение ошибок
в системах программного обеспечения
по категориям. Желательно иметь
максимально возможный перечень ошибок,
которые могут возникать при разработке
и выполнении программ, это даст возможность
разработчикам избежать многих из них.

Категория ошибок
определяется как видовое описание
ошибок конкретных типов, авторами
выявлено около 20 основных классов
ошибок. Приведем кратко описание основных
классов ошибок (полный перечень ошибок
приведен в таблице ?.?)

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

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

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

1. Когда следует прекращать тестирование программ

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

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

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

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

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

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

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

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

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

Примечание:
Принято считать, что сам термин алгоритм
происходит от имени персидского
математика Абу-Ждафара Мохаммеда
Ибн-Мусы Аль-Хорезми, который в 825 г.
описал правила выполнения арифметических
действий в десятичной системе счисления.
Понятие алгоритма стало предметом
соответствующей теории –
теории алгоритмов, которая занимается
изучением общих свойств алгоритмов,
какой-то период времени языки
программирования назывались
алгоритмическими.

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

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

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

Программирование
(в узком смысле) – процесс кодирования
и отладки программы в рамках реального
проекта.

Целью программирования
является описание процессов обработки
данных (в дальнейшем 
просто процессов). Согласно IFIP
(Международная федерация по обработке
информации) и ICC (Международный
вычислительный центр) данные
(data) 
это представление фактов и идей в
формализованном виде, пригодном для
передачи и переработки в некоем процессе,
а информация (information)
 это смысл, который
придается данным при их представлении.

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

Основоположник
кибернетики Н. Винер
считал, что «Информация – это информация,
а не энергия и не материя», и поставил
информацию в один ряд с другими наиболее
общими философскими категориями.

В словаре русского
языка С.И. Ожегов [20] определил
информацию как: 1) сведения об окружающем
мире и протекающих в нем процессах;
2) сообщения, осведомляющие о положении
дел, о состоянии чего-либо.

В законе «Об
информации, информационных технологиях
и защите информации» [11] дается следующее
определение информации: «Информация –
сведения о лицах, предметах, фактах,
событиях, явлениях и процессах независимо
от формы их представления».

Итак, данные
участвуют в некотором информационном
процессе (information
process)
или в обработке данных. Обработка
данных (data
processing)
– это выполнение систематической
последовательности действий с данными.
Данные представляются и хранятся на
так называемых носителях данных.
Совокупность носителей данных,
используемых при какой-либо обработке
данных, называется информационной
средой (data
medium).
Набор данных, содержащихся в какой-либо
момент в информационной среде, называется
состоянием этой информационной
среды. Поэтому процесс можно
определить как последовательность
сменяющих друг друга состояний некоторой
информационной среды [10].

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

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

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

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

Технология
программирования (programming
technology)
– это совокупность методов и средств,
используемых в процессе разработки
программных продуктов, представляет
собой набор технологических инструкций,
включающих в себя:

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

• перечисление
  условий, при которых выполняется та
  или иная операция;

• описание самих
  операций, где для каждой операции
  выделены исходные данные, результаты,
  а также инструкции, нормативы, стандарты,
  критерии и методы оценки и т.п. (рисунок
  1) [6].

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

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

Любая технология
имеет две стороны:

• принципиальную
  (внутреннюю);

• организационно-производственную
  (внешнюю).

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

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

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

Не следует путать
технологию программирования с
методологией. В технологии программирования
методы рассматриваются «сверху» 
с точки зрения организации технологических
процессов, а в методологии программирования
методы рассматриваются «снизу» 
с точки зрения основ их построения.

Методология
программирования
– совокупность механизмов, применяемых
в процессе разработки программного
обеспечения и объединенных одним общим
философским подходом [4]¹.

В литературе широко
используется близкое к технологии
программирования понятие программной
инженерии
(software
engineering),
определяемой как систематический подход
к разработке, эксплуатации, сопровождению
и изъятию из обращения программных
средств [9]².
Главное различие между технологией
программирования и программной инженерией
как дисциплинами для изучения заключается
в способе рассмотрения и систематизации
материала. В технологии программирования
акцент делается на изучении процессов
разработки ПП (технологических
процессов) и порядке их прохождения
 методы и
инструментальные средства разработки
ПП используются в этих процессах
(их применение и образует технологические
процессы). Тогда как в программной
инженерии изучаются различные методы
и инструментальные средства разработки
ПС с точки зрения достижения определенных
целей – эти методы и средства могут
использоваться в разных технологических
процессах (и в разных технологиях
программирования) [36].

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

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

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

• использовать ряд
  базовых принципов (о них будет идти
  речь позже) для достижения поставленной
  цели – выпуска надежной ПС.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #

  07.06.20152.23 Mб14Учебник Кутафина.doc

• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Определение

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

Баги обнаруживаются чаще всего в момент отладки или бета-тестирования. Реже – после итогового релиза готовой программы. Вот несколько вариантов багов:

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

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

История происхождения термина

Баг – слово, которое используется разработчиками в качестве сленга. Оно произошло от слова «bug» – «жук». Точно неизвестно, откуда в программировании и IT возник соответствующий термин. Существуют две теории:

1. 9 сентября 1945 года ученые из Гарварда тестировали очередную вычислительную машину. Она называлась Mark II Aiken Relay Calculator. Устройство начало работать с ошибками. Когда его разобрали, то ученые заметили мотылька, застрявшего между реле. Тогда некая Грейс Хоппер назвала произошедший сбой упомянутым термином.
2. Слово «баг» появилось задолго до появления Mark II. Термин использовался Томасом Эдисоном и указывал на мелкие недочеты и трудности. Во время Второй Мировой войны «bugs» называли проблемы с радарной электроникой.

Второй вариант кажется более реалистичным. Это факт, который подтвержден документально. Со временем научились различать различные типы багов в IT. Далее они будут рассмотрены более подробно.

Как классифицируют

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

1. Серьезные неполадки. Это нарушения работоспособности приложения, которые могут приводить к непредвиденным крупным изменениям.
2. Незначительные ошибки в программах. Чаще всего не оказывают серьезного воздействия на функциональность ПО.
3. Showstopper. Критические проблемы в приложении или аппаратном обеспечении. Приводят к выходу программы из строя почти всегда. Для примера можно взять любое клиент-серверное приложение, в котором не получается авторизоваться через логин и пароль.

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

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

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

Виды

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

Разработчики выделяют следующие типы ошибок по уровню сложности:

1. «Борбаг» – «стабильная» неполадка. Она легко обнаруживается на этапе разработки и компилирования. Иногда – во время тестирования наработкой исходной программы.
2. «Гейзенбаг» – баги с поддержкой изменения свойств, включая зависимость от среды, в которой было запущено приложение. Сюда относят периодические неполадки в программах. Они могут исчезать на некоторое время, но через какой-то промежуток вновь дают о себе знать.
3. «Мандельбаг» – непредвиденные ошибки. Обладают энтропийным поведением. Предсказать, к чему они приведут, практически невозможно.
4. «Шрединбаг» – критические неполадки. Приводят к тому, что злоумышленники могут взломать программу. Данный тип ошибок обнаружить достаточно трудно, потому что они никак себя не проявляют.

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

Типы багов

Ошибки в программах бывают:

• логическими;
• синтаксическими;
• взаимодействия;
• компиляционные;
• ресурсные;
• арифметические;
• среды выполнения.

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

Ошибки синтаксиса

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

Синтаксические ошибки – ошибки синтаксиса, правил языка. Вот пример в Паскале:

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

Логические

Тут стоит выделить обычные и арифметические типы. Вторые возникают, когда программе при работе необходимо вычислить много переменных, но на каком-то этапе расчетов возникают неполадки или нечто непредвиденное. Пример – получение в результатах «бесконечности».

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

Выше – пример логической ошибки в программе. Тут:

1. Происходит сравнение значения i с 15.
2. На экран выводится сообщение, если I = 15.
3. В заданном цикле i не будет равно 15. Связано это с диапазоном значений – от 1 до 10.

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

Время выполнения

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

Самый распространенный пример в данной категории – это неожиданное деление на ноль. Предложенный фрагмент кода с точки зрения синтаксиса и логики написан грамотно. Но, если клиент наберет 0, произойдет сбой системы.

Компиляционный тип

Встречается при разработке на языках высокого уровня. Во время преобразований в машинный тип «что-то идет не так». Причиной служат синтаксические ошибки или сбои непосредственно в компиляторе.

Наличие подобных неполадок делает бета-тестирование невозможным. Компиляционные ошибки устраняются при разработке-отладке.

Ресурсные

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

Исправить ситуацию помогают основательные работы над исходным кодом. А именно – полное переписывание программы или «проблемного» фрагмента.

Взаимодействие

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

Исключения и как избежать багов

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

Исключения бывают:

1. Программными. Они генерируются приложением или ОС.
2. Аппаратными. Создаются процессором. Пример – обращение к невыделенной памяти.

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Присутствуют варианты как для продвинутых, так и для начинающих пользователей.