3. 可靠性测试自动化总体框架设计

星载计算机的可靠性测试不是单一软件的职责，而是由测试用例、激励设备、被测单机、判据引擎和测试数据共同构成的闭环系统。总体框架设计的核心任务，是把“分层架构、软硬件协同、执行引擎、资源管理与数据流”四件事统一到一张可落地的蓝图上，使测试脚本、硬件接口、判据逻辑和数据记录彼此解耦，又能协同工作。

一、测试自动化分层架构

推荐采用五层结构，自下而上依次为：硬件接口层、设备抽象层、测试服务层、测试执行层和测试应用层。硬件接口层直接面对1553B总线板卡、RS-422串口卡、LVDS采集卡、程控电源和数字万用表等物理设备，负责时序收发与电平匹配；设备抽象层把不同厂商的板卡封装成统一接口，例如将“发送1553B消息”抽象为 bus.send(cmd, data, timeout)，屏蔽底层寄存器差异；测试服务层提供遥测解析、指令注入、电源时序控制、故障注入等原子能力；测试执行层负责用例调度、参数绑定、判据判定和结果记录；测试应用层面向测试人员，提供用例编辑、执行监控和报告生成界面。

分层的价值在于：更换一块总线板卡时，只需修改设备抽象层的驱动适配，上层用例和判据不受影响；新增一类判据时，只需扩展执行层的判据插件，不必改动硬件接口。这种“下层稳定、上层灵活”的结构，是自动化测试能够长期维护的前提。

二、软硬件协同机制

软硬件协同的关键是时间同步与事件对齐。星载计算机测试中，一条遥控指令发出后，遥测参数可能在几十毫秒到数秒后变化，判据必须基于统一时基。框架中通常由硬件接口层提供IRIG-B或PTP时间戳，测试服务层在采集遥测时打上同一时基的标签，执行引擎再按时间窗口比对“指令发出时刻”与“遥测响应时刻”。

协同还包括状态机同步：被测单机可能处于加电、自检、待机、工作、安全模式等状态，测试脚本必须根据当前状态决定可执行的指令集。框架中用一个共享的“被测对象状态表”记录当前模式，执行引擎在每一步操作前检查前置状态，避免在错误状态下注入指令导致误判。

三、测试执行引擎

执行引擎是框架的“心脏”，建议采用“用例描述—参数绑定—步骤执行—判据评估—结果归档”的流水线。用例以结构化文本或表格描述，例如：

用例编号: TC-PWR-001
前置状态: 单机处于待机模式
步骤1: 设置程控电源输出 +28V，上升时间 10ms
步骤2: 等待 500ms，采集遥测帧 0x1A 的电源状态字
判据: 电源状态字 bit0 = 1 且 母线电压在 27.5V~28.5V 之间
超时: 2000ms

引擎按步骤驱动设备抽象层，每一步执行后立即采集判据所需数据，并记录时间戳、原始值和判定结果。判据评估采用插件式设计，支持阈值判据、趋势判据、序列判据和统计判据。执行过程中若某步超时或判据失败，引擎按预设策略选择继续、重试或中止，并保留现场数据用于复盘。

四、资源管理与数据流设计

资源管理要解决“谁在用、用多久、冲突怎么办”。框架中把总线通道、串口、电源通道、故障注入通道等抽象为可申请资源，执行引擎在用例开始前申请资源，结束后释放；若资源被占用，则进入等待队列或按优先级抢占。对于多站并行测试，资源锁必须支持跨进程，避免两个用例同时向同一1553B通道发送指令。

数据流设计遵循“采集—缓存—判定—归档”四段式。采集层以固定周期或事件触发方式获取遥测、总线和电源数据；缓存层用环形缓冲区保存最近若干秒的原始数据，便于判据回溯；判定层从缓存中按时间窗口取数，执行判据；归档层把原始数据、判据结果和用例元数据写入测试数据库，并生成可追溯的测试报告。数据流中每一段都带统一时基和用例标识，确保事后可以还原“哪条指令、在什么状态、引发了什么响应、判据为何通过或失败”。

五、关键设计约束与落地建议

第一，时基必须统一。所有采集数据、指令记录和判据结果都带同一时间源标签，否则“指令发出后多久响应”无法准确判断。第二，资源必须互斥。总线通道和电源通道在任一时刻只能被一个用例占用，跨进程锁是并行测试的安全底线。第三，判据必须可配置。阈值、时间窗口、重试次数等参数应放在用例描述中，而不是硬编码在引擎里，便于不同型号单机复用同一套框架。第四，数据必须可追溯。每条判据结果都要能回溯到原始采集数据、用例版本和被测对象状态，这是可靠性测试报告具备说服力的基础。

实际落地时，可先实现最小闭环：一个1553B通道、一个程控电源、一条“加电—等待—采集—判据”的用例，跑通后再逐步扩展设备抽象层和判据插件。框架的价值不在于一次设计完美，而在于分层边界清晰，使后续新增设备、新增判据和新增测试模式都能以增量方式接入，而不推翻已有结构。