结论先行

staging 中“游戏能打开”只证明一条正常路径在一个测试环境中成功过。进入 production 前，还需要证明候选版本和验收范围已经冻结，功能与异常路径得到验证，账务和记录能够对齐，生产配置与权限边界清楚，故障责任有人承担，并且回滚或停止方案可执行。

验收应当输出证据和结论，而不是只输出“已测试”。建议每一项都记录环境、候选版本、用例、实际结果、证据位置、责任人和阻断级别。没有证据的项目保留为“未验证”，不因会议口头确认而自动通过。

七类生产前验收证据

类别 最低通过证据 应阻断 production 的情况
1. 范围与候选版本 双方确认的接口、钱包、游戏范围、候选版本、配置清单和未包含项 候选版本仍变化；测试范围与拟发布范围不一致
2. 功能路径 启动、返回、钱包主流程、记录查询等约定用例有可复核结果 关键主流程失败；只验证前端展示，没有后端业务结果
3. 异常路径 超时、重复、断连、业务失败、部分成功或状态不明用例有结论 异常后无法判断最终状态；团队只能靠盲目重试恢复
4. 对账与一致性 请求、交易、局、金额、币种、余额或账变能够用稳定标识关联 记录无法关联；差异没有查询、处理和关闭路径
5. 安全与环境隔离 staging 与 production 的凭据、访问、数据、日志和配置边界已核验 复用测试凭据；秘密进入代码或日志；生产权限不清楚
6. 责任与运行准备 上线决策人、技术值守、账务差异、安全事件和升级路径已确认 只有销售联系人；故障与资金差异无人负责
7. 回滚、停止与恢复 回滚或停止条件、执行人、数据处理、恢复验证和沟通路径已确认 无法安全停止；回滚后账务或交易状态无人核对

0. 开始验收前：冻结范围和证据格式

在执行测试之前，先记录以下基线：

  • 候选发布版本、API 文档版本和配置版本；
  • 计划启用的厂商、游戏、钱包模式、币种、语言和市场范围；
  • 明确不在本次上线范围内的项目；
  • staging 与 production 的差异清单；
  • 每个用例的前置条件、输入、预期业务结果、实际结果和证据位置；
  • 缺陷严重级别、例外批准人和最终 go / no-go 决策人。

如果测试对象和发布对象不是同一个候选版本，应重新评估受影响的验收项，不能沿用旧结论。

1. 功能验收

功能验收至少应覆盖双方约定的完整业务链，而不只是一张游戏画面：

  • 游戏目录或目标游戏能够按约定标识被识别；
  • 会话创建、进入、返回和过期行为符合约定；
  • 采用的钱包模式完成约定的主流程；
  • 业务结果不能只由 HTTP 状态推断，需按接口协议判断；
  • 交易、局和相关记录能够查询并与测试动作对应；
  • 不同权限、币种、语言或设备范围只测试已进入本次基线的组合。

通过条件应写成可观察结果，例如“测试交易可由指定业务标识查询并与账变一致”，而不是“钱包正常”。

2. 异常验收

异常用例应由风险和实际协议共同确定，通常包括：

  • 请求超时、响应丢失或连接中断；
  • 重复提交或重复回调；
  • 参数、权限、签名或业务校验失败；
  • 上下游部分成功，调用方得到的状态不完整；
  • 服务恢复后的查询、补偿、对账或人工升级；
  • 达到项目约定的重试边界后，系统能够停止自动动作并保留证据。

本清单只要求异常路径有被验证的结果，不替项目发明幂等键、重试次数或退避参数。具体设计见《幂等、重试和对账为什么要一起设计》，并以双方正式协议为准。

3. 对账与记录验收

使用至少一组正常交易和一组异常或状态不明场景，检查：

  • 请求标识、业务交易标识、局或投注标识是否能关联；
  • 金额、币种、方向、最终状态和时间解释是否一致；
  • 钱包余额或账变与交易记录是否相符；
  • 重复事件能否被识别，而不是生成两笔不可区分的结果；
  • 差异是否有负责人、处理记录、关闭条件和审计证据；
  • 查询或导出范围能否满足已约定的运营与财务复核需求。

验收通过只说明已覆盖的样本和场景满足标准，不代表未来不会发生差异。

4. 安全、配置与环境隔离

production 不是把 staging 配置原样复制到另一个地址。上线前至少应核验：

  • 测试与生产使用不同且受控的凭据、权限和配置；
  • 秘密不进入源码、截图、工单正文或普通应用日志；
  • 生产访问按职责最小化，并有授权、变更和撤销记录；
  • 日志既能支持追踪，又不会记录签名密钥、完整凭据或不必要的敏感数据；
  • 测试数据不会被误认为生产交易，生产数据不会未经批准流入测试环境；
  • 配置差异已被审阅，生产域名、网络规则和监控目标通过项目内的真实检查确认；
  • 依赖版本、时钟、证书或签名相关配置存在明确负责人。

