五、缺陷管理
1. 缺陷的定义
- 错误:静态存在于文档说明中的表述或编写错误。
- Bug:存在代码或硬件系统中的错误。Debug就是寻找错误
- 缺陷:被测对象实际表现与用户的显性需求或隐性需求之间的差异,包含了错误和bug
(1) 功能实现的错误
(2) 功能实现的遗漏
(3) 功能实现的多余
(4) 功能实现不好 - 失效:因缺陷激发或者导致的功能的异常,无法使用的现象
2. 缺陷的产生原因
- 需求表述理解,编写过程中引起的错误
- 系统设计架构引起的错误
- 开发过程中缺乏有效的沟通和监督(Team)
- 开发人员编码过程产生的错误
- 软件开发工具本身的错误
- 软件需求、复杂度越来越高
- 与用户需求不符合,即使本身不存在某种意义上的而缺陷
- 缺陷严重度:表示软件缺陷所造成的危害的恶劣程度,一般分为5级
- Fatal:致命的缺陷,造成系统或程序的崩溃、死机、系统悬挂,或造成数据丢失、主要功能丧失等。
- Critical:严重的缺陷,主要指功能或特性没有实现,主要功能部分丧失,次要功能完全丧失,或致命的错误声明。
- Major:主要缺陷,虽然不影响系统的运行,但没有很好的实现功能,没有达到预期效果。比如提示信息不准确,或用户界面差,操作时间长等。
- Minor:一些小问题,对功能几乎没有影响,产品及属性仍可使用。
- Suggestion:一些友好的建议
4. 缺陷的优先级:表示修复缺陷的先后次序,一般用ABCD或者1234
- A类:最高优先级:立即修复,停止进一步测试
- B类:次高优先级:在产品发布之前必须修复
- C类:中等优先级:如果时间允许应该修复
- D类:最低优先级,可能会修复,但是也可以不修复
5. 严重性和优先级的关系
- 一般情况下:严重程度高的缺陷优先级高
- 特殊情况下:不成正比
- 没有必然的联系,结合实际综合考虑
6. 缺陷的生命周期
7. 缺陷报告的格式,主要应该包括如下信息
- 缺陷ID:用来唯一标识缺陷的字段,不可重复,不能复用
- 概要描述:描述缺陷的表象或存在的形式,便于开发人员快速推测缺陷的产生原因
- 发现人:缺陷的发现者,一般测试工程师,项目组其他人员,用户
- 发现时间
- 修复时间
- 所属版本:为了统计不同版本的缺陷数量,以及确定测试版本的发布风险
- 所属模块:缺陷所在的功能或业务模块,便于后期统计每个功能或业务模块的缺陷分布情况,从而合理利用资源
- 缺陷状态
- 缺陷的严重度:
- 修复的优先级
- 详细描述:对概要描述的补充,步骤,测试数据,操作顺序,当时物理环境
- 下一步处理人
8. 缺陷管理的流程
- 角色定义:定义管理流程中,所涉及到的角色,包括主要职责,工作内容。比如项目组里,包含测试工程师,测试经理,开发工程师,开发经理,项目经理。
- 流程定义:定义流程所有角色所遵循的规则
(1) 测试工程师发现并提交缺陷
(2) 测试经理进行却笑的过滤
(3) 测试经理将缺陷交给开发经理
(4) 开发经理根据情况,分配开发人员修复缺陷
(5) 开发工程师确认缺陷,如果是就修复,不是就拒绝,并说明理由
(6) 如果缺陷修复了,测试人员要进行回归测试,如果回归测试发没有问题,close,如果有问题reopen
(7) 如果出现矛盾,双方阐述理由,无法达成一致,项目经理协调处理。 - 工具应该:
(1) 开源:excel,bugfree
(2) 商业:QC,禅道