返工率从35%降到8%！测试左移3个月，我们团队发生了什么？

"这个功能明明按需求做的，为什么测试说不对？"

"需求文档写得很清楚啊，怎么开发出来完全不是那么回事？"

如果你的团队经常出现这样的对话，那么你们遇到的不是技术问题，而是需求理解的问题。根据我10年+的测试经验，超过60%的生产问题其实在需求阶段就已经埋下了隐患。

多年前，我所在的团队接手了一个电商平台的改造项目。项目初期，我们每个迭代都要返工30%以上的功能，团队士气低落，客户频繁投诉。后来我们在需求阶段引入了测试左移实践，3个月后，返工率降到了5%以下，交付周期缩短了40%。

这篇文章将通过这个真实案例，分享我们是如何在需求阶段实施测试左移的，包括具体的操作方法、遇到的问题和解决方案。

问题的发现：一次失败的迭代

1.1项目背景

这是一个中型电商平台的优惠券系统改造项目：

• 团队规模：8人（产品1人，开发5人，测试2人）
• 迭代周期：2周一个迭代
• 业务复杂度：涉及多种优惠券类型、叠加规则、使用限制

1.2第一次迭代的灾难

第一次迭代的需求是"满减券功能优化"。需求文档只有简单的一页纸：

需求：优化满减券功能

目标：提升用户体验，增加优惠券使用率

功能点：

1. 支持多档满减（满100减10，满200减25）

2. 支持跨品类使用

3. 优化券的展示样式

看起来很简单对吧？但开发完成后，测试发现了23个问题：

• 典型问题列表：
• 多档满减的计算逻辑不明确（按订单总额还是按商品分类？）
• 跨品类使用的限制条件缺失（是否包含特价商品？）
• 与其他优惠的叠加规则未定义（能否与店铺券同时使用？）
• 券的有效期判断逻辑不清晰（是按领取时间还是使用时间？）
• 库存扣减时机未说明（下单时扣还是支付时扣？）

更糟糕的是，开发人员、测试人员、产品经理对这些问题的理解完全不同。我们花了整整一周时间开会讨论、修改代码、重新测试。原本2周的迭代，最终用了3周半才勉强上线。

1.3问题根源分析

复盘会上，我们分析了问题的根本原因：

• 原因一：需求文档过于简单
• 只描述了"做什么"，没有说明"怎么做"
• 缺少边界条件和异常场景的说明
• 没有明确的验收标准
• 原因二：需求评审流于形式
• 评审会只有产品经理讲解，其他人听
• 没有人提出质疑和问题
• 会议结束就算评审通过
• 原因三：测试介入太晚
• 测试人员在开发完成后才开始介入
• 发现问题时代码已经写完，修改成本高
• 测试人员对需求的理解不够深入

解决方案：建立"三方评审"机制

2.1机制设计

我们决定建立一个"三方评审"机制，让产品、开发、测试在需求阶段就深度协作。

• 会议设置：
• 时间：每个需求开发前，安排1小时的评审会
• 参与人：产品经理、开发负责人、测试负责人（必须参加）
• 产出物：完善的需求文档 + 测试场景清单 + 验收标准
• 会议流程：

1. 产品讲解（15分钟）：介绍需求背景、目标、功能点

2. 开发质疑（15分钟）：从技术实现角度提出问题

3. 测试质疑（20分钟）：从测试角度提出问题

4. 讨论确认（10分钟）：三方讨论并达成一致

2.2测试质疑清单

为了让测试人员能够系统地发现需求问题，我设计了一个标准化的质疑提问清单：

• 功能完整性检查：
• 正常流程是否完整？
• 异常情况如何处理？
• 边界条件是什么？
• 与现有功能的关系如何？

• 数据准确性检查：
• 数据来源是什么？
• 数据格式和范围是什么？
• 数据校验规则是什么？
• 数据异常如何处理？

• 业务规则检查：
• 业务规则是否明确？
• 规则的优先级是什么？
• 规则冲突如何处理？
• 规则变更的影响范围？

• 用户体验检查：
• 用户操作路径是否合理？
• 错误提示是否友好？
• 响应时间是否可接受？
• 是否考虑了不同用户场景？

2.3第二次迭代的实践

第二次迭代的需求是"新增积分兑换券功能"。这次我们严格按照三方评审机制执行。

评审会实录（节选）：

• 产品讲解：
• "用户可以用积分兑换优惠券，100积分可以兑换一张10元券..."
• 测试质疑：
• Q1：积分不足时如何提示？
• Q2：兑换后积分什么时候扣除？
• Q3：兑换的券有效期多久？
• Q4：用户可以兑换多少张？有没有限制？
• Q5：兑换失败（比如网络异常）如何处理？
• Q6：积分扣除了但券没发放成功怎么办？

• 开发补充：
• Q7：积分余额从哪个系统获取？接口响应时间多久？
• Q8：如果积分系统不可用，是否需要降级方案？

