管理学大师德鲁克曾说过“如果你无法衡量它，就无法管理它（If you can’t measure it, you can’t manage it）”。可见，要想有效管理某个事务，就需要将它全面且有效地度量起来。
质量度量体系如何建设？
大家都知道作为测试人员，主要任务是质量保障，保障线上环境没有故障和缺陷，最终交付给真实用户的质量，即交付质量。那么，质量度量是不是只关注交付质量指标就足够了呢？答案显然是否定的。因为如果只关注交付质量，往往达不到提升交付质量的目的。比如，你每天关注线上交付质量，忙着一个又一个的项目，一段时间过后，发现线上环境的故障数和缺陷数未见减少，这时候你甚至不知道根因出在哪里，应该如何改进，现有的工作哪些要继续保持哪些要放弃，等等。
这是因为交付质量是一个滞后性指标，当你知道它时，它已经发生了。如果要想避免此类情况，还需要多关注一个引领性指标。
滞后性指标：
顾名思义，就是事情已经发生之后产生的数据，可以理解为线上的交付质量
引领性指标：
与滞后性指标相反，是一个前置指标，可以理解为交付过程中的过程质量。
一、对于线上的交付质量，可以通过以下维度进行度量
从上述指标不难看出，保障交付质量是要努力减少线上故障和线上缺陷，降低故障级别。但是线上故障又是不可避免，那么就需要最大限度地降低线上故障的影响，比如降低线上故障的恢复时长，减少对生产环境真实用户的影响。
二、交付过程中的质量度量
1、需求阶段，可以通过以下维度进行度量
一般来说，需求质量 Bug 数应该占总 Bug 数的 5% 左右。需求评审打回的标准可以是发现 5 个逻辑类的问题。需求评审打回、需求变更、需求插入等情况，对软件过程的健康度和质量有较大危害，建议制定相对严苛的流程规范，以减少此类情况发生。比如需求评审不通过时，需求文档的作者需要向相关人员发送重新评审的申请邮件，并针对当次打回情况做改进分析。
2、在开发阶段，可以通过以下维度进行度量
一般情况下，提测质量等于 1 才符合预期，即 15/15、12/12 等，因为只要有 1 条冒烟用例执行不通过，则可以进行提测打回。
3、在测试阶段，可以通过以下维度进行度量
4、在发布阶段，可以通过以下维度进行度量
通常情况下，构建失败率和发布回滚率应该控制在 1% 以内，所以每一次发布失败和发布回滚都值得深入分析。非发布时间发布，很容易造成线上故障，且由于处于业务高峰时段，出现故障时容易出现“雪崩效应”，造成的业务影响难以估量，因而应予以杜绝非发布时间发布线上服务。
三、质量度量的认知
追求单一或局部指标的提升比较容易，但很容易产生扭曲行为，构建指标体系并整体提升才是正确的路。比如，要想降低千行代码 Bug 率，可以在不增加 Bug 数量的前提下，有意稀释代码，这样该指标肯定能降低，但没有任何意义，自欺欺人。
同时度量指标的确定，要与相关方达成共识，自上而下认可它们。质量不是测试团队自己的事情，需要产品研发相关方共同的努力。如果制定了一个度量指标，需要相关方提升它，但相关方并不认可它，就容易产生太多无效沟通和扯皮。
作者简介：NJL，京东集团测试开发，京东大学内部讲师，CSDN博客专家，CCTalk成员。
欢迎关注：
往期回顾：
测试各类自学成长笔记
面试百问：没有需求文档怎么测试？
面试百问：如何单独负责测试项目？
测试的核心价值到底是什么？
为什么职场中那个很努力的人却先离职了？