需要覆盖正常、异常与极端场景三类工况
别名: 验证场景覆盖 · 异常工况测试 · beyond-design-basis scenario
概念解释
验证场景覆盖（scenario coverage for validation）要求用正常、异常和极端三类条件检验设计，而不是只在日常流程下测一遍就收工：正常场景暴露的是日常效率和长期累积的操作负担，异常场景检验的是诊断速度和处置恢复，极端场景检验的是能力边界、资源冲突和安全停止的可靠性。覆盖不是从每一类里各挑一个代表性故事，而是要覆盖与风险相关的任务组合。
机制
只在正常工况下测试之所以测不出安全问题，是因为安全关键的失效恰恰发生在系统偏离正常的那一刻。同一个设计缺陷在不同工况下的后果完全不同：把关键信息埋在多层菜单里，在正常工况下不会造成事故，因为操作员有充裕的时间去逐层查找；但同样的信息层级放到异常工况下——需要在短时间内判断多个异常的优先级——就可能直接导致误判或延误处置时机；放到极端工况下——多个异常同时发生、操作员的认知负荷已经很高——查找路径本身就可能被彻底放弃，因为没有余量再去做主动搜索。三类工况之所以要分开设计测试，是因为它们检验的其实是不同的能力：正常工况测的是效率与常规流程是否顺手，异常工况测的是诊断速度和优先级判断是否正确，极端工况测的是在多重压力叠加之下，操作员能不能仍然完成那些不可省略的最低限度安全动作。只做单一工况的测试，等于只验证了设计在某一种能力需求下的表现，对另外两种能力需求完全没有信息。
怎么研究
从风险分析、任务分析和运行经验中建立场景覆盖矩阵，为每个场景标注它触及的安全功能、涉及的角色和所处的环境条件，而不是先想好几个场景再倒推它们覆盖了什么。对已经测过的场景，用机制等价但表现形式不同的新变体去检验设计的稳健性，避免测试结果只对某个具体故事情节成立。极端场景不等于任意小概率事件的堆砌，需要说明它的可信依据来自哪里——是历史事件、是风险评估的边界值，还是已知的共因失效模式，同时也要如实报告哪些理论上可能的组合没有被覆盖到，以及不覆盖的理由。
边界
组合数量随因素数增长很快，不可能穷举所有正常、异常、极端条件的排列组合，因此风险导向的抽样、边界值选取和共同原因条件的优先覆盖，比盲目堆砌场景数量更有价值。超出设计基准的极端场景测试结果，可以用来做韧性方面的学习——了解系统在设计假设之外还能撑多久、以什么方式失效——但不应该把这类学习结果混同为法定验收范围内的通过或不通过。
怎么落地
- 用场景—任务—安全功能矩阵显示已覆盖和尚未覆盖的部分，让空白可见而不是被掩盖。
- 在每一类工况中都加入中断、错误数据和资源受限这几种可信的组合条件，而不是让每类场景只测单一变量。
- 报告未覆盖项及其选择理由，并在设计变更或发生实际事件之后重新评审和更新这份矩阵。
- 针对异常与极端场景，分别记录诊断到判断优先级所用的时间，以及在高负荷下是否仍完成了最低限度的安全动作，这两类指标不能用效率类指标替代。