公司中的BUG管理系统用的是 Bugzilla.
这个管理系统非常不错。但是全是英文版，初学者对更改哪个状态不了解，如果造成不必要的麻烦。下面简单介绍下Bugzilla中的所有状态。 “状态”和”解决”域定义并且跟踪了bug的生命周期。
| 状态 | 说明 |
|---|---|
| UNCONFIRMED | 没有人确认这个bug需要被解决。有正确权限的用户可以确认这个bug,把它的状态改成”NEW”。bug经常直接被解决并被标志成”RESOVLED”,但是通常的情况是bug需要先被指定这个bug的属主开发人员确认。 |
| NEW | bug已经被加入到属主的bug列表中,必须被处理。在这种状态下的bug即将被接受且被标志成”ASSIGNED”,或者是传递给另外某一个人员,期间把bug状态维持在NE,或者是直接被解决,并标志成”RESOLVED”。 |
| ASSIGNED | 这个状态下的bug还没有被解决,但是已经指派给可以解决它的人员。从这一步往下,bug可以被指派给另一个人员,并标志成NEW,或者是直接解决bug,标志成”RESOLVED”。 |
| REOPENED | bug曾经被解决,但是解决方案被认为是不正确的。从这一步往下,bug可以被标志成ASSIGNED和RESOLVED。 |
| RESOLVED | bug的解决方案已经形成,在等待QA的验证。从这一步往下,bug可以被标志成”REOPENED”,或者是”VERIFIED”,或者是被认为很好的解决了,标志成”CLOSED”。 |
| VERIFIED | QA已经查看过bug的解决方案,并且同意针对bug已经做出的修改。 |
| CLOSED | bug已经被解决,解决方案是被认为是正确的。 |
| 解决 | 说明 |
|---|---|
| FIXED | 对bug的一个修改已经被登记,并且已经经过测试。 |
| INVALID | 被描述的问题不是一个bug。 |
| WONTFIX | 被描述的问题是一个bug,但是不准备进行修改。 |
| LATER | 被描述的问题是一个bug,但是不在产品的目前版本中进行修改。 |
| REMIND | 被描述的问题是一个bug,但是很可能不在产品的目前版本中进行修改,但可能还是问题 |
| DUPLICATE | 提出的问题和当前已经存在的某个bug重复。 |
| WORKSFORME | 不能重现这个bug,查看源代码也不知道为什么会出现这样的bug 现象,如果以后有更多的关于这个bug的线索,重新接受这个bug。 |
Speak Your Mind