bug状态流程图和处理流程

千里

（一）：测试人员只要发现问题就立即新建一个Bug进行跟踪并指派给相关的开发小组长，设置缺陷状态为“New”。

（二）：开发组长分派缺陷

1.
开发小组长判断Bug属于某个特定的开发人员并指派给他处理，设置状态为“Assigned”。

2.
如果延期解决，要留下文字说明并置缺陷状态为“Confirmed”。

（三）：开发人员查询状态为“Assigned”的缺陷，做如下处理。

1.
如果是缺陷，则修改程序解决这个Bug并把Bug返回给当初的测试人员并置状态为“Resolved”

2.
如果分派错误，要留下文字说明并设置状态为“Feedback”。

3.
如果不能解决，要留下文字说明并保持缺陷为“Acknowledged”状态。

（四）：测试人员查询状态为“Resolved”的缺陷，验证缺陷是否已解决，做如下处理。

1.
如何解决了，就关闭这个Bug，置缺陷的状态为“Closed”。

2.
如果还能重现或者不同意开发人员的解决方法，返还给当初的开发人员做进一步调查处理，置状态为“Assigned”

（五）：测试组长可召集开发组长定期评审状态为"Feedback"和"Acknowledged"，做如下处理。

1.
如果组委会决定立即解决，则重新分派缺陷，置状态为"Assigned"

2.
如果组委会决定延期解决，则置状态为"Confirmed"。

（六）：当前版本的测试结束后测试组长可召集开发组长、产品人员开会评审状态为"Confirmed"，做如下处理。

1.
如果需要在下一版本修复，则重新激活此bug并将严重级别调高。

2.
如果评审决定不修复此缺陷，则直接关闭此bug。

（七）：对于认为不是bug的情况，开发可“Feedback”。然后进行步骤（五）去评审，如果此时仍然认为不是bug，就将bug状态置为“Confirmed”。最后进行步骤（六），如果此时仍然认为不是bug，则直接“Closed”。此流程略微长一点，但避免了开发单方面否定bug的权力。

xiaozuo1010

1.测试人员提交Bug入库，分配给相应的开发人员，经确认如果是缺陷，状态为Open。如果不是，则拒绝，设置为Declined状态。
2.开发人员查询状态为Open的Bug，修改后的缺陷则设置其状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
3.测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。 继续提交。
4.待所有的缺陷达到缺陷修复标准后，停止测试。

msnshow

看看这个