W8.01.3Testing extreme custom combinations设计
极端自定义组合需要测试确保仍可通关
别名: 极端组合 · edge case testing · completability · custom difficulty QA
概念解释
难度参数开放自定义后，玩家可能组合出设计者没有预设过的极端配置：游戏速度 0.5 倍加无敌加自动瞄准，或伤害 10 倍加资源稀缺加计时收紧。这些组合可能让某些关卡在逻辑上无法通关（需要承受一轮攻击的谜题在无敌模式下失去触发条件）、或让后续内容失去平衡（经济在 10 倍掉落下崩溃）。极端组合测试（extreme combination testing）验证所有参数组合下游戏仍可被推进到结局，是开放自定义的配套义务。
机制
参数组合的故障模式不是参数本身的问题，而是游戏逻辑对参数的隐含依赖。关卡设计在默认难度下写成「承受 Boss 三次攻击后触发过场」，伤害调到最低后玩家永远达不到触发条件，游戏卡死。这类依赖在开发时不可见——默认参数下一切正常，只有组合空间被展开后才会暴露。测试不能穷举所有组合（参数是连续值），但可以系统化采样：每个参数取最小、默认、最大三个值，组合空间虽然仍有多个维度，但关键故障集中在少数参数的极端值上，采样覆盖率远高于随机测试。
边界
「保证可通关」不等于「保证所有组合下体验合理」。极端组合（比如无敌 + 一击必杀）可能让游戏变得无聊，这是玩家的选择而非缺陷——测试的义务是可通关和可推进，不是替玩家判断配置是否有趣。测试资源有限时的优先级：主线必需路径的组合优先于支线，战斗参数的组合优先于画面参数。此外，发售后新增参数（DLC、补丁）会扩大组合空间，极端组合测试需要作为回归测试在每次参数变更后重跑，不是一次性义务。
怎么落地
- 列出全部可调参数和取值范围，用每个参数的最小/默认/最大值生成采样组合清单，优先覆盖影响核心循环的参数。
- 对每个采样组合执行「可通关性冒烟测试」：主线每个章节的进入、关键机制触发、结局达成三点确认。
- 验证办法：把发现卡死的组合整理成已知约束清单，在自定义界面约束这些组合（禁用冲突值并说明原因），或修复底层依赖让参数真正独立。