回放测试概述：什么是接口回放测试、应用场景与价值
大家好，我是你们这趟 Retrofit 回放测试之旅的向导。
做 Android 开发这么多年，我踩过最多的坑，就是接口联调。每次后端改了个字段，我这边就要手动构造一堆 mock 数据，跑断腿去验证。说实话，这效率太低了。直到我接触了接口回放测试，这问题才算是找到了解法。
1.1 什么是接口回放测试
简单来说，就是把线上真实流量“录”下来，然后在我们本地测试的时候“放”一遍。
你想想看，线上用户发了什么请求，服务器返回了什么结果。这些都被我们记录下来。然后在跑单元测试或者集成测试时，我们不再真的去调服务器，而是用录好的数据来模拟。
我第一次接触这个概念是在 2019 年。当时有个项目，每次回归测试都要手动改几十个 mock json 文件。后来发现改完后，跟线上实际返回的结构还有差异。这种痛苦，我猜很多同学都体会过。
为什么会有这个需求？说白了，mock 数据是“你以为”的线上数据。你定义的 Bean 结构，你造的测试数据，难免会跟真实情况有出入。尤其是后端接口改版，你这边浑然不知，测试还是绿的，一上线就崩溃。
1.2 回放测试的核心流程
整个过程其实不复杂。我习惯把它分成三步：捕获、存档、回放。
先看一张图，能帮你快速建立直觉。
看完这张图，我再具体说说每一步是干什么的。
| 步骤 | 做什么 | 产出 |
|---|---|---|
| ① 捕获 | 通过 OkHttp Interceptor 拦截请求与响应 | 序列化的 .json 或 .pb 文件 |
| ② 存档 | 按测试用例/模块归类存储 | 回放数据仓库 |
| ③ 回放 | MockInterceptor 被替换为本地读取器 | 测试通过/失败报告 |
这里有个关键点：捕获的数据必须完整。不光是请求体，还有 URL、Header、StatusCode。我遇到过有人只录了 Response，结果请求参数变了都不知道。
1.3 应用场景与价值
光说概念可能有点虚，我们聊聊实际能用在哪。
- 回归测试加速：不用每次都跑全量接口。跑回放就像看录像，一秒跑完几十个接口。
- 线下复现线上 Bug：线上出了 crash，把当时的请求拉下来，本地一放，问题立刻重现。
- CI 流水线集成：每次 PR 提交后自动跑回放。如果新代码改变了 Response 解析，立刻报红。
- 兼容性验证：换 Retrofit 版本、换 OkHttp 版本时，跑一遍回放。结果不一致说明有问题。
它的价值其实就一句话：用真实世界的噪音，来检验你代码的鲁棒性。 你不用再担心 mock 数据跟线上不一致，也不用焦虑什么时候后端悄悄改了接口格式。
我个人习惯是在项目初期就引入回放测试。越早引入收益越大。等到项目大了再改，成本就高了。
嗯，说到这，你应该对接口回放测试有了一个整体的认识。它不是什么高深的技术，核心就是记录与重放。但一旦用好了，你会发现你的测试代码变得特别“抗打”。