Bug，项目过程中的重要数据

作者|孙敏

为什么要做Bug分析？

Bug是项目过程中的一个有价值的虫子，它不只是给开发的，而是开给整个项目组的。

通过Bug我们能获得什么？

• 积累测试方法，增强QA的测试能力，提升产品质量

• 发现项目过程中的问题，推动优化解决问题；以及可以用来侧面验证流程优化是否有效

• 提高开发的编码能力，做到Bug预防

项目过程中不可能没Bug，但是我们要利用已有Bug减少未来Bug数，提高产品质量。

Bug包含了哪些信息可以分析？

Bug本身的信息

• 标题、描述（操作步骤、预期结果、实际结果、截图等附加信息、环境）、创建人、修复人、创建日期、修复日期、关闭日期、优先级、严重程度、解决方法、状态、重新打开次数、所属需求等

Bug产生的阶段

• 接口测试、冒烟测试、功能阶段、UI+PM体验、集中测试、上线发版后

• Bug与所属需求的一些case情况等，都可以组合用来分析

Bug规范

• 要做Bug分析，必须有一个统一的规范，才能得出更准确的数据

Bug产生阶段的划分

• 在转转，开发提测后，QA测试的流程是接口测试、冒烟测试、功能/专项测试、UI+PM体验、server上线、集中测试、回归测试、发版

• Bug贯穿在提测到上线后，按照阶段来看主要产生在接口测试、冒烟测试、功能测试、集中测试，以及少部分在上线后被发现

• 为了方便后期生成自动分析图标，可以定一些开Bug的规范来标识Bug阶段，比如利用好Bug标题

Bug解决方案

• 解决方案要与RD协商好，得到RD的认可才可以

• 成员需要了解每种解决方案对应的意义是什么

• 解决方案并不是一成不变的，根据需要可以增加或调整，但要避免过度添加

目前我们的解决方案如下：

• 编码错误

• 需求变更

• 环境配置：因为环境问题，或配置中心配置错误导致的Bug

• 需求/UI设计缺陷：需求或UI设计不合理，或小细节设计缺失

• 不是BUG ：非Bug，RD不需要更改任何的配置或代码

• 重复BUG ：同一个问题，提了多个(不同现象算不同问题)

• 无法重现

• 历史遗留：历史版本就存在的问题

• 以后解决：当前版本不解决，下个版本再解决

• 兼容性

• 第三方依赖：非组内代码调用

• 实现与文档不符：功能实现与文档不一致（漏需求等）

• 技术方案设计不足：代码设计有问题

其中历史遗留，需求/UI设计缺陷，环境配置就是在项目过程中衍生出的解决方案；并且在项目中明确了重复BUG和以后解决的定义。

更合理的解决方案，有助于更好的分析Bug产生的原因，当这些问题都解决后，Bug自然也就可以减少了。

Bug等级

1、Bug等级有两个层面：优先级和严重程度

2、优先级根据Bug紧急程度分为：高、中、低

3、Bug严重程度分为：致命、严重、一般、提示、建议

• 按迭代分析Bug严重程度，可以看出版本的提测质量

• 按人分析它所有Bug的严重程度占比，长期以往，如果一个人的Bug总是严重Bug较多，也能侧面反映出一个人的代码质量且严重程度高的BUG也有更高的单独分析价值，可以积累更多的测试经验

我们关心项目中的哪些数据？怎么通过Bug获得相应的结果

首先我们要有关注点，然后再去挖掘可以反应这个关注点的数据。

这里先提一个概念叫有效Bug数，即排除了不是Bug、重复Bug的数据。有效Bug主要用于做按人（RD和PM）分析的时候，判断每种解决方案的占比，这样的分析结果RD会更加认可。当然如果一人的不是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分析需要找到Bug产生的根本原因，多问多想，避免下次出现同样的问题；积累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 -

---

关注「测试开发社区」

把握前沿Python测试开发技术脉搏