Министерство образования Республики Беларусь

Учреждение образования
БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ

Факультет компьютерных технологий

Кафедра информационных систем и технологий

Дисциплина: Надёжность программного обеспечения

Контрольная работа
На тему «Жизненный цикл дефекта»

Студент группы 98107Х

ХХХХ
Руководитель: Горбачёв Д.В.

Минск 2021
 ПЛАН

ВВЕДЕНИЕ..............................................................................................................3
1. Дефект................................................................................................................3
2. Жизненный цикл дефекта.................................................................................9
3. Системы документирования дефектов..........................................................15
Список литературы...............................................................................................18

2
 ВВЕДЕНИЕ

Темой данной курсовой работы является жизненный цикл

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

1. Дефект

Упрощённый взгляд на понятие дефекта.

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

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

Рисунок 1.1 - Ошибки, дефекты, сбои и отказы

Если же посмотреть на англоязычную терминологию,

представленную в глоссарии ISTQB и иных источниках, можно
построить чуть более сложную схему, представленную на рисунке 1.2:

Рисунок 1.2 - Взаимосвязь проблем в разработке программных продуктов

Рассмотрим все соответствующие термины.

4
 Ошибка (mistake) — действие человека, приводящее к
некорректным результатам.
Этот термин очень часто используют как наиболее
универсальный, описывающий любые проблемы («ошибка человека»,
«ошибка в коде», «ошибка в документации», «ошибка выполнения
операции», «ошибка передачи данных», «ошибочный результат» и т.
п.) Более того, куда чаще можно услышать «отчёт об ошибке», чем
«отчёт о дефекте». И это нормально, так сложилось исторически, к
тому же термин «ошибка» на самом деле очень широкий.
Дефект (bug, problem, fault) — недостаток в компоненте или
системе, способный привести к ситуации сбоя или отказа.
Довольно часто можно услышать данный термин в значении
«баг» (произношение англ. слова bug). Интересно то, что Bug в
переводе означает “жук, насекомое”. Первая ошибка, которая была
задокументирована, возникла как раз из-за жука. В середине 40-х годов
20 века ученых Гарвардского университета вызвали для того, чтобы
определить причину сбоя в работе вычислительной машины Mark II.
Покопавшись в этой громадной куче приборов, соединенных
проводами, они обнаружили бабочку, застрявшую между контактами
электромеханического реле. Стало ясно, что именно она и явилась
причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и
сформулировала результат исследований: “неполадку вызвал баг”.
Извлеченное насекомое было вклеено скотчем в технический дневник,
с соответствующей сопроводительной надписью. Ее, как говорят, до
сих пор можно увидеть в этом журнале, хранящемся в университетском
научном музее.
Дефект в программе не появляется просто так, у него всегда есть
источник. Например, ошибка программиста при написании кода.
Дефекты встречаются, потому что люди склонны ошибаться,
существует нехватка времени, сложность кода, сложность

5
инфраструктуры, изменения технологий и/или много системных
взаимодействий.
Что еще интересно, что программ, не содержащих дефектов, не
бывает. По статистике на каждую тысячу строк программного кода,
который пишут программисты, приходится несколько ошибок, а
количество строк в сложном программном обеспечении достигает
нескольких миллионов. Поэтому поиск и исправление этих багов –
очень трудоемкое дело, составляющее до 45% всех затрат на
разработку программного обеспечения.
Как и термин «ошибка», термин дефект также понимают
достаточно широко, говоря о дефектах в документации, настройках,
входных данных и т.д. На рисунке 1.1 видно, что этот термин как раз
стоит посередине — бессмысленно писать отчёты о человеческих
ошибках, равно как и почти бесполезно просто описывать проявления
сбоев и отказов — нужно докопаться до их причины, и первым шагом в
этом направлении является именно описание дефекта.
При исполнении кода программы дефекты, заложенные еще во
время его написания, могут проявиться: программа может не делать
того, что должна или наоборот – делать то, чего не должна, –
происходит сбой.
Сбой (failure) – несоответствие фактического результата
(actualresult) работы компонента или системы ожидаемому результату
(expectedresult). Сбой в работе программы может являться индикатором
наличия в ней дефекта.
Таким образом, баг(дефект) существует при одновременном
выполнении трех условий:
 известен ожидаемый результат;
 известен фактический результат;
 фактический результат отличается от ожидаемого результата.

