1. CBTC安全场景测试需求边界与可测性判定

从一条运营安全需求出发：先划边界，再谈可测

本案例给定一条典型的CBTC运营安全需求，任务是把它分解为可判定的测试需求，逐项判定可测性，并把不可测部分显式标注出来，形成一份测试需求边界说明。注意：这里不设计具体场景，也不写测试用例，只回答“这条需求到底要测什么、哪些能测、哪些测不了、测不了的部分靠什么替代”。

第一步：把需求拆成可判定的测试需求项

拆解原则是“一个测试需求项只对应一个可判定的安全行为或约束”。对上述需求，可拆出五项：

第二步：逐项判定可测性

可测性判定看三件事：能否构造输入、能否观测输出、判定准则是否明确。三者齐备为可测；缺一即为部分可测或不可测。

• TR-01 部分可测：障碍物可用试验台架或仿真注入，但真实线路上的检测时延受传感器与轨旁条件影响，实验室只能给出标称值，需标注“实测范围受限”。
• TR-02 可测：EB指令时刻可由车载日志或信号采集卡直接观测，判定准则为“EB发出时列车前端距障碍物距离 ≥ 最小安全距离”。
• TR-03 部分可测：停车点可测，但制动率受载荷、坡度、轮轨黏着影响，需限定工况集合，超出集合的部分不可测。
• TR-04 不可测（就本需求表述而言）：“无法避免碰撞”的判定阈值需求未量化，缺少可判定的边界条件，属于需求缺陷导致的不可测。
• TR-05 可测：记录字段与时间戳可直接比对，判定准则为字段齐全且时间戳与事件时刻偏差在允许范围内。

第三步：识别不可测部分并给出替代观测

TR-04 的不可测不是测试能力问题，而是需求本身缺少可判定阈值。处理方式不是硬造一个阈值，而是：

1. 把“无法避免碰撞”回退为需求澄清项，要求补充碰撞判定的量化条件（如相对速度、剩余距离、制动能力余量）。
2. 在澄清前，把 TR-04 降级为“预警输出存在性”观测项：只验证系统在给定注入条件下是否输出预警信号并记录，不判定“是否真的无法避免”。
3. 在边界说明中明确标注该降级，避免后续场景设计把替代观测误当成完整验证。

边界说明的落地格式

把上述结论整理成可直接交接给场景设计环节的边界说明，字段如下（示例填写）：