此文已由作者夏君授权网易云社区发布。
欢迎访问网易云社区,了解更多网易技术产品运营经验。
产品测试组_理财基金
统计季度: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+款云产品!
更多网易技术、产品、运营经验分享请点击。
相关文章:
【推荐】 分布式存储系统可靠性系列二:系统估算示例
【推荐】 浅析电商防止恶意下单