资源 · 61
项目验收：将需求转化为标准和证据
准备场景、预期结果、证据和例外情况决策，通过实际测试的任务来评估交付情况。
已更新 · 3 min
本指南有助于实现的目标
- 从任务开始
- 编写可测试的预期
- 将证据与场景关联
- 解决异常
快速检查
- 谁应该接收交付？
- 异常是否算通过？
- 修正后测试是否可以重用？
分步指南
- 1
从任务开始
说明谁需要在什么情况下完成什么，以及在什么约束条件下。 所提出的方法借鉴了 GOV.UK 的服务评估准备工作，但并未将私人验收视为公开认证。
交付物：需求和优先级流程。
- 2
编写可测试的预期
将“快速”或“直观”等词语替换为可观察的结果和测量环境。 包括错误、权限、语言和可访问性。 标准说明用户除了功能存在之外还能获得什么。
交付物：标准和虚拟测试数据。
- 3
将证据与场景关联
记录每次试验的版本、环境、前提条件、操作和结果。 仅凭屏幕截图无法证明测试成功。 请准备审核人员无需访问机密信息即可检查或重现的证据。
交付成果：可重现的证据记录。
- 4
解决异常
在验收前，定义阻塞性故障、允许的例外情况及其负责人。 已接受的例外情况需要明确范围、原因和截止日期；它并不能将失败的测试变成通过的测试。
交付成果：例外情况登记表和决策。
- 5
与运维部门完成交接。
同时包括测试文档、恢复和支持交接。 对于人工智能服务，需明确限制和负责人。 保留测试范围，并说明需要再次验收审核的未解决问题和条件。
交付成果：交付决策和例外情况跟进。
可重复使用的工作表
填写您已授权的观察结果。 这些字段是工作模板，而非观察结果。
| 字段 | 待记录信息 |
|---|---|
| 需求 | 人员、任务和背景 |
| 标准 | 预期结果和前提条件 |
| 试验 | 版本、虚构数据和观察结果 |
| 决策 | 例外情况、所有者和截止日期 |
虚构示例
示例情境
虚构示例：表单提交案例后，在移动设备上丢失了附件。
决策及预期证据
验收标准区分技术提交和完整案例；只有当接收者能够找回附件时，需求才能满足。
区分机制
| 机制 | 目的 | 验证或限制 |
|---|---|---|
| 演示 | 理解选定的旅程 | 不要将其视为全面覆盖 |
| 业务验收 | 验证任务和预期结果 | 包含错误和不同的用户配置文件 |
| 技术评审 | 检查合同和行为 | 将结果与用户需求联系起来 |
管理指标
| 指标 | 衡量内容 | 首要行动 |
|---|---|---|
| 已覆盖的标准 | 实际执行的标准 | 区分未测试、已通过和未通过的测试 |
| 未解决的例外情况 | 已接受或已阻碍的差距 | 指定负责人和截止日期 |
| 可重现的证据 | 可重构的场景 | 记录版本和前提条件 |
常见错误
- 不要将其视为全面覆盖
- 包含错误和不同的用户配置文件
- 将结果与用户需求联系起来
常见问题解答
谁应该接收交付？
指定需求负责人，并征求相关专家的意见。 在测试前明确此责任。
异常是否算通过？
否。 它仍然是一个已知的差距；验收是在范围内做出的已记录的决定。
修正后测试是否可以重用？
是的，在数据稳定且满足前提条件的情况下，需要命名新版本并说明可能受影响的流程。
官方参考文献
参考文献支持该方法。 请根据您的实际情况调整检查；它们并非认证。 原始参考文献标题和源文档可能使用其他语言。
参考资料查阅日期 .
