测试策略总览：单元测试、集成测试、端到端测试、回归测试在流水线中的角色

说实话，我刚入行那会儿，对测试的理解特别简单——能跑就行。直到有一次，我负责的一条支付流水线在凌晨两点挂了，原因是上游改了字段类型，下游没感知。那晚我盯着告警屏幕，心里只有一个念头：测试策略不是流程，是流水线的安全带。

这一章，咱们就把四种核心测试类型掰开揉碎。我会结合自己踩过的坑，告诉你它们各自该在流水线的哪个环节出现，以及——为什么少一个都不行。

单元测试：流水线的第一道防线

单元测试，说白了就是给每个函数、每个模块做体检。我个人的习惯是：写数据转换逻辑之前，先写单元测试。为什么？因为数据流水线里最隐蔽的 bug，往往藏在某个看似简单的 map() 或 filter() 里。

举个例子，你写了一个清洗函数，把空字符串转成 null：

def clean_empty(value):
    if value == "" or value is None:
        return None
    return value.strip()

看着没问题对吧？但如果你不写单元测试，你永远不会发现——当传入的是数字 0 时，0 == "" 在 Python 里是 False，但 0.strip() 会直接报错。我曾经就在生产流水线上被这种问题坑过，数据跑了一半全挂了。

集成测试：接口契约的守护者

单元测试过了，不代表模块之间能好好配合。集成测试就是用来验证模块间的握手协议的。

我记得有一次，数据团队改了 Kafka 消息的 schema，把 user_id 从 int 改成了 string。单元测试全绿，但集成测试一跑就炸——下游的聚合模块还在用 int 做 join。你想想看，这种问题单元测试根本抓不到，因为每个模块自己都是对的。

集成测试的核心关注点：

• 数据格式一致性：上游输出的字段类型、长度、是否可为空，下游是否认
• 接口超时与重试：网络抖动时，流水线能不能优雅降级
• 状态传递：批处理作业的 checkpoint 能否正确传递

端到端测试：模拟真实世界的压力测试

端到端测试，我更喜欢叫它“全链路彩排”。它模拟的是真实用户或真实数据源触发完整流水线的过程。

为什么要做这个？因为有些问题只有在真实数据量、真实并发、真实依赖下才会暴露。比如：

• 某个 API 在并发 100 时响应变慢，导致流水线整体延迟飙升
• 数据库连接池在高峰期被耗尽
• 某个中间件在数据量超过 10GB 时内存溢出

我参与过的一个项目，单元测试和集成测试都过了，但端到端测试一跑，发现从数据采集到报表展示，整整花了 47 分钟——业务要求是 5 分钟以内。如果没有端到端测试，上线那天就是事故现场。

回归测试：防止“修好一个 bug，引入三个新 bug”

回归测试，说白了就是给旧功能上保险。你改了一行代码，怎么知道其他 100 个依赖它的模块没受影响？

我曾经犯过一个错：优化了一个数据去重逻辑，自测通过，上线后却发现历史数据报表的累计值全错了。原因是我改动了去重的时间窗口，影响了历史回溯的逻辑。从那以后，我养成了一个习惯：每次代码变更，必须跑一遍回归测试集。

回归测试的最佳实践：

1. 建立基线测试集：把过去 3 个月发现的所有 bug 对应的测试用例收进来
2. 自动化执行：每次 CI/CD 构建时自动触发
3. 分级执行：核心路径全量回归，非核心路径抽样回归

四种测试的对比与选择

说了这么多，咱们用一张表总结一下：

测试类型	测试范围	执行速度	定位精度	维护成本	流水线中的位置
单元测试	单个函数/模块	毫秒级	高（精确到行）	低	代码提交前
集成测试	模块间交互	秒级	中（定位到接口）	中	构建阶段
端到端测试	完整业务链路	分钟级	低（定位到流程）	高	预发布环境
回归测试	存量功能	取决于规模	中	中高	每次代码变更后

你可能会问：四种测试都要写吗？ 我的答案是：看流水线的关键程度。如果是内部报表流水线，单元测试 + 集成测试就够了。如果是面向客户的实时推荐流水线，四种测试一个都不能少。