前言：一个真实的验收场景

场景：某次需求验收，产品经理和研发发生了激烈争论：

• 产品经理："这个功能没做完，用户登录后应该跳转到首页，但现在跳转到了个人中心。"
• 研发："PRD里只写了'登录成功'，没写跳转到哪里，我跳转到个人中心也没问题啊。"
• 产品经理："这还用说吗？登录后当然跳转首页啊！"
• 研发："你没写清楚，我怎么知道？"

结果：双方各执一词，验收无法进行，最后只能重新评审，浪费了1天时间。

教训：如果PRD里有明确的验收标准，就不会有这种扯皮。验收标准就是"做什么"的明确答案。

这篇给你完整的验收标准写法，减少验收时的沟通成本。

一、为什么需要验收标准？3个真实场景

场景1：验收时总是扯皮

问题：产品说没做完，研发说做完了，双方各执一词。

后果：验收无法进行，需要重新评审，浪费时间和精力。

解决方案：在PRD中明确验收标准，用Given/When/Then模板描述，避免歧义。

场景2：测试不知道测什么

问题：测试拿到PRD后，不知道应该测试哪些场景，遗漏关键测试点。

后果：测试不充分，上线后出现问题，需要紧急修复。

解决方案：验收标准就是测试用例的线索，测试可以根据验收标准设计测试用例。

场景3：需求理解不一致

问题：产品、研发、测试对需求的理解不一致，导致实现偏差。

后果：需要返工，影响项目进度，增加成本。

解决方案：验收标准是需求的明确描述，所有人都按照验收标准理解和实现。

总结：验收标准不是可选项，而是减少沟通成本的必需品。没有验收标准，就像没有标准答案的考试，每个人都有自己的理解。

二、Given/When/Then模板（3步搞定）

Given/When/Then是行为驱动开发（BDD）的经典模板，用3个步骤描述一个功能：

Given（前置条件）：描述测试的初始状态
When（触发操作）：描述用户执行的操作
Then（期望结果）：描述期望的结果

示例：
Given 用户已登录，且购物车有1件商品
When 用户点击"提交订单"按钮
Then 系统创建订单，跳转到支付页面，购物车清空

三、5个真实案例（可直接使用）

下面给出5个真实场景的验收标准，你可以直接参考使用：

案例1：用户登录

功能点：用户登录
Given 用户未登录
When 用户输入正确的用户名和密码，点击"登录"
Then 登录成功，跳转到首页，显示用户名

异常情况1：
Given 用户未登录
When 用户输入错误的密码，点击"登录"
Then 提示"用户名或密码错误"，不跳转

异常情况2：
Given 用户未登录
When 用户输入不存在的用户名，点击"登录"
Then 提示"用户名或密码错误"，不跳转

异常情况3：
Given 用户已登录
When 用户再次访问登录页
Then 自动跳转到首页

案例2：创建订单

功能点：创建订单
Given 用户已登录，购物车有2件商品，库存充足
When 用户选择收货地址，点击"提交订单"
Then 订单创建成功，扣减库存，跳转到支付页面

异常情况1：
Given 用户已登录，购物车有1件商品，库存不足
When 用户点击"提交订单"
Then 提示"库存不足"，不创建订单

异常情况2：
Given 用户已登录，购物车为空
When 用户点击"提交订单"
Then 提示"购物车为空"，不创建订单

案例3：审批流程

功能点：审批通过
Given 审批单状态为"审批中"，当前用户是审批人
When 用户填写审批意见，点击"通过"
Then 审批单状态改为"已通过"，发送通知给申请人

异常情况1：
Given 审批单状态为"已通过"
When 用户点击"通过"
Then 提示"审批单已通过"，不允许重复审批

异常情况2：
Given 审批单状态为"审批中"，当前用户不是审批人
When 用户点击"通过"
Then 提示"你没有权限审批"，不允许操作

案例4：数据导出

功能点：导出用户列表
Given 用户已登录，有导出权限，用户列表有100条数据
When 用户点击"导出"
Then 创建导出任务，显示进度，导出完成后提供下载链接

异常情况1：
Given 用户已登录，无导出权限
When 用户点击"导出"
Then 提示"你没有权限导出"，不创建任务

异常情况2：
Given 用户已登录，有导出权限，用户列表超过10000条
When 用户点击"导出"
Then 提示"导出数量超过限制，请缩小筛选范围"

