持续交付 接口自动化测试的覆盖和 Diff 平台的悖论
看了一下这个视频 https://cloud.tencent.com/developer/salon/live-1262
里面说有个接口自动化平台有很多的用例，大概有几万这个数量级。然后还有什么 Diff 平台，如果重构就会根据 diff 平台进行测试。最近也经常看到什么 Diff 平台，比较接口返回的差异等等，这样可以帮助快速找到问题等等，这里面说实话有些真的不能理解，为什么：
- 如果接口自动化平台足够好了，覆盖的 Case 那么多，为什么重构之后测试的时候不能直接用，还要 Diff 平台帮助找到差别
- 如果需要 Diff 平台帮助，为什么又说接口自动化平台做的如何如何好，如何如何方便呢，如何如何效率高呢？
我感觉如果两个是互补关系的，那么必然有互补的道理，但是缺没有人说明白。
我这边的想法很简单：
- 接口自动化测试平台足够好，自动化测试用例覆盖足够多，难道接口的返回结构变了都检查不出来？
- Diff 平台真的有很大用处吗？全量的接口测试结构检查需要多长时间？如果有自动化 Case 了直接把 case 跑起来不就可以了吗，如果 case 在不同环境里面都可以直接运行，那为什么还要什么 diff 平台？如果自动化 case 都不全，又花精力去搞什么 diff，那为什么不去多补补 case
- 测试用例，diff 工具到底分工在哪里？Diff 出来的东西到底有多大的用处？
期待各位大佬们的帮忙呢。
- 接口自动化测试平台足够好，这个很难，100% 的覆盖率，也不能保证用户数据 100% 覆盖，只是保证了 code statement 或者 code line 覆盖率
- diff 平台足够好的化，理论上是可以吃掉接口自动化。
个人理解，按照你说的描述，diff 平台指的应该是录制回放后，对比线上和新版本之间返回值差异的 diff 平台吧？
1、diff 平台通过录制回放来积累测试数据和场景，能够积累到的数据量可以轻松到十万甚至百万级，成本上比每个接口写自动化低很多。而且这个是线上流量，最接近真实用户场景，发现的问题价值也高。简单理解的话，可以理解为是一种另类的灰度，来的操作还是用户的真实操作，只是结果只用来比对，不会真实返回给用户。对于大型应用效果甚好，毕竟可能是过万的接口数量，录制 1 小时可能就能有几十万的数据了，也没啥维护成本（下次用那就下次再录好了），比给这么多接口做接口自动化爽多了。
2、如果既有 diff 平台，又有接口自动化，一般分工是接口自动化主要针对新增的接口，因为这个时候没有线上流量可供 diff；而存量接口主要通过 diff ，通过录制 - 回放流量，可以覆盖更多的场景（比如特殊的数据、特殊的用户），需要付出的只是录制的耗时和回放的耗时。
3、至于互补， diff 平台的原理决定了它对一种场景是无能为力的，那就是还没上线，没有 “正确数据” 可供 diff 的新接口、新代码。另外为了保障所有输入值一致进而输出值可比较，基本上程序的所有输入（比如查询数据库的返回值）都是被回放的，不是真实执行的，所以起不到集成测试作用。个人理解可能由于这两个原因，加上本身技术门槛（不是所有的程序都能直接做录制回放，而且目前也没有开源或者开放的、兼容性很强的 diff 平台），所以 diff 平台基本上宣扬都很好，但实际在很多公司基本没有，基本集中在基础设施投入比较大的大公司内部。
为什么重构之后测试的时候不能直接用，还要 Diff 平台帮助找到差别
补充一下对这个问题的回答，基本上重构项目都是比较老的项目，所以接口自动化程度嘛，基本都不会很高（和接口自动化平台强不强无关，基本都是无可奈何的历史原因）。为这次重构补充所有接口自动化，工程量太庞大，也基本不可能满足重构的时间要求。
我觉得线上采集数据的方式有天生的缺陷
- 线上的量看起来可能大，但有可能只是重复一种场景或部分场景。除非对采集的数据筛选分析，再做补充，那又回到了接口用例设计
- 如果只是粗暴回放对比，那成蛮干凑绩效了
我很赞同你的想法 @hellohell ，多谢 @ 恒温 @ 陈恒捷 大佬，这块我自己也想到一些问题：
- 线上数据如何说明场景覆盖更全了？有什么理论依据吗？要不然就算采集了数据，回放 100 万次是同样的用例有什么价值呢？
- 如果说异常数据只是偶然的几条造成的，这个数据如何被采样到 diff 平台？不能只是撞运气吧
- 还是就是数据脱敏的问题怎么解决？这么多线上数据被用来做测试的话，我感觉要被告死的
- 还有就是线上数据和测试环境的用户基础数据应该是完全不同的，线上数据就这么容易的可以回放了？感觉真是有很多很多的问题待解答
到底这中 Diff 平台带来了多大的提升？
继续请各位大佬帮助回答。
simonpatrick
回复
1、线上数据不是说明场景覆盖更全，只是说明使用最频繁的部分会被覆盖。不能保障缺陷率很低，但可以保障不出 P0、P1 这种对用户影响很大的缺陷。类似于冒烟测试之于全量测试的作用，用相对低的成本发现相对高价值的问题。也有做到非常强大的，会去进一步筛选流量达到更高覆盖率，去年 MTSC 大会百度有分享他们千万级别的录制流量怎么结合机器学习做流量的筛选。
2、这种问题确实是碰运气。。。不过这类问题属于非常偶发的问题，对于重构项目出现个别用户问题一般并非那么不可接受，而且相比人工去补回各种接口测试，录制回放性价比高不少。
3、一般使用会配合堡垒环境 + 平台脱敏，不会给测试直接接触原始线上数据的。
4、录制回放一般有两种，一种是只针对读接口，那么只需要恢复录制开始时的数据库相关内容即可。另一种是针对读和写接口。对于这种，可以这么考虑：程序员编写的程序，本质上是对输入（包括用户输入、数据库读取的数据等）进行逻辑处理，然后再进行输出（比如网络的 response ，数据库的重新写入）。在录制回放里面，录制的不仅是网络流量，包括数据库、中间件的输入和返回都会一并被录制和回放。对程序来说，感受到的输入会和线上基本一致。
至于带来多大的提升，这个估计得大厂里有这个工具能实际使用的同学才能回答了。
diff 平台需要把代码覆盖率考虑进去，从而精简 case，根据覆盖率的结果去覆盖相应的参数接口，有针对性的输入才能得出相应的输出，且整体数据以及操作比较明确。
如果自动化 case 都不全，又花精力去搞什么 diff，那为什么不去多补补 case
工作也挺久了，除了一些开源项目，没有发现 case 全的情况，即使写得比较多，测试用例的质量也一言难尽
达到一定效果的情况下，两者成本差距非常大
testcase 只能在测试环境里运行，不能在其他环境里运行