平台认证与验收

原理：把平台要求转成可追踪证据

每条要求至少有四个字段：

认证失败常来自边界状态：断网/重连、账号切换、手柄断开、低存储、挂起恢复、地区限制、首次启动和更新迁移。测试矩阵要覆盖“功能 × 状态 × 平台”，而不是只跑理想路径。

应用：从需求到提交

flowchart TD
    R["平台原文要求"] --> T["需求追踪表"]
    T --> I["实现与配置"]
    I --> V["设备/账号状态测试"]
    V --> E["证据包"]
    E --> S["提交候选包"]
    S --> F{"反馈"}
    F -->|"通过"| P["发布门控"]
    F -->|"失败"| I

建议把平台验收纳入 CI/CD：自动完成包签名、启动 Smoke、存档迁移、网络断线、输入设备和内容检查；需要真实设备或人工判断的项目进入发布前测试池，并保留设备型号、系统版本和区域信息。

认证与最佳实践的边界

• 正式认证要求：例如 Xbox Requirements/Certification 文档中的条款，按目标产品、平台和 SDK 版本逐条满足。
• 可访问性指南：Xbox Accessibility Guidelines 提供 best practices、guardrails 和 validation checklists；其定位不是一张可替代认证条款的 compliance checklist。应将其用于发现风险、改善体验和设计测试，而不是声称“遵循指南即通过认证”。
• 商店要求：素材、年龄分级、隐私政策、第三方许可和地区限制可能由商店另行要求，需使用当前版本官方页面核对。

取舍与常见坑

• 过早依赖最终硬件：早期用模拟/自动化覆盖状态逻辑，最后再用目标设备确认体验差异。
• 证据不可复现：只贴截图不记录包版本、步骤和设备，无法响应平台复测。
• 忽视更新路径：认证通过首发包不代表补丁、DLC、跨版本存档和账号切换安全。
• 把建议当条款：引用指南时标注其性质和版本，避免过度承诺。
• 合规孤岛：让平台、工程、策划、QA 和客服共享同一追踪表，减少“实现了但没人知道”的风险。