产品验收标准与QA协同质量门禁 - 第1节

1.1 适用场景

验收标准并非对所有需求场景同等适用。以下场景必须显式定义验收标准：

• 用户故事（User Story）：在Sprint计划中，每个故事必须附带验收标准才能进入开发。
• 功能需求：新增/变更的功能点，需通过验收标准明确“做完”的定义。
• 非功能需求：性能、安全、可用性等维度，必须用可量化的验收标准约束。
• 缺陷修复：修复验证的标准需要与原始需求验收标准对齐。
• 第三方集成：接口对接、数据同步等边界场景，验收标准是联调通过的依据。

1.2 前置条件

制定验收标准前，团队需具备以下条件：

1. 需求已通过需求评审，核心业务逻辑无二义性。
2. 产品负责人（PO）与开发、QA三方已对齐需求上下文。
3. 团队已确定本次迭代的DoD（完成的定义）基线。
4. 具备可用的测试环境或测试桩说明。

1.3 验收标准核心定义

验收标准是一组可执行的断言集合，用于判断一个需求是否满足预期。它不是需求的复述，而是需求的可测试化映射。

1.4 质量属性分类框架

验收标准需要覆盖以下七个质量属性维度。每个维度对应不同的验证方法：

• 功能正确性：输入→输出逻辑正确，包括边界值、异常流。
• 性能：响应时间、吞吐量、并发数等量化指标。
• 安全性：权限校验、数据加密、防注入等。
• 可用性：UI交互符合预期，错误提示清晰。
• 兼容性：浏览器/设备/系统版本覆盖。
• 可维护性：日志输出、错误码规范、配置分离。
• 可靠性：异常恢复、数据一致性、无崩溃。

1.5 操作步骤：制定验收标准的标准流程

1. 步骤一：解析需求——从需求中提取触发条件、执行动作、期望结果。
2. 步骤二：按质量属性分类——将提取的要素归入1.4节中的七个维度。
3. 步骤三：为每个属性编写断言——使用“如果…那么…”句式，确保无歧义。
4. 步骤四：边界与异常补充——至少写出3个正常流 + 2个异常流验收标准。
5. 步骤五：三方评审（PO+Dev+QA）——确保PO认可业务、Dev认可可实现、QA认可可测试。

1.6 输入输出物

1.7 责任边界

• 产品负责人（PO）：负责验收标准的业务正确性和完整性。
• 开发工程师（Dev）：负责判断验收标准技术可行，并据此编写代码。
• 测试工程师（QA）：负责验收标准的可测试性审核，并将标准转化为测试用例。
• Scrum Master：监督验收标准是否在Sprint计划阶段完成，避免事后补充。

1.8 记录材料

以下为验收标准记录的示范模板，建议存储在文档库或任务管理工具中：

# 验收标准清单 - [需求ID/故事名称]

## 功能正确性
- AC01：输入合法A值，系统应返回正确计算结果。
- AC02：输入非法字符，系统应提示“格式错误”并阻止提交。

## 性能
- AC03：在100ms内完成单次请求响应（95分位）。

## 安全性
- AC04：未登录用户无法访问API接口，返回401。

## 兼容性
- AC05：在Chrome 110+、Edge 110+、Safari 16+中UI渲染一致。

1.9 异常处理

1.10 可测试性原则

任何一条验收标准必须通过“SMART”检验：

• S（Specific）：具体，不笼统。 ❌“系统响应快” → ✅“95%请求在200ms内完成”。
• M（Measurable）：可度量。 ❌“体验好” → ✅“首次内容绘制时间小于1.5s”。
• A（Achievable）：可达成。 ❌“100%无故障运行10年” → ✅“无故障运行48小时”。
• R（Relevant）：与需求相关。 ❌“数据库使用MySQL 8.0” → ✅（只在架构决策中出现，不在验收标准中重复）。
• T（Testable）：可验证。 ❌“系统应当安全” → ✅“未授权用户访问控制台，应在3秒内被拒绝并记录日志”。

1.11 本章验收标准检查清单

本章内容本身也需满足验收标准。以下是自检得分卡：