2025第一篇-精准测试等基建的十五种变现场景

以精准测试等为代表的质量保障的基础设施建设，常常面临一个尴尬的局面：开发者们精通底层技术，却往往不擅长实际应用场景的推广落地。这种状况容易导致技术优势无法转化为实际效益，空有一身武艺，以为《胜券在握》，却最后落得两手空空的窘境。囧囧。面对企业领导者对于“降低成本、提高质量、增加效率”这一看似是“不可能三角”的要求，本文将探讨如何以综合利用接口变更清单、代码静态分析、调用链分析、Git差异分析、流量录制回放等技术，实现质量保障的数字化，进而在DevOps的各个环节实现技术变现，提高软件质量和测试效率。以下是笔者梳理的15个应用场景。请注意，本文主要讨论应用场景，不展开讲述背后的技术。

接下来，笔者将简略地逐一介绍一下上述场景。

变更接口清单【1】

这是最为基础的一个应用，也是最容易变现的场景。

接口变更有两个含义，分别是 接口定义的变更和接口实现的变更。

接口定义的变更可以是指接口方法的入参和返回值的变化。如接口入参或者返回值的类型是对象（如xxxDTO），那么这个对象的属性的增删改，就可以视为是接口定义的变化。

而基于代码静态分析，结合调用链分析的结果，首先就能得到微服务的每个接口的调用链，进而为接口建立一个调用链的知识库A。在这个基础之上，结合Git diff，找到变化部分的代码清单B。结合A\B的数据，就可以得到变更接口的清单，这个可以被视为是接口实现的变化。

能够实现变更接口清单功能的开源项目，有如code-diff,jcci等。而java-callgrah2等则提供了JAVA语言的静态调用链分析的底层能力。

变更接口清单的作用

最基本的作用，就是使用这个清单来快速识别和测试受影响的接口，确保所有变更的接口都经过适当的测试。

如果DevOps平台有接口覆盖率的能力，就能结合变更接口清单得到一个变更接口覆盖率【2】，类似于增量代码覆盖率。如果DevOps平台还有门禁能力的话，也可以额外设置变更接口覆盖率门禁【3】。

变更接口清单 叠加 线上调用记录。

通过可观测平台的数据，获得每个接口的忙闲时段、冷热等数据，以及跨微服务的调用链数据，则可以额外实现两个场景

热点接口覆盖率【4】，这是一个业务视角的统计指标。结合着线上接口的调用情况等，可以识别出对于业务影响比较大的接口作为“必测接口清单”或者类似的质量保障要求。当然，也可以根据业务需求来人工标注出一个清单，意思是一样的。

跨服务的影响分析【5】

《三毛从军记》中有个段子，三毛被抓壮丁后，长官宣布完任务后，要求主动上战场完成任务的向前一步，三毛没有动，但是列队其他人都后退了一步，于是三毛就获得了任务。在微服务架构下，类似的情况也一直在发生。而现实的业务场景中，往往会出现类似这样的问题，就是某个服务自身没有变化，而由于其所依赖的下游应用的变化，导致了其自身的行为或者是状态不符合预期，进而产生了业务问题。

那为什么没有在前期的影响分析、质量保障活动中发现这些其实是显而易见的问题呢? 在前述所有的场景中，我们的注意力都是在有变化的应用身上。就像“醉汉在路灯下找钥匙”一样，只在有灯光的地方进行寻找，而钥匙则静静地躺在路灯光照范围之外。

因此，如果能结合线上的可观测数据等跨服务的动态调用链tracing数据，就可以在下游微服务的某个接口发生变化时，根据这些数据，来提醒上游的调用方。这就是所谓的跨服务的影响分析了。

目前为止，我们已经围绕着变更接口清单，结合着git diff、覆盖率、tracing等技术，介绍了5种应用场景了。

那么，上述技术在测试用例的环节，可以有哪些应用场景呢？

紧接着刚才提到的可观察数据。我们知道在tracing服务中，除了有链路的调用数据，还包括了方法某次执行的具体入参和出参。

因此，我们可以得到另外一个应用场景， 流量录制回放【6】。当然，如果是使用Skywalking等tracing平台，那么其自身是只有录制功能，没有回放功能的。业界也有jvm-sandbox等工具箱以及配套的jvm-sandbox-repeater等录制回放工具来实现上述场景。不过由于此类工具通常不会在线上环境部署，因此建议优先考虑能够线上线下通吃的方案，这样如果能“一鱼多吃”的话，性价比比较高。

前面讲的主要还是接口级别的流量录制回放。目前也有团队开始利用这些流量探索 方法级别的录制回放，也就是基于目标方法的出入参流量数据，来实现单元测试用例自动生成【7】。笔者也实现过一个简单的基于AOP方案的流量录制生成集成测试用例的案例，感兴趣的读者可以移步《2021第一篇-流量录制回放完整案例》查看。

基于这个技术，也可以借助于LLM，将此类数据作为few-shot来让LLM生成更为贴合业务实际的单元测试用例【8】这就比录制回放能产生更多的差异性，理论上也能覆盖更多的代码路径。

此外，流量录制回放还有一个简单的场景，就是所谓的客户端流量录制。这个技术的典型应用就是手自一体【9】了。感兴趣的读者可以参考笔者之前写的文章《手自一体提效软件测试》

谈完了用例自动生成，再来谈谈经典的用例推荐。

这就到了人人熟知的精准测试环节了。结合着覆盖率统计的基础技术，通过流量染色+覆盖率统计算法二开等方式，得到每个测试用例对应的覆盖率统计报告。再通过倒排，得到每个方法对应的测试用例集。当结合git diff之后，就可以根据这份清单来为有变化的方法来推荐测试用例了。当然，此时精准测试用例推荐【10】的噪声也比较大，需要通过某些算法来筛选出每个方法对应的测试用例最小集【11】，这样的推荐就更加“精准”了。

当然，如果不和覆盖率统计结合，而是采用变更接口清单+接口测试平台的方式，通过筛选某个接口在接口中心的测试用例，也可以得到一份比较粗糙的接口测试用例推荐清单【12】。

在聊了用例生成和用例推荐之后，就来到了用例执行了。

前面提到了可观测平台的数据，在测试用例执行的过程中，结合流量染色+可观测平台中的日志数据，可以为每个测试用例提供一份配套的服务端日志。当某个测试用例执行失败时，就可以在测试用例平台上直接进行用例排错【13】，而不再需要跑到环境当中tail或者到可观测平台上去筛选了。

更进一步地，如果有测试用例自身的执行日志，再叠加对应的日志和/或tracing数据。如果用例执行失败，结合前后两次的这些数据，就可以借助于LLM来进行用例执行结果分析，用于快速排错【14】或者是自动化缺陷上报【15】。

最后放一张2025年的工作思路的图，简单粗暴。如果说2024年是实现了生产线、质量保障等工作的数字化，那么2025年就是基于这些数据寻找价值变现的场景了。

那么，你的2025年工作主线是什么？还有更多的变现场景吗？欢迎留用并顺手点赞哦。