【APP】Bug分类与分析

提起Bug相信每个测试都不陌生，那么平常工作中都有哪些痛点呢？
比如提测质量不高，延期提测，bug反复出现，开发对bug有异议，需求定义不清晰等等

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

上线前：

上线后：

【自测用例未通过】定义场景：
自测用例里明确写明且没有争议的测试点
说明：开发提测就说明对测试点没有争议，有争议的测试点可以在自测时提出来讨论

【代码错误】定义场景：
和需求不一致，若无其它类型的原因，默认为代码错误

【需求不清晰】定义场景：
需求中没有具体定义
需求设计缺陷
需求理解存在二义性
说明：二义性的问题，在报bug的时候测试可能不知道与开发理解存在二义性，开发若有异议可以提出来，重新定义bug类型

【需求变更】定义场景：
产品需求移交后中途变更需求
说明：开发与测试获取的需求信息不一致时，测试报bug后若开发有异议，可重新定义bug类型

【测试遗漏】定义场景：
测试未测到或遗漏的bug

【历史遗留】定义场景：
之前版本已存在但未记录进禅道

【改动波及】定义场景：
开发重构时，改动影响到其它模块
改bug时，产生新的bug

【覆盖升级】定义场景：
因版本覆盖升级导致的bug

【线上故障】定义场景：
线上版本的影响主流程的bug

【生产环境bug】定义场景：
线上版本发现的不影响主流程的bug

什么样的Bug做为重点分析类型呢？
这个可以根据每个团队的不同来定义，但总体来说有以下几种建议：

从Bug整体入手：

从单个Bug入手：

规则是死的，人是活的，相信总能在相互磨合中找到最适合团队的工作方式，工作重要，开心更重要啊！
希望大家每天都是开开心心工作，开开心心赚钱~~~