写了一份bugzilla流程

1、测试人员发现错误后，判断属于哪个模块的问题，填写错误报告后，系统会自动通过Email通知评审人员或直接通知默认开发者。（注：在提交错误时，应选中发给某一组，否则所有人员都会看到该错误）

 

2、  评审人员根据具体情况，对错误重新分配。可有以下几个分类：

 

1确认是错误（Accept），2）需要及时改的功能性错误，3）不是错误，4）以后再修改的错误，5）无法重现的错误，6)重复的错误

 

对以上错误的处理是：

 

a)     1/2情况需要评审员首先确认错误（accept）或者重新分配错误给开发人员，

 

b)     3、4、5的情况评审员选择解决错误(resolve)，解决错误的类型分别对应：3、4、5。

 

c)     6的情况设成重复错误（duplicate），并填写与此重复错误的编号。

 

 

3、  开发者收到Email信息后，判断是否为自己的修改范围.
　 1） 若不是,重新reassigned分配给评审人员或应该分配的开发者。
　 2） 若是，选确认错误(Accept)，再进行进行处理，

 

3）  对已经进行处理过的错误，选中“已解决”并给出解决的途径。

 

4、  试人员查询开发者或评审员已修改（已解决）的错误，进行重新测试。（可创建附件）
　1） 经验证无误后，修改状态为VERIFIED（已验证）。待整个产品发布后，修改为CLOSED（关闭）。
　2） 还有问题，REOPENED（重新打开），状态重新变为“New"，    

 

5、 如果这个错误一周内一直没被处理过。bugzilla就会一直会发email给它的属主，直到采取行动。可以设定最迟采取行动的期限，比如说3天，系统默认为7天。

 

6、在产品发布前，需要确保所有的错误状态都是“已验证”（verified）

 

7、在产品发布时，将所有状态为“已验证”的错误进行关闭(close)。