发表于：2018-10-06 作者：smartkeyi 来源：简书

　　提起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
　　规则是死的，人是活的，相信总能在相互磨合中找到最适合团队的工作方式，工作重要，开心更重要啊！