个人觉得如果有专门的测试团队mantis才能发挥它的最大作用，如果是小团队或者抬头就能沟通的团队来说，只能发挥它30%的作用。初次使用mantis要学习一下，其中状态流程部分是都会碰到的。这里转载了一下状态流程的说明：

在 Mantis中的 问题状态一共有以下几种

1

0:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved,90:closed

10:新建,20:反馈,30:公认,40:已确认,50:已分派,80:已解决,90:已关闭

问题完成度有以下几种：

10:open,20:fixed,30:reopened,40:unable to reproduce,50:not fixable,60:duplicate,

70:no change required,80:suspended,90:won\'t fix

10:未处理,20:已修正,30:重新打开,40:无法重现,50:无法修复,60:重复问题,70:不是问题,

80:暂停,90:不做修改

可以在管理里面看到默认流程下的各种状态和完成度，一些基本的应该是这样吧：

角色有以下几种

报告人

修改人

测试人

审核人

流程1

报告–审核–修改–测试–关闭

一个问题来了以后，经过审核人审核，提出修改意见，然后指派给修改人员，

修改人员修改完成后指派测试人员，或者由审核人指派测试人员，测试完毕后关闭

如果有问题仍然存在，问题状态为反馈，完成度为 ，重新打开

过程               问题状态               完成度

新报告问题         新建                   未修改

审核后             已确认，已分派         未修改

修改后             已解决                 已修正，无法重现，重复问题，不是问题，暂停，不修改

测试后             已关闭，反馈           已修正，无法重现，重复问题，不是问题，暂停，不修改，重新打开

流程2

报告–审核–测试–关闭

当审核认为不需要修改的时候可以直接将问题分派给测试人员，由测试人员测试，

如果有问题仍然存在，问题状态为反馈，完成度为 ，重新打开

过程               问题状态               完成度

新报告问题         新建                   未修改

审核后             已确认，已分派         未修改，无法重现，重复问题，不是问题，暂停，不修改

测试后             已关闭，反馈           已修正，无法重现，重复问题，不是问题，暂停，不修改 ，重新打开

但是其中的公认是什么意思呢？在什么时候使用？

如果没有到最后也没有什么好的理解，我准备把这个状态更改为 “设计”

也就是说，一个问题需要重新更改设计，这个动作修改人是不能完成的，也就是所要增加一个角色“设计人员”

流程3

报告–审核–设计–审核–修改–测试–关闭

过程               问题状态               完成度

新报告问题         新建                   未修改

审核后             设计，已分派           未修改

设计后             已确认                 未修改

审核后             已确认，已分派         未修改

修改后             已解决                 已修正

测试后             已关闭，反馈           已修正，重新打开

一、New(新建) 状态说明： 

1. 测试人员发现bug，填写好bug report后通过“1”submit bug，此时bug的状态为new； 2. 处于new状态的bug，team leader认为是bug且需要修复的，通过“2”将bug分派给

相应的开发人员，此时bug的状态为assigned(分配状态)； 

3. 处于new状态的bug，team leader认为测试人员的bug描述不清或者有疑问，通过“3”

将bug反馈给测试人员，并在note里注明原因，此时bug的状态为confirmed（回馈状态）； 

4. 处于new状态的bug，team leader认为需要延后修复、需跟客户确认、不能修复的bug，

通过“4”将bug的状态更改为acknowledged（等待状态）。 

二、Assigned(已分派) 状态说明： 

5. 处于assigned状态的bug，开发人员将其修复后，通过“5”将bug的状态更改为resolved； 6. 处于assigned状态的bug，开发人员认为测试人员的bug描述不清或者有疑问，通过“6”

将bug反馈给测试人员，并在note里注明原因，此时bug的状态为confirmed； 7. 处于assigned状态的bug，开发人员认为需要延后修复、需跟客户确认、不能修复的bug，

通过“7”将bug的状态更改为acknowledged。 

三、Resolved(已解决) 状态说明： 

8. 处于resolved状态的bug，测试人员进行回归测试确认bug已经被修复后，通过“8”

将bug关闭，此时bug的状态为closed；  

9. 处于resolved状态的bug，测试人员进行回归测试发现bug没有修复或者由此引发了其

他的bug，通过“9”将bug反馈给开发人员，并在note里注明原因，此时bug的状态为feedback。 

四、Closed(已关闭) 状态说明： 

10. 处于closed状态的bug，若测试人员在测试过程中还发现该问题，可以通过“10” 将

bug反馈给开发人员，并在note里注明原因，此时bug的状态为feedback。 

五、Feedback(打回) 状态说明： 

11. 处于feedback状态的bug，开发人员将其修复后，通过“11”将bug的状态更改为resolved； 12. 处于feedback状态的bug，开发人员认为测试人员的bug描述不清或者有疑问，通过“12”

将bug反馈给测试人员，并在note里注明原因，此时bug的状态为confirmed； 13. 处于feedback状态的bug，team leader或者开发人员认为该bug需要重新分派，通过“13”

将bug重新分派给相应的开发人员，此时bug的状态为assigned； 

14. 处于feedback状态的bug，开发人员认为需要延后修复、需要跟客户确认、不能修复的

bug，通过“14”将bug的状态更改为acknowledged。 

六、Confirmed(已确认) 状态说明： 

15. 处于confirmed状态的bug，测试人员对于开发人员的疑问作出回应，通过“15”将bug

的状态更改为feedback，并在note里注明原因； 

16. 处于confirmed状态的bug，测试人员认为该bug有争议，需上一级领导确认的，通过

“16”将bug的状态更改为acknowledged； 

17. 处于confirmed状态的bug，测试人员认为该bug不需要修复，通过“17”将bug关闭，

此时bug的状态为closed。 

七、Acknowledged(公认) 状态说明： 

18. 处于acknowledged状态的bug，team leader或者测试人员认为该bug必须修复，通过“18”

重新将bug分派给相应的开发人员，此时bug的状态为assigned； 

19. 处于acknowledged状态的bug，team leader或者开发人员发现该bug已经修复了，通过

“19” 将bug的状态更改为resolved； 

20. 处于acknowledged状态的bug，测试人员认为该bug不需要修复，通过“20”将bug

关闭，此时bug的状态为closed

转载请注明：26点的博客 » 缺陷追踪系统mantis的状态流程说明