自动化用例挂了到底谁修？聊聊「用例归谁维护」这条边界怎么画

背景

做了 8 年测试开发，最近在一次跨团队复盘会上听到一句让我很扎心的话：「测试用例挂了，测试开发就该负责修，这是你的交付物。」我当时没接话，但回来反复在想——这条边界真的该这么画吗？

我自己的处境很典型：负责一条 B 端 SaaS 链路的接口自动化（pytest + httpx，约 1800 条用例），跑在多人共享的 staging 上。一个月里用例红灯大概 200+ 次，拆开看：

• 约 40% 是被开发改接口 / 改字段 / 改默认值「顺带」打挂的；
• 约 30% 是共享环境数据污染、上下游服务抖动、限流熔断态残留；
• 约 20% 是用例本身写得脆（硬编码 ID、sleep、断言过强）；
• 剩下 10% 才是真 bug。

也就是说，真正属于「测试开发该修」的只有 20%~30%，但按「用例归测试开发」这条边界，剩下的 70%~80% 全压到我头上——我一天 6 小时在修别人打挂的东西，真正做新用例和治理的时间被挤到边角。

几种我见过的做法

1. 全归测试开发：用例是测试的交付物，谁挂了谁修。优点是责任单一、响应快；缺点是测试开发沦为「用例保姆」，开发对接口变更的破坏性没有成本感，越改越随意。
2. 按模块划界：开发写自己模块的用例，测试开发写端到端 / 跨模块用例，各修各的。优点是逼开发理解自己的接口；缺点是开发写的用例质量参差，测试开发最后还是得兜底评审。
3. 谁改谁修（BLAME）：谁提交的 commit 把用例打挂了，谁在 24h 内修完。优点是责任最清晰、对接口变更有强约束；缺点是跨团队扯皮成本高，需要 CI 里能精确归因（blame 到 commit）。
4. 全归开发 + 测试开发做平台：测试开发只提供框架、数据工厂、断言库，用例全部下沉到业务开发。优点是测试开发精力回到平台与质量指标上；缺点是对开发的工程素养要求很高，小团队很难落地。

我的倾向

我倾向 方案 3（谁改谁修）+ 方案 2（跨模块用例归测试开发）的组合，理由有三：

• 责任要跟着「变更」走，而不是跟着「文件归属」走——这是工程上唯一可执行的边界；
• 测试开发把精力收口到三件事上：测试框架与数据工厂、跨模块场景、质量指标（通过率 / flaky 率 / 平均修复时长）；
• 这条边界必须写进团队约定并公示，否则每次红灯都是扯皮现场。

配套的避坑清单（我踩过、也劝大家避）：

• CI 里必须能精确 blame 到 commit，否则「谁改谁修」无从谈起；
• 用例命名规范里要带模块前缀，否则归因失败；
• 共享 staging 上必须做 schema 隔离或事务回滚，否则 30% 的环境污染永远算不清账；
• 测试开发要定期出「用例健康度报告」，用数据说话，而不是用嗓门。

想听大家聊聊

1. 你们团队现在实际用的是上面哪条边界？踩过什么坑？
2. 有没有做过「谁改谁修」落地失败的真实案例？卡在哪一环？
3. 测试开发在「修用例」和「做平台 / 做治理」之间，你们是怎么分配精力的？有没有可量化的指标？
4. 对于跨模块 / 端到端用例，你们更倾向让测试开发写，还是让开发写、测试评审？
5. 一个更尖锐的问题：如果开发长期不修自己打挂的用例，测试开发有没有「拒收」的权力？ 这条线你们团队敢不敢划？

欢迎带上你的具体数字（用例数、红灯占比、修复时长）来聊，空对空的观点我基本不听。