"这个功能明明按需求做的，为什么测试说不对？"
"需求文档写得很清楚啊，怎么开发出来完全不是那么回事？"
如果你的团队经常出现这样的对话，那么你们遇到的不是技术问题，而是需求理解的问题。根据我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：提示"优惠券已过期"
未完待续，后面将继续为大家介绍遇到的挑战与解决方案、实施建议与关键要点、三个月后的成果及总结。
热门跟贴