3. 验收标准与需求文档的关系：从用户故事到验收条件

3.1 适用场景

• 团队采用用户故事（User Story）描述功能需求，需要将模糊的故事转化为可验证、可衡量的验收条件。
• 需求文档（如 PRD、特性描述）包含多个用户故事，且QA、开发、产品三方需对齐“完成”的定义。
• 增量交付场景中，每个迭代的每个用户故事都必须附带一条或多条验收条件，作为“Done”的判定依据。

3.2 前置条件

1. 已有一份经过PO（Product Owner）确认的用户故事列表，故事满足INVEST原则（Independent, Negotiable, Valuable, Estimable, Small, Testable）。
2. 团队已统一验收条件的书写模板（例如GWT格式：Given / When / Then）。
3. 项目已建立需求-验收条件双向追溯机制（如需求管理工具中关联字段或Excel追踪矩阵）。

3.3 操作步骤

Step 1：解析用户故事 — 阅读故事标题、描述（As a… I want… So that…）以及附件/原型，识别故事中的核心角色、动作、业务价值。

Step 2：拆分业务场景 — 针对故事覆盖的正常流程、可选流程、异常流程，列出具体场景列表。

Step 3：撰写验收条件 — 每个场景用“Given … When … Then …”结构化描述前置条件、触发事件、预期结果。

Step 4：补充可衡量性 — 将定性描述（如“响应快”）转化为量化指标（如“响应时间 < 200ms”），确保每个Then可以明确通过测试判定。

Step 5：评审与确认 — PO、QA、开发共同评审验收条件，确保无遗漏、无歧义、可测试。

Step 6：关联到需求文档 — 将验收条件ID回填到用户故事卡片/需求管理工具，建立追踪链接。

3.4 输入输出物

类型	物项名称	格式/载体
输入	用户故事列表	Jira/Confluence/Excel需求表格
输入	原型/业务规则文档	PDF、Figma链接、结构化文档
输出	验收条件清单	与故事关联的表格或工具字段
输出	需求-验收条件追溯矩阵	Excel / ALM工具追踪记录

3.5 责任边界

• 产品负责人（PO）：提供清晰、完整的用户故事，并最终确认验收条件是否满足业务意图。
• 业务分析师：协助PO拆分场景，撰写初步验收条件草稿。
• 测试工程师：从可测性角度审查验收条件，补充边界值和异常场景的Given。
• 开发工程师：确认验收条件在技术实现上的可行性，必要时提出简化建议。

3.6 记录材料

1. 用户故事卡片（物理或电子）—— 包含故事ID、标题、描述、验收条件ID列表。
2. 验收条件详情表 —— 每行一条验收条件，含所属故事ID、场景名称、GWT文本、可衡量指标（时间/数量/状态等）。
3. 追溯矩阵报告 —— 展示每个用户故事是否已覆盖所有验收条件，以及每个验收条件对应哪个测试用例。

3.7 异常处理

异常场景	处理方式
用户故事过于模糊，无法拆出具体场景	返回PO补充分支流程、业务规则，或组织需求澄清会议
验收条件之间存在冲突（如不同场景对同一状态要求不同）	拉通相关干系人（PO、开发、测试）协商统一判定标准
验收条件不可测试（如“界面美观”）	要求PO替换为可量化描述（如“页面加载时间<2s”或“符合XX设计规范”）
故事过大，验收条件超过7条	建议将故事拆分为多个小故事，每个故事对应<=5条验收条件

3.8 验收标准组织（映射结构）

下图展示了从一条用户故事到多条验收条件的典型映射关系，以及验收条件内部GWT三要素与可衡量指标的嵌入方式。

3.9 验收条件书写示例（GWT + 指标）

以下是一条完整的验收条件，包含可衡量指标嵌入：

验收条件 ID: AC-015
所属故事: US-003-搜索商品筛选
场景: 正常搜索并应用价格排序
Given: 用户已登录，且搜索关键词为“电动牙刷”
When: 用户点击“按价格从低到高”排序按钮
Then:
  - 搜索结果列表按价格升序排列
  - 列表第一项价格 <= 列表最后一项价格
  - 页面渲染时间 < 2s（性能）

3.10 常见误区与避坑

• 验收条件等于测试用例：验收条件是业务行为描述，测试用例包含具体输入数据、环境配置；验收条件应保持业务语言，不可测试用例化。
• 一条验收条件覆盖多个场景：推荐“一个场景 → 一个验收条件”，便于独立验证和出错定位。
• 忽略异常验收条件：用户故事中的异常路径（网络超时、无权限、空数据）必须分别写出验收条件，否则开发很可能遗漏处理。
• 未绑定可衡量指标：仅写“响应快”属于主观描述，必须转化为可计量的阈值（如“响应时间 < 1s”）。