我删掉了所有手写测试，用线上流量生成了它们

凌晨两点，第17次CI失败后，我终于承认一件事：我写的测试，测的是我对代码的想象，不是代码本身。

这不是某个小团队的困境。每个后端工程师都熟悉这种场景——你对着POST /orders端点，凭记忆拼凑请求体，猜测字段该填什么，然后假装自己在测试API。

真正击穿我的是一次线上事故。用户传了空数组items和过期优惠券EXPIRED2022，系统返回422。这个组合我从未想过，但用户想到了。生产环境成了我的测试盲区。

问题的根源：我们在用错误的"真相"写测试

手动写测试时，我的信息来源是什么？

读代码时的理解、脑子里对端点行为的假设、可能还记得的几个Postman请求。但这些都不是真相。

真相是生产流量——真实用户、真实参数、真实边界情况。数据已经存在，我只是没用。

六个月前我开始想：如果直接捕获流量呢？拦截每个HTTP请求和响应，拿到方法、路径、请求头、请求体、状态码，就有了一切生成测试的原材料。不是猜的测试，是基于真实发生的测试。

架构比想象中简单

整个链路五步走：

进站请求 → 中间件（按X%采样）→ 脱敏PII（邮箱、令牌、卡号）→ 上传收集器 → httrace generate生成测试文件

采样率是关键。100%捕获没必要，开销和成本都扛不住。10%就能拿到统计上有效的样本。

Python ASGI中间件的核心逻辑很直白：初始化时配好api_key、service名、sample_rate；每次请求先判断类型和随机数，不符合采样率直接放行；符合的就捕获请求体、劫持响应流、记录状态码和延迟，最后异步上传。

fire-and-forget的设计让上传不阻塞主请求，latency_ms用time.monotonic()算，避免系统时间跳变的影响。

脱敏不是可选项，是红线

捕获流量最大的阻力从来不是技术，是合规。邮箱、身份令牌、信用卡号必须脱敏，否则就是埋雷。

我的做法是字段级识别：正则匹配邮箱格式、Luhn算法校验卡号、关键字匹配token/auth字段。脱敏后替换为占位符，比如user_123@example.com变成user_@redacted.com，保留结构但销毁内容。

这里有个细节：某些字段看似无害，组合起来却能定位到人。比如user_id + 时间戳 + IP段，足够缩小到个体。所以脱敏策略要覆盖关联风险，不只是单字段。

从原始流量到可运行测试

收集器攒够一批流量后，httrace generate命令启动转换。这一步要解决几个问题：

同一端点的不同参数组合要聚类，避免生成一千个几乎一样的测试；响应体里动态生成的字段（如created_at、uuid）要做模糊匹配，不能硬编码断言；依赖外部服务的调用要mock，否则测试跑不通。

生成的测试长这样：

def test_post_orders_items_empty_coupon_expired(): resp = client.post("/orders", json={ "user_id": "user_abc123", "items": [], "coupon": "EXPIRED2022" }) assert resp.status_code == 422 assert resp.json()["error_code"] == "COUPON_INVALID"

注意user_id被哈希脱敏了，但业务逻辑完整保留。这个测试来自真实用户的失败请求，不是我拍脑袋想的。

采样策略的权衡

10%是起点，不是终点。不同端点应该有不同的采样率：

核心支付链路可以提到50%，因为失败代价高；只读查询可以降到1%，因为行为稳定；新上线的实验功能临时提到100%，快速积累样本。

采样还要考虑时间分布。流量高峰期的样本更能代表真实压力，低谷期的可能全是爬虫和监控探针。我的中间件加了简单的时间权重，高峰样本优先入库。

和手写测试的共存

流量生成的测试覆盖"发生了什么"，但不覆盖"应该发生什么"。边界条件的主动设计、业务规则的显式断言，仍然需要人写。

我的混合策略：流量测试保回归，手写测试保正确性。每次部署前，流量测试确保没破坏现有行为，手写测试确保新功能符合预期。

有个意外收获：流量测试暴露了手写测试的盲点。比如我发现某个端点对Content-Type的容错比文档写的更宽松，文档说必须application/json，实际上text/plain也能过，因为代码里做了自动转换。这个行为被流量测试捕获后，我决定不修复代码——而是更新文档。

成本核算：比你想象的便宜

很多人问存储开销。按日均100万请求、平均请求响应体各10KB、10%采样算：

每日原始数据：100万 × 10% × 20KB = 2GB

压缩后约400MB，云端存储月成本几十块。脱敏和聚类后的测试代码更小，Git仓库无压力。

真正的成本是认知：团队要接受"测试不是人写的"这件事。我见过最强烈的抵触来自资深工程师，他们担心失去对测试质量的控制。我的说服方式是并排跑一个月，对比流量测试和手写测试的漏报率，数据说话。

失败案例：我踩过的坑

第一次上线时没做请求体大小限制，一个用户上传了50MB的JSON数组，直接把中间件内存打爆。后来加了10MB硬上限，超限的请求只记元数据不记body。

还有一次脱敏规则漏了手机号，测试代码里出现了真实号码，被安全扫描拦下。现在脱敏模块有强制审计日志，每次生成报告列明识别出的敏感字段类型和数量。

最尴尬的是时区问题。流量里的created_at是UTC，生成测试时没转换，CI服务器在另一个时区，断言失败。现在所有时间字段统一用ISO 8601带时区格式，比较时做归一化。

为什么这件事值得做

手动写集成测试的本质矛盾：你在用静态代码去验证动态系统，用有限想象去覆盖无限组合。流量驱动测试把这个关系倒过来——让系统的真实行为告诉你它需要被验证什么。

这不是说工程师可以偷懒。你仍然要理解业务、设计架构、写出能捕获流量的代码。但测试的维护成本，从"每个变更都要人工更新一堆假设"变成了"系统自愈式地跟随生产环境"。

六个月下来，我的测试覆盖率从62%升到89%，但更重要的是覆盖质量。那些89%里，有37%来自我永远不会手动想到的参数组合。它们在线上发生了，被捕获了，现在被保护了。

最后说个冷笑话：我现在写测试的时间确实少了，但调试测试生成器的时间多了。自动化这件事，总是把一种工作变成另一种工作，只是后者可以批量解决罢了。