叁叁肆

这个世界会好吗

453篇博客

如何作缺陷分析

叁叁肆2018-10-22 13:40

此文已由作者夏君授权网易云社区发布。

欢迎访问网易云社区,了解更多网易技术产品运营经验。


产品测试组_理财基金
统计季度:2016_Q1

关键字:jira、Bug收敛、零Bug反弹、同比/环比
第一部分  jira图表数据分析

1. 最新问题图(以柱状统计图显示指定项目最新创建的问题):
说明:
绿色柱体含义为某一周提交的bug数,绿色柱体重合的红色柱体表示该天提交的所有bug中到目前统计时间点为止所剩余的未解决掉的bug数。 


分析:
如果某一天的提交的bug数量非常多,说明这一天提交的测试版本中可能是添加了某个新的功能点,且该功能点处于不稳定状态 ;还一种可能就是开发的某一处的修改带来了连锁反应,将其它稳定之处也连带改的不稳定了,从而注入了新的bug(在实际的工作中,确实遇到过这样的问题,开发为了修改一个bug,将起先版本中稳定的功能点也改坏了)。

2. 创建与解决的问题对比图(显示一个项目或保存的过滤器的问题创建与解决对比情况):
说明:

红色曲线表示随日期增加所提交的bug数累计分布,绿色线条表示随日期增加所解决的bug数累计分布。

末端一处两曲线呈水平分布,稳定状态。


          分析:
Bug累计数随日期的增加还在持续的快速增长,并且红色曲线斜率多处区域大于45°,说明产品仍存在较多缺陷,质量并没有稳定下来。
两条曲线斜率多处区域均大于45°,说明测试和开发的效率都还是不错的
因为质量还没有稳定,所以项目测试暂时不能被关闭

其他情况:
情况一:两条曲线之间的间距越来越小,且红色曲线的斜率趋于平缓
分析:质量越来越稳定,且可以预见两条曲线有交织的可能性,可以考虑关闭项目测试。
情况二:两条曲线之间的间距越来越大,且红色曲线斜率并没有放缓趋势
分析:产品质量比较差,需要及时做出修改和调整,使产品质量相对稳定下来。 
情况三:两条曲线之间间距稳定,但是曲线斜率趋于平缓
分析:开发遇到了技术挑战,效率开始降低。由于模块不能及时发布,同时也影响了测试效率。

3. 解决时间(显示指定项目或过滤器解决问题的时间柱状图):
说明:
此图显示了修复bug所花费的平均天数,横坐标代表bug关闭的日期



分析:
绝大部分的bug修复花费了较长的天数,说明此项目对于开发团队可能是全新的领域,诸多问题对于他们来说都是非常大挑战;如果此种情况不存在,那么开发的效率可能存在问题,可能是资源受限,如人力不足等

 4. 饼图汇总统计:
 1) 应用模块占比(模块缺陷分布图)


分析:直观的显示出各个模块缺陷的分布情况,从而可以非常好的定位当前工作的重点是优先解决哪些模块的缺陷

2) 问题解决优先级(优先级分布图):
说明:问题的优先级表示其重要性,以下列示出当前的优先级别:
 P0 必须有
 P1 应该有
Major loss of function.
 P2 有了更好

分析:
图中的P1 缺陷占到 95% 的比率,几乎全部,质量控制需待加强。


3) 缺陷重要程度占比(缺陷严重性分布图):
          

分析:大部分的缺陷属于功能缺失。


4)  报告者占比(缺陷提交者分布图):


  
分析:本季度产出缺陷效率高, 442/66天/3人=2.23/人*天

5) 缺陷处理时间(缺陷解决分布图):

 
分析:
· 已完成和已修复说明了当前开发的工作进度和效能。
· 重复/无法复现/无效三项直接说明了测试组工作细致程度,如果数值偏大,那么工作严谨程度有待加强。


6)BUG 发现阶段(测试/预发/线上分配):

分析:
预发阶段暴露部分测试阶段遗漏问题
预发典型遗漏问题
简要描述: 首页-我的资产没有显示基金资产  --遗漏场景
支付定时钟未轮询        --开发未提供
余额不足跳失败页面      --合作方待配合
未上架基金产品不能作为精选基金  --遗漏场景
新加的页面文案
提供真实数据与实际测试数据不一样,有些字段控制,比如判费率 
预发人为因素:数据库表索引未提供明确
相关配置未整理完毕   
分析结果:
QA:补充用例,引入多角色资源测试
开发:配置问题整理预发上线checklist
            
 5  BUGBASH分布
           
分析:
用户体验46,占总缺陷比例= 46 / 365 = 12.6%
程序设计BUG,占总缺陷比例=3/365=0.8%

