当前位置：首页> 正在进行安全检测...

正在进行安全检测...

时间：2023-11-14 02:02:59 下载该word文档

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给开发人员。

阅读全文