管理学大师德鲁克曾说过“如果你无法衡量它，就无法管理它（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 数量的前提下，有意稀释代码，这样该指标肯定能降低，但没有任何意义，自欺欺人罢了。
度量指标的确定，要与相关方达成共识，自上而下认可它们。质量不是测试团队自己的事情，需要产品研发相关方共同的努力。如果制定了一个度量指标，需要相关方提升它，但相关方并不认可它，就容易产生太多无效沟通和扯皮。
**下一个重点，质量运营**
质量运营的目的是质量改进，质量度量是其着陆点，因为形成了多维度的质量度量体系，所以当出现质量痛点或质量隐患时，可以比较容易在度量指标上得以体现。质量运营是基于质量痛点进行分析，找到可能的解决方案，制定规划并推进，对其进行阶段性地复盘和改进。
通过 PDCA 四个方面对质量运营展开说明。
1、P（Plan）：制定改进计划
质量改进计划的制定是质量改进过程的第一步，也是最为关键的一步，可以从如下改进思路制定计划。
通常来说，初创业务或成长期业务下，业务变化快，质量保障建设薄弱，质量痛点问题多，质量目标难以确定，这时候以质量痛点驱动为主。随着业务逐渐成熟和稳定，质量在业务中的重要性更为凸显，对质量目标的要求越来越高，这时候以质量目标驱动为主，质量痛点驱动为辅。
2、D（Do）：实施落地计划
无论采取怎样的质量改进思路，质量运营都是一个持续运转和迭代的过程，运营周期不同，目的和关注点也有较多不同，具体如下：
数据收集和聚合
有了质量度量体系，还需要针对这些指标所对应的数据进行收集和聚合，这就需要在产品研发过程的关键环节进行”埋点“，对关键过程数据和结果数据进行存储。因此，建议利用成熟的项目过程管理工具，如 Jira、TAPD 等。随着度量指标的丰富，可能还需要进行二次开发或者自建平台。
3、C（Check）：复盘和反馈
复盘是质量运营中非常关键的环节，它起到了承前启后的作用。它的最佳场所，常常体现在各种书面总结报告或复盘总结会议上，能够起到最大程度的效果触达，同时提升相关团队的质量意识和认知。
4、A（Action）：改进和推广
基于前面的步骤，可以知道质量运营计划和改善策略是否有效，如果有效，则进行推广，反哺到日常研发过程中，尽量形成平台能力或可落地的规范。
比如，经过一段时间的质量度量与运营后，当各团队的 Bug 工时比都小于 0.6，那么可以和相关方团队达成共识，将标准提高到 0.4。而如果改善未达预期或完全无效，则可进一步分析原因，从而优化或改进落地计划。
5、 质量运营实践认知
很多测试团队所做的质量运营都止步于通晒数据，但是质量运营最重要的是要基于数据进行分析，帮助相关方做改进，同时跟进反馈改进的效果。做改进是主要。
质量运营需要推动多个团队配合，应“先礼后兵”，不可轻易用向上管理的激进方式。首先，采用向上管理的方式容易使团队间产生对立情绪，影响日常协作。其次，没有哪个团队不重视质量，只是有时候它们在质量改进方面并不是足够专业，这时候反而是测试人员扮演老师和教练角色的时候，带领他们一起做分析、改进和提升。