案例5：商品上架

功能点：商品上架
Given 商品状态为"草稿"，商品信息完整
When 用户点击"上架"
Then 商品状态改为"已上架"，前台可见

异常情况1：
Given 商品状态为"草稿"，商品图片未上传
When 用户点击"上架"
Then 提示"请上传商品图片"，不允许上架

异常情况2：
Given 商品状态为"已上架"
When 用户点击"上架"
Then 提示"商品已上架"，不重复操作

四、验收标准实施步骤（4步搞定）

步骤1：梳理功能点

首先梳理所有功能点，包括正向流程和异常流程：

• 正向流程：正常情况下的操作流程
• 异常流程：异常情况下的处理流程
• 边界条件：边界值的处理

在梳理功能点时，可以使用思维导图工具来整理功能分类和验收标准，比如使用AI思维导图工具，输入功能需求，自动生成结构化的验收标准思维导图，帮助快速完成设计。

步骤2：使用Given/When/Then模板

对每个功能点，使用Given/When/Then模板描述：

• Given（前置条件）：描述测试的初始状态
• When（触发操作）：描述用户执行的操作
• Then（期望结果）：描述期望的结果

步骤3：补充异常场景

对每个功能点，补充异常场景的验收标准：

• 异常情况1：输入错误数据
• 异常情况2：权限不足
• 异常情况3：数据不存在

步骤4：评审和确认

验收标准写完后，需要评审和确认：

• 产品评审：确保验收标准符合产品需求
• 研发确认：确保验收标准可以实现
• 测试确认：确保验收标准可以测试

五、验收标准模板（可直接使用）

下面是一个完整的验收标准模板，你可以直接复制使用：

功能点：
Given（前置条件）：
When（触发操作）：
Then（期望结果）：

异常情况1：
Given：
When：
Then：

异常情况2：
Given：
When：
Then：

权限校验：
- 谁能操作：
- 谁不能操作：

数据准备：
- 测试数据：
- 初始化脚本：

六、真实案例：3个踩坑经历

案例1：验收时总是扯皮

背景：某次需求验收，产品经理和研发对"登录后跳转"的理解不一致。

问题：PRD中没有明确的验收标准，导致双方各执一词。

解决方案：

1. 优化PRD：
   - 使用Given/When/Then模板描述验收标准
   - 明确登录后跳转到首页
   - 补充异常场景（如已登录用户访问登录页）
   
2. 建立验收标准规范：
   - 所有功能点必须有验收标准
   - 使用统一模板（Given/When/Then）
   - 评审时确认验收标准
   
3. 实施效果：
   - 验收时不再扯皮
   - 需求理解一致
   - 验收效率提升

教训：验收标准不是可选项，而是必需品。没有验收标准，验收时就会扯皮。

案例2：测试不知道测什么

背景：某次需求，测试拿到PRD后，不知道应该测试哪些场景。

问题：PRD中只写了功能描述，没有写验收标准，测试无法设计测试用例。

解决方案：

1. 优化PRD：
   - 每个功能点都有验收标准
   - 使用Given/When/Then模板
   - 补充异常场景和边界条件
   
2. 建立测试用例线索：
   - 验收标准就是测试用例的线索
   - 测试根据验收标准设计测试用例
   - 产品可以补充测试用例线索
   
3. 实施效果：
   - 测试知道测什么
   - 测试用例更全面
   - 测试效率提升

教训：验收标准是测试用例的线索，没有验收标准，测试就无法设计测试用例。

案例3：需求理解不一致

背景：某次需求，产品、研发、测试对需求的理解不一致，导致实现偏差。

问题：PRD中的描述不够明确，每个人都有自己的理解。

解决方案：

1. 优化PRD：
   - 使用Given/When/Then模板，描述更明确
   - 补充异常场景和边界条件
   - 使用示例说明，避免歧义
   
2. 建立需求评审机制：
   - 需求评审时确认验收标准
   - 所有人按照验收标准理解和实现
   - 验收时按照验收标准验收
   
3. 实施效果：
   - 需求理解一致
   - 实现偏差减少
   - 返工减少

教训：验收标准是需求的明确描述，没有验收标准，需求理解就会不一致。

七、常见错误及解决方案

错误1：验收标准不够明确

