Bugzilla各种状态详细解释
1.NEW测试人员将Bug提交给任务分发人员（研发模块负责人），此时Bug状态为NEW，开始Bug的生命周期
如果测试人员知道具体负责的研发人员，也可以直接指定，在Assign To项目中输入具体负责的研发人员Email
2.ASSI
任务分发人员将Bug分发给指定研发人员时，将Bug置为ASSI状态，解决Bug的工作开始
3.Ressigned
研发人员接收到Bug，经过分析，不属于自己负责的范围，如果知道谁应该负责，可以在Assigned To项目旁点击edit,直接输入被指定人的Email，将Bug转移给其他研发人员
研发人员接收到Bug，经过分析，不属于自己负责的范围，如果不知道谁应该负责，将Bug退回给任务分发人员
（Bugzllia没有该状态，列在此处，只为研发人员处理不属于自己负责范围的Bug提供参考）
4.RESO DUPL
研发人员接收分配给自己的Bug后，在当前项目的Bug List中查看该Bug是否与之前的Bug重复，若重复，将新Bug置为RESO DUPL状态，并在Commnet中注明与哪个Bug重复
（部分研发人员将旧Bug置为RESO DUPL是错误的）
5.RESO INVA
研发人员对于没有重复的Bug进行修复，经过分析，如果Bug是因为在错误的环境下产生或由于错误操作导致或由于测试人员错误理解而产生，属于无效Bug，将Bug置为RESO INVA状态，并在Commnet中注明置为无效的原因
6.RESO LATE
研发人员对于没有重复的有效Bug进行修复，经过分析，如果当前版本无法修复，但在以后项目中或条件成熟时会修复，将Bug置为RESO LATE状态，并在Commnet中注明置为LATE的原因
（部分研发人员将此类Bug误置为RESO INVA是错误的）
7.RESO WONT
研发人员对于没有重复的有效Bug进行修复，经过分析，不在产品需求范围内，而且在可预见的未来内也不会提供该功能，将Bug置为RESO WONT状态，并在Commnet中注明置为WONT的原因
8.RESO WORK
研发人员对于没有重复的有效Bug进行修复，按照Bug的步骤，多次验证，却无法重现该Bug，需要测试人员再次发现该Bug时告知自己，以便查找原因时，将Bug置为RESO WORK状态
9.RESO FIXE
研发人员对于没有重复的有效Bug进行修复，发现了产生Bug的原因，经过修改代码，能够消除该Bug，将Bug置为RESO FIXE状态，并在Commnet中注明问题的原因、修复的方法和将在哪个版本中修复，以便测试人员准确及时验证
（部分研发人员只注明修复了Bug，但没有说明版本，或说明版本错误）
10.VERI FIXE
测试人员在处理RESO FIXE时，在指定的版本及以后的版本中进行验证，如果发现该Bug已经不存在，将Bug置为VERI FIXE状态，并在Commnet中注明验证通过的版本
11.REOP
测试人员在处理RESO FIXE时，在指定的版本及以后的版本中进行验证，如果发现该Bug仍存在，将Bug置为REOP状态，并在Commnet中注明重现该Bug的版本，补充必要的信息，需要研发人员继续查找原因，进一步修复Bug
测试人员在测试过程中，发现状态为VERI FIXE的Bug重现了，将Bug置为REOP状态，并在Commnet中注明重现该Bug的版本，补充必要的信息，需要研发人员继续查找原因，进一步修复Bug
测试人员在测试过程中，发现状态为CLOS的Bug重现了，操作同上
12.CLOS
测试人员在回归测试时，再次验证VERI FIXE状态的Bug，如果该Bug仍未重现，将该Bug置为CLOS状态，并在Commnet中注明最后验证的版本，至此Bug的生命周期结束
如果该项目后续版本中再出现该Bug时，需要REOP
以上的操作只在同一个项目中进行处理，不同项目的Bug不存在重复问题。
测试人员在提交Bug时，如果希望其他人也了解Bug的进展，可以在CC项中输入他们的Email
Bug已经提交后，如果希望其他人也了解Bug的进展，可以在CC List项中点击edit，添加他们的Email
支持分享
页:
[1]
