第1章 验收标准核心概念与价值

1.1 适用场景

验收标准并非只在项目收尾时才被关注，它的制定与评审贯穿整个软件生命周期。以下场景是强制需要明确验收标准的：

• 需求确认阶段：每项用户故事或功能特性必须附带可验证的验收条件。
• 迭代/冲刺计划会：团队共同约定当前迭代内交付物应达到的质量底线。
• 开发完成提测前：开发人员自测的依据，判断是否可移交测试。
• 测试用例设计：测试工程师基于验收标准编写测试场景和断言。
• 客户/业务方验收：对照验收标准逐项确认，避免主观判定导致的返工。

1.2 前置条件

在正式开始制定验收标准之前，需要以下输入已就绪：

输入项	状态要求	典型产出物
业务目标说明	已获干系人共识	项目章程/愿景文档
详细需求文档	至少有0.5版草稿	用户故事、用例、功能列表
技术可行性评估	已完成	技术方案或原理验证报告
验收角色定义	明确谁有最终签字权	利益相关者登记册

1.3 操作步骤

制定验收标准并非一次线性活动，而是不断收敛的迭代过程。以下是标准四步法：

1. 拆解功能意图：从需求描述中提取"做对的事"的关键条件。
2. 定义可测量行为：用Given-When-Then格式表述用户可观察的系统响应。
3. 划定边界：明确异常范围、性能阈值、安全合规约束。
4. 集体评审：产品、开发、测试三方确认"通过"的判定标准一致。

1.4 输入输出物

类型	输入	输出
文档/工件	业务需求、用户故事地图	验收标准清单（Ac清单）
数据	历史故障数据、行业规范	阈值定义表、检查项列表
工具产物	原型、UI设计稿	验收标准与设计对应矩阵

1.5 责任边界

验收标准不是单一角色的任务，各方在其中的权责必须清晰：

• 产品经理/业务方：提供业务期望，对标准中"正确性"负责。
• 开发工程师：确认标准在技术实现上可行，并据此自测。
• 测试工程师：将验收标准转化为测试用例，负责标准可验证性审核。
• 项目经理：组织评审会议，推动标准签署并追踪完成状态。
• 客户（最终验收者）：拥有验收标准的最终解释权。

1.6 记录材料

每项验收标准应记录在统一模板中，建议包含以下字段：

| 标准ID | 关联需求 | 场景描述 (Given-When-Then) | 通过/失败条件 | 优先级 | 创建者 | 评审人 | 状态 |
|--------|----------|----------------------------|----------------|--------|--------|--------|------|
| AC-001 | US-12    | 用户登录时输入正确密码     | 3秒内返回Token | P0     | 张三   | 李四   | 已通过 |

1.7 异常处理

在验收标准制定和使用过程中可能遇到的异常及应对预案：

异常情形	影响	处理措施
需求频繁变更	验收标准滞后，失去参照意义	建立变更关联机制，每次需求变化同步更新AC清单
标准含糊不可测	测试与开发对结果产生争议	引入"三朋友测试"：让非项目人员凭标准执行测试
多角色标准冲突	无法统一签发	召开仲裁会议，由产品负责人最终裁决
无历史数据支撑阈值	标准过于宽松或严苛	先设定保守值，运行2个迭代后根据实际数据校准

1.8 验收标准（本章）

完成本章学习后，学员应能：

• 用自己的语言描述验收标准的定义及其在软件生命周期中的定位。
• 列举至少3条验收标准与需求、测试之间的正向关系。
• 指出验收标准缺失或模糊时对交付质量造成的典型风险。
• 在给定的项目场景中正确区分输入物与输出物。