如何作缺陷分析

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

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

产品测试组_理财基金
统计季度：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+款云产品！ 

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

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