英国赌博委员会的技术标准将开发、测试与生产系统分离列为其监管范围内的安全要求之一。这可以作为环境隔离的参考，但不同目标市场和项目仍需单独核验，不能据此声称已满足全部监管或安全要求。

5. 责任与运行准备

上线前将联系人升级为可执行的责任矩阵：

场景 需要预先确认的责任
API 或会话故障 首个响应方、证据要求、技术升级与外部沟通
资金或记录差异 暂停条件、对账人、业务决策人和关闭标准
游戏目录或版本变化 变更发起、影响评估、通知和回归测试
凭据或安全事件 隔离、轮换、调查、通知和恢复批准
发布与回滚 go / no-go、执行、验证和最终记录归属

如果响应目标、服务可用性或赔偿机制是上线条件，应在正式合同或双方确认的运行文件中约定。

6. 回滚、停止与恢复

不是所有 API 集成都能简单回退代码。涉及交易和钱包状态时，还要回答回滚期间已经发生的业务事件如何处理。验收至少应确认：

  • 触发停止或回滚的明确条件；
  • 可以关闭哪些入口，哪些在途事件仍需处理；
  • 回滚由谁执行、谁批准、谁验证；
  • 配置或版本恢复后，如何确认服务、记录和账务状态；
  • production 中已经生成的数据是否需要保留、补偿或人工对账；
  • 无法快速回滚时，是否有受控降级、暂停和沟通方案。

回滚方案应在风险允许的环境中演练或进行桌面推演，并保留结果。本文不假设 AG 已提供某种特定的回滚工具。

最终 go / no-go 记录

进入 production 前，建议用一页记录完成最终决策：

  • 候选版本与配置：明确；
  • 七类验收证据：逐项已核验、有条件通过或阻断；
  • 未解决缺陷与例外：包含风险、责任人和批准人；
  • 监控、升级、停止和恢复责任：明确；
  • production 访问和商业范围：另行批准；
  • 决策：go、限定范围 go，或 no-go；
  • 决策日期与签署角色：记录，但不以本文规定固定上线时间。

当前可用于项目评估的范围

  • 集成流程把需求确认、技术范围、测试验收和 production 前协调作为不同阶段；
  • 公开 API 参考展示业务结果码、请求或交易标识、两种钱包方向以及记录查询范围，可用于设计验收用例；
  • “游戏能打开”只覆盖一条可见路径，不能证明钱包、异常、记录与权限等完整集成已经通过；
  • 实际运行结果和 production 准入应以约定环境中的测试记录与双方签署结论为准。

使用这些信息时需要注意什么

  • 不确认 AG 已向任何具体项目提供 staging、production 凭据或生产准入；
  • 不规定固定测试周期、上线日期、重试参数、性能、容量或 SLA；
  • 不承诺通过 staging 就能在 production 得到完全相同的结果；
  • 不承诺某个游戏、版本或钱包模式适用于任一市场或现有平台；
  • 不宣称绝对安全，也不替代合同、合规、安全和生产变更审批。

常见问题

staging 全部通过，是否可以直接上线？

不能自动得出这个结论。还需要核验候选版本、环境差异、生产访问、责任、监控、商业范围和回滚条件，并由约定角色做 go / no-go 决策。

只测试正常路径可以吗？

不建议。超时、重复、断连、业务失败和状态不明往往最容易造成重复处理或账务差异。异常路径应按风险与协议进入验收。

谁应该签署上线结论？

由项目责任矩阵决定。通常技术、测试、运营或财务、安全以及具有生产决策权的角色分别确认自己负责的范围；销售确认不能替代技术或生产批准。

每个项目都必须执行相同清单吗？

七类证据可以作为共同骨架，但具体用例应根据钱包模式、业务范围、目标市场、现有平台和变更风险裁剪。裁剪本身也应被记录和批准。

延伸阅读与下一步

如需制定项目验收范围，可通过“联系我们”提供钱包模式、目标游戏、现有平台边界和预期环境；AG 再基于已确认协议协作定义用例与证据，不预先承诺上线时间或生产准入。

参考资料与适用说明

产品范围可参考集成流程、Slots API和公开 API 参考。

通用发布方法参考 Google SRE 的发布工程与生产就绪评审相关实践。市场特定的环境隔离示例参考英国赌博委员会的远程博彩与软件技术标准：安全要求。这些来源用于解释通用验收原则，不证明 AG 已实施其全部流程，也不构成任何市场的合规结论。

production 条件应由技术、QA、运营或财务、安全、商务和合规角色按实际项目确认，并写入正式项目文件。

需要把指南转成项目方案？

文章用于帮助团队梳理采购和接入问题，不替代技术、合同、认证或当地法律确认。

联系我们