提起Bug相信每个测试都不陌生，那么平常工作中都有哪些痛点呢？
比如提测质量不高，延期提测，bug反复出现， 开发对bug有异议，需求定义不清晰等等
那有什么好的解决方法呢？
我们组内结合开发的建议，提出了对bug进行更详细分类的方式，找出影响提测质量的关键类型bug，找出有异议的bug，找出需求不清晰的bug等，在一个迭代结束后拿来分析，挨个突破，提高整个团队的工作效率和质量。
一 Bug分类
上线前：
- 自测用例未通过
- 代码错误
- 需求不清晰
- 需求变更
- 测试遗漏
- 历史遗留
- 改动波及
- 覆盖升级
上线后：
- 线上故障-新增
- 生产环境Bug-新增
二 BUG 分类定义场景
【自测用例未通过 】定义场景：
自测用例里明确写明且没有争议的测试点
说明：开发提测就说明对测试点没有争议，有争议的测试点可以在自测时提出来讨论
【代码错误】定义场景：
和需求不一致，若无其它类型的原因，默认为代码错误
【需求不清晰】定义场景：
需求中没有具体定义
需求设计缺陷
需求理解存在二义性
说明：二义性的问题，在报bug的时候测试可能不知道与开发理解存在二义性，开发若有异议可以提出来，重新定义bug类型
【需求变更】定义场景：
产品需求移交后中途变更需求
说明：开发与测试获取的需求信息不一致时，测试报bug后若开发有异议，可重新定义bug类型
【测试遗漏】定义场景：
测试未测到或遗漏的bug
【历史遗留】定义场景：
之前版本已存在但未记录进禅道
【改动波及】定义场景：
开发重构时，改动影响到其它模块
改bug时，产生新的bug
【覆盖升级】定义场景：
因版本覆盖升级导致的bug
【线上故障】定义场景：
线上版本的影响主流程的bug
【生产环境bug】定义场景：
线上版本发现的不影响主流程的bug
三 Bug分析
什么样的Bug做为重点分析类型呢？
这个可以根据每个团队的不同来定义，但总体来说有以下几种建议：
从Bug整体入手：
- Bug整体数量和之前迭代的比较
- Bug类型所占的比例分析
- Bug严重程度所占的比例分析
- Bug激活次数分析
从单个Bug入手：
- 线上故障/Bug
- 严重程度为高的Bug
- 反复出现的Bug
- 典型Bug
- 特殊场景Bug
规则是死的，人是活的，相信总能在相互磨合中找到最适合团队的工作方式，工作重要，开心更重要啊！
希望大家每天都是开开心心工作，开开心心赚钱~~~
