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

发表于:2020-1-22 14:42

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:孙敏    来源:转转QA

#
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规范,自动生成分析图表。
  将这些数据存储到数据库中,长期的统计分析总结,将获得一个良好的收益。

     本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号