软件测试缺陷的定义、产生原因、缺陷报告格式、缺陷报告

软件缺陷的定义

错误

静态存在于说明文档中的表述或编码错误

缺陷

存在于代码中或硬件系统中的错误

BUG

被测对象实际表现与用户显性需求或隐性需求中的差异

• • • 功能实现错误
    • 功能实现遗漏
    • 功能实现多余
    • 功能实现不好

失效

因缺陷激发后导致功能的异常，无法使用的现象（动态的，不一定会发生）

缺陷产生的原因

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

缺陷的报告的书写格式

• 缺陷ID：用来唯一表示缺陷的字段，一般使用阿拉伯数字，缺陷ID不可重复，并且不可服用
• 概要描述：概括描述缺陷的表象或存在的形式，便于开发人员快速推测缺陷的产生原因
• 发现人：缺陷的发现人员一般为测试工程师，也有可能是项目的开发人员，如开发人员、项目经理、维护人员，甚至是客户
• 发现时间：缺陷发现的时间
• 修复时间：缺陷修复的时间
• 所属版本：发现缺陷的版本，便于后期统计不同版本之间发现的缺陷数量，以及确定测试版本的发布风险
• 所属模块：缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从而利于回归测试投入确定或研发资源分配
• 缺陷状态

缺陷所存在的状态，一般分为6种

new：缺陷尚未进入缺陷管理流程时，定义为new，如新发现或新提交的bug

open：经过确认后确认是BUG，缺陷正式进入管理流程，

fix：开发人员却认为BUG，并且做了修复活动，

ciose：缺陷经过校验，确认已被修复或无需处理

reject：开发人员需对open状态的BUG进行判断，如果确认是缺陷，则需要进行修复活动，如果因需求变化，设计变化等原因导致缺陷已经不存在，则可reject次缺陷

reopen：当以fix或close的缺陷未能成功修复或再次发生时再次打开

• 缺陷严重度

缺陷引发后果的严重程度

low：缺陷导致的后果不是很严重，一般而言，仅是使用户感觉使用不方便、界面不美观等感受

medium：一般的错别字，字体错误，显示错误，子功能实现错误或冗余

high：某个具体功能不能正常使用，如查询功能错误、排序功能错误等

very high：导致大面积功能无法使用

urgent：大面积功能不能使用，终止性错误、初始化错误

• 缺陷的优先级：有开发人员确认，决定缺陷修复的先后时间
• 详细描述：对概要描述的补充，说明缺陷产生的步骤，测试数据、系统的截图等等
• 下一步处理人：缺陷接下来由谁处理

缺陷的管理

 角色定义

定义管理流程中所涉及到的角色、主要职责、工作内容、范围等等

如测试工程师、测试经理、开发工程师、开发经理、项目经理

流程定义

定义流程中所有角色应遵守的规则

1. 测试工程师发现并提交BUG
2. 测试经理进行缺陷的过滤
   1. 缺陷描述是否正确
   2. 是否是因为对需求不理解而造成的误提交
   3. 描述中是否带有个人感情色彩的词语
   4. 缺陷定义级别是否定义合理

3.测试经理将缺陷指派给开发经理

4.开发经理将缺陷指派给响应的开发人员

5.开发工程师确认缺陷，如果是缺陷，则fix，如果不是缺陷，则reject并给出理由

6.如果缺陷状态为fix，则测试工程师进行确认活动，如果成功，则将缺陷状态改为close，如果没有fix，则将状态改为reopen

7.如果开发人员认为不是缺陷，测试人员应说明认为是缺陷的原因，如果意见不能一致，则由项目经理协调处理

工具应用

采用哪种缺陷管理工具，如开源（Bugzilla、jira、matins、Excel等）还是商业（QC/ALM、禅道等）

模型选择

• ODC 
• 四象限
• Gompertz