本文载自http://birtc.cnblogs.com/archive/2005/08/19/218446.html
在 Mantis中的 问题状态一共有以下几种
10: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

报告-审核-设计-审核-修改-测试-关闭
过程               问题状态               完成度
新报告问题         新建                   未修改
审核后             设计，已分派           未修改
设计后             已确认                 未修改
审核后             已确认，已分派         未修改
修改后             已解决                 已修正
测试后             已关闭，反馈           已修正，重新打开

Bug管理的流程和几个重点
The Last Day Of Summer
http://www.cnblogs.com/dahuzizyd/archive/2005/03/04/112566.aspx
前两天谈论的bug管理的问题，大家列举了很多bug跟踪软件，我觉得工具是一部分，但是主要还在bug管理的流程上。
在这些bug管理工具里，bug的一个最重要的属性就是“状态”，一般又有“新增（New或Active）”，“处理中（in progress）”，“已修正（Fixed）”，“重新打开（reopened）”，“关闭（Close）”等几个，这几个状态一看就很明白一个bug从发现到排除要走哪些流程：
1.测试人员发现bug，提交。bug状态为New
2.开发人员接收bug，bug状态为in Progress
3.开发人员修改完毕，提交，bug状态改为Fixed
4.测试人员针对开发人员作的修改，再次对bug进行测试，如果bug依然存在，就把bug状态置为reopened，流程到第二步重新开始，如果问题已经解决，就直接改为close，该bug的流程就走完了。

流程虽然简单，但是在实际使用中还是发现一些问题：
1.bug信息不全：
有的信息，比如项目，模块，指定处理人（也就是指派给谁处理）等，这些信息会用来作统计分析，哪个项目，哪个模块，谁的bug多，谁发现的bug多，谁改的bug多等，根据这些信息可以大致看出一个人的工作量和工作质量。所以不要嫌麻烦，把bug的信息写全些。
2.所提供的信息不准确：
有的bug描述一带而过，表述含糊不清，只是说出现了错误，但是错误的现象是什么，提示信息是什么，怎么操作才出现的，都不清楚，这样的bug交给开发人员，只会给开发人员增加负担，因为他自己还要再作测试，以发现更多的信息，去排除bug，或者他会到测试那边其讨论，询问详情，有时要多次反馈才能确定到底是什么问题。
3.开发人员关闭bug：
只有bug的提交人（也就是发现人）才能去关闭该bug，开发人员只能使用两个状态：“处理中”和“已修正”
4.bug的可重现性：
这个重要的属性是在bug管理软件中无法体现和度量的， 这个任务主要都在测试这边，如果你发现了一个bug，赶紧把开发人员叫过来，人家来了，你要给他看看这个bug，可是却怎么也不出现了，连自己都不知道这个bug是怎样操作后才出现的。这样不能重现的bug几乎就不能算作bug，也是最让人头疼的问题。那么作为测试人员，你的任务就是要尽可能的找到bug出现的规律，尝试各种可能，即使不能重现，起码也要让开发人员知道你已经作了哪些尝试，而他不必再去走弯路。