左移搞错了，越忙越返工！3个阶段这样做才真提效

• 需求阶段：发现一个歧义点，可能只需要1小时澄清；
• 编码后：同样的问题可能需要1天改代码、回归测试；
• 上线后：则可能需要1周紧急修复、灰度发布，还面临用户投诉和监管处罚。

1. 需求阶段：别只“听会”，要做“需求校验官”

很多测试参加需求评审，就是坐在角落记笔记，回去再写用例。这不叫左移，这叫“被动接锅”。

真正的左移，是在需求还没定稿时，就主动挑刺、推动澄清、预防模糊。

我们团队的做法很简单，每次评审前花30分钟准备，聚焦三件事：

✅ 提前列“疑问清单”
拿到PRD后，先问自己：

• 哪些描述模棱两可？（比如“年收入达标”——具体是多少？含不含奖金？）
• 哪些场景被忽略了？（比如“秒杀结束未支付订单自动取消”——多久取消？有没有通知？）
  
  把问题一条条写下来，会上直接抛出来。

✅ 推动需求“实例化”
别接受“提升用户体验”这种空话。要把它变成可验证的场景。
推荐用 Given-When-Then 格式：

Given 用户未注册手机号，When 输入手机号获取验证码，Then 系统应发送验证码，并提示“验证码已发送至1381234”。

这样开发知道怎么实现，测试知道怎么验证，后期少扯皮。

✅ 预判业务风险
结合你的领域经验，提前点出潜在雷区：

• “这个支付流程，考虑过超时回滚吗？”
• “用户上传身份证，有没有做脱敏和合规校验？”

📌 小技巧：评审结束后，把验收标准、澄清结论、风险点整理成一份《需求校验快照》，发到群里全员确认。避免后期“我以为你说的是A，你其实说的是B”。

2. 设计阶段：别当“旁观者”，要做“质量守门员”

设计阶段埋下的坑，往往到集成甚至上线才暴露。但测试不用懂架构图，也能守住三道关：可测性、安全性、接口清晰度。

我们团队常用两个动作：

✅ 带着“3个问题”参加设计评审
不用听完整场技术方案，重点盯住：

1. 模块能不能独立测试？（比如是否过度耦合）
2. 高并发/异常场景有没有兜底？（比如库存扣减没加锁）
3. 接口参数、返回值、错误码是否明确定义？

举个例子：在做医疗设备软件时，我们发现传感器输入没做范围校验，当场提出，设计阶段就补上了——避免了后期安全合规风险。

✅ 推动接口契约“提前落地”
前后端联调总打架？问题往往出在接口定义模糊。
测试要主动推动：在设计阶段就用 OpenAPI 或 proto 文件锁定接口契约。
更进一步，可以用 Mock Server 提前跑通调用链，验证逻辑是否合理——等代码写完再发现问题，成本太高了。

3. 编码阶段：别等“提测后”，要做“同步赋能者”

编码阶段的左移，不是让测试去写业务代码，而是帮开发把质量内建到编码过程中。

年底迭代快，更要靠这几个动作提效：

✅ 给单元测试“设底线”
开发嫌写单元测试费时间？那就设一个最低门槛：

• CI流水线强制检查覆盖率（比如针对新开发的核心业务模块，建议设置≥70%的单元测试覆盖率门槛；工具类代码可要求≥80%）；
• 不达标，代码不让合入主干。

我们做秒杀功能时，靠这一招，50%以上的缺陷在本地就被拦截了，测试阶段压力大减。

✅ 在代码评审中“带质量视角”
别只看缩进和命名。重点看：

• 异常处理是否缺失？（比如没判空）
• 有没有性能隐患？（比如循环里查数据库）
• 日志是否足够定位问题？

有一次，我在评审中发现支付接口没校验金额一致性，当场指出，避免了资损风险。

✅ 给开发一份“自测清单”
年底节奏快，开发可能没空全覆盖。
测试可以提供一份极简自测Checklist，比如登录功能：

1. 正确账号密码 → 登录成功
2. 错误密码 → 提示“密码错误”
3. 账号为空 → 提示“请输入账号”
4. 连续输错3次 → 账号锁定

看似小事，但能拦住80%的低级缺陷，省下大量回归时间。

需求阶段多问一句，设计阶段多盯一眼，编码阶段多帮一把——
省下的，是后期通宵改bug的时间，更是团队的信任和效率。

年底冲刺，与其在返工中疲于奔命，不如从今天开始，在正确的地方，提前半步。