作者|孙敏
为什么要做Bug分析?
Bug是项目过程中的一个有价值的虫子,它不只是给开发的,而是开给整个项目组的。
通过Bug我们能获得什么?
项目过程中不可能没Bug,但是我们要利用已有Bug减少未来Bug数,提高产品质量。
Bug包含了哪些信息可以分析?
Bug本身的信息
Bug产生的阶段
Bug规范
Bug产生阶段的划分
Bug解决方案
目前我们的解决方案如下:
其中历史遗留,需求/UI设计缺陷,环境配置就是在项目过程中衍生出的解决方案;并且在项目中明确了重复BUG和以后解决的定义。
更合理的解决方案,有助于更好的分析Bug产生的原因,当这些问题都解决后,Bug自然也就可以减少了。
Bug等级
1、Bug等级有两个层面:优先级和严重程度
2、优先级根据Bug紧急程度分为:高、中、低
3、Bug严重程度分为:致命、严重、一般、提示、建议
我们关心项目中的哪些数据?怎么通过Bug获得相应的结果
首先我们要有关注点,然后再去挖掘可以反应这个关注点的数据。
这里先提一个概念叫有效Bug数,即排除了不是Bug、重复Bug的数据。有效Bug主要用于做按人(RD和PM)分析的时候,判断每种解决方案的占比,这样的分析结果RD会更加认可。当然如果一人的不是Bug占比一直偏高,那也可以思考一下为什么总是这个人将Bug置为不是Bug。
从QA角度
1、 接口测试质量
2、 功能测试质量
3、工作量大小
4、提Bug的有效性
从RD角度
1、 开发的提测质量
2、 开发的代码质量
从产品/UI角度
1、产品/UI的需求设计是否合理;
2、需求是否经常变更;
需求变动,需求/UI设计不合理,这两个都可以通过Bug解决方案进行分析,大致推算出一个PM需求质量
从项目角度
1、Bug创建及修复情况
根据每日创建和每日解决Bug数的曲线,来查看QA测试情况,以及RD解决Bug是否及时
例如下图:
分析:
2、针对解决方案进行分析
Bug规范的部分讲了,每个解决方案都对应一个意义。如果项目中某项解决方案占比较高,可以看下是为什么,以及考虑一下怎么减少这些Bug?
比如下图,除了编码错误的,不是Bug以及设计缺陷的Bug占比较高。
3、验证一些提升效率的手段是否有效
项目中遇到问题,会涉及一些流程改进,有些改进通过Bug信息可以分析。
比如分批提测,参考下图,RD正式的提测时间为12月27日,但是因为在开发阶段引入了分批提测,一部分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 -