6
 Важно понимать, что не все баги становятся причиной сбоев –
некоторые из них могут никак себя не проявлять и оставаться
незамеченными (или проявляться только при очень специфических
обстоятельствах).
Причиной сбоев могут быть не только дефекты, но также и
условия окружающей среды: например, радиация, электромагнитные
поля или загрязнение также могут влиять на работу как программного,
так и аппаратного обеспечения.
Всего существует несколько источников дефектов и,
соответственно, сбоев:
 ошибки в спецификации, дизайне или реализации программной
системы;
 ошибки использования системы;
 неблагоприятные условия окружающей среды;
 умышленное причинение вреда;
 потенциальные последствия предыдущих ошибок, условий или
умышленных действий.
Дефекты могут возникать на разных уровнях, и от того, будут ли
они исправлены и когда, будет напрямую зависеть качество системы.
Итак, мы вернулись к тому, с чего начинали в части этой главы,
описывающей предельно упрощённый взгляд на дефекты. Ошибки,
дефекты, сбои, отказы и т. д. являются проявлением аномалий —
отклонений фактического результата от ожидаемого. Стоит отметить,
что ожидаемый результат действительно может основываться на опыте
и здравом смысле, т. к. поведение программного средства никогда не
специфицируют до уровня базовых элементарных приёмов работы с
компьютером.
Понятие дефекта в рассматриваемой предметной области тесно
связано с отчетом о дефекте.

7
 Отчёт о дефекте (defect report) — документ, описывающий и
приоритизирующий обнаруженный дефект, а также содействующий
его устранению.
Как следует из самого определения, отчёт о дефекте пишется со
следующими основными целями:
• предоставить информацию о проблеме — уведомить проектную
команду и иных заинтересованных лиц о наличии проблемы, описать
суть проблемы;
• приоритизировать проблему — определить степень опасности
проблемы для проекта и желаемые сроки её устранения;
• содействовать устранению проблемы — качественный отчёт о
дефекте не только предоставляет все необходимые подробности для
понимания сути случившегося, но также может содержать анализ
причин возникновения проблемы и рекомендации по исправлению
ситуации.
На последней цели следует остановиться подробнее. Есть
мнение, что «хорошо написанный отчёт о дефекте — половина
решения проблемы для программиста». И это действительно так от
полноты, корректности, аккуратности, подробности и логичности
отчёта о дефекте зависит очень многое — одна и та же проблема может
быть описана так, что программисту останется буквально исправить
пару строк кода, а может быть описана и так, что сам автор отчёта на
следующий день не сможет понять, что же он имел в виду.
«Сверхцель» написания отчёта о дефекте состоит в быстром
исправлении ошибки (а в идеале — и недопущении её возникновения в
будущем). Потому качеству отчётов о дефекте следует уделять особое,
повышенное внимание.

8
2. Жизненный цикл дефекта

Жизненный цикл дефекта (Defect Lifecycle) – это

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

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

10
 В это состояние отчёт переводит тестировщик, удостоверившийся, что
дефект на самом деле был устранён. Как правило, такую проверку выполняет
тестировщик, изначально написавший отчёт о дефекте.
По поводу того, должен ли проверять факт устранения дефекта именно
тот тестировщик, который его обнаружил, или обязательно другой, есть
много «священных войн».
Сторонники второго варианта утверждают, что свежий взгляд
человека, ранее не знакомого с данным дефектом, позволяет ему в процессе
верификации с большой вероятностью обнаружить новые дефекты.
Несмотря на то, что такая точка зрения имеет право на существование,
всё же отметим: при грамотной организации процесса тестирования поиск
дефектов эффективно происходит на соответствующей стадии работы, а
верификация силами тестировщика, обнаружившего данный дефект, всё же
позволяет существенно сэкономить время.
 Закрыт (closed).
