3. 联锁测试环境搭建与工具链

联锁逻辑测试的结论是否可信，很大程度上不取决于测试用例写得多巧妙，而取决于测试环境是否“可复现”。同一组进路排列、信号开放、区段占用与故障注入条件，今天跑出通过、明天跑出失败，如果无法判断是联锁逻辑真的有问题，还是环境本身漂移了，那么后续的故障定位就失去了基准。因此本节的核心任务不是简单地把软件装起来，而是围绕仿真测试平台、联锁仿真机、接口模拟器、测试脚本框架与版本管理五个要素，搭建一条从被测逻辑到外部接口、再到测试执行与结果归档的完整工具链，并把它固化为可重复使用的测试基线。

一、工具链的分层结构与职责边界

联锁测试环境通常按“被测对象—接口适配—激励与采集—执行与归档”分层组织。最内层是联锁仿真机，它加载联锁逻辑程序（或逻辑数据），对外表现为一套完整的联锁运算实体，接收来自接口模拟器的采集码位，输出驱动码位。中间层是接口模拟器，它替代真实的轨旁设备与相邻系统，把道岔、信号机、轨道区段、计轴、站台门、屏蔽门以及相邻联锁的接口状态以码位形式提供给联锁仿真机，同时接收联锁输出的控制命令并回读其状态。外层是仿真测试平台，负责场景编排、时钟推进、故障注入与结果记录；最外层是测试脚本框架，把测试用例翻译成可自动执行的激励序列与断言集合。版本管理则贯穿全部层次，保证逻辑程序、接口配置、脚本与用例数据处于同一可追溯的版本组合。

二、联锁仿真机与接口模拟器的关键配置

联锁仿真机不是“把程序跑起来”就完事，它需要与真实联锁保持一致的运算周期与数据接口。搭建时应明确三件事：逻辑程序版本、逻辑数据（站场拓扑、进路表、码位表）版本、以及运算周期。以常见的周期运算型联锁为例，可把仿真周期设为 100 ms，与现场设备扫描周期对齐；若测试时序类逻辑（如信号开放后的接近锁闭延时），周期设置必须与设计文件一致，否则延时判据会整体偏移。

接口模拟器的核心是码位映射表。它把联锁的每一个采集码位与驱动码位映射为可编程的变量，例如把“1G 轨道区段占用”映射为采集码位 ACQ_1G_OCC，把“X 信号机绿灯驱动”映射为驱动码位 DRV_X_G。映射表必须与联锁码位表逐条核对，任何一条错位都会导致“逻辑正确但现象错误”的假故障。实际搭建时建议先做一次空跑核对：不加载任何测试用例，仅让接口模拟器把所有采集码位置为“空闲/无占用”的默认态，观察联锁仿真机是否进入稳定的初始状态、有无异常报警，以此确认映射方向与极性（常开/常闭、高有效/低有效）没有接反。

三、测试脚本框架：把用例变成可执行的激励与断言

测试脚本框架的价值在于把“人读的用例”转成“机读的激励序列 + 断言集合”。一个实用的框架通常包含四类原语：置位/复位（设置采集码位）、等待（按时钟推进或条件等待）、断言（检查驱动码位或内部状态）、注入（制造故障，如强制某区段持续占用、模拟通信中断）。下面给出一个以进路排列为例的脚本片段，参数为教学示例，实际值应以本站码位表和设计文件为准：

# 用例：X→S 接车进路排列（示例参数）
SET   ACQ_1G_OCC   = 0      # 1G 区段空闲
SET   ACQ_3G_OCC   = 0      # 3G 区段空闲
SET   ACQ_X_DW     = 1      # 道岔 X 定位表示
SET   ACQ_S_DW     = 1      # 道岔 S 定位表示
WAIT  200ms                 # 等待采集稳定
CMD   ROUTE_SETUP  X_TO_S   # 下发进路排列命令
WAIT_UNTIL DRV_X_G == 1  TIMEOUT 3000ms
ASSERT DRV_S_H == 1         # S 信号机红灯应熄灭/绿灯点亮（按设计）
ASSERT DRV_X_G == 1
ASSERT LOCK_1G  == 1        # 1G 区段应进入锁闭

脚本中的 WAIT_UNTIL 与 TIMEOUT 是保证可复现的关键：等待必须带超时，断言必须给出明确的期望值与判定依据。若某条断言失败，框架应记录失败时刻的完整码位快照（采集侧与驱动侧全部码位），这份快照就是后续故障定位的原始证据。建议框架统一输出“用例编号、基线版本、失败断言、时刻、码位快照”五元组，便于回归比对。

四、版本管理：让“同一基线”真正成立

可复现的测试基线，本质上是一组版本号的固定组合。建议把联锁逻辑程序、逻辑数据、接口模拟器码位映射表、测试脚本与用例数据分别纳入版本管理，并用一个基线标签把它们绑定在一起。例如基线 BL-2024-03-A 对应逻辑程序 v2.3.1、逻辑数据 v1.8.0、映射表 v1.8.0、脚本库 v0.9.4。任何一次测试报告都必须记录该基线标签，否则结果无法复现。

版本管理还要解决“环境漂移”问题。常见漂移来源包括：接口模拟器映射表被临时修改、仿真周期被调整、故障注入脚本残留未清理。对策是把这些配置全部纳入版本库，并在每次测试启动时执行一次基线自检：比对当前加载的映射表哈希、周期参数、注入开关状态与基线标签所记录的值是否一致，不一致则拒绝启动或显式告警。这样，测试结论才能稳定地归因到联锁逻辑本身，而不是环境差异。

五、一次完整的基线验证示例

假设要验证“1G 区段故障占用时，已排列进路应保持锁闭且信号不得开放”。在基线 BL-2024-03-A 下，脚本先按正常条件排列 X→S 进路并确认信号开放，随后通过接口模拟器把 ACQ_1G_OCC 置 1 模拟故障占用，等待 500 ms 后断言：信号驱动码位应回到禁止开放状态、1G 锁闭状态保持、且不出现进路自动解锁。若断言全部通过，记录该用例通过；若失败，则导出失败时刻码位快照，对照联锁逻辑数据中的区段锁闭条件逐条排查。整个过程在固定基线、固定周期、固定映射表下执行，结果可重复、可追溯，这才是“可复现测试基线”的实际含义。

综上，联锁测试环境搭建的重点在于把仿真测试平台、联锁仿真机、接口模拟器、脚本框架与版本管理组织成一条职责清晰、数据流向明确的工具链，并以基线标签固定全部版本与配置。只有工具链本身稳定可信，后续的联锁逻辑测试结论与故障定位才有可靠的起点。