184 lines
8.1 KiB
Markdown
184 lines
8.1 KiB
Markdown
---
|
||
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% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
|
||
|
||
### 回归缺陷
|
||
|
||
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
|
||
|
||
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
|
||
|
||
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
|
||
|
||
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
|
||
|
||
### 关闭缺陷
|
||
|
||
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
|