第二部分 依据项目阶段分析数据
目前项目周期短,采取半敏捷开发模式,迭代提测及开发,过程功能不断迭代,也使缺陷不断的引入,并不断发现。众所周知,缺陷越早发现,修复的成本越低,越到后面,质量不能得到很好的保证。因此分析阶段缺陷,有效避免流入下一个阶段,非常必要的。
 1. 缺陷引入-各项目阶段配比图:

说明:
 a.  阶段缺陷移除率可以有效的衡量测试用例是否充分,测试效率是否充足。
 b. 开发需要在当前测试阶段提供哪些功能点已经可测试,哪些功能点Blocked。

陷发现阶段\缺陷注入阶段

需求评审

迭代1

迭代2

迭代3

阶段测试发现总计

需求文档审核

10




15

冒烟测试

10

64



74

第一轮测试

10

30

50


90

第二轮测试

10

90

20

120

第三轮测试

10 30 10

10

60

预发/线上测试

-




20

引入总计

50

214

80

10

379

本阶段缺陷移除率

13.19%

56.46%

21.11%

2.64%


  • 阶段缺陷移除率=(本阶段发现的属于本阶段功能的缺陷数/最终统计的所有属于本阶段功能的缺陷数)x100%


2. 各阶段之活动BUG图/BUG打开关闭图模型分析:
说明:
打开bug:包括重新打开数量
关闭bug:单位为次数  
活动bug:解决中,已解决(指在项目中还需要大家去关注的Bug)

                                提测阶段图
 分析:
1. 活动bug数字越大,说明软件的质量越差。
2. 当天打开,关闭数字很大,说明Bug的处理非常活跃,软件非常不稳定
3.  关闭Bug>打开Bug,活动Bug数回落(“Bug收敛”)
4.  正常的项目测试应该是,活动Bug先上扬,再回落,最后在低位小幅振荡,零打开BUG反弹。

第三部分  其他分析维度及典型缺陷分析思路
1) 同比、环比
a. 同一合作方同一个产品,不同迭代缺陷各维度分析
eg: 以上  盈米:中金
b. 不同合作方同一类产品,缺陷对比分析
eg: 公募基金 : 易钱袋
c. 不同产品对比分析
d. 不同业务线对比分析
……
2)系统过程稳定,引入其他维度分析
现有:总缺陷数、缺陷解决所费时间、某一模块的缺陷占总的缺陷数的比率、某一类型(优先级/重要性)的缺陷数占所有类型的缺陷数的比率、千行代码缺陷率
稳定性条件:头脑风暴、鱼骨头收集可能的原因,柏拉图分析主要原因
3)典型缺陷思路,经典案例之前每组都有分析过
10why法:   
1w:这个问题是什么?有什么影响? 
2w:为什么会出现这个问题?什么场景下会出现这个问题? 
3w:这个问题是在哪个阶段发现的? 
4w:缺陷是在哪个阶段引入的? 
5w:为什么会在这个阶段引入问题? 
6w:(how)如何避免引入这个问题? 
7w:应该在哪个阶段发现这个问题? 
8w:为什么没有在这个阶段发现这个问题? 
9w:(how)如何才能在这个阶段发现这个问题? 
10w:(how)如何改进基于风险测试的过程,提取预估到这样的产品风险?  

第四部  总结
可能存在的潜在缺陷和后续工作:
a. 第一次与我们平台对接,数据流程上面可能有些不可预测性的问题,后续持续跟进
做的好的地方:
a. 发动全员参与质量保障,本期新增页面交互量多,发起BUGBASH 
b. 及时沟通反馈,统计未解决问题
c. 前期数据准备,比如业务测试场景的分析,预期的风险
d. 提前与其他项目沟通上线发布
e. 开发修复BUG响应速度很快,且自行协助测试分析容易出错的点
 
做的不好的地方:
a. 中间涉及需求不断变更,包括页面
b. 质量比较差,对于页面交互评审工作可以提前
c. 稳定性、可靠性测试未开展,接口自动化
d. 开发尽量自己多下订单
e. 开发没有复测缺陷,没有利用自行环境,直接提测,干扰测试时间
f.  BUG基本上面备注,开发层面原因分析
 
后续改进:
a. 用例整理,修正和补充遗漏分析点
b. 分析稳定、可靠性测试需求
c. 业务测试技能交叉分享,组内相互串通
d. 盈米问题跟踪
e. 借助fiddler、浏览器插件排查问题快速定位总结

遗留未解决问题:
讨论:
1. 缺陷格式和属性没有严格要求,记录简单,很多必要信息的缺失,对后续的跟踪和分析极为不利。
2. 有些属性可能不是那么有意义,导致存储信息不仅没用反而添乱,也不利于分析。
3. 创新引入分析


网易云免费体验馆,0成本体验20+款云产品! 

更多网易技术、产品、运营经验分享请点击


相关文章:
【推荐】 分布式存储系统可靠性系列二:系统估算示例
【推荐】 浅析电商防止恶意下单