缺陷管理流程，如图
流程说明：
1. 测试人员提交新的缺陷入库，此时缺陷处于**(Open)状态
注意：针对不可以重现的缺陷处理建议>>开发找不到原因的情况下，不进行处理，保留其状态为Open，并留下文字说明 (或者其它，如公司有自主研发的缺陷管理系统情况下)，测试对其进行监控一段时间，比如连续监控2个版本。过了这段监控期，还是没重现，开发可以视其为非缺陷并设置状态为Rejected，备注。测试人员对其进行关闭。
2. 开发人员判断是否是缺陷：
2.1 是缺陷，判断缺陷是否已经重复提交，如果已经提交则设置缺陷为拒绝状态，否则判断是否当前版本中修复：
2.1.1 当前版本中修复，设置状态为Fixed
2.1.2 延迟处理，下个版本中解决,设置状态为Delayed并留下文字说明
2.2 非缺陷，不转需求的情况下直接拒绝，设置状态为Rejected，测试人员对其再次验证，如果判断为缺陷，可以再次打开，此时为**状态（Open）
注意：有些提交的缺陷可能是建议类的，比界面颜色不好看或者布局不合理之类，对其是否是缺陷不好判断的情况下，开发可把这些转为需求，由相关需求人员进行处理(不接受，接受并进行需求变更等)。（这里某些缺陷管理工具比如禅道，转需求后是自动关闭缺陷的，虽然个人觉得比较合理的应该是谁开启谁关闭，但从效率的角度看似乎也合理，，不必要太追究了）。
3. 回归测试时，测试人员对状态为Fixed的缺陷，对其再次验证，如果通过则关闭，否则设置为拒绝Rejected状态。
4.除此之外，也有直接从closed状态直接打开，变为open的，个人感觉那个就是个特例，图中未体现。啥时候会用到呢？情况一：测试不小心把其设置为closed的，情况二：对某些类型的关注：如某些缺陷在上个版本中修复了，这个版本又出现了的情形
特别说明：
1.当开发人员定位到缺陷并不是他所负责程序模块引起时，建议直接把缺陷指派给相关人员。
2.上图是个人结合实际及相关资料整理的，总体遵循效率优先和实用性原则。每家公司都有自己的管理规范、流程，某些公司还有指定专门负责人如测试经理对缺陷进行审核，然后再进行分配。对比下，个人觉得由单个测试人员直接提交给单个开发人员更有效率。前者可能更权威就是，但是反过来想下，判断是否为缺陷，开发相对来说更有判断力，至于有歧义的缺陷，可由需求人员进行参与。
转载于:https://my.oschina.net/guyson/blog/318321