测试开发

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

背景 我是测试开发，维护一套 B 端 SaaS 接口自动化（Python 3.11 + pytest 7.4 + httpx，约 1800 条用例，跑在 4 人共享的 staging + MySQL 8 + Redis 7）。套件从 700

背景 做了 15 年测试开发，我最近在一个 12 人后端团队做发布质量复盘时，撞上一堵反复出现的墙：过去 18 个月，团队接口自动化从 600 条涨到 2100 条，CI 全绿率长期 95%+，单测覆盖率 78%，但同期线上 P1/P2 事

背景：我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 900 条用例），后端 Spring Boot 3 + MySQL 8 + Redis 7，跑在 4 人共享的 stag

背景 做了 5 年测试开发，最近盘一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 800 条用例），一个反复出现的痛点不是「断言写错」，而是「断言写多严」的尺度问题。举几个真实例子：一

【背景】 我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 600 条用例），后端 Spring Boot 3 + RabbitMQ 3.12 + MySQL 8。核心链路是「

【背景】我负责一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 700 条用例，MySQL 8）。里面有一批"老用例"是 2 年前从手工用例平移过来的，它们的共同特征是不自己造数，而

背景 做了 3 年接口自动化（pytest + httpx，套件 2000+ 条，跑在多人共享的 staging 上），我最怕的不是"用例红了"，而是"红的里面有几条是真的"。flaky 用例是自动化套件的头号天敌：它不报错，它只是间歇性地

背景 我在一家 B 端 SaaS 团队负责接口自动化（Python 3.11 + pytest 7.4 + httpx 0.25，约 800 条用例），后端 Spring Boot 3 + MySQL 8 + Redis 7 + Rocke

背景：我维护一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 400 条用例），后端 Java + Spring Boot。很多用例的造数不是"一步到位"，而是一条 5~6 步的依赖链，

背景：我维护一套 B 端 SaaS 的接口自动化（pytest + requests，约 350 条用例），团队 4 人，后端 Java + Spring Boot，前端 React。每次发版前跑一轮回归，CI 上大约 20 分钟跑完。 现

【背景】我负责一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 500 条用例），后端 Spring Boot 3，网关层挂了 Sentinel 限流 + 熔断。用例是「造数 → 调接口

【背景】我负责一条订单支付链路的接口自动化（Python 3.11 + pytest 7 + httpx，约 400 条用例）。核心链路是"下单 → 调第三方支付 → 等对方异步 webhook 回调 → 改单 → 通知下游"。第三方回调是

背景 我在一家做 B 端 SaaS 的团队负责接口自动化（Python 3.11 + pytest 7 + httpx，约 600 条用例），后端是 Spring Boot 3 + MySQL + Redis + RocketMQ，CI 用

背景：我负责一套 B 端 SaaS 的接口自动化（Python + requests + pytest，约 400 条用例），数据层是 MySQL。用例普遍是「造数 → 调接口 → 断言」的三段式，造数靠直接调内部 admin 接口或写库脚