聊聊交付质量与测试覆盖率

昨天星球里一位同学抛出了这样一个问题：总监问他，如何度量测试交付的结果，是足够完全覆盖的？

有同学说增量代码覆盖率；有同学说增量代码覆盖率不够，需要全量代码覆盖率；也有同学说，看线上的问题反馈，是否存在测试阶段没有覆盖到的。种种说法，哪个更正确？

这篇文章，聊聊我对于交付质量，以及测试覆盖率的看法。

首先，评价任何软件产品的质量，一定是以最终的生产交付质量为准，或者说供用户使用的产品质量。

如果用户在使用过程中不出问题，那就可以说明这款产品的质量很好。相反，如果用户在使用过程中出现了大量问题，即使你在测试阶段做了再多测试工作，也无济于事。

其次，从软件工程的角度来说，软件质量如果不加以控制，则会陷入不断熵增的状态，直至崩溃。因此软件工程的核心是聚焦质量的不可控问题，然后通过工程化的方法来保证质量。

影响软件质量的要素有三个，分别是范围、时间和成本。三者之间是互相制约的关系，我们最多只能追求其中两点。在保证交付质量不变的前提下，需要在三者之间找到一个平衡点，并根据具体情况动态调整优先级和资源配置。

假设每版本交付的范围和时间不变(很难改变)，那我们能做的就是通过降低成本(提升效率)来提升交付质量。提高效率可以从需求实例化、流程规范化、过程自动化等角度开展工作。

想要测试过程尽可能通过自动化方式执行，那么需要对执行的每个步骤进行量化，或者说通过明确清晰的步骤与可预期的结果来衡量测试执行的结果。这个时候，问题就回到了测试覆盖率上。

最后，一句话总结：交付质量是最终追求，高效测试是必经之路，而测试覆盖率则是通往必经之路的必要手段。

对测试同学来说，质量是团队的安全线，也是最高目标。在保障交付质量的前提下，如何提高测试执行效率呢？我个人认为可以分为短期和长期两个阶段来开展实践。

短期改进可以从度量、工具、轮子三个方面开展：

1、度量：要达到提效的目标，首先要有一个对比，即首先要知道当前的成本投入和效率是多少，识别其中的低效率和高成本环节，然后才能制定对应的改进方案。

度量结果只是一个评估当前状况的参考值，仅对后续改进提供参考，但绝不是唯一指标。

2、工具：要想短期内提升效率，一个不是捷径的捷径就是改善工具。

比如以前接口测试都是手动执行，提升效率则可以采用自动化的方式；以前准备测试数据都是手动写SQL去一条一条插入数据，提升效率则可以考虑流量录制或者通过存储过程的方式去预埋数据，这样效率也会提高。

工具优化意味着需要投入一定的额外成本，短期内成本也会上升，但长期来说，工具改善后带来的效率提升是更高的。

3、轮子：造轮子这件事大家都懂的，轮子多了，其实就是一种功能重叠和额外的资源浪费。

造轮子需要投入资源，维护轮子需要资源，且很多轮子在功能上是重叠的。因此短期内要降低成本，砍掉重复的轮子就是一种很现实的方案。当然，砍哪些轮子，如何整合资源，需要评估分析。

长期投入是一个持续迭代优化的过程，以一个版本迭代为时间周期，低效且高成本的环节，最常见的有如下几种情况：

• 需求不明确、需求频繁变更、临时插入需求；
• 提测质量差、编译打包失败、服务发布报错；
• 服务经常挂、服务频繁发布、测试数据不可用；
• 大量的会议、沟通确认信息、跨部门资源协调；

鉴于上述几点因素，在长期投入改进方面，可以从如下几个方面入手：

• 测试左移：加强需求和设计阶段的评审和风险评估，准备应对风险的冗余方案；需求实例化。
• 质量门禁：推动软件研发交付各阶段的质量门禁，做好质量卡点，比如提测冒烟、单元测试等。
• 质量内建：通过流程规范宣讲以及以身作则的带头实践，要求各个角色实时对软件的质量负责，减少因为前期风险不可控而导致后期的修复成本增加，进而浪费大量资源。
• 环境治理：测试环境的稳定性是一个被大家忽略的环节，但这是我们所有测试活动开展的基础。可以通过规范变更流程、打通底层数据、变更权限收口等手段来提升测试环境的稳定性，降低环境不可用带来的时间浪费和排查问题带来的成本。

最后，我们来聊聊测试覆盖率的话题。

质量度量的本质是控制风险并解决问题，通过量化手段评估最终质量的过程。而测试覆盖率，就是质量度量过程中很重要的一个评估维度。

个人观点：测试覆盖率和需求挂钩，高度依赖研发过程，需要分阶段执行不同粒度，最终结果和线上交付质量成比例。