质量度量是指我们采集了一些产品研发过程及上线后质量相关的数据，经过聚合计算，通过图表、质量分等方式呈现出来这件事。在业界也有一些关于这方面的分享，比如“质量运营”，“数字化软件过程”，“质量罗盘”等，今天我们就来分享一下做质量度量的过程与思考。
一、背景与目标
为什么做这件事？之前关于质量相关的数据都是散落在各个系统，查看起来不方便，并且无法以我们关心的维度、指标去看这些数据，为管理与质量运营做支撑；因此想通过做质量度量，达到让关心质量的小伙伴查看部门、应用等维度产品的质量做的怎么样，给出改进建议，从而推动软件质量的提升。
二、产品设计
如何实现目标呢？
- 聚合维度：从目标上来看因为要看部门、应用、人的质量，所以数据就要以这三个维度来聚合。
- 评价方式：数据有了怎么看是好，还是差呢？这就用到数据的评价方式：横向与别人比、纵向与自己比、达成率、质量分。
- 改进建议：质量不好，怎么给改进建议呢？这是很复杂的问题，因为这涉及到数据的质量，数据全面性，数据相关性等一系列问题。目前只是做了一些关键数据趋势对比结果输出及纵向比较的结果提示，更多的事情还需要人来做。
2.1 聚合维度
确定要三个维度来聚合数据，那具体如何做呢？下面来具体讲讲我们的设计，因为和质量相关数据有很多，比如有测试 bug，线上 bug，应用发布等，这就需要让数据与聚合维度产生关系：
- 部门：1）与人相关的数据，通过"人"所在的部门来聚合，如测试bug数据。 2）与应用相关的数据，通过应用与部门的对应关系来聚合，如单测覆盖率数据。
- 应用：有些数据和应用没有关系，比如测试 bug，在创建时并没有选择应用，我们想过强制要求选择，发现成本很高，后面就放弃了。
2.2 评价方式
这些评价方式在实际过程中，会根据不同场景，选择不同的方式。
- 横向与别人比：看数据top，平均水平等，举例：8月份，初级 bug 率top3的部门。
- 纵向与自己比：看数据趋势，举例：最近半年，A部门的月初级 bug 率趋势。
- 达成率：设定一个指标的目标，各个部门的标准可以一致，也可以根据自己的实际做设定。举例：如单测覆盖达成率，设定目标为应用单测覆盖率要达到80%，如果营销部门一共有10个应用，5个应用达到80%，那么营销部门单测覆盖达成率就是50%。
- 质量分，计算指标维度分数是一种综合的方式，展现的方式也最直观。算分要求要事先设定好目标阈值，然后计算实际值与阈值的差别，根据一定的算法，得出具体分数。如果给用户的是一个总分，那么通常会设定子维度的权重百分比，加总子维度乘以权重后的得分算出总分。
2.3 指标项
- 什么是指标项？在这里是指数据的数量或百分比，如有效 bug 数量、初级 bug 率等。
- 到底选哪些呢？我们先是列了一些能想到的指标项，再根据数据的成熟度、用户关心程度、实现成本等方面做了反复讨论，定下具体做哪些指标，优先级是怎样。
- 具体在哪些，如何定义？因为在我们对外的白皮书里有详细介绍，这里就不重复了。
2.4 呈现方式
我们会将一类数据的指标放到一个页面呈现，称为度量组页，用户首先会进到一个质量概览页，这个页面会呈现质量分、一些关键指标的变化信息，从这里可以进到具体的指标组页，会有横向、纵向等更详细信息的展示。
2.4.1 部门概览页
2.4.2 线上有效 bug 数量趋势图（线上 bug 指标组页）
三、技术实现
因为会涉及多个系统及大量的数据，我们采用了离线计算的方式，整个系统由数据计算与数据呈现两块组成，这样的系统架构带来了几个明显的好处：
- 首先数据图表的展示速度很快，因为数据结果基本是预先计算好的，只需要简单的查询与加总就可以返回了。
- 其次是灵活性比较高，因为需求经常会调整（特别是前期，很多东西都是需要摸索，不断试错的），而数据处理是通过 HIVE 实现，更改后可很快生效，不用走繁琐的系统发布过程。
- 当然这样的设计另一方面也舍弃数据实效性，但大多数情况下，这些数据实时性要求没有那么高，为了弥补我们也提供了可以手工数据更新的能力。
3.1 数据处理流程
3.1.1 数据导入
我们依赖的数据有几种类型：
- 可以导入数据仓库的数据，这样我们只配置导入或者直接依赖就可以；
- 提供方式只有是接口的数据，对于这类我们用系统定时任务同步到数据库中，再导入数据仓库。
3.1.2 数据明细处理
这步的目的是方便后面的统计与明细数据的查看。
举例：我们要统计 bug reopen 率，首先 bug 是否被 reopen 过，原始数据上并没有这样直接的标记，这需要根据 bug 操作记录来判断，这一步就来做这个判断与标识，方便下一步统计时逻辑的简化；其次用户看 bug reopen 率时，也想看具体哪些 bug 被 reopen 过，这一步产生的结果数据导出后，可供用户查询。
3.1.3 数据统计
这步是数据处理的核心步骤，要解决下面几类问题：
- 首先是数据统计粒度问题：我们这里最细的时间粒度是天，如果数据的聚合维度是部门，那就是计算每个部门每天的数据，而周、月的数据，可以基于天的数据再计算，我们考虑如果进一步计算会产生过多的结果表，并且数据量并不太大，就放到页面查询时由系统接口来计算。
- 其次是全量与增量计算的问题：所谓全量计算就是每次都把全部的数据重新计算一遍，而增量计算就是指只对新增的数据做计算，增量计算数据量小，处理速度快，是最倾向使用的方式，但现实情况要根据数据的实际情况来选择，如果数据产生后会经常变化的，比如 bug 数据，bug 可以从打开到关闭，也可过一段再被打开，这样的数据只能用全量计算。而发布的数据就可以用增量计算，因为每天的发布数据产生之后就不会再变化了。
3.2 一些问题
- 指标项多，连表过多。
有的数据指标项有十几个，每个指标都需要聚合之后，再与其它指标进行全表连接。开始时我们是根据每个指标去实现的，每个指标产生了一个子表，分别完成之后，发现子表数据根本合不到一起。为了减少子表，我们将聚合条件一致的做了合并，然后再对子表进行了分类，比较相近的子表先两两相连，逐层向上，只到最后合成一张。 - 有效 bug 是按创建时间还是解决时间算。
一个 bug 是不是有效 bug 是在这个 bug 解决后决定的，当它的创建时间与解决时间不同时，它应归为创建那一天的，还是解决那一天的呢？后来总结发现这两种其实都行，对比来看，以创建时间来算，同一天的数据，不同时间查会不同，而以解决时间来算就会很稳定，显示时能标明当天创建的有效 bug 或者当天解决的有效 bug会比较清楚。
四、总结
质量度量在测试与效能团队共同努力下，经过前后三个迭代的不断完善，功能在9月份全部上线完成。总结经验教训，在产品设计上我们需要明确用户是谁？面临什么问题？具体场景是什么？也需要提高主动触达用户能力。技术实现上我们需要增加更快呈现数据指标的能力。未来的规划，结合质量运营，通过不断完善指标项与数据质量，为用户提出改进建议，以达到推进质量提升的目标。
