版本质量总结的纬度
在一些大的团队,一般会有专职的角色来负责质量管理,即QA。QA在每个项目或版本结束时,追本溯源,重新审视项目过程,从不同纬度来分析版本的各种数据,从而挖掘出整个研发流程和团队存在的问题,进行流程改善和质量、效率提升。
那么通常可以从哪些方面来进行版本质量分析呢。
- 交付准点率
- 交付通过率
- 部署通过率
- case通过率
- BUG 修复率
- 严重BUG率
- BUG修复周期
- 人均BUG数
- 线上事故率
1 开发交付质量
项目研发流程里的第一个环节是资源规划:包括设备利用(硬件设施的分配)、资金(开发资金的来源和使用目的)、人力分配(开发团队的组建)、时间安排(开发周期)。资源规划制定好后,才能有秩序的开展研发工作,按时按质研发和提测,才能保证项目最终按时交付。
从准时提测率、一次性提测通过率、首次提测案例通过率、失败再次提测平均时间四个维度来分析,有利于监督开发提测质量和效率,让整个项目的进度处于可控的状态。
但是开发角度对QA 所进行的交付质量监督表示排斥的,所以前期的交付时间、交付标准务必要要求明确,才能保证数据源的准确性和完整性。下方通过一个示例来体现计算公式,示例来自某个项目的开发提测数据:
模块 |
提测日期 |
是否一次性提测通过 |
提测次数 |
失败次数 |
提测是否延期 |
提测延期(D) |
首次案例通过率 |
失败再次提测时间(H) |
前后端 |
责任人 |
模块A |
6月7号 |
否 |
3 |
2 |
是 |
1 |
90% |
0.5 |
后端 |
王一 |
模块C |
7月28号 |
是 |
1 |
0 |
否 |
0 |
100% |
0 |
前端 |
赵二 |
模块D |
7月1号 |
否 |
2 |
1 |
否 |
0 |
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 |
|