1. 课程概述：Mock回放与CI自动化测试集成

我先问个问题——你有没有遇到过这种情况？

辛辛苦苦写了一大堆接口测试，结果跑 CI 的时候，依赖的外部服务突然挂了。或者，某个第三方 API 改了响应格式，你的测试全部红了，但你的代码其实一条没改。更让人崩溃的是，这种红跟你自己的逻辑完全没关系，纯粹是外部依赖不稳定。

嗯，我早年在一个金融项目里就吃过这种亏。每天上班第一件事，不是看代码，是先看 CI 报告里有多少「假阳性」。当时团队三十多人，每周花在排查这类问题上的时间，少说十几个小时。后来我们引入了 Mock 回放机制，彻底把 CI 的稳定性拉了起来。

这一章，我们先从概念上把 Mock 回放和 CI 自动化测试的关系理清楚。说白了，就是给你一张地图，告诉你这门课要带你走到哪，路上有哪些风景和坑。

1.1 Mock 回放到底是什么？

Mock 回放，你可以把它理解成「录磁带」。

第一步，我们先把真实服务（比如支付网关、用户鉴权系统）的请求-响应数据录下来。第二步，在测试环境里把这些录好的数据「回放」给被测代码，这样你的代码以为自己在跟真实服务通信，但实际上它只是在跟一份历史数据打交道。

核心价值在哪里？我举个例子。

这里有个关键点：Mock 回放不是简单的「写死返回值」。它保留了请求的上下文——请求头、参数、甚至时序。回放时不仅能匹配到正确的响应，还能校验你的代码是否按照预期的方式调用了外部服务。

1.2 CI 自动化测试为什么需要它？

CI 的价值，说白了就一句话：尽早发现问题，立刻反馈。

但现实很骨感。我在上一家公司维护过一套日均跑 2000 次构建的 CI 流水线。早期没有 Mock 回放的时候，每次构建至少有三个外部依赖要连通：第三方支付、消息队列、短信服务。一到月底对账期间，这三个服务必有一个在降级。结果 CI 报告里全是超时和连接拒绝——全是假阳性。

团队最后养成了「先看失败原因再决定是否合入」的习惯。你想想看，这还叫什么自动测试？

引入 Mock 回放后，CI 的稳定性直接从 75% 提升到了 99% 以上。为什么？因为回放数据是从真实服务录制下来的，天然符合当前的服务契约。每次构建时，测试代码只跟本地快照交互，网络抖动、服务升级、限流策略——这些外部因素全部被隔离了。

1.3 这门课适合谁？

如果你是以下三类中的一员，我建议你认真看看这门课的内容：

• 后端/测试开发工程师：每天跟接口打交道，受够了外部依赖不稳定的困扰。
• CI/CD 运维或 SRE：负责流水线稳定性，需要把假阳性率压到极低。
• 团队技术负责人：想引入一套既能提高测试效率、又不会增加过多维护成本的基础设施。

说实话，这门课不适合完全零基础的人。你需要了解基本的 HTTP 协议、Python 编程和 CI 流水线的概念。但如果你做过一两个自动化测试项目，那门槛就不高了。

1.4 学习目标

学完这门课，我希望你能亲手搞定下面这些事：

1. 理解 Mock 回放的核心原理：不只是会用工具，而是知道回放匹配的算法、录制的粒度选择。
2. 搭建一套可用的回放框架：基于 Python 语言，从录制、存储到回放，自己能走通全流程。
3. 集成到 CI 流水线中：在 GitHub Actions、GitLab CI 或 Jenkins 里配置自动录制和回放任务。
4. 处理常见异常场景：比如录制数据过大、请求顺序变化、加密参数如何忽略等。
5. 建立团队级最佳实践：知道哪些接口该录、哪些不该录，如何维护回放数据仓库，怎么用版本管理。

1.5 本章知识体系

为了让整本书的结构更直观，我画了一张图。你可以把它当作路线图：核心概念在上层，落地实践在下层，中间用 CI 集成串起来。

整本书就围绕这三个层面展开：先讲怎么录制和回放（上层），再讲怎么和 CI 结合（中层），最后是落地后带来的实际收益和避坑指南（下层）。每一章都会给到你即拿即用的代码和配置。