作为低值易耗品的自动化测试用例和到处是暗物质的可观测宇宙

如果一个系统在5年后再次进行重构，那么它配套的自动化测试用例、可观测平台数据、接口数据资产又是什么个情况呢？这是来自一个刚接手了类似这样一个系统的重构测试任务的同学的吐槽。

图片

项目上线就封存的自动化测试用例

自动化测试用例是资产还是一次性低值易耗品？

在若干年前，在这个系统的上一次重构时，开发同学将这个系统从传统的C++程序转写成了基于JAVA的系统。因为涉及到行业协议、又涉及到MONEY(每天很多的那种), 因此开发和测试的同学还是很认真地进行了测试。至于自动化测试，也是在这个项目里引入了DBRider这个工具、模拟外部金融机构的挡板以便于流程性的测试、做了不少可靠性测试用于发现往来消息传递可靠性的问题。最终上线之后业务和架构层面若干年都没有发生什么线上事件。这个项目也是该同学转做DevOps平台之前带的最后一个测试项目了。

然后最近随着系统的再一次重构，以及该同学若干年后重操测试旧业，这个系统的测试又回到了其团队手中。

于是，第一个槽点就来了。团队负责回归自动化用例的小伙子发现某个简单的Create类的接口用例跑不通。本来这个事情也挺正常的，系统重构嘛。结果询问开发后说这次重构主要是改SQL,并没有改JAVA代码。然后去git blame了一下出问题的那个接口的后端代码。发现在在当年提交测试用例进代码库后的大半年后，这个系统应该进行了第一次上线后的业务改造。证据是这个接口的代码进行了修改，入参中新增了一个必填项，又修改了返回值的业务含义！

从这个情况来看，团队得出了第一个结论：这些自动化用例在提交之后，应该过去的若干年中再也没有被执行过。虽然这个系统在后续也经历了若干次改造，但是都是通过前端点点点+新增别的自动化用例的方式来进行的测试活动。

图片

自动化测试的投入就是这么从固定资产性投入变成了一次性低值易耗品的投入。

为什么没有跑呢？这就有点意思了。去询问了一下后续接手测试的同学，首先是重构结束之后，后续的维护开发和测试就换了一拨人。测试团队重新接手和项目结束中间的一段时间，是开发团队自行在维护。而测试团队重新接手后新增的用例，被在了另外一个repo里维护和执行的，直到DevOps平台建设了接口自动化测试模块。当然测试范围就仅限于后续改造的点了，也就是用例和测试范围非常有限。

当然第二个槽点是这些在另一个repo里的用例还没来得及迁移到这个新建的测试平台里。

图片

可观测宇宙中的暗物质

我调用了谁，谁又调用了我？

由于这是一次重构，那么影响分析是必须要做的事情。之前建设的架构治理平台就派上用场了（参看之前写的文章）。

我调用了谁，谁又调用了我？这是最基础的数据了。

前面提到了由于某个接口的返回值的业务含义被调整了导致自动化测试用 例的失败。所以就想到去架构治理平台那边查看一下这类数据，看看是不是除了前端界面调用这个接口之外，就没有别的调用方了（除了用例）, 这样即使改回去也是比较安全的。

但是在平台上一番搜索之后，发现查无此人。再一询问，发现之前的可观测平台是伴随着系统云原生化进行落地的，也就是将关注点放在了上云的系统，而那些没有上云的遗留系统，则没有要求上报数据。这就形成了数据黑洞了。

图片

然后接口平台又出幺蛾子了。

架构治理平台这边没数据，那就看看接口平台上的数据吧，譬如某个接口有哪些测试用例。结果再次查无此人。

经过分析，发现是接口平台在CI环节进行OpenAPI解析时，发现这个系统的（大）部分接口写法不规范，于是只上报了符合规范的部分接口，但是没有通过问题上报机制把这些问题报出来。例如，某个controller里面有大约20个接口方法，但是在接口平台上只有一个接口的数据。

加上接口覆盖率等发布门禁指标推广的迟滞，导致事情一直没有爆出来，也就没人关注到了。

尴尬地想抠脚趾。