# 示例：评估与发布报告

版本 1.0 · 2026 年 10 月 13 日 · Wavect

本报告使用虚构的 B2B 预约产品展示交付格式。以下记录为示例，不是客户的测试结果。

## 任务与评估方法

将已有原型准备到首次客户试点，并把运营交接给客户团队。范围包括预约创建、角色权限、请求重试和恢复。两个合成租户各有管理员、编辑者和只读用户。检查版本 A，记录可复现问题，再使用相同测试数据在版本 B 中复测约定的修复。

## 发布决策

**在恢复检查 OP-01 通过前，暂缓试点。** 示例复测中的权限与重试修复符合相应验收要求。备份任务成功本身，不能证明接手团队能够恢复服务。

## 问题与复测记录

| ID | 严重程度与影响 | 复现步骤 | 版本 A 的预期 / 观察结果 | 版本 B 的验收与状态 | 负责人 |
| --- | --- | --- | --- | --- | --- |
| QA-01 | 高：只读用户可修改预约 | 使用租户 A 的只读身份发送与编辑者相同的更新请求，再刷新预约 | 预期拒绝且记录不变；观察到更新被接受 | 通过：只读请求被拒绝且记录不变；A 的编辑者仍可更新；租户 B 无法访问记录 | API 工程师 |
| QA-02 | 高：重试产生重复预约 | 提交预约、中断响应，再用同一请求 ID 重试 | 预期一条预约且返回同一结果；观察到两条预约 | 通过：重试返回原结果；两个不同请求仍创建各自的预约 | API 工程师 |
| OP-01 | 发布阻碍：恢复职责未经验证 | 用接手团队的权限，在隔离环境中恢复最新合成备份 | 预期预约可读且重启有文档；观察到缺少恢复权限与负责人 | 阻塞：分配权限、完成恢复、核对测试记录，并按约定目标测量恢复时间 | 平台负责人 |

严重程度由本范围内的用户影响和恢复难度决定，与发现问题的工具无关。高严重度问题在试点前需要修复，或由明确负责人作出风险接受决定。发布阻碍表示未满足约定的发布条件。

## 原型救援：保留、加固、替换

- **保留：** 可用的预约模型和日历界面；每次修复后用相同数据验证。
- **加固：** 后端权限和请求去重。既检查失败场景，也检查获准操作。
- **替换：** 将依赖离任供应商账户的部署路径迁移到客户控制的账户。这些问题并不要求重写预约功能。
- **顺序：** 建立客户权限，修复 QA-01 与 QA-02，复测，再完成 OP-01 后批准试点。工作量与报价根据代码库检查及约定的修复范围确定。

## 接手验收

接手团队必须能够从固定提交构建、部署到预发布环境、验证关键预约流程、查看监控并执行恢复。记录代码库与环境负责人、密钥存放位置（不含密钥值）、部署与回滚步骤、备份保留规则和支持升级路径。确认替代权限可用后，再轮换继承的凭据。

源代码、基础设施账户和问题登记表由客户保有。每个未解决事项都需要负责人、下一次检查和决策日期。交接在新团队演示约定运营步骤后完成，而不是在发送文档时完成。

## 证据索引与剩余范围

附上 A 与 B 的提交标识、测试数据说明、QA-01 和 QA-02 的脱敏请求与响应记录、回归输出以及 OP-01 恢复日志。在问题、修复和复测中保持相同证据 ID。每个结果记录评审人、日期和环境。

负载能力、支付集成、移动离线运行和真实客户数据不在本示例范围内。“通过”适用于注明的检查与版本。报告以明确的下一步发布决策及负责人结束。