做台架自动化测试的人迟早会撞上同一个问题HIL设备买回来只是开始真正磨人的是用脚本把它“跑起来”。dSPACE、NI、ETAS、Vector各家HIL系统都有自己的接口测试自动化工具想跟它们对话得为每家写一套适配层。ASAM XIL API就是来终结这种局面的——它把测试自动化和HIL台架之间的通信标准化了。这篇文章我从XIL API的基本定位讲起把它和MIL/SIL/HIL这套分层验证体系串在一起给出可落地的接口调用方法和完整的自动化测试流程最后用BMS台架的实战案例收尾适合测试工程师、仿真工程师以及所有想理顺“模型测试到实车测试之间那一段”的人。1. 为什么需要XIL API台架测试的“各说各话”困境1.1 各家HIL厂商各说各话的时代早些年做HIL台架自动化最痛苦的不是写用例而是“适配”。我2016年接手的一个VCU项目台架是dSPACE SCALEXIO测试自动化用的是Python脚本通过AutomationDesk的COM接口去操作模型变量。后来项目扩了一个NI PXI的小台架专门做低压功能测试结果同一套用例逻辑在NI上要从VeriStand的Workspace API走变量访问方式、触发方式、数据采集方式完全两回事。再后来ETAS的LABCAR台架也上了团队里光接口封装代码就维护了三份而且每一份都跟具体的台架配置深度耦合。这种局面下测试用例的“可移植性”是空谈。换台架等于把用例重写一遍重写过程中还容易引入跟被测功能无关的差错。更麻烦的是同一个测试用例在不同台架上跑出来的数据还经常对不上排查了半天发现是信号映射的方式不同而不是控制器本身有问题。1.2 ASAM XIL API的出现定义一条统一的总线XIL API解决的问题就是上面这个“适配地狱”。ASAMAssociation for Standardisation of Automation and Measuring Systems是一个专注汽车开发与测试标准化的组织XIL APIX-in-the-Loop API是它发布的一套接口规范专门定义测试自动化工具与实时仿真系统HIL台架之间的通信方式。你可以把XIL API理解成USB标准鼠标、键盘、U盘不需要关心你电脑主板上具体是哪家芯片组只要都实现了USB协议插上就能用。XIL API就是这套“协议”。HIL厂商在自己的实时系统里实现一个XIL API的Provider服务端测试自动化工具作为Client客户端去调用两边都按同一套接口名、同一套数据模型来通信台架换了测试脚本主体不用动。需要说明一点XIL API不是仿真软件它不管数学模型怎么建、不管实时内核怎么调度它只负责“访问”——怎么拿到模型变量、怎么读写ECU引脚、怎么配置测量、怎么触发采集。这套标准最早在2010年左右发布2.0版本后来的2.1版本补充了不少细节目前主流厂商的HIL产品都宣称支持2.1。另外XIL API也跟ASAM体系里的其他标准有配合比如诊断端口对接ODX诊断描述数据访问走NDX数据格式标定端口则经常跟XCP协议关联起来用。1.3 标准里到底管了哪几件事从接口层面看XIL API管了四件事TestBench对象代表一次连到台架的会话一切访问都从它开始Port端口按功能划分的访问通道模型变量走ModelPortECU引脚走ECU-Access Port内存读写走ECU-Memory Port总线通信走CAN/LIN/FlexRay/Ethernet PortVariable与Procedure变量对象负责数据的读写Procedure负责台架上的过程性操作启动模型、停止模型、重置模型等事件与测量支持事件监听、采样配置、触发采集、数据缓冲区管理。这套模型最大的价值在于它把“测试用例关心的逻辑对象”和“台架上的物理资源”解耦了。测试脚本里写的是“把单体电压设为3.3V”这种逻辑操作至于这个电压是在SCALEXIO的模拟量通道上还是NI的FPGA上由映射层去处理。我在第3章的Mapping机制里会详细讲。2. MIL/SIL/HIL分层验证体系先模型后实物2.1 四个层级的定位一张表说清要理解XIL API为什么长这样得先看它在整个验证链条里的位置。控制器开发通常走“模型—代码—芯片—控制器—实车”这条链每一环都有对应的测试层级层级被测对象运行环境主要验证目标典型工具MIL控制模型Simulink/AMEsim等纯仿真环境控制算法、功能逻辑、策略正确性Simulink、CarSim、TruckSimSIL产品级C代码PC宿主机编译运行代码与模型一致性、逻辑错误代码生成工具PC编译器PIL产品代码目标处理器目标芯片评估板代码在真实CPU上的行为、时序编译器、调试器、评估板HIL真实ECU实时仿真机IO信号调理硬件集成、电气接口、总线时序、故障注入dSPACE SCALEXIO、NI PXI、ETAS LABCARMIL阶段跑得最快改模型、跑仿真几分钟一轮适合把控制策略的“大逻辑”磨对。SIL阶段把自动生成的C代码放进来这时候你能抓到模型和代码理解不一致的问题比如数据溢出、类型转换、除法处理——这些在MIL里看不出来。PIL是可选的过渡层当代码跑在目标芯片上出现时序问题时用它在芯片上复现。HIL则是最后的关卡真实ECU接到实时仿真机上模型里跑的是整车或部件环境IO、总线、传感器信号全部是真实的电气信号。2.2 一个项目里各层级怎么分工我自己的经验是MIL管功能对不对SIL管代码有没有BUGHIL管装上车能不能用。三个层级不是从属关系而是成本递增、检出缺陷类型不同的互补关系。MIL阶段主要用例状态机模型验证、控制策略边界、标定初值合理性SIL阶段主要用例数据溢出、除零、整数溢出、死代码、模型代码一致性HIL阶段主要用例IO通道映射、总线报文时序、诊断故障码、上下电时序、故障注入恢复、基础功能稳定性。从成本来看MIL发现并修复一个逻辑缺陷可能只影响一天的工作量而同样的缺陷到HIL阶段发现可能连硬件改版都牵扯进来了。这也是为什么现在行业里强调“左移测试”——尽量把问题在更早的层级暴露。2.3 测试用例如何跨层级复用各层级之间不是完全割裂的。很多功能测试用例在MIL里写了一版到HIL又能用关键在于把用例里的“操作对象”抽象成逻辑信号而不是具体的仿真模型变量。XIL API在这里的作用就体现出来了它把访问模型变量、访问总线信号、访问ECU引脚统一成一套Port接口用例里写“设置车速为50km/h”在MIL里映射到Simulink模型的某个信号在HIL里映射到实时机的车速信号或总线上的车速报文脚本本身几乎不用改。这也是XIL API叫“X-in-the-Loop”的原因——无论是Model、Software还是Hardware in the loop访问接口统一用一条API。所以你在MIL阶段写好的用例逻辑完全可以作为HIL用例的底稿真正要做的工作只是把信号映射表和判据阈值按台架环境重新标定一遍。3. XIL API核心架构拆解TestBench、Port与变量访问3.1 一切从TestBench开始XIL API的顶层对象是ITestBench它代表一次与台架的会话。你在脚本里做的事情本质上就是创建或连接一个TestBench对象通过GetPort拿到需要的端口通过端口创建变量、读写数据、配置测量用完释放。为什么要有TestBench这一层因为一台实时机上可能跑着多个仿真模型或者一个测试任务要同时操作多台设备实时机负载箱电源。TestBench就是你对“当前这套台架组合”的句柄同一个厂商实现可以同时创建多个TestBench互不干扰。3.2 Port端口按功能划分的访问通道XIL API把台架能做的事按功能切成了若干端口我按使用频率排个序端口功能典型场景ModelPort访问仿真模型内部的变量、总线信号、模型函数给模型设置输入、读取模型输出、调用模型算法ECU-Access Port访问ECU引脚级信号模拟量、数字量、PWM、电阻等模拟传感器输出、测量ECU驱动信号、PWM占空比测量Measurement Port配置采样、触发、数据缓冲按固定频率采集电压、电流、模型变量Stimulation Port配置激励信号、波形生成生成正弦波、阶跃、脉冲激励CAN/LIN/FlexRay/Ethernet Port总线报文与信号的发送接收发送报文、读取总线信号、总线故障模拟Calibration Port在线标定ECU内部参数标定控制器参数、PID增益调整ECU-Memory PortECU内存读写、Flash操作读取故障码存储、写标定数据、刷写Diagnostics Port诊断服务访问结合ODX读取诊断故障码、执行例行程序Signal-Based Port与具体总线类型无关的信号级访问用例里不写总线类型只写信号名Data Access Port大块数据交换NDX格式大数据量的分布式测试数据同步String Port字符串类型模型变量的读写读取模型状态字符串、版本信息Testbench Port控制台架硬件资源电源、负载等台架电源上电、下电、负载切换端口不是固定的几个标准允许厂商扩展也允许一个台架里存在多个同类型端口比如两个ModelPort对应两个实时处理器板卡。GetPort方法需要传入端口名端口名在台架工程文件里定义这跟具体的台架配置强相关。3.3 变量对象读写数据的最小单元以ModelPort为例访问一个模型变量的套路是var model_port.CreateVariable(Model.Battery.SOC) var.Value 80.0 # 写入 soc model_port.GetVariableValue(var) # 读取注意几个要点CreateVariable传入的变量名必须是台架实时模型里实际存在的名字不同厂商的命名规则略有差异dSPACE习惯用Model.xxxNI VeriStand习惯用Aliases或通道名Value的类型取决于变量类型可能是double、integer、boolean也可能是数组如果变量名不存在CreateVariable会抛异常很多“脚本突然跑不过”的问题就是从这里来的。提示XIL API的调用完全基于“逻辑变量”层面。你看到的是“设置车速50”底层可能是CAN报文信号、模拟量通道或模型变量具体是哪种由映射层决定。写用例时不要在脚本里硬编码台架路径否则换台架就是重写。3.4 测量与激励异步机制的同步化使用测量和激励是台架测试里最常用的异步操作。测量Port的思路是先创建一个“采样配置”告诉它采哪些信号、采样率多少、缓冲多大然后触发一次或连续采集最后从缓冲区把数据取回来。下面示意一段配置采样并触发的代码meas_port testbench.GetMeasurement(MeasurementPort) # 创建采样配置参数为采样率单位Hz示意写法 sampler meas_port.CreateSignalSamplingConfiguration(1000.0) sampler.AddSignal(model_var_voltage) sampler.AddSignal(model_var_current) # 触发一次同步测量timeout单位为毫秒 meas_port.ExecuteSimpleTrigger(10000) samples sampler.ReadData()激励Port正好反过来往模型或总线上“灌”波形。用XIL API做激励可以定义一个幅值序列也可以直接循环写变量来构造阶跃信号。工程上更常见的做法是在实时模型内部直接写激励逻辑XIL API只负责在合适的时机改标志位这样能保证实时性避免因为网络往返延迟把波形搞失真。3.5 Procedure控制台架上的“过程”台架上的操作比如启动模型、停止模型、重置模型、加载工况XIL API统一抽象成Procedure。Procedure分两类可以启动后干别的异步也可以等它跑完同步等待。start_proc testbench.GetProcedure(StartSimulation) testbench.StartProcedure(start_proc) testbench.WaitForProcedure(start_proc, 5000) # 最多等5秒在实际项目里WaitForProcedure超时是最常见的脚本挂起点之一。启动模型如果超过你设的超时时间多半不是脚本问题而是模型里有初值不稳定、或者某个外部设备没有就绪。排查思路我放到最后一章讲。4. 环境准备与Python调用XIL API实操4.1 你需要准备什么想用Python直接调XIL API环境上通常需要这几样一套HIL实时系统dSPACE SCALEXIO、NI PXI、ETAS LABCAR等并且厂商装了XIL API Provider组件厂商提供的客户端接口库一般是COM组件或.NET程序集Windows环境因为COM/.NET基本都在Windows上Python用pywin32即win32com做COM互操作如果台架上要跑总线通信还需要对应的总线接口卡驱动CANcaseXL、VN1600等。以某厂商的台架为例装完Provider后Python里先做一次连通性自检用厂商工具打开台架工程确认实时程序能正常加载运行再在Python里连接。4.2 连接与导航一个最小可跑的脚本import pythoncom import win32com.client def main(): pythoncom.CoInitialize() # 1. 创建厂商的应用对象以VXIL为例 app win32com.client.Dispatch(VXIL.Application) # 2. 创建TestBench名称要与台架工程一致 tb app.CreateTestBench(VCU_HIL_Bench) # 3. 获取ModelPort model tb.GetModelPort(ModelPort) print(Connected to TestBench:, tb.Name) return tb, model这段代码有三个重要细节第一pythoncom.CoInitialize()必须在每个线程里先调用COM对象的线程模型要求你在哪个线程里创建、就在哪个线程里使用。很多初学者把TestBench创建在子线程然后主线程去操作结果各种COM 0x8001010E错误服务器在另一个线程调用中。第二CreateTestBench传入的名称必须和台架工程的槽位/实例名一致不是随便起个名字。名字对不上后面所有的GetPort都会失败。第三TestBench对象用完后要释放否则厂商Provider端会一直占用实时机的资源。批量跑回归时每轮用例都泄漏几个句柄跑到后半夜台架就死了这是夜间回归失败最常见的原因之一。4.3 一个完整的自动化用例脚本下面是我在项目里实际用过的脚本骨架做了脱敏简化。场景是给整车模型加一个车速斜坡把车速从0拉到80km/h验证VCU是否发出预期的扭矩请求并把扭矩请求值记录下来。import time import pythoncom import win32com.client class VCUTest: def __init__(self, bench_name): self.bench_name bench_name self.tb None self.model None self.meas None def setup(self): pythoncom.CoInitialize() app win32com.client.Dispatch(VXIL.Application) self.tb app.CreateTestBench(self.bench_name) self.model self.tb.GetModelPort(ModelPort) self.meas self.tb.GetMeasurement(MeasurementPort) self.start_var self.model.CreateVariable(Model.Driver.AccelPedal) self.torque_var self.model.CreateVariable(Model.VCU.TorqueRequest) def run(self): # 预置工况 self.start_var.Value 0.0 proc self.tb.GetProcedure(StartSimulation) self.tb.StartProcedure(proc) self.tb.WaitForProcedure(proc, 5000) # 配置测量100Hz采样扭矩请求500ms sampler self.meas.CreateSignalSamplingConfiguration(100.0) sampler.AddSignal(self.torque_var) self.meas.ExecuteSimpleTrigger(500) # 油门踏板阶跃 self.start_var.Value 35.0 time.sleep(0.2) # 采集数据 samples sampler.ReadData() peak_torque max(samples) if samples else 0.0 # 判定示意阈值 passed 80.0 peak_torque 200.0 return passed, peak_torque def teardown(self): proc self.tb.GetProcedure(StopSimulation) self.tb.StartProcedure(proc) # 释放句柄 self.tb None pythoncom.CoUninitialize() if __name__ __main__: t VCUTest(VCU_HIL_Bench) t.setup() try: ok, val t.run() print(fPASS{ok}, PeakTorque{val:.1f} Nm) finally: t.teardown()这段骨架直接可以照着搭。注意CreateSignalSamplingConfiguration、ExecuteSimpleTrigger这些方法的具体签名在不同厂商实现里小有差别动手前先查厂商的API文档但整体调用流程是通用的预置→启动→配置采样→动作→采集→判读→停止→释放。4.4 和ECU-TEST / TPT这类工具怎么分工自己写Python脚本是一条路工程上还有很多团队用ECU-TEST、TPT这类商用测试工具。它们本质上也是XIL API的Client只不过把XIL API又封装了一层提供了图形化的用例管理、报告、评审流程。我的建议是测试用例量大、要过评审/追溯体系的用ECU-TEST/TPT这种工具它们对XIL API的封装更完整报告能自动生成要做快速验证、探索性测试、或者需要跟CI系统深度集成的直接用Python调XIL API更灵活依赖也少两者可以共存Python跑冒烟和快速回归ECU-TEST跑需要正式交付的用例。5. HIL台架自动化测试的完整流程5.1 从需求到可执行用例HIL自动化测试不是把MIL用例拿过来改改名字就行你需要先做一轮“台架化”设计。我的做法分四步需求拆解把每条系统需求拆成可测量的测试条件。比如“VCU必须限制最大驱动扭矩”拆分出“车速0、油门0、挡位D、电池SOC20%”这些前置条件以及“扭矩请求≤250Nm”这个判定条件确定激励与观测点激励是给模型变量还是总线报文在ModelPort操作还是在CAN Port操作观测点是模型变量、ECU引脚还是总线信号这一步决定了用例挂在哪个Port上定义信号映射用例里的逻辑信号如“油门开度”映射到台架上的具体路径模型变量路径、报文信号名这个映射表要单独维护不能散落在脚本里写自动判据判据要有容差窗口和持续时间不能只看瞬时值。比如“扭矩在2秒内稳定在240±5Nm”比“扭矩240Nm”更符合工程实际。5.2 信号映射表最容易翻车的地方我见过太多项目在信号映射表上翻车。映射表的形式很简单就是一张Excel或CSV逻辑信号台架路径类型单位方向油门踏板开度Model.Driver.AccelPedaldouble%激励车速Bus.CAN1.VehSpd.Signalintkm/h观测电机扭矩Model.Motor.TrqdoubleNm观测充电连接状态Model.Charging.CPVoltagedoubleV激励翻车点在于台架模型的信号路径经常在软件升级后变化映射表没同步CreateVariable(Model.Driver.AccelPedal)直接抛异常。解决的办法是脚本启动时先做一遍“映射校验”——遍历映射表里的每个路径逐个CreateVariable失败的路径收集成清单一口气报出来。千万不要让一个查不到变量的错误在跑了200个用例之后才炸出来。5.3 测试执行、判读与报告执行阶段要注意“数据的时间基准”。台架上的模型变量、总线报文、ECU引脚信号它们的时间戳来自不同的时钟域——仿真时钟、总线硬件时钟、PC端采集时钟。如果你要把扭矩请求和车速信号做相关性分析得先确认它们是否基于同一个时间基准。XIL API的Measurement Port通常会做时间戳对齐但如果你同时用time.sleep驱动脚本流程那种时间是脚本时间不是采样时间不能混用。自动判读数理上不复杂难的是“什么样的判据可信”。我常用的策略是先人工执行一遍观察信号在稳态、阶跃、暂态的典型数值范围和稳定时间把观测到的±5%和±1~2拍作为判据初值再跑10遍确认没有误报才把判据固化进用例。报告这块自己用Python的话我建议直接生成HTML或Excel结构化报告包含用例名、前置条件、输入激励、观测曲线嵌入图片、判定结果、失败时抓拍的信号波形。不要只用一行“PASS/FAIL”失败时没有上下文排查起来等于重跑一遍。5.4 回归策略与夜间自动执行HIL台架很贵很多公司是一天两班倒或者夜间无人值守跑回归。我的经验是分三级冒烟级每次加载新模型版本后跑只跑20~30个核心用例验证台架本身和模型基本健康耗时控制在15分钟内回归级每晚跑全量功能用例覆盖所有需求矩阵跑完自动出报告早晨工程师按报告分拣问题深度级每周跑一次长期稳定性、老化场景、极端工况用例这些用例耗时长但能暴露“跑久了才出现”的问题。CI集成方面只要XIL API能通过Python调用Jenkins/GitLab CI就能调度。关键是要做好失败分级台架硬件异常比如测试机掉线、模型加载失败、用例断言失败这三类要分开报否则工程师每天早晨要被几百条失败信息淹没。6. BMS台架自动化测试实例从单体电压模拟到SOC估算验证6.1 BMS HIL为什么难做BMS电池管理系统的HIL测试在台架测试里属于“高段位”难度。难点在三个地方第一单体电压通道多且要求精度高。一个电池包几百串单体每串都要一个独立的电压仿真通道而且稳态下电压波动要控制在毫伏级否则BMS的SOC估算、内阻辨识会被你给的假数据带偏。XIL API访问这类通道通常走ModelPort或ECU-Access Port脚本里要批量处理几百个变量。第二温度传感器是NTC电阻网络。BMS检测的是分压网络电压台架要么用电阻阵列模拟要么在模型里直接算。用XIL API写NTC温度模拟时不能只写一个“温度值”要理解背后的分压电路模型。第三故障注入类型多。单体传感器断线、采集通道漂移、接触器粘连、绝缘电阻下降、充电枪互锁异常每类故障都要能注入、能清除、能观察BMS的响应和恢复。XIL API在故障注入上一般通过ModelPort里的故障标志位或者ECU-Access Port的程控继电器阵列来做。6.2 一个具体的测试场景SOC估算对异常单体的响应下面这个用例是我在BMS台架上做过的典型场景。背景是电池包100串单体BMS根据单体电压估算SOC并做均衡控制。# 连接台架省略初始化 model tb.GetModelPort(ModelPort) can tb.GetCanPort(CAN1) # 1. 初始化所有单体电压为3.60V for cell_id in range(1, 101): v model.CreateVariable(fModel.CellVoltage.Cell{cell_id:03d}) v.Value 3.60 # 2. 第5串电压阶跃到3.30V模拟异常单体 cell5 model.CreateVariable(Model.CellVoltage.Cell005) cell5.Value 3.30 # 3. 通过CAN读取BMS广播的SOC和单体最高最低电压 soc_signal can.GetSignal(BMS_Status.SOC) vmax_signal can.GetSignal(BMS_Status.CellVoltageMax) vmin_signal can.GetSignal(BMS_Status.CellVoltageMin) time.sleep(2) # 等待BMS刷新周期 # 4. 判定BMS应报出Cell005异常并限制功率示意这个用例的判读点有两个一是CellVoltageMin应该紧跟在3.30V附近且有报警二是BMS的充放电功率限制标志位应该在若干周期内被置位。跑的时候注意BMS的故障确认时间去抖有的BMS要连续几个周期判定才报故障脚本里不能只等2秒要轮询等待到故障确认。6.3 BMS测试中容易被低估的三件事初始SOC的一致性每次用例开始前必须把电池模型初始化为同一状态同一SOC、同一温度分布否则不同用例的基线不同结果不可比。我一般在setup里加一个“电池模型复位”的Procedure调用电流源/负载模拟BMS测试经常要模拟充放电电流这个电流会反过来影响单体电压。在纯模型层面要注意电流积分方向的正确性如果台架上接了真实的电池模拟器比如可编程电源那XIL API控制的是模拟器的电流设置值跟模型变量的用法完全不同数据量控制BMS长时间测试采几百路信号一小时就能上GB。我建议按需采集——只要关注十几个关键信号就不要全采采样率够用即可稳态用1Hz瞬态用100Hz否则分析工具和存储都会被拖垮。7. 踩坑记录与性能优化来自现场的经验7.1 COM线程模型与超时处理前面提到过COM的线程模型问题这里再展开。XIL API的COM对象大多是单线程套间STA你在一个线程里创建了TestBench就必须在同一线程里调用它。想用线程池并发跑多个用例要么每线程独立创建自己的TestBench要么把XIL API调用集中到单一工作线程其他线程通过队列往里塞任务。这个架构要在项目早期定下来不然后期改造量很大。超时处理也值得单独说。WaitForProcedure、ExecuteSimpleTrigger这类阻塞调用如果Provider端一直不返回脚本会卡死。我的做法是所有阻塞调用都包一层带超时的封装超时后先做一次“探活”——查一下台架连接还通不通、模型进程还在不在把“超时”和“死机”分开。很多新手一超时就杀进程实际上台架只是慢等一等就恢复了。7.2 测量缓冲区与性能平衡测量数据量一大性能问题马上来。我踩过的坑在一个热管理用例里同时采样100路信号采样率设成1000Hz结果脚本每取一次数据要等好几秒整个用例跑得比蜗牛还慢。后来把采样率降到实际需要的水平——温度信号1Hz就够只有快速瞬态信号才用高采样率——性能立竿见影。另外XIL API的测量数据是存在Provider端的缓冲区里的如果Client取走太慢缓冲区溢出老数据会被覆盖而且不会通知你。取数据要及时取完尽快处理。大数据量的场景比如整车热管理全模型数据记录建议走Data Access Port的NDX文件通道让数据异步落盘不要在API调用链上同步搬运。7.3 夜间回归失败的经典排查链路夜间回归失败的排查我总结了一个固定链路分享出来先看失败模式全部用例同一时刻失败还是分散失败全部失败多半是台架或连接层问题分散失败才是个别用例问题看台架探活实时机还能Ping通吗Provider进程还活着吗很多“全部失败”其实只是台架电脑半夜更新重启了看日志时间点失败用例的前一条用例做了什么有时候是前一个用例没释放句柄拖垮了整轮复现时先跑冒烟别直接重跑失败用例先跑冒烟级用例确认台架健康再跑失败用例看映射校验报告如果是“变量不存在”类错误基本就是模型升级后映射表没同步不是代码逻辑问题。这套链路我写成过一个诊断脚本每次夜间回归失败后自动跑一遍把结论直接贴到工作群里省了第二天早上大量排查工作。另外还有一个很容易被忽略的细节测试数据归档策略。HIL台架一天的夜间回归能产生几十GB数据我建议按“用例结果”来归档——PASS的只保留曲线缩略图和统计特征值FAIL的保留完整原始数据。这样既满足追溯又不会把存储塞爆。最后说一点个人体会。XIL API这个东西表面上是接口标准实际上是把“测试用例”和“台架硬件”之间的耦合关系做了一个清晰的切割。一开始推行标准化接口确实有学习成本团队里也有抵触情绪但坚持下来你会发现收益是长期的——换台架、跨项目复用用例、新成员上手都比以前顺滑太多。如果你所在的团队还在为每套台架维护一套脚本我建议从一个小范围试点开始挑一个稳定台架、一组核心用例先跑通XIL API这条链路再逐步铺开。流程和技术都是越用越顺的。
