---
title: 缺陷的生命周期
date: 2020-06-29 22:06:23
tags: [缺陷的生命周期]
categories: [质量体系]
author: Anges黎梦
sticky: 1
---

## 什么是软件缺陷？

软件缺陷（Defect），常常又被叫做Bug。

所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

IEEE729-1983对缺陷有一个标准的定义：

- 从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；

- 从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。


## 缺陷属性

1. 缺陷标识(Identifier)： 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。

2. 缺陷类型 (Type)： 缺陷类型是根据缺陷的自然属性划分的缺陷种类。

3. 缺陷严重程度 (Severity) ：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

4. 缺陷优先级(Priority)： 缺陷的优先级指缺陷必须被修复的紧急程度。

5. 缺陷状态(Status) ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

6. 缺陷起源(Origin) ：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。

7. 缺陷来源(Source)： 缺陷来源指引起缺陷的起因。

8. 缺陷根源(Root Cause)： 缺陷根源指发生错误的根本因素。

## 缺陷类型（Type）

F- Function ：影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。

A- Assignment： 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。

I- Interface： 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。

C- Checking： 提示的错误信息，不适当的数据验证等缺陷。

B Build/package/merge ：由于配置库、变更管理或版本控制引起的错误。

D- Documentation： 影响发布和维护，包括注释。

G- Algorithm ：算法错误。

U-User Interface：人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。

P-Performance：不满足系统可测量的属性值，如：执行时间，事务处理速率等。

N-Norms：不符合各种标准的要求，如编码标准、设计符号等。

## 缺陷严重程度（Severity）

**软件测试错误严重程度**

1. Critical：不能执行正常工作功能或重要功能。或者危及人身安全。

2. Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）

3. Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）

4. Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

5. Other：其它错误。

**同行评审错误严重程度**

1. Major：主要的，较大的缺陷

2. Minor：次要的，小的缺陷

## 缺陷优先级（Priority）

1. Resolve Immediately：缺陷必须被立即解决。

2. Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。

3. Not Urgent：缺陷可以在方便时被纠正。

## 缺陷状态（Status）

1. Submitted: 已提交的缺陷

2. Open :确认“提交的缺陷”，等待处理

3. Rejected: 拒绝“提交的缺陷”，不需要修复或不是缺陷

4. Resolved :缺陷被修复

5. Closed :确认被修复的缺陷，将其关闭

这里根据不同公司需求的不同，其实还有几个细节状态：

6. Verified :已验证修复的缺陷，等待上线。

7. Hang : 挂起，暂时不予处理的缺陷

## 缺陷起源（Origin）

1. Requirement：在需求阶段发现的缺陷

2. Architecture：在构架阶段发现的缺陷

3. Design：在设计阶段发现的缺陷

4. Code：在编码阶段发现的缺陷

5. Test：在测试阶段发现的缺陷

## 缺陷来源（Source）

1. Requirement： 由于需求的问题引起的缺陷

2. Architecture： 由于构架的问题引起的缺陷

3. Design： 由于设计的问题引起的缺陷

4. Code： 由于编码的问题引起的缺陷

5. Test： 由于测试的问题引起的缺陷

6. Integration： 由于集成的问题引起的缺陷

## 生命周期

在很多公司的流程里，其实是这样的一个流程。

缺陷提交 -> 确认缺陷 -> 已拒绝 -> 关闭或重新打开

缺陷提交 -> 确认缺陷 -> 缺陷修复 -> 缺陷已验证 -> 关闭（缺陷已上线）

而这个流程，通常被称为缺陷的生命周期。

### 提交（打开）缺陷

　　在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
　　当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
　　如果是回归不通过的缺陷，其状态又会变为打开状态。
 
### 分配（转交）缺陷

　　这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
　　有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
　　也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
 
### 确认缺陷

　　当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
 
### 挂起

　　在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
 
### 修复缺陷

　　开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
 
### 回归缺陷

　　回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。

　　确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。

　　确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。

　　确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
 
### 关闭缺陷

　　对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。