原文链接 https://mp.weixin.qq.com/s/RAtrfwMEo72PtKDDba0WwA
01/为什么再聊测试充分度？
为什么说是再聊，是因为22年写过一篇测试充分度的文章《对测试充分度的思考》，当时从整个测试流程（宏观）角度切入，例如 单元测试、集成测试、全链路测试以及非功能测试，以及从代码覆盖率（微观）角度，分析哪些代码行/分支等没有测试用例覆盖到，力求每个环节都做到尽善尽美，没有遗漏。
第二个原因就是测试充分度确实太重要了，不是说老板经常在夜深人静的时候走到你身边问上几句“xx，怎么样，测完了吗？测试的怎么样？”，对你来说有压力，不知道怎么回答。而是传统意义上来讲，测试充分度非常依赖测试人员业务经验，精通业务的测试老鸟熟知业务代码，自然在设计用例场景的时候考虑比较全面。反之，而测试新人则出现遗漏测试场景的概率比较大。
而如何回答“测够了吗?”。代码覆盖率是衡量测试充分性的起点，但远远不是终点。要回答”测够了吗”，至少还要考虑是否测了所有的场景、所有的状态转移路径等等。即便如此，我们可能还是无法100%确信我们已经测够了，可能我们最终只能做到非常趋近于测够了。
02/为什么说100%代码覆盖率不是终点？
1. 代码覆盖率不等于测试质量；
2. 即使代码覆盖率达到了 100%，测试也都通过了，也不代表就完全涵盖了现实使用中所有可能的情况。
举个最简单的例子，即使我们从测试代码里删除了所有的断言，我们的代码覆盖率是会保持不变的，因为其只会统计应用在测试期间执行了多少代码行。详情推荐阅读这篇文章《The 100% code coverage problem》链接如下↓
https://jeroenmols.com/blog/2017/11/28/coveragproblem
代码覆盖率只是推进测试充分度的一种手段，它不是测试质量（测试充分度则与测试质量有直接联系，一般来说测试充分度越高，测试质量越高），因此100%的代码覆盖率并不一定带来100%的测试质量。
03/对测试充分度的再思考
分析任何事物都有宏观层面与微观层面，例如《宏观经济学》从整个经济整体层面研究这台机器如何运转的，它主要关注国家范围内的经济现象和趋势；而《微观经济学》则是研究个体经济行为，它关注的是个体经济单位在资源分配和决策制定方面的行为和选择。虽然二者研究对象有所区别，但最终目的都是研究如何促使经济机器健康运转，可以说只是切入点不同。
当然这个思想对于研究测试充分度来说也是适用的，下面我就从宏观层面与微观层面分享下观点。
04/微观【接口】与宏观【业务场景】建立联系
从接口微观层面看，一个接口（以http接口为例）包含methodType、请求参数、请求头等关键信息，我们深入一个接口内部的实现，通常是基于请求参数里的某些关键字段做if...else判断，然后走不同的逻辑。
因此我认为接口测试重点是找到关键字段，覆盖关键字段的所有场景，才是提高测试充分度的关键，也可以是说测试用例的有效的，而不是对一个非关键字段设计各种无效测试用例（少投入时间到无关紧要的事物上）。
上述可以得到一个结论：接口参数里关键字段 和 业务场景是强相关的。根据关键字段得到的所有业务场景就是测试充分度的分母。
核心公式:
测试充分度 = 测试用例中覆盖到的关键字段值的业务场景/关键字段所有取值的业务场景
再回过头看代码覆盖率，分析代码覆盖率则不一定能推导出有哪些业务场景。
业务场景A，走代码块A
业务场景B，走代码块B
业务场景C，走代码块A+B
则100%的代码覆盖率不能推导出100%业务场景
因此从理论上讲，我们只需要分析关键字段，其实就可以分析出有哪些测试场景。最happy的情况就是，一个接口就一个关键字段，那么很容易分析出有哪些业务场景。但是如果只是一个接口的关键字段比较多怎么办，难道要做笛卡尔积，似乎又陷入了无法穷尽的境地（测试是无法穷尽的）。
但似乎还有转机，既然理论上做笛卡尔积的业务场景无法得到，我们能否根据线上真实运行的业务场景作为测试充分度的分母？
答案当然是可以的。
因此我们可以分析线上用户发起服务请求的（当然是非敏感）日志，来计算出线上真实的业务场景，然后反过来推动补充线下测试用例未覆盖业务场景。
推论公式:
测试充分度 = 测试用例中覆盖到的关键字段值的业务场景/线上关键字段有取值的业务场景
这样我们就把一个非常依赖测试人员业务经验的问题转化成了一个技术问题，即便业务经验不足也可以通过分析关键字段来设计测试场景。
哈哈，看到这里，是不是觉得测试充分度也不过如此？的确，有时候我们在专注一件事情毫无头绪的时候，不如换个角度去思考这件事情。
今天就聊到这里了，关于测试充分度度量如何实现我们后面有机会再聊。
