接口自动化里 fixture 依赖链太长，调试时看不清哪一步挂了，怎么破？

背景：我维护一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 400 条用例），后端 Java + Spring Boot。很多用例的造数不是"一步到位"，而是一条 5~6 步的依赖链，比如：创建企业 → 创建部门 → 创建用户 → 分配角色 → 创建订单 → 发起支付，最后一步才是我要测的目标接口（比如"支付回调"）。这些步骤我用 @pytest.fixture 串起来，scope=function 保证隔离。

现象：链一长，调试体验就崩了，具体卡点有三个：

1. 定位难：一个 test 红了，pytest 的 traceback 只显示最后一步的断言失败（比如 KeyError: 'payment_id'），但根因可能是第 2 步"创建部门"返回的结构变了（后端加了嵌套层级）。我得翻 5 个 fixture 的源码才能猜出哪步出了问题，一次 debug 平均 15~20 分钟，比写新用例还慢。
2. 耗时难：scope=function 意味着每个 test 都跑完整条链，400 条用例里 60% 有 5+ 步造数，CI 一轮要 35 分钟。但如果改 scope=session/class 共享，又踩了"用例之间数据互相污染"的坑（同账号多订单互相干扰）。
3. 改一处动全身：后端把"创建企业"的入参从 companyName 改成了 name，我 grep 了 40 个文件才修完，因为 fixture 链里每一层都硬编码了上一步的返回字段名。

已尝试的排查：

• 用 pytest --setup-show 看 fixture 执行顺序——能看到顺序，但看不到每步的入参和返回值，等于"知道谁先谁后，不知道谁挂了"；
• 给每步 fixture 加 logging.info 打印关键返回值——日志确实有了，但散落在 stdout 里，400 条用例跑完日志 2 万行，找一条特定用例的链路要 Ctrl+F 三轮；
• 把 fixture 链抽成"工厂函数"（普通 Python 函数，不是 fixture），手动在 test 里调用——DRY 了，但失去了自动 teardown（造了企业不删，数据库里堆了几千条脏数据），而且工厂函数之间没有依赖声明，全靠注释说明"先调 A 再调 B"；
• 想用 Testcontainers 起一个干净环境——但我们连的是共享 staging 环境，不是本地容器，这条路暂时走不通。

期望得到的答案形态：

• 你们团队 fixture 链最长到几层？超过 3 层后是怎么管理的？有没有"造数链"的统一日志/可视化方案（比如每步自动打 trace_id，最后输出一棵执行树）？
• scope 到底怎么定？function 太重、session 太脏，你们有没有"按造数成本分层"的中间策略（比如"创建企业"用 session 共享，"创建订单"用 function 隔离）？
• 有没有人用"测试数据工厂"模式（不是 fixture，是普通函数 + 显式调用 + 手动 cleanup）替代 fixture 链？实际效果、坑、和 fixture 方案的对比？
• 后端改接口结构时，你们怎么批量发现哪些 fixture 受影响？有没有 OpenAPI diff → 测试代码影响面分析的工具链或脚本？

欢迎带具体代码片段、fixture 结构、CI 日志样例来聊，越具体越好。