表现：验收标准描述模糊，导致理解不一致。

示例："登录成功后跳转"，没有明确跳转到哪里。

解决方案：

• 使用Given/When/Then模板，描述更明确
• 使用具体的数据和场景，避免抽象描述
• 补充示例说明，避免歧义

错误2：只写正向流程，不写异常流程

表现：验收标准只写了正常情况，没有写异常情况。

示例：只写了"输入正确密码登录成功"，没有写"输入错误密码提示错误"。

解决方案：

• 正向流程必须写，异常流程也要写
• 关键异常流程必须写，常规异常流程可以简写
• 边界条件选择性写

错误3：验收标准太详细或太简单

表现：验收标准写得太详细，像测试用例；或者写得太简单，没有指导意义。

示例：验收标准写了每个字段的校验规则，或者只写了"功能可用"。

解决方案：

• 验收标准要适中，既要明确，又不能太详细
• 关键场景必须写，常规场景可以简写
• 测试可以根据验收标准补充详细测试用例

错误4：验收标准不及时更新

表现：需求变更后，验收标准没有及时更新。

示例：需求从"跳转首页"改为"跳转个人中心"，但验收标准还是"跳转首页"。

解决方案：

• 需求变更时，同步更新验收标准
• 建立验收标准版本管理机制
• 评审时确认验收标准是否更新

错误5：验收标准没有评审

表现：验收标准写完后，没有经过评审，导致验收标准不合理。

示例：验收标准要求"响应时间≤1秒"，但实际业务无法实现。

解决方案：

• 验收标准写完后，必须经过评审
• 产品、研发、测试都要参与评审
• 确保验收标准可以实现和测试

八、最佳实践

实践1：使用Given/When/Then模板

统一使用Given/When/Then模板，描述更清晰：

• Given（前置条件）：描述测试的初始状态
• When（触发操作）：描述用户执行的操作
• Then（期望结果）：描述期望的结果

实践2：正向流程+异常流程

验收标准要包含正向流程和异常流程：

• 正向流程：正常情况下的操作流程
• 异常流程：异常情况下的处理流程
• 边界条件：边界值的处理

实践3：验收标准评审机制

建立验收标准评审机制，确保验收标准合理：

• 产品评审：确保验收标准符合产品需求
• 研发确认：确保验收标准可以实现
• 测试确认：确保验收标准可以测试

实践4：验收标准版本管理

对验收标准进行版本管理，及时更新：

• 版本控制：记录验收标准的版本和变更历史
• 及时更新：需求变更时，同步更新验收标准
• 通知机制：验收标准更新后，通知相关人员

实践5：利用AI辅助验收标准设计

利用AI工具辅助验收标准设计，提高效率和准确性：

• 功能分析：AI可以根据功能描述，自动生成验收标准大纲
• 场景识别：AI可以识别正向流程和异常流程
• 模板生成：AI可以根据输入生成验收标准模板，例如使用AI思维导图工具，输入功能需求，自动生成结构化的验收标准思维导图，帮助产品经理快速完成设计。

九、FAQ

Q1：验收标准谁来写？

建议产品经理写。测试可以补充测试用例。产品经理最了解需求，应该由产品经理写验收标准。

Q2：验收标准要写多详细？

建议：正向流程必须写，关键异常流程必须写，边界条件选择性写。验收标准要适中，既要明确，又不能太详细。

Q3：验收标准和测试用例的区别？

验收标准是"做什么"，测试用例是"怎么测"。验收标准更抽象，测试用例更具体。测试可以根据验收标准设计测试用例。

Q4：验收标准什么时候写？

建议在需求评审时写，或者在PRD编写时同步写。验收标准应该在开发前确定，避免开发后才发现理解不一致。

Q5：验收标准需要评审吗？

需要。验收标准写完后，必须经过评审，产品、研发、测试都要参与，确保验收标准可以实现和测试。

Q6：验收标准需要更新吗？

需要。需求变更时，验收标准也要同步更新。建立验收标准版本管理机制，及时更新。

Q7：如何快速设计验收标准？

建议：使用Given/When/Then模板，先写正向流程，再补充异常流程。可以使用思维导图工具来整理功能分类和验收标准，比如使用AI思维导图工具，输入功能需求，自动生成结构化的验收标准思维导图，帮助快速完成设计。