提起Bug相信每个测试都不陌生，那么平常工作中都有哪些痛点呢？

　　比如提测质量不高，延期提测，bug反复出现， 开发对bug有异议，需求定义不清晰等等

　　那有什么好的解决方法呢？

　　我们组内结合开发的建议，提出了对bug进行更详细分类的方式，找出影响提测质量的关键类型bug，找出有异议的bug，找出需求不清晰的bug等，在一个迭代结束后拿来分析，挨个突破，提高整个团队的工作效率和质量。

　　一 Bug分类

　　上线前：

　　1.自测用例未通过

　　2.代码错误

　　3.需求不清晰

　　4.需求变更

　　5.测试遗漏

　　6.历史遗留

　　7.改动波及

　　8.覆盖升级

　　上线后：

　　线上故障-新增

　　生产环境Bug-新增

　　二 BUG 分类定义场景

　　【自测用例未通过 】定义场景：

　　自测用例里明确写明且没有争议的测试点

　　说明：开发提测就说明对测试点没有争议，有争议的测试点可以在自测时提出来讨论

　　【代码错误】定义场景：

　　和需求不一致，若无其它类型的原因，默认为代码错误

　　【需求不清晰】定义场景：

　　需求中没有具体定义

　　需求设计缺陷

　　需求理解存在二义性

　　说明：二义性的问题，在报bug的时候测试可能不知道与开发理解存在二义性，开发若有异议可以提出来，重新定义bug类型

　　【需求变更】定义场景：

　　产品需求移交后中途变更需求

　　说明：开发与测试获取的需求信息不一致时，测试报bug后若开发有异议，可重新定义bug类型

　　【测试遗漏】定义场景：

　　测试未测到或遗漏的bug

　　【历史遗留】定义场景：

　　之前版本已存在但未记录进禅道

　　【改动波及】定义场景：

　　开发重构时，改动影响到其它模块

　　改bug时，产生新的bug

　　【覆盖升级】定义场景：

　　因版本覆盖升级导致的bug

　　【线上故障】定义场景：

　　线上版本的影响主流程的bug

　　【生产环境bug】定义场景：

　　线上版本发现的不影响主流程的bug

　　三 Bug分析

　　什么样的Bug做为重点分析类型呢？

　　这个可以根据每个团队的不同来定义，但总体来说有以下几种建议：

　　从Bug整体入手：

　　1.Bug整体数量和之前迭代的比较

　　2.Bug类型所占的比例分析

　　3.Bug严重程度所占的比例分析

　　4.Bug激活次数分析

　　5.从单个Bug入手：

　　6.线上故障/Bug

　　7.严重程度为高的Bug

　　8.反复出现的Bug

　　9.典型Bug

　　10.特殊场景Bug

　　规则是死的，人是活的，相信总能在相互磨合中找到最适合团队的工作方式，工作重要，开心更重要啊！