五、缺陷管理

1. 缺陷的定义

1. 错误：静态存在于文档说明中的表述或编写错误。
2. Bug：存在代码或硬件系统中的错误。Debug就是寻找错误
3. 缺陷：被测对象实际表现与用户的显性需求或隐性需求之间的差异，包含了错误和bug
   (1) 功能实现的错误
   (2) 功能实现的遗漏
   (3) 功能实现的多余
   (4) 功能实现不好
4. 失效：因缺陷激发或者导致的功能的异常，无法使用的现象

2. 缺陷的产生原因

1. 需求表述理解，编写过程中引起的错误
2. 系统设计架构引起的错误
3. 开发过程中缺乏有效的沟通和监督（Team）
4. 开发人员编码过程产生的错误
5. 软件开发工具本身的错误
6. 软件需求、复杂度越来越高
7. 与用户需求不符合，即使本身不存在某种意义上的而缺陷

3. 缺陷严重度：表示软件缺陷所造成的危害的恶劣程度，一般分为5级
   

1. Fatal：致命的缺陷，造成系统或程序的崩溃、死机、系统悬挂，或造成数据丢失、主要功能丧失等。
2. Critical：严重的缺陷，主要指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。
3. Major：主要缺陷，虽然不影响系统的运行，但没有很好的实现功能，没有达到预期效果。比如提示信息不准确，或用户界面差，操作时间长等。
4. Minor：一些小问题，对功能几乎没有影响，产品及属性仍可使用。
5. Suggestion：一些友好的建议
   
   

4. 缺陷的优先级：表示修复缺陷的先后次序，一般用ABCD或者1234

1. A类：最高优先级：立即修复，停止进一步测试
2. B类：次高优先级：在产品发布之前必须修复
3. C类：中等优先级：如果时间允许应该修复
4. D类：最低优先级，可能会修复，但是也可以不修复

5. 严重性和优先级的关系

1. 一般情况下：严重程度高的缺陷优先级高
2. 特殊情况下：不成正比
3. 没有必然的联系，结合实际综合考虑

6. 缺陷的生命周期

7. 缺陷报告的格式，主要应该包括如下信息

1. 缺陷ID：用来唯一标识缺陷的字段，不可重复，不能复用
2. 概要描述：描述缺陷的表象或存在的形式，便于开发人员快速推测缺陷的产生原因
3. 发现人:缺陷的发现者，一般测试工程师，项目组其他人员，用户
4. 发现时间
5. 修复时间
6. 所属版本：为了统计不同版本的缺陷数量，以及确定测试版本的发布风险
7. 所属模块：缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从而合理利用资源
8. 缺陷状态
9. 缺陷的严重度：
10. 修复的优先级
11. 详细描述：对概要描述的补充，步骤，测试数据，操作顺序，当时物理环境
12. 下一步处理人

8. 缺陷管理的流程

1. 角色定义：定义管理流程中，所涉及到的角色，包括主要职责，工作内容。比如项目组里，包含测试工程师，测试经理，开发工程师，开发经理，项目经理。
2. 流程定义：定义流程所有角色所遵循的规则
   (1) 测试工程师发现并提交缺陷
   (2) 测试经理进行却笑的过滤
   (3) 测试经理将缺陷交给开发经理
   (4) 开发经理根据情况，分配开发人员修复缺陷
   (5) 开发工程师确认缺陷，如果是就修复，不是就拒绝，并说明理由
   (6) 如果缺陷修复了，测试人员要进行回归测试，如果回归测试发没有问题，close，如果有问题reopen
   (7) 如果出现矛盾，双方阐述理由，无法达成一致，项目经理协调处理。
3. 工具应该：
   (1) 开源：excel，bugfree
   (2) 商业：QC，禅道