测试造数到底谁该负责：自己造、找开发要，还是脱敏生产数据？

背景

做了 10 年测试开发，最近在新团队接手一条交易链路时，被"测试数据从哪来"这件事卡了整整一周。不是用例写不出来，而是数据造不出来：一个下单接口要依赖用户、商品、库存、风控、优惠券五个前置状态，每个状态背后还有一张配置表和一次异步落库。我按"造数 → 调接口 → 断言"的套路去写，结果造数脚本比被测代码还长，而且一改业务字段就得跟着改，维护起来像给房子打地基——地皮一变，整面墙都得重砌。

常见分歧（我观察到的三种做法）

1. 测试自己造数：用 seed 脚本 / API 编排把前置状态一步步调出来。好处是可控、可复现；坏处是造数逻辑和业务逻辑强耦合，业务一改，造数脚本先崩，而且经常造出"看起来对、其实缺了某个隐藏字段"的脏数据。
2. 找开发要 / 让开发在测试环境预置：开发写一套"测试夹具（fixture）"，测试直接用。好处是数据真实、贴近业务；坏处是开发排期紧、不愿长期维护，而且这等于把测试的一部分工作外包出去了，边界又模糊了（正好呼应我之前看到过"用例挂了谁修"的讨论）。
3. 脱敏生产数据回流：把生产真实数据脱敏后灌到测试环境。好处是数据最真实、覆盖各种边界态；坏处是合规、安全、成本三重门槛，而且生产数据"真实"不代表"可控"，反而常常更难复现。

我的倾向与理由

我倾向于分层，而不是三选一：

• 单元 / 接口层：用轻量 fixture 造最小必要数据，只造"被测逻辑真正读到的字段"，不追求数据完整，追求可控 + 快；
• 集成 / 链路层：允许用脱敏生产数据打底 + 少量手工修正，因为这类场景的价值就在于"真实态"，而不是"造得出来"；
• 造数本身当一等公民对待：给它写版本号、给它做契约（fixture 的输入/输出 schema），业务字段变更时由开发负责更新 fixture（因为业务字段是他定义的），测试只负责断言。这样"造数归谁"就按字段定义权来切，比按"用例归谁"来切更清晰。

打个比方：造数不是"搬砖"，而是"翻译"——把业务语言翻译成测试能用的数据；翻译的人最该是懂业务的人，而不是最急着跑用例的人。

想听大家在什么场景下怎么选

• 你们团队目前是哪种做法？造数脚本大概占自动化代码的多少比例？
• 当业务字段高频变更时，你们的 fixture 谁在维护、多久崩一次？
• 有没有团队真的把"脱敏生产数据"跑通了？踩过哪些合规或复现的坑？
• 如果让你重新设计，你会怎么给"造数"定边界和归属？

欢迎把你们的具体做法（语言栈 / 用例量级 / 造数方式）贴出来，我们一起对比哪种更可持续。