Это состояние отчёта, означающее, что по данному дефекту не
планируется никаких дальнейших действий.
Здесь есть некоторые расхождения в жизненном цикле, принятом в
разных инструментальных средствах управления отчётами о дефектах:
 В некоторых средствах существуют оба состояния — «Проверен» и
«Закрыт», чтобы подчеркнуть, что в состоянии «Проверен» ещё могут
потребоваться какие-то дополнительные действия (обсуждения,
дополнительные проверки в новых билдах и т. д.), в то время как состояние
«Закрыт» означает «с дефектом покончено, больше к этому вопросу не
возвращаемся».
 В некоторых средствах одного из состояний нет (оно поглощается
другим).
 В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт
о дефекте может быть переведён из множества предшествующих состояний с
резолюциями наподобие:

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

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

Рисунок 2.2 - Жизненный цикл отчёта о дефекте в JIRA

Для большей наглядности можно рассмотреть жизненный цикл

дефекта с точки зрения участников команды разработки и их функций.

13
 Итак, сначала тестировщик находит баг. Далее заносит его в
систему учета ошибок. После этого программист начинает изучать
отчет о дефекте. Именно на этом этапе он решает баг это или нет.
Давайте посмотрим сначала сценарий, в котором разработчик
принял баг. Перед ним сразу встает задача пофиксить его, то есть
исправить и залить (отдать заново на проверку). Как только
разработчик все сделал, баг снова отправляется к тестировщику,
который производит тестирование исправлений, а также проверяет
смежные участки (регрессионное тестирование).
Если баг больше не воспроизводится, то тестировщик закрывает
баг. Если баг снова воспроизводится, то мы возвращаем его
программисту. И снова проходим все шаги, начиная с 3-го шага
(рассмотрения проблемы программистом).
Теперь другой сценарий — разработчик не принял баг. Если баг
не принят, то разработчик возвращает его нам. На данном этапе задача
— рассмотреть проблему. Если баг вернули из-за некорректного
описания, то значит переписываем его. Если невозможно
воспроизвести дефект, то заново проверяем все шаги, может мы что-то
упустили при описании. Если разработчик прав и бага нет, то мы
закрываем баг. А если баг все же есть, то вносим необходимые
коррективы и опять возвращаемся на шаг 3.
Рисунок 2.3 отображает жизненный цикл дефекта именно с
данной точки зрения.

14
 Рисунок 2.3 - Жизненный цикл бага с точки зрения команды

Именно так выглядят основные этапы жизненного цикла бага.

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

15
 3. Системы документирования дефектов

На сегодняшний день жизненный цикл дефекта используется в

так называемых системах документирования дефектов, описание
которых будет рассмотрено в данной главе контрольной работы.
Так называемые «инструментальные средства управления
отчётами о дефектах» в обычной разговорной речи называют «баг-
трекинговыми системами», «баг-трекерами» и т. д. Но стоит
придерживаться более строгой терминологии.
Инструментальных средств управления отчётами о дефектах (bug
tracking system, defect management) очень много, к тому же многие
компании разрабатывают свои внутренние средства решения этой
задачи. Зачастую такие инструментальные средства являются частями
инструментальных средств управления тестированием.
Как и в случае с инструментальными средствами управления
тестированием, не имеет смысла заучивать, как работать с отчётами о
дефектах в том или ином средстве. Рассмотрим общий набор функций,
как правило, реализуемых такими средствами:
• Создание отчётов о дефектах, управление их жизненным циклом с
учётом контроля версий, прав доступа и разрешённых переходов из
состояния в состояние.
• Сбор, анализ и предоставление статистики в удобной для восприятия
человеком форме.
• Рассылка уведомлений, напоминаний и иных артефактов
соответствующим сотрудникам.
• Организация взаимосвязей между отчётами о дефектах, тест-
кейсами, требованиями и анализ таких связей с возможностью формирования
рекомендаций.
• Подготовка информации для включения в отчёт о результатах
тестирования.

