版本质量总结的纬度
在一些大的团队，一般会有专职的角色来负责质量管理，即QA。QA在每个项目或版本结束时，追本溯源，重新审视项目过程，从不同纬度来分析版本的各种数据，从而挖掘出整个研发流程和团队存在的问题，进行流程改善和质量、效率提升。
那么通常可以从哪些方面来进行版本质量分析呢。
1 开发交付质量
项目研发流程里的第一个环节是资源规划：包括设备利用（硬件设施的分配）、资金（开发资金的来源和使用目的）、人力分配（开发团队的组建）、时间安排（开发周期）。资源规划制定好后，才能有秩序的开展研发工作，按时按质研发和提测，才能保证项目最终按时交付。
从准时提测率、一次性提测通过率、首次提测案例通过率、失败再次提测平均时间四个维度来分析，有利于监督开发提测质量和效率，让整个项目的进度处于可控的状态。
但是开发角度对QA 所进行的交付质量监督表示排斥的，所以前期的交付时间、交付标准务必要要求明确，才能保证数据源的准确性和完整性。下方通过一个示例来体现计算公式，示例来自某个项目的开发提测数据：
准时提测率=提测未延期次数/提测总次数（即3/4=75%）
一次性提测通过率=一次性提测通过次数/提测总次数（即2/4=50%）
首次提测案例通过率=首次案例提测通过率求和/提测总次数（即375%/4=94%）
失败再次提测平均时间=失败再次提测时间总和/失败提测总次数（即2/2=1H）
2 发版质量监测
2.1 发版质量
通常发版失败的主要原因主要有：生产环境与测试环境差异过大、生产包或生产环境漏改或改错相关配置文件、测试环境无法测试或漏测、多个子系统相互依赖，可能导致某个子系统发版本时，需要等待另一个子系统也发出对应版本，这样版本间形成等待关系和依赖关系，最后可能导致发版失败。
2.2 发版时效
发版时效是指一个项目开始准备部署发版到最后发版成功的时间。所以发版时效跟发版流程有直接关联。大部分研发团队版本的发版流程如下：
下下方通过一个示例来体现计算公式，示例来自某个项目的发版时序：
发版一次性通过率=发版一次性通过次数/发版次数（即0/1=0%）
发版时效=离场时间-部署准备时间（即5.5H）
部署时效=部署完成时间-部署实施时间（即2H）
测试验证时效=测试进行首次发版验证的时间，不包含问题回归的时间（即2H）
发版时效一般可能是大于等于测试验证时效+部署时效，因为可能有修复生产验证发现的问题和进行回归（如上表的差值1.5H）
通过统计发版质量和时效，分析发版数据，有助于清晰的看到项目项目生产与测试环境期间的问题，针对环节中人力和时间损耗大的点进行改善，有助于减少发版频率和发版人力损耗，敏捷项目流程，实现构建即上线。
3 版本bug数据
从项目初期的产品需求PK，到开发阶段的自测、迭代提测、集成上线提测，直至发布后用户反馈，bug几乎贯穿了产品发展的各个阶段。
这是一份bug清单，被隐去了某些项目内部信息。
正常一个bug描述以及跟踪过程所必须的字段有：系统、版本、项目、主题、模块、提交人、引入者、问题类型；各个项目根据实际需要也可以有一些自定义的字段，比如下方示例取自我所在项目的bug清单中的：端（为了区分不同的开发团队）、测试阶段（为了分析项目周期中bug的走势）
对于测试人员来说，提升对产品的理解，做好bug的提交、跟进和分析，能够更高效、更有效的测试，并能够更好的把控和提升项目质量。
3.1 bug状态分布
根据bug状态的分布，可以看出有效和无效 bug 的占比，已解决和未解决问题的占比，从而看出 bug 的质量以及版本的质量。
非缺陷：一般出现原因为两种，一是对测试同学对需求理解有误误报了bug，一种是需求不明确或不完善导致的bug。这两种都是应该在项目中优化和避免的。
缺陷遗留：一般出现原因为两种，一般是因技术难点或架构原因难以修改导致的bug遗留，但缺陷遗留必须是开发、产品、测试、PM等多方共同商议达成一致才可遗留
后续解决：一般是一些体验和优化问题，对用户使用影响不大，多方确认下个版本再修复的。
正常一个项目发版时，这几项特殊状态的bug都应该占比极少。
3.2 bug级别和模块分布
一般情况下，用例和bug的级别可分为四级，这是大多数公司对于用例和bug级别的标准定义：
当各等级的 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，各个踩过的坑，思考后续如何避免类似问题，在下次测试中得到提升，在下个版本的项目流程中进行优化改善，提高质量和效率才是根本目的。