Bug处理的流程

Bug的常用状态：新建、确认、修正、拒绝、关闭、延期处理、重新打开、无法重现

新建：测试人员执行测试，如果发现测试问题，在系统中记录问题，此状态为“新建”

确认:开发人员确认测试提交的问题存在，如果存在，则已经分配给开发人员

修正：开发人员已经修改完成，记录问题产生的原因，将状态修改为“修正”，等待测试人员的验证

拒绝：开发认为测试提交的问题不存在或是描述不清晰拒绝修改这个bug

延期处理: 开发认为测试提交的问题，不在当前版本处理该bug，下一个版本修改

关闭:测试人员对开发已经修复的问题进行验证，如果测试通过，则修改此状态为“关闭”

重新打开：测试人员对开发已经修复的问题进行验证，如果测试不通过，则修改此状态为“重新打开”

无法重现：开发人员确认测试提交的问题存在，如果不存在，则说明原因，并将状态 “无法重现”

Bug优先级

Bug的优先级定义：

　1.极度重要：“停下其他事，马上修复此问题！！！！”    

  2.重要：“需要尽快解决。”

 3.一般：“快点修复，但如果不能马上解决也可以。”

 4.不重要：“如果有必要，这个问题可以推后处理。”

　5.极不重要：“这个想法或建议应该暂缓执行，以后再说。”

Bug的严重程度

严重错误：由于程序所引起的死机，非法退出，死循环导致数据库发生死锁，等等

较严重错误：功能不符，功能缺失、数据不能保存等等

一般性错误：删除操作未给提示，界面错误等等

较小错误：建议类，用户体验类的问题等等

Bug的判定原则

软件未达到软件产品规格说明书

软件出现软件产品规格说明书不一致功能

软件规格说明书中未提到的隐含需求

最终认为体验不好，软件易用性差

用户反馈的问题

Bug的书写原则

Bug的提交的信息必须完整，具体如下：

     a) 头信息包括：测试软件名称、版本号、严重程度、优先程度、测试平台、

缺陷或错误范围。要求填写真实、完整、准确。

 b) 简述是对缺陷或错误特征的简单描述，可以使用短语或短句，要求简练、

准确，并描述清楚正确的应该是怎么样的，现在有什么错误，以及出现几率。 

c) 操作步骤是描述该缺陷或错误出现的操作顺序，要求真实、完整、简洁、准确。

每一个步骤尽量只记录一个操作，结束时写上出现频率。

  d)  预期结果与实际结果，要求真实、完整、简洁、准确。

e) 注释一般是对缺陷或错误的附加描述。比如：问题的特征，问题的解决方案等等

f) 对于描述不清楚的问题，可以抓张图片说明，对于非必现的问题，需要

添加log附件。 

Bug的管理原则

Bug是可是再现的错误

Bug的验证必须由提交测试人验证

开发人员修复bug的过程，需要填写修改的原因,以及需要在那个版本上验证

对于有争议的bug,需要找第三方需求或是产品来进行确认

如果测试人员发现bug短期内无法修复，需要先与相关的人员沟通问题，以及需要汇报给领导，请领导一同商议解决策略

测试人员不能处理的bug，需要汇报给领导，请领导决策

对于无法重现的问题，需要单独记录文件表，进行后续跟踪

对于偶现的问题，需要在bug的结尾加上复现率
测试经理加强对bug的关注，对长时间没有处理的问题，应该进行关注以及跟踪