📚 课程目录第2章验收标准定义原则

2. 验收标准定义原则

验收标准（Acceptance Criteria）是PRD到测试收尾的“准绳”。一个松散的验收标准会导致PRD模糊、测试边界混乱、版本反复。本章聚焦于四组核心原则——SMART原则、测试可执行性、明确通过/失败条件、与PRD一一对应——作为验收标准定义的基线。

2.1 什么是验收标准

验收标准是一组具体的、可验证的条件，用于判定某段功能或用户故事是否满足业务诉求并达到交付质量。它既不是需求原文摘抄，也不是技术实现细节，而是业务+质量双视角的契约。

常见误区：将验收标准写成PRD摘要，或写成大段的测试步骤。验收标准应聚焦“什么算是完成”，而非“怎么测试”。

2.2 四大核心原则

2.2.1 SMART原则

S – Specific（具体的）：描述可观测的行为或数据，避免“系统性能好”这种模糊描述。
M – Measurable（可衡量的）：使用数字、时长、错误率等量化指标。
A – Achievable（可实现的）：在当前技术栈和工期范围内可达成。
R – Relevant（相关的）：与核心业务价值直接关联，排除与特性无关的约束。
T – Time-bound（有时限的）：给定固定时间窗口或响应上限。

  正面示例：“用户点击‘导出’按钮后，系统应在3秒内生成CSV文件，文件大小不超过10MB，且成功率≥99.5%。”

  反面示例：“导出功能要快、能正常用。”

2.2.2 测试可执行性

每条验收标准应能直接转化为测试步骤，不需额外补充上下文。如果测试人员拿到验收标准后需要反复追问PM，就说明未通过可执行性检查。

典型特征：

有明确的输入（数据/操作）和预期输出。
不依赖内部代码实现（黑盒视角）。
单条标准内不包含“与/或”分支以免测试二义性。

2.2.3 明确通过/失败条件

每个验收标准必须有一个布尔结果（Pass/Fail），不能出现“基本通过”“大半通过”等中间态。失败条件与通过条件一样重要——例如“当网络延时超过2000ms时，系统应显示‘网络异常’提示，而非白屏”。

2.2.4 与PRD一一对应

每条验收标准必须能追溯到PRD中的一条或多条原始需求。如果验收标准在PRD中找不到对应条款，说明这可能是测试隐性需求或过度设计；反之，PRD中重要的功能点不应在验收标准中遗漏。建议在验收标准末尾增加【PRD ID】字段。

原则	检查要点	违例典型表现
SMART	是否包含数量/时长/成功率等可量化项	“尽快”“足够”“支持多用户”
测试可执行性	是否可盲测（不额外咨询PM）	条件描述为空，只有“正常”二字
通过/失败条件	是否只有Pass/Fail两种结果	“部分通过”“灰度通过”等模糊状态
PRD一一对应	是否标注PRD段落编号或功能ID	验收标准比PRD多或少20%

2.3 原则之间的关系

四原则并非独立判据，而是逐层递进：SMART奠定量化基础 → 测试可执行性确保可自动化 → 通过/失败条件消除歧义 → PRD对应保证需求覆盖。任何一环缺失，验收标准都可能成为无效契约。

协作风险点：QA和PM对“具体”的理解可能有偏差。建议在prd评审之后、验收标准编写之前，由QA、PM、开发共同做一次“验收标准walkthrough”，现场确认每条原则达标。

2.4 操作步骤

提取：从PRD中逐条摘录功能点及业务规则。
转换：对每个功能点，用SMART原则写出1~3条验收标准。
验证可执行：假设自己是测试工程师，按验收标准能否写出具体测试步骤？如果不能，返回修改。
设定通过/失败：针对边界条件、异常场景补充明确失败的判定。
标注关联：在每条验收标准末尾注明PRD章节号或需求ID。
评审：组织三方（PM/DEV/QA）逐条确认，记录遗留项。
入库：将验收标准写入测试管理工具或文档，作为测试用例设计基线。

2.5 输入输出物

类型	名称	说明
输入	PRD（已定稿）	包含功能列表、业务规则、异常定义、非功能性要求
输入	原有验收标准模板	公司或项目组已有的标准格式（推荐结构化+四原则检查）
输出	验收标准清单（V1.0）	每一条含：ID、描述、SMART检查标记、通过/失败条件、PRD关联编号、编写人、评审结论
输出	评审纪要与遗留问题列表	三方讨论未达成一致的条款及待确认事项

2.6 责任边界

产品经理（PM）：提供PRD及业务规则，对验收标准中“与PRD一一对应”负最终责任。
质量工程师（QA）：主导验收标准编写，运用SMART和可执行性检查，确保每条可测试。
开发工程师（DEV）：参与评审，确认可实现性与时间约束，反馈技术风险。
技术项目经理（TPM）：组织验收标准评审，推动遗留问题闭环，维护验收标准清单状态。

2.7 记录材料

验收标准评审后应保留以下记录：

验收标准评审会议纪要（含参会人、日期、决策项）
已标注四原则检查结果的验收标准清单（Excel/Notion/测试平台）
未通过的验收标准及其重写计划

2.8 异常处理

在验收标准定义过程中可能遇到以下异常，应对策略如下：

异常场景	处理方式
PRD细节缺失，无法写出具体验收标准	将“待PRD补充”标注为标准状态，提JIRA/需求澄清单给PM，设定澄清截止日
验收标准内存在多个独立逻辑分支	拆分为多条独立标准，每一条只覆盖一个判定结果
PM在评审中推翻已定PRD	标记该标准为“PRD变更”，冻结当前版本，等PRD更新后重新走验收标准定义流程
不同角色对“可衡量”的阈值争议	按“最小可接受值”与“目标值”双线记录，在下一次迭代回顾会中复盘

2.9 验收标准定义原则流程图

下面使用SVG展示从PRD出发，经过四原则校验，最终产出可执行验收标准的核心流程。

2.10 验收标准模板示例（JSON）

以下是一个符合四原则的验收标准条目示例，用于导出到测试管理系统。

{
  "id": "AC-FE-202",
  "description": "在收银台页面，当用户选择微信支付且订单金额 > 5000 元，
                  系统应弹窗提示“大额支付需验证身份证后四位”，验证失败则交易取消。",
  "smart_check": {
    "specific": "yes",
    "measurable": "yes (金额5000, 验证失败取消)",
    "achievable": "yes",
    "relevant": "yes",
    "time_bound": "no (建议补充响应时间 ≤ 2s)"
  },
  "testable": true,
  "pass_condition": "输入正确身份证后四位 → 交易继续，跳转微信支付",
  "fail_condition": "输入错误身份证后四位三次 → 弹窗提示“验证超限，请稍后再试”",
  "prd_references": ["PRD-v3.2-§4.3.1", "PRD-v3.2-§9.2.2"],
  "status": "approved"
}

在下一步编写验收标准时，建议直接使用此类结构化格式，确保SMART、可测试、通过/失败条件和PRD对应全部显式记录。