软件缺陷的定义
错误
静态存在于说明文档中的表述或编码错误
缺陷
存在于代码中或硬件系统中的错误
BUG
被测对象实际表现与用户显性需求或隐性需求中的差异
-
-
- 功能实现错误
- 功能实现遗漏
- 功能实现多余
- 功能实现不好
-
失效
因缺陷激发后导致功能的异常，无法使用的现象（动态的，不一定会发生）
缺陷产生的原因
- 需求表达理解、解码过程中一起的错误
- 系统设计架构引起的错误
- 开发过程中缺乏有效的沟通及监督
- 程序员编码过程产生的错误
- 软件开发工具本身的问题
- 软件需求、复杂度越来越高
- 与用户需求不符合，即使本身不存在某种意义上的错误
缺陷的报告的书写格式
- 缺陷ID：用来唯一表示缺陷的字段，一般使用阿拉伯数字，缺陷ID不可重复，并且不可服用
- 概要描述：概括描述缺陷的表象或存在的形式，便于开发人员快速推测缺陷的产生原因
- 发现人：缺陷的发现人员一般为测试工程师，也有可能是项目的开发人员，如开发人员、项目经理、维护人员，甚至是客户
- 发现时间：缺陷发现的时间
- 修复时间：缺陷修复的时间
- 所属版本：发现缺陷的版本，便于后期统计不同版本之间发现的缺陷数量，以及确定测试版本的发布风险
- 所属模块：缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从而利于回归测试投入确定或研发资源分配
- 缺陷状态
缺陷所存在的状态，一般分为6种
new：缺陷尚未进入缺陷管理流程时，定义为new，如新发现或新提交的bug
open：经过确认后确认是BUG，缺陷正式进入管理流程，
fix：开发人员却认为BUG，并且做了修复活动，
ciose：缺陷经过校验，确认已被修复或无需处理
reject：开发人员需对open状态的BUG进行判断，如果确认是缺陷，则需要进行修复活动，如果因需求变化，设计变化等原因导致缺陷已经不存在，则可reject次缺陷
reopen：当以fix或close的缺陷未能成功修复或再次发生时再次打开
- 缺陷严重度
缺陷引发后果的严重程度
low：缺陷导致的后果不是很严重，一般而言，仅是使用户感觉使用不方便、界面不美观等感受
medium：一般的错别字，字体错误，显示错误，子功能实现错误或冗余
high：某个具体功能不能正常使用，如查询功能错误、排序功能错误等
very high：导致大面积功能无法使用
urgent：大面积功能不能使用，终止性错误、初始化错误
- 缺陷的优先级：有开发人员确认，决定缺陷修复的先后时间
- 详细描述：对概要描述的补充，说明缺陷产生的步骤，测试数据、系统的截图等等
- 下一步处理人：缺陷接下来由谁处理
缺陷的管理
角色定义
定义管理流程中所涉及到的角色、主要职责、工作内容、范围等等
如测试工程师、测试经理、开发工程师、开发经理、项目经理
流程定义
定义流程中所有角色应遵守的规则
- 测试工程师发现并提交BUG
- 测试经理进行缺陷的过滤
- 缺陷描述是否正确
- 是否是因为对需求不理解而造成的误提交
- 描述中是否带有个人感情色彩的词语
- 缺陷定义级别是否定义合理
3.测试经理将缺陷指派给开发经理
4.开发经理将缺陷指派给响应的开发人员
5.开发工程师确认缺陷，如果是缺陷，则fix，如果不是缺陷，则reject并给出理由
6.如果缺陷状态为fix，则测试工程师进行确认活动，如果成功，则将缺陷状态改为close，如果没有fix，则将状态改为reopen
7.如果开发人员认为不是缺陷，测试人员应说明认为是缺陷的原因，如果意见不能一致，则由项目经理协调处理
工具应用
采用哪种缺陷管理工具，如开源（Bugzilla、jira、matins、Excel等）还是商业（QC/ALM、禅道等）
模型选择
- ODC
- 四象限
- Gompertz