• 讨论结果：
• 产品经理当场补充了8个之前没有考虑到的场景，并承诺会在需求文档中详细说明。

• 完善后的需求文档（部分）：

功能：积分兑换优惠券

1. 兑换规则

- 兑换比例：100积分 = 1张10元券

- 每日限额：每个用户每天最多兑换3张

- 积分要求：用户积分余额 >= 100

2. 兑换流程

- 用户点击兑换按钮

- 系统校验积分余额（调用积分系统接口，超时时间3秒）

- 积分充足：扣除积分 → 发放优惠券 → 提示成功

- 积分不足：提示"您的积分不足，当前积分XX，需要100积分"

3. 异常处理

- 积分系统不可用：提示"系统繁忙，请稍后再试"

- 积分扣除成功但券发放失败：记录日志，后台补发

- 网络超时：提示用户刷新页面查看兑换结果

4. 验收标准

- Given：用户积分余额为150

Then：积分扣除100，获得1张10元券，提示兑换成功

- Given：用户积分余额为50

Then：提示"您的积分不足，当前积分50，需要100积分"

- Given：用户今日已兑换3张券

Then：提示"今日兑换次数已达上限"

2.4实施效果

第二次迭代的结果让我们惊喜：

数据对比：

团队反馈：

- 开发："需求更清晰了，开发过程中几乎不需要回头问产品"

- 测试："提前介入让我对需求理解更深，测试用例设计更有针对性"

- 产品："虽然前期花的时间多了，但后期省了更多时间，整体效率提升了"

深化实践：验收标准的编写技巧

3.1为什么需要明确的验收标准

在实践中我们发现，即使需求文档写得很详细，如果没有明确的验收标准，开发和测试对"做完"的理解仍然会有偏差。

一个真实的例子：

• 需求："用户登录失败3次后，账号锁定30分钟"
• 开发理解：连续输错3次密码后锁定
• 测试理解：24小时内累计输错3次后锁定
• 结果：开发完成后，测试认为不符合需求，又花了0.5天修改。

☑️转岗软件I测试/野路子技能提升

☑️想了解更多涨薪技能提升方法

✔️可以到我的个人号：atstudy-js

即可加入领取 ⬇️⬇️⬇️

转行、入门、提升、需要的各种干货资料

内含AI测试、 车载测试、AI大模型开发、BI数据分析、银行测试、游戏测试、AIGC

3.2Given-When-Then格式

我们采用了Given-When-Then格式来编写验收标准，这个格式简单易懂，能够消除歧义。

• 格式说明：
• Given：前置条件（系统处于什么状态）
• When：用户操作（用户做了什么）
• Then：预期结果（系统应该如何响应）

• 改进后的验收标准：

场景1：首次登录失败

Given：用户账号正常，未被锁定

When：输入错误密码点击登录

Then：提示"密码错误，您还有2次尝试机会"

场景2：第三次登录失败

Given：用户已连续输错2次密码

When：再次输入错误密码点击登录

Then：账号被锁定，提示"密码错误次数过多，账号已锁定30分钟"

场景3：锁定期间尝试登录

Given：用户账号已被锁定，距离锁定时间10分钟

When：输入正确密码点击登录

Then：提示"账号已锁定，请20分钟后再试"

场景4：锁定期满后登录

Given：用户账号锁定已满30分钟

When：输入正确密码点击登录

Then：登录成功，错误次数清零

场景5：登录成功后错误次数清零

Given：用户已输错1次密码

When：输入正确密码登录成功

Then：错误次数清零，下次输错从1开始计数

3.3边界条件的识别

在编写验收标准时，特别要注意边界条件。我总结了一个"边界条件检查清单"：

• 数值边界：
• 最小值、最大值、零值
• 临界值（如优惠券满100减10，测试99、100、101）
• 时间边界：
• 开始时间、结束时间
• 跨天、跨月、跨年的情况
• 时区问题
• 状态边界：
• 初始状态、中间状态、结束状态
• 状态转换的各种路径

• 数量边界：
• 空集合、单个元素、多个元素
• 超出限制的情况
• 实际案例：

优惠券使用的边界条件：

场景：订单金额刚好等于满减门槛

Given：用户有一张"满100减10"的优惠券

When：下单金额为100元，使用该优惠券

Then：优惠10元，实付90元

场景：订单金额略小于满减门槛

Given：用户有一张"满100减10"的优惠券

When：下单金额为99.99元，尝试使用该优惠券

Then：提示"订单金额不满足使用条件，需满100元"

场景：优惠券在使用时刚好过期

Given：用户有一张优惠券，有效期至2024-03-01 23:59:59

When：在2024-03-01 23:59:59下单并使用该券

Then：可以正常使用

场景：优惠券在使用时刚刚过期

Given：用户有一张优惠券，有效期至2024-03-01 23:59:59

When：在2024-03-02 00:00:00下单并使用该券

Then：提示"优惠券已过期"

未完待续，后面将继续为大家介绍遇到的挑战与解决方案、实施建议与关键要点、三个月后的成果及总结。