bug处理流程

1、每一个Bug，开发在修复（Fixed）或者拒绝（Rejected）后，都需要给出一个注释，添加注释之前，需先点一下“添加注释”的按钮，如下图所示，这样添加注释人员的名字就会出现，否则，添加注释的人多了，不知道是谁写的。具体注释的内容（产生bug原因，修改的地方）是由各个组自己跟开发约定。

2、在Bug处理过程中，如果一个Bug开发方认为 A、当前不能做，或者需要延迟开发； B、就应该是这样的，不是Bug

遇到这两种情况时，Bug状态可以改为Rejected，同时需转发（Assigned&To）该Bug给项目经理进行确认，项目经理需要对此Bug做一个说明（加一个注释），测试人员根据项目经理的解释决定这个Bug的最终状态。

3、Bug状态的转换：以下几类问题不可以被Rejected回来，一旦发现开发把下列问题Rejected回来，我们不可以直接closed掉，要根据实际情况做出Reopen或Deferred处理。 1)、环境配置问题 2)、数据问题 3)、历史问题 4)、需求问题

只有因为我们理解的偏差导致的不需要任何修改，客观上本来就是正确的Bug

才可以直接closed掉。

4、Comment问题：除open和closed两种状态可以不加注释外，其它任何的状态改变都要加上注释说明。

5、Deferred问题处理：测试人员需评估deferred的风险，线下跟项目经理和项目测试负责人（或是导师）review。

a)几方讨论都同意deferred：QA应把bug指派给项目经理，项目经理在“Comment”中加上注释，对此bug的处理解决方案；然后ＱA把此bug为deferred状态，并说明。

b)几方讨论不同意deferred此bug：ＱＡ需reopen此bug给开发人员。 c)小需求中的bug要deferred，流程和处理方式同项目deferred处理。 d）项目结项后，项目组需要在2周内完成项目Deferred&Bug的修复计划，并按照计划进行修复；如果未能按照计划修复的Deferred&Bug按照Deferred&Bug处理流程处理。

6、Bug的生命周期，适时结束：当前问题解决后，适时将Bug&closed掉。由于当前这个Bug引起的其它问题，另设Bug去跟踪。Closed的Bug原则上不允许再Reopen出来。

7、开发在处理不了当前BUG或认为该BUG非自己所有时，可转给对应的开发或开发技术经理Assigned&to，但不能变更该BUG状态。由相应开发或技术经理去处理这个BUG。 8、关于bug指派问题

1）由于项目或小需求导致的bug&deferred的话直接指派给相应开发人员 2）如果是历史遗留问题可以找相应产品线的开发主管商量指派给谁

3)如果是需求有问题，开发已经开发了，我们跟需求确认是需求问题，我们把bug提给需求编写者，如果需求文档已经更新了（并通知了相关人员），该BUG还是提给开发人员。