缺陷的处理过程(生命周期)

步骤 1: 测试人员填写<<缺陷报告>>提交给开发经理,此时缺陷状态为: new
步骤 2: 开发经理要验证缺陷:
	情况1:验证确认是缺陷,那么开发经理要激活缺陷(将状态设置open) 并将缺陷指派给相应的开发人员
	情况2:如果验证不是缺陷,那么开发经理会拒绝缺陷(将状态设置为:rejected).
		扩展:如何处理被拒绝的缺陷?
		  首先确认是否由于自己的操作失误或配置问题造成了假缺陷
		  还要分析缺陷被拒绝的原因:如果是需求理解不一致,可以通过产品部门确认;如果是缺陷不可重现等要与开发方充分沟通,尽可能重现缺陷.
		  最后如果还不能确认,可以反馈给测试组长或者经理进一步沟通讨论.
	    通过上述的沟通,最终确认:如果是缺陷,那么谁拒绝的谁负责重新激活缺陷,重新回到缺陷处理流程. 
		  	如果是假缺陷,那么由测试人员(或者测试组长)将缺陷关闭.
步骤 3: 开发人员修改缺陷,修改完成后,将缺陷设置为: fixed
步骤 4: 测试人员反反测修改的缺陷,
	情况1:反测通过,测试人员将缺陷关闭(closed)
	情况2:反测失败,测试人员将缺陷重新激活(reopen),开发人员重新修改缺陷,知道反测通过,缺陷关闭为止.

问题:

1.常规的缺陷处理过程
New->open->fixed->closed
2.带有返测失败的缺陷处理过程?(反测失败一次)
New->open->fixed->reopen->fixed->closed
3.被拒绝的缺陷处理过程?
	真bug
		New->rejected->open->fixed->closed
	假bug
		New->rejected->closed

缺陷报告
1.定义

发现缺陷,用缺陷报告记录缺陷->将缺陷报告提交给开发方,并跟踪和管理缺陷.缺陷报告是测试人员和开发人员之间重要的沟通工具.

2.缺陷报告的主要组成部分:

	1.缺陷编号(defect id)
	2.标题(summary)
	3.发现者(detected by)
	4.日期(datected on date)
	5.指派给(assigned to)
		测试人员->开发经理->开发人员
	6.功能模块(subject)
	7.版本(detected in release/version)
	8.缺陷的状态(status)
	9.缺陷的严重程度(severity)
			级别:
					urgent 致命的
					Very high 非常严重的
					High 严重
					Medium 一般的
					Low 小问题

缺陷报告的用途

1.记录缺陷
2.跟踪和管理缺陷
3.可以更容易地实现对缺陷的分类，统计和总结

如何识别缺陷？

1.参考需求-与需求不符的就是缺陷
2.与测试人员，开发人员，客户等沟通 
3.参考测试用例的预期结果，当实际结果与预期结果不一致就是bug
4.参考缺陷定义