16
 • Интеграция с системами управления проектами.
Иными словами, хорошее инструментальное средство управления
жизненным циклом отчётов о дефектах не только избавляет человека
от необходимости внимательно выполнять большое количество
рутинных операций, но и предоставляет дополнительные возможности,
облегчающие работу тестировщика и делающие её более эффективной.
Состав информации о дефекте
Главный компонент такой системы — база данных, содержащая
сведения об обнаруженных дефектах. Эти сведения могут включать в
себя:
 номер (идентификатор) дефекта;
 короткое описание дефекта;
 кто сообщил о дефекте;
 дата и время, когда был обнаружен дефект;
 версия продукта, в которой обнаружен дефект;
 серьёзность (критичность) дефекта и приоритет решения;
 описание шагов для выявления дефекта (воспроизведения
неправильного поведения программы);
 ожидаемый результат и фактический результат;
 кто ответственен за устранение дефекта;
 обсуждение возможных решений и их последствий;
 текущее состояние (статус) дефекта;
 версия продукта, в которой дефект исправлен.
Кроме того, развитые системы предоставляют возможность
прикреплять файлы, помогающие описать проблему (например, дамп
памяти или скриншот).
Как правило, система отслеживания ошибок использует тот или
иной вариант «жизненного цикла» ошибки, стадия которого
определяется текущим состоянием, или статусом, в котором находится

17
ошибка. Основные пункты жизненного цикла дефекта были описаны в
главе 2.
Существует большое разнообразие bug traking систем, вот далеко
не полный их список:
Свободно распространяемые BTS (bug traking systems):
 Redmine;
 BUGS — the Bug Genie;
 Bugzilla;
 eTraxis;
 GNATS;
 Mantis bug tracking system;
 Trac;
 EmForge;
 Picket;
 Flyspray;
 DEVPROM.
Платные BTS (bug traking systems):
 Atlassian JIRA;
 Bontq;
 PVCS Tracker;
 Project Kaiser;
 TrackStudio Enterprise;
 YouTrack;
 ClearQuest.

18
 Список литературы

1. Ауэр, К. Экстремальное программирование: постановка процесса. С

первых шагов и до победного конца. Сер. Библиотека программиста / К.
Ауэр, Р. Миллер. – СПб. : Питер, 2004. – 368 с.
2. Блок-схема выбора оптимальной методологии разработки ПО
[Электронный ресурс]. – 2015. – Режим доступа
:http://megamozg.ru/post/23022/.
3. Керниган Б., Ритчи Д. Язык программирования Си. М.: Финансы и
статистика, 1992. – 272 с.
4. Браун, К. Быстрое тестирование / К. Браун, Р. Калбертсон, Г. Кобб. –
М. : Вильямс, 2002. – 384 с.
5. Вигерс, К. Разработка требований к программному обеспечению
(Software Re- quirements, Third Ed.) / К. Вигерс, Д. Битти. – 3-е изд. – M. :
Русская редакция, 2014. – 737c.
6. Дастин, Э. Автоматизированное тестирование программного
обеспечения / Э. Дастин, Д. Рэшка. – М. : Лори, 2005. – 592 с.
7. Канер, С. Тестирование программного обеспечения.
Фундаментальные кон- цепции менеджмента бизнес-приложений / С. Канер,
Д. Фолк, Е. К. Нгуен. – Ярославль : ДиаСофт, 2001. – 538 с.
8. Котляров, В. П. Основы тестирования программного
обеспечения / В. П. Котляров. – М. : «Интернет-университет
информационных технологий ИНТУИТ.ру, 2006. – 285 с.

19