分支剧情怎么测试：状态矩阵、路径覆盖与回归测试完整模板

分支剧情不能靠“把每条路线玩一遍”完成测试。路径会迅速增长，许多缺陷来自状态组合。更可靠的方法是先验证状态转移，再用风险优先的路径覆盖关键组合，最后把每次缺陷转成回归用例。

删除没有读取点的变量，补齐没有来源的读取条件。

每条用例记录起始节点、前置状态、操作、预期下一节点、状态变化和截图或日志。限时选择还要测超时、边界输入与重复点击；媒体节点要测加载失败和恢复。

优先覆盖两个变量的关键组合，例如关系高低与是否持有钥匙、QTE 成败与是否掌握线索。它不能替代高风险全组合，但能以较低成本发现常见条件错误。

默认主线、每个结局的最短路线、最低资源路线、全 QTE 失败路线、存档/章节恢复路线，以及历史严重缺陷的回归路线。

版本/平台：
起始节点与前置状态：
复现步骤：
实际/预期结果：
发生频率：
截图或日志：

发布前至少确保所有严重缺陷关闭、每个结局可复现两次、存档升级和章节跳转已验证，并明确尚未覆盖的组合风险。

只拿故事图测试，会知道玩家从 A 到了 B，却不知道哪些变量被写入。状态字典为变量定义类型、默认值、合法范围、写入与读取节点。任何变量改名或范围变化，都要同步更新用例。

关系值尤其容易失控。不要只写“信任增加”，应写从多少到多少、是否封顶、哪些场景读取，以及界面如何反馈。若结局条件是 trust > 3，边界值 3 和 4 都必须测试。

正常选择之外，还要测试重复点击、倒计时边界输入、断网、切后台、媒体加载失败、快速跳过、切换语言与恢复存档。常见缺陷不是故事写错，而是状态在异常操作后被重复写入或完全漏写。

每条用例从可复现存档开始。只写“进入第三章点击左边”不足以复现，因为第三章可能继承不同关系和道具。

P0 覆盖主线、全部结局、存档损坏和内容安全；P1 覆盖重要关系、道具、QTE 与章节跳转；P2 覆盖局部对白和低风险视觉差异。每次提交跑节点与 P0 冒烟，候选版本再跑 P1/P2。

覆盖率不要只报走过多少节点。同时报告状态转移、结局条件、异常恢复和未测组合。一个节点被访问过，不代表它的全部条件正确。

每修复一个问题，就把原始前置状态和操作加入回归集合。若问题来自章节跳转默认值，今后的所有版本都要验证这个场景，否则同类错误会在重构后重新出现。

例如玩家在 N05 获得钥匙，跳到 N08 后系统却使用默认 has_key=false。记录应包含完整流程与跳转流程对照、存档版本和日志；修复后分别验证新存档、旧存档与章节重开。

报告列出通过的结局、关键路径、阻断缺陷、剩余风险和版本。不要用“全流程已测”这种不可审计表述。目标不是宣称没有 bug，而是让决策者知道哪些因果已验证、哪些组合仍未知。

主线首通、付费入口、不可逆选择和最终结局列为最高风险，每次构建都跑；常见支线和主要汇流按日回归；罕见组合可按版本轮换。优先级由用户影响、发生概率、修复成本和历史缺陷共同决定，不能只测试最容易自动化的路线。

每条用例写清初始存档、操作步骤、预期状态、可见结果和清理方式。失败时保存构建号、节点、状态快照、截图或录像及最短复现路径。若只能描述“偶尔跳错结局”，开发者很难定位是条件计算、存档迁移还是媒体加载问题。

新增状态、重命名节点或调整默认值时，用发布版旧存档进入新构建，检查缺失字段如何补齐、已解锁内容是否保留、回档是否越过关键迁移。全新存档通过并不代表升级安全。无法兼容时应提前说明影响并提供可理解的处理方案。

验收会议只处理有证据的结果：哪些路径已跑、覆盖了哪些状态边界、剩余缺口为何可以接受。把未覆盖区域明确列出，比用一个笼统通过率制造安全感更有价值。