测试系列-版本质量总结的纬度
来源:互联网 发布:小学同步教学软件 编辑:程序博客网 时间:2024/06/18 18:07
版本质量总结的纬度
在一些大的团队,一般会有专职的角色来负责质量管理,即QA。QA在每个项目或版本结束时,追本溯源,重新审视项目过程,从不同纬度来分析版本的各种数据,从而挖掘出整个研发流程和团队存在的问题,进行流程改善和质量、效率提升。
那么通常可以从哪些方面来进行版本质量分析呢。
1 开发交付质量
项目研发流程里的第一个环节是资源规划:包括设备利用(硬件设施的分配)、资金(开发资金的来源和使用目的)、人力分配(开发团队的组建)、时间安排(开发周期)。资源规划制定好后,才能有秩序的开展研发工作,按时按质研发和提测,才能保证项目最终按时交付。
从准时提测率、一次性提测通过率、首次提测案例通过率、失败再次提测平均时间四个维度来分析,有利于监督开发提测质量和效率,让整个项目的进度处于可控的状态。
但是开发角度对QA 所进行的交付质量监督表示排斥的,所以前期的交付时间、交付标准务必要要求明确,才能保证数据源的准确性和完整性。下方通过一个示例来体现计算公式,示例来自某个项目的开发提测数据:
模块
提测日期
是否一次性提测通过
提测次数
失败次数
提测是否延期
提测延期(D)
首次案例通过率
失败再次提测时间(H)
前后端
责任人
模块A
6月7号
否
3
1
是
0
90%
0.5
后端
王一
模块C
7月28号
是
1
0
否
0
100%
0
前端
赵二
模块D
7月1号
否
2
1
否
1
85%
1.5
H5
李三
模块B
7月28号
是
1
0
否
0
100%
0
前端
赵二
准时提测率=提测未延期次数/提测总次数(即3/4=75%)
一次性提测通过率=一次性提测通过次数/提测总次数(即2/4=50%)
首次提测案例通过率=首次案例提测通过率求和/提测总次数(即375%/4=94%)
失败再次提测平均时间=失败再次提测时间总和/失败提测总次数(即2/2=1H)
2 发版质量监测
2.1 发版质量
通常发版失败的主要原因主要有:生产环境与测试环境差异过大、生产包或生产环境漏改或改错相关配置文件、测试环境无法测试或漏测、多个子系统相互依赖,可能导致某个子系统发版本时,需要等待另一个子系统也发出对应版本,这样版本间形成等待关系和依赖关系,最后可能导致发版失败。
2.2 发版时效
发版时效是指一个项目开始准备部署发版到最后发版成功的时间。所以发版时效跟发版流程有直接关联。大部分研发团队版本的发版流程如下:
下方通过一个示例来体现计算公式,示例来自某个项目的发版时序:
发版时序
时间
间隔(H)
备注
部署准备时间
12:00
部署实施时间
19:00
7
部署完成时间
21:00
2
验证完成时间
23:00
2
发现9个问题,修复后回归通过
修复完成时间
24:00
1
离场时间
0:30 次日
0.5
发版一次性通过率=发版一次性通过次数/发版次数(即0/1=0%)
发版时效=离场时间-部署准备时间(即5.5H)
部署时效=部署完成时间-部署实施时间(即2H)
测试验证时效=测试进行首次发版验证的时间,不包含问题回归的时间(即2H)
发版时效一般可能是大于等于测试验证时效+部署时效,因为可能有修复生产验证发现的问题和进行回归(如上表的差值1.5H)
通过统计发版质量和时效,分析发版数据,有助于清晰的看到项目项目生产与测试环境期间的问题,针对环节中人力和时间损耗大的点进行改善,有助于减少发版频率和发版人力损耗,敏捷项目流程,实现构建即上线。
3 版本bug数据
从项目初期的产品需求PK,到开发阶段的自测、迭代提测、集成上线提测,直至发布后用户反馈,bug几乎贯穿了产品发展的各个阶段。
这是一份bug清单,被隐去了某些项目内部信息。
ID
状态
优先级
主题
模块
系统
测试阶段
提交人
创建于
结束日期
生命周期
问题类型
引入者
端
项目
版本
48468
关闭
普通
个人中心
iOS
STORY/SIT
测试 王芳
2017-8-9
2017-8-9
0
code issue
刘生
前端
48441
关闭
普通
个人中心
Android
UAT
测试 王芳
2017-8-8
2017-8-22
14
code issue
刘生
前端
48380
关闭
普通
个人中心
iOS
STORY/SIT
测试 王芳
2017-8-5
2017-8-9
4
code issue
刘生
前端
48209
关闭
普通
一级页面
Android
STORY/SIT
测试 王芳
2017-7-31
2017-8-7
7
code issue
刘生
前端
48076
非缺陷
高
一级页面
iOS
STORY/SIT
测试 刘磊
2017-7-27
2017-7-28
1
code issue
赵杨
后端
47914
缺陷遗留
普通
一级页面
Android
STORY/SIT
测试 刘磊
2017-7-25
2017-8-18
24
code issue
赵杨
后端
47907
关闭
普通
一级页面
Android
STORY/SIT
测试 刘磊
2017-7-25
2017-7-27
2
code issue
赵杨
后端
47628
关闭
普通
一级页面
Android
STORY/SIT
测试 刘磊
2017-7-10
2017-7-25
15
code issue
赵杨
后端
47622
后续解决
低
一级页面
Android
STORY/SIT
测试 刘磊
2017-7-10
2017-7-27
17
code issue
李白
后端
47512
关闭
普通
一级页面
iOS
STORY/SIT
测试 刘磊
2017-6-30
2017-7-11
11
code issue
李白
后端
47480
关闭
高
一级页面
iOS
STORY/SIT
测试 刘磊
2017-6-29
2017-7-10
11
3rd party issue
李白
后端
正常一个bug描述以及跟踪过程所必须的字段有:系统、版本、项目、主题、模块、提交人、引入者、问题类型;各个项目根据实际需要也可以有一些自定义的字段,比如下方示例取自我所在项目的bug清单中的:端(为了区分不同的开发团队)、测试阶段(为了分析项目周期中bug的走势)
对于测试人员来说,提升对产品的理解,做好bug的提交、跟进和分析,能够更高效、更有效的测试,并能够更好的把控和提升项目质量。
3.1 bug状态分布
根据bug状态的分布,可以看出有效和无效 bug 的占比,已解决和未解决问题的占比,从而看出 bug 的质量以及版本的质量。
非缺陷:一般出现原因为两种,一是对测试同学对需求理解有误误报了bug,一种是需求不明确或不完善导致的bug。这两种都是应该在项目中优化和避免的。
缺陷遗留:一般出现原因为两种,一般是因技术难点或架构原因难以修改导致的bug遗留,但缺陷遗留必须是开发、产品、测试、PM等多方共同商议达成一致才可遗留
后续解决:一般是一些体验和优化问题,对用户使用影响不大,多方确认下个版本再修复的。
正常一个项目发版时,这几项特殊状态的bug都应该占比极少。
3.2 bug级别和模块分布
一般情况下,用例和bug的级别可分为四级,这是大多数公司对于用例和bug级别的标准定义:
等级
p0/致命
p1/高
p2/普通
p3/低
占比
15%
35%
35%
15%
当各等级的 bug占比严重出现偏差时,需要分析具体原因。如果紧急和高的bug过多,可能是开发质量太不过关。如果是低的bug过多,可能是产品需求设计不够好,或者是测试同学发现深度bug的能力欠缺。
在软件开发中有着八二原则:80%的bug是由20%的代码造成的,90%的停机是由10%(甚至更少)的缺陷造成的。bug总是集中爆发在某几部分代码中,特别是严重的bug。
bug数排前或者 bug 等级偏高的几个模块,即不稳定模块,不仅是开发和测试的关注重点,是重构和回归测试的依据,也是一个研发项目要改善和提升的重点模块。并且可以针对各个模块的bug具体原因进行分析,比如是CMS配置问题、代码质量问题、接口设计不合理、还是需求规则不明确导致的问题,从而针对性的一一改善。
3.3 bug责任人分布
可以从bug提交人、bug引入者、前端、后端问题几个详细维度去分析。如果项目区分了前端开发、后端开发、H5开发,则还要区分下对应的责任人。
从bug责任分布,可以明显的看出测试同学的bug数排名,以及开发的bug数排名。对于代码的质量、测试和开发同学的工作能力、以及工作量投入产出评估都具有参考价值。
3.4 bug生命周期和生长趋势
bug生命周期以bug创建日期算,bug关闭日期结束。各个项目、各个测试阶段都会有bug生命周期的标准,比如某个项目SIT测试期间要求bug日清,那么bug的生命周期正常情况下应该不超过24H。
bug生长趋势是指一个项目或版本进行期间,每日bug增长和关闭的曲线。理想的项目流程中,新增和关闭的bug曲线伴随着项目的进行应当是有个一致坡度的增幅和减幅的。
正常情况下,80%以上的bug应该在模块化测试及STORY阶段被发现,SIT集成期间发现与集成有关的bug,而UAT和PVT期间发现的bug数应该极少趋向于零。
假设一个项目的bug生长曲线见下图:
并且测试阶段对应为:
STORY: 6.6-8.7
SIT:8.8-8.10
UAT:7.31-8.15
那么可以看到bug曲线反馈的现象:
bug增长曲线来看:
a) STORY阶段发现的bug数逐渐增加,暴露出了项目组80%以上的bug。
b) SIT期间bug数在5个以下。
c) UAT期间bug数有少量的增加,可能是因为客户反馈的需求或者是测试遗漏的bug。需要重点分析。
但从关闭曲线来看:开发前期极少解决问题,到STORY尾声和SIT期间才大量修复问题。现象是不合理的,在项目后期极大的加重了开发和测试的压力。那么是什么原因导致的这种不合理现象,是否可以改善?
3.5 典型bug案例
另外还可以从一些典型bug案例上进行分析。比如:
选择比较有特性难以发现的bug,分析一下测试的方法和测试粒度
选择测试用例未覆盖的bug,根据bug补充测试案例
4 线上用户反馈
4.1 问题反馈
收集市场和各种反馈渠道上用户的问题,对整个版本的质量进行一个更加深入的了解,毕竟测试期间能够覆盖的机型,能够覆盖的场景还是有限的,不可能模拟到大千用户。
分析Crash日志,进行分析和归类,快速相应解决问题。
4.2 运营数据
关注版本的留存、日活、月活、停留时长等是另一个纬度对版本质量的分析。
总之,从版本总结的角度,追溯项目流程中涉及到的各个角色,各个环节,各个bug,各个踩过的坑,思考后续如何避免类似问题,在下次测试中得到提升,在下个版本的项目流程中进行优化改善,提高质量和效率才是根本目的。
- 测试系列-版本质量总结的纬度
- 测试方法论-质量的基石
- 自动化测试开发实践系列(一)个人对测试、质量、竞争的理解
- 《知识结构》系列---软件测试、软件质量
- 纬度的正负区分
- 版本计划对版本质量的影响
- 提高测试质量的要诀
- POI 的简单版本 EasyPoi性能测试 系列一
- 软件测试-软件质量
- 项目代码质量的总结
- 有关电能质量的总结
- 高质量的代码总结
- 衡量软件测试质量的常用的质量度量指标
- 软件质量与测试的新纪元
- 软件质量与测试的新纪元
- 软件测试过程质量的度量
- IC 产品的质量与可靠性测试
- 质量保障测试人员的一天
- gdfzoj #791 硬币(优先队列)
- HDOJ 1166 敌兵布阵 (区间求和)(线段树)(树状数组)
- python:4:列表基本用法及相关函数(2)
- LinearLayout的layout_weight
- 项目管理的75条建议
- 测试系列-版本质量总结的纬度
- 程序的内核态和用户态
- 使用Ambari快速部署Hadoop大数据环境
- 写给前端工程师的理论基础(4)--详解SSL
- 在字符串中找出连续最长的数字串
- 机器学习学习笔记.day1
- springboot schedule
- Android控件之ViewFlipper
- 绕过htaccess的限制工具-HTExploit