作者|孙敏
Bug是项目过程中的一个有价值的虫子，它不只是给开发的，而是开给整个项目组的。
通过Bug我们能获得什么？
积累测试方法，增强QA的测试能力，提升产品质量
发现项目过程中的问题，推动优化解决问题；以及可以用来侧面验证流程优化是否有效
提高开发的编码能力，做到Bug预防
项目过程中不可能没Bug，但是我们要利用已有Bug减少未来Bug数，提高产品质量。
Bug本身的信息
标题、描述（操作步骤、预期结果、实际结果、截图等附加信息、环境）、创建人、修复人、创建日期、修复日期、关闭日期、优先级、严重程度、解决方法、状态、重新打开次数、所属需求等
Bug产生的阶段
接口测试、冒烟测试、功能阶段、UI+PM体验、集中测试、上线发版后
Bug与所属需求的一些case情况等，都可以组合用来分析
Bug规范
要做Bug分析，必须有一个统一的规范，才能得出更准确的数据
Bu*生阶段的划分
在转转，开发提测后，QA测试的流程是接口测试、冒烟测试、功能/专项测试、UI+PM体验、server上线、集中测试、回归测试、发版
Bug贯穿在提测到上线后，按照阶段来看主要产生在接口测试、冒烟测试、功能测试、集中测试，以及少部分在上线后被发现
为了方便后期生成自动分析图标，可以定一些开Bug的规范来标识Bug阶段，比如利用好Bug标题
Bug解决方案
解决方案要与RD协商好，得到RD的认可才可以
成员需要了解每种解决方案对应的意义是什么
解决方案并不是一成不变的，根据需要可以增加或调整，但要避免过度添加
目前我们的解决方案如下：
编码错误
需求变更
环境配置：因为环境问题，或配置中心配置错误导致的Bug
需求/UI设计缺陷：需求或UI设计不合理，或小细节设计缺失
不是BUG ：非Bug，RD不需要更改任何的配置或代码
重复BUG ：同一个问题，提了多个(不同现象算不同问题)
无法重现
历史遗留：历史版本就存在的问题
以后解决：当前版本不解决，下个版本再解决
兼容性
第三方依赖：非组内代码调用
实现与文档不符：功能实现与文档不一致（漏需求等）
技术方案设计不足：代码设计有问题
其中历史遗留，需求/UI设计缺陷，环境配置就是在项目过程中衍生出的解决方案；并且在项目中明确了重复BUG和以后解决的定义。
更合理的解决方案，有助于更好的分析Bu*生的原因，当这些问题都解决后，Bug自然也就可以减少了。
Bug等级
1、Bug等级有两个层面：优先级和严重程度
2、优先级根据Bug紧急程度分为：高、中、低
3、Bug严重程度分为：致命、严重、一般、提示、建议
按迭代分析Bug严重程度，可以看出版本的提测质量
按人分析它所有Bug的严重程度占比，长期以往，如果一个人的Bug总是严重Bug较多，也能侧面反映出一个人的代码质量且严重程度高的BUG也有更高的单独分析价值，可以积累更多的测试经验
从QA角度
1、 接口测试质量
想要了解一个接口测试情况，可以通过Bug按创建人统计接口漏测率
2、 功能测试质量
漏测越少，测试质量相对于越高
集中测试Bug+线上Bug：这些都是在QA自己功能测试完成后发现的，其实都属于QA漏测，需要进一步分析一下这些BUG的产生原因，尽量避免
3、工作量大小
Bug数虽然不能完全代表工作量，但是如果加上case数做对比，那一定程度可以标识一个人的工作量，并且也可以看出一个人的测试详尽程度
4、提Bug的有效性
Bug越精准越好，那反过来说，如果QA不是Bug数量占比越少，那也就说明他开出的Bug有效性越高
QA开出的Bug不一定都是有效的，但是应尽量减少其占比，可以适当提高定位问题的能力，Bug开的更精准
另外通过这些Bug分析是不是隐藏了一些其他问题？比如我们引入的环境配置，就是从不是Bug中拆离出来的，更合理的解决方案才更易于分析问题。
从RD角度
1、 开发的提测质量
冒烟通过率能够反应出RD的提测质量
转转提测要求：冒烟通过率100%，但是偶尔会有部分需求冒烟通过率只到了90%。那就需要去分析没通过冒烟的原因：是RD开发时间太紧没有review代码？自测没过冒烟case？还是server端接口提测质量差，导致没时间联调？
2、 开发的代码质量
Bug数结合需求大小，以及通过Android和iOS两端做对比
Bug的严重程度也是一个可参考的点
Bug还有一个叫做重新打开次数的属性，这个可以看出RD解决问题的能力，如果一个RD解决的Bug总是被重新打开，一定程度上反应了RD的不细心和态度问题
从产品/UI角度
1、产品/UI的需求设计是否合理；
2、需求是否经常变更；
需求变动，需求/UI设计不合理，这两个都可以通过Bug解决方案进行分析，大致推算出一个PM需求质量
从项目角度
1、Bug创建及修复情况
根据每日创建和每日解决Bug数的曲线，来查看QA测试情况，以及RD解决Bug是否及时
例如下图：
分析：
配合排期看，QA介入功能测试时间为3月22日，22日那天也确实是一个创建Bug的高峰，但是26还有一个凸起，这天是集中测试，集中测试当天有这么多Bug就需要分析为什么会有这么多问题前期没发现？
RD解决Bug曲线27日解决的Bug较少，理论集测当天后需要Bug清0，需要看一下是什么原因没有Bug清0？
2、针对解决方案进行分析
Bug规范的部分讲了，每个解决方案都对应一个意义。如果项目中某项解决方案占比较高，可以看下是为什么，以及考虑一下怎么减少这些Bug？
比如下图，除了编码错误的，不是Bug以及设计缺陷的Bug占比较高。
3、验证一些提升效率的手段是否有效
项目中遇到问题，会涉及一些流程改进，有些改进通过Bug信息可以分析。
比如分批提测，参考下图，RD正式的提测时间为12月27日，但是因为在开发阶段引入了分批提测，一部分Bug在正式提测前就已经暴露出来了，问题越早暴露解决成本越低。
按单个Bug分析
Bug众多，每个都分析具体产生原因，花费精力大。可以挑选一部分进行分析
不易于发现的（不保留后台活动）
有通用代表性的
线上问题
接口漏测
集成阶段发现的问题
解决方案为不是Bug的
Bug分析需要找到Bu*生的根本原因，多问多想，避免下次出现同样的问题；积累case模板以及测试方法。例如以前出现过配置项配置错误时，app没兼容好的线上问题，那通过这个Bug进行思考，配置类其实应该多考虑各种异常情况，考虑native的健壮性，通过这个问题后期我们也积累了配置类相关的测试case。
历史Bug分析
当数据积累多了，我们就有多个迭代的数据进行综合分析了
1、针对某个RD的历史解决方案占比
2、 某个RD的Bug数排名，需要和case数相比较
3、 某个QA接口漏测率、集测Bug占比Bug总数，不是Bug占比
4、需求变更最多的PM
通过这些累积的数据，可以分析一个RD的开发质量，一个QA的测试质量，以及可以根据数据，推断出一个RD容易出问题的功能点，做到Bug预测；同时通过分析各种问题产生的原因，做业务积累，让RD和QA同时受益。
Bug的数据有很多，纯靠人工去分析工作量太大，需要借助一些工具进行分析。
各个公司管理Bug的工具不一样，但是都大同小异。第三方的缺陷管理有一定的报表功能，但是不一定能满足自己的需求，如果不易扩展也不能推动第三方去完成我们的需求，可以考虑自己将Bug数据存储下来。同时存储需求下的Bug、case，以及需求的开发人员，测试人员等信息，结合定义的Bug规范，自动生成分析图表。
将这些数据存储到数据库中，长期的统计分析总结，将获得一个良好的收益。
- To Be Continued -
