后台有同学留言问了这样一个问题：想在团队内推动质量度量落地，对每版本迭代的交付质量有更好的评估，但没有太多的实践经验，有没有什么落地方法或者注意事项。
首先聊聊质量度量本身，即质量需不需要度量？
答案显而易见：质量需要度量，而且需要持续的度量！为什么呢？
我们所从事的软件测试工作(随着技术不断发展，现在也叫作质量保障)，工作对象就是软件系统。经过需求设计、需求评审、技术设计、代码开发、测试验证、上线发布等多个环节，才能保障这些软件的最终交付质量。
这一整套复杂的流程，实际上就是将不确定性(需求)转化为确定性(具有严密逻辑的软件系统)的过程。确定性，需要一定的衡量标准来评估它是否满足预期的设计，因此需要一定的数据来进行度量。
而持续度量的原因，是业务和技术本身就处在一个不断变化发展的状态，需要持续的度量和评估，才能保障软件系统的质量长期处在一定的水准之上，满足用户需要和保障业务目标达成。
质量度量的本质，是具体的定量，而非抽象的定性。
其次聊聊质量度量的注意事项，这些注意事项是我个人结合工作经历和实践总结的经验教训，仅供参考。
质量保障是一个体系化和长期建设的过程，而质量度量作为最重要的一环之一，在落地过程中需要持续跟进和优化。
- 质量保障不仅仅是QA同学的事情，因此质量度量也不能只关注测试维度。
- 度量指标需要根据团队特性和业务具体情况来制定，并且需要评估是否合理，而不是强行制定强行执行。
- 质量度量是为了保障最终交付质量能更好的满足用户需要，进一步达成业务目标，而非为了度量而强行度量。
- 质量度量并非一蹴而就，在软件不同的生命周期和团队成熟度阶段，度量的范围和执行严格程度要灵活变通。
最后，分享一些我对于软件质量度量的一些思考。
1、不要为了度量而度量，找到合适的度量对象很重要。
比如听一些同学说他们的质量度量指标，就有首次测试用例执行通过率，以及累积测试用例执行通过率。
这两个指标是为了解决什么问题？如果只是看到别人有，那我也要做，只是浪费时间和资源。而且你花大力气去做，大概率也得不到整个技术团队的认可。
2、度量指标一定要和具体的问题挂钩，否则指标没有意义。
最常见的，测试用例覆盖率，测试用例通过率。这个度量指标的作用是什么，要解决什么问题。
比如提测冒烟通过率必须100%，否则证明了主流程存在block，影响测试进度。这个度量指标要解决的是可测性和测试进度，提高从编码到测试环节的交付产出物质量。
3、度量的指标和数值一定要和直接干系人达成一致。
还是以冒烟提测通过率为例，如果研发团队不认可，怎么办？
很多时候测试团队没有太大话语权，没办法影响到研发团队。这个时候要学会迂回策略。即如果冒烟提测通过率不达标，导致了什么结果，这个结果的风险是什么，会带来什么不好的影响。然后向更上一层汇报，暴露风险。
4、度量指标和数值不能解决问题，只能证明发生了什么。
设置度量指标和衡量的数值后，要明确一点：度量产生的数据不能直接解决问题，而是证明产生了什么结果。
要分析数据背后的原因，什么原因导致了这个结果，这个原因的风险和对交付质量有什么不好的影响，然后才是拿着数据和分析的结果去推动改进。
5、落地质量度量有很多前置条件，质量度量不是单一存在的。
举个例子，通过度量缺陷数量和用例数量以及对应的百分比，来评估每版本的编码质量。
这个逻辑没问题，但不是单单搞个对比数据就可以的。缺陷&用例需要和对应的代码分支关联，代码又要和需求关联。否则只有数据，没有因果关系，证明不了问题，也解决不了最本质的需求不完善和代码质量不高的问题。
6、质量度量是一个复杂的技术工程，更需要大量的沟通和协作。
工作真正要解决的是人的问题，技术不存在难点，难点在于思路，以及说服其他人配合你行动。
想清楚再行动，先从小范围试点，从最痛的点开始，这样推进的动力更大。
