1.new/confirmed
测试人员将Bug提交给任务分发人员（研发模块负责人），

此时Bug状态为new/confirmed，开始Bug的生命周期，如果测试人员知道具体负责的研发人员，也可以直接指定，在Assign To项目中输入具体负责的研发人员Email.研发人员接收到Bug，经过分析，不属于自己负责的范围，如果知道谁应该负责，可以在Assigned To项目旁点击edit,直接输入被指定人的Email，将Bug转移给其他研发人员.

2.RESOLVED DUPLICATE

研发人员接收分配给自己的Bug后，在当前项目的Bug List中查看该Bug是否与之前的Bug重复，若重复，将新Bug置为RESOLVED DUPLICATE状态，并在Commnet中注明与哪个Bug重复。在Assigned To项目旁点击edit,直接测试人员的Email，将Bug转移给测试人员。测试人员确认重复后将bug置为VERIFIED DUPLICATE。如果没有重复则在Commnet标明原因，将bug置为bug置为UNCONFIRMED，在Assigned To项目旁点击edit,直接研发人员的Email，将Bug转移给研发人员。

3.RESOLVED INVALID

研发人员对于没有重复的Bug进行修复，经过分析，如果Bug是因为在错误的环境下产生或由于错误操作导致或由于测试人员错误理解而产生，属于无效Bug，将Bug置为RESOLVED INVALID状态，并在Commnet中注明置为无效的原因。Assigned To项目旁点击edit,直接输入产品人员的Email，将Bug转移给产品人员去确认，产品人员确认后在Commnet中注明是否真正是无效的bug如果是无效则在Assigned To项目旁点击edit,直接输入提交bug的测试人员的Email，将Bug转移给测试人员。如果需要修复则把bug置为UNCONFIRMED，在Assigned To项目旁点击edit,直接研发人员的Email，将Bug转移给研发人员。如果不需要修复，测试人员接收到bug后将bug置为VERIFIED INVALID。

4.RESOLVED WONTFIX

研发人员对于没有重复的有效Bug进行修复，经过分析，不在产品需求范围内，而且在可预见的未来内也不会提供该功能，将Bug置为WONTFIX状态，并在Commnet中注明置为WONTFIX的原因。Assigned To项目旁点击edit,直接输入产品人员的Email，将Bug转移给产品人员去确认，产品人员确认后在Commnet中注明是否真正是无效的bug。如果是无效则在Assigned To项目旁点击edit,直接输入提交bug的测试人员的Email，将Bug转移给测试人员。如果需要修复则把bug置为UNCONFIRMED，在Assigned To项目旁点击edit,直接研发人员的Email，将Bug转移给研发人员。如果不需要修复，测试人员将bug置为VERIFIED WONTFIX。


5.RESOLVED WORKSFORME

研发人员对于没有重复的有效Bug进行修复，按照Bug的步骤，多次验证，却无法重现该RESOLVED WORKSFORME，需要测试人员提供更多的信息，将bug置为RESOLVED WORKSFORME。在Assigned To项目旁点击edit,直接测试人员的Email，将Bug转移给测试人员。测试人员提供信息后把bug置为UNCONFIRMED，在Assigned To项目旁点击edit,直接研发人员的Email，将Bug转移给研发人员。


6.RESOLVED FIXED

研发人员对于没有重复的有效Bug进行修复，发现了产生Bug的原因，经过修改代码，能够消除该Bug，将Bug置为RESOLVED FIXED状态，并在Commnet中注明问题的原因、修复的方法，以便测试人员准确及时验证，将bug置为RESOLVED FIXED，在Assigned To项目旁点击edit,直接测试人员的Email，将Bug转移给测试人员

7.VERIFIED FIXE 

测试人员在处理RESOLVED FIXED的bug时，进行验证，如果发现该Bug已经不存在，将Bug置为VERIFIED FIXE状态，并在Commnet中注明验证通过的版本。如果没有验真通过需要修复则把bug置为UNCONFIRMED，在Assigned To项目旁点击edit,直接研发人员的Email，将Bug转移给研发人员

8.IN-PROGRESS
研发人员正在修复bug 可将bug状态置为IN-PROGRESS

bugzilla使用规范分享