1. 内容整体设计与思路拆解1.1 为什么选择“Excel Test Sequence”这条路做模型测试的人应该都有体会模型本身写得再漂亮如果验证手段跟不上交付的时候心里总是不踏实。我最早接触Simulink Test Sequence是在一个汽车电子项目上那时候我们被要求对几十个输入信号、十几条状态切换路径做回归验证而且客户希望测试用例能跟着需求文档走方便评审和追溯。纯手写测试框架显然不现实手工在Simulink里拖信号、看波形、卡阈值一轮下来就要两三天更别提需求变更后全部重跑一遍的酸爽。后来我摸索出一套组合打法用Excel维护测试用例用Test Sequence承载时序逻辑用Simulink Test做批量执行和报告生成。这套流程跑通之后同样的回归测试从两三天压缩到几个小时而且用例可维护性、可读性都上了一个台阶。这篇文章就是把这套我自己踩坑踩出来的方法完整拆开从Excel表格设计、Test Sequence脚本编写到模型验证的闭环流程一步一步讲清楚。先说清楚这套方案适合谁正在做MILModel in the Loop测试的工程师手里有Simulink模型但测试用例管理混乱的团队以及被需求变更搞得焦头烂额、想建立一套可追溯验证机制的朋友。如果你只是偶尔在Simulink里跑个仿真看看波形这篇内容你能学到Test Sequence的核心理念但Excel驱动的完整链路可能会有点超纲建议先收藏。1.2 方案选型背后的四个关键考量我当时对比过几种方案最后定在Excel Test Sequence Simulink Test的组合上不是没有理由的。信号级测试 vs 系统级测试Test Sequence适合做基于时间步进的信号级时序测试它可以在每个仿真步长内判断条件、切换状态、输出信号。如果你的测试对象是一个整车控制器模型输入是传感器信号、输出是执行器指令Test Sequence就是天然匹配的。相比起直接用Signal Editor给信号、再用Scope人工核对Test Sequence能在仿真过程中主动判断期望值并标记结果这是它最核心的价值。可追溯性和评审友好度客户或者质量部门来评审测试用例时你总不能让对方打开一堆.m文件去读代码。Excel表格天然就是他们熟悉的工具一行一条用例列名写清楚前置条件、输入信号、期望输出、容差范围评审效率高得多。Excel还可以用公式和条件格式做用例覆盖度统计这些是纯脚本方案比不了的。复用性和维护成本需求变更了改动往往集中在输入信号的范围、某条时序的延迟时间、某个阈值的上下限。这些参数在Test Sequence脚本里写死的话每改一次都要打开模型、修改逻辑、重新生成测试把参数抽到Excel里管理改完数据文件重新跑一遍就行模型文件和测试逻辑一行都不用动。与Simulink Test的集成Simulink Test可以批量运行测试用例并生成HTML报告但它需要一个外部的用例管理载体。Excel承担这个载体最合适因为MATLAB对Excel的操作接口非常成熟readtable、xlsread老版本、writetable这些函数足够我们做数据导入和结果回写。提示如果你的团队已经上了ALMApplication Lifecycle Management工具比如Jama或者DOORSExcel可以作为一个中间转换层存在通过脚本把ALM导出的需求条目映射到Excel测试用例表里再进一步驱动模型测试。这样追溯链是“需求条目 → Excel用例 → 测试报告”整条链都是可审计的。2. Test Sequence核心机制与建模避坑指南2.1 Test Sequence到底是个什么东西第一次打开Test Sequence模块的人多半会被里面那种“有点像状态机、又有点像脚本”的界面搞懵。我在这里用一句话帮你建立心智模型Test Sequence本质是一个由时序步骤Step组成的有限状态机每个步骤内可以写基于当前仿真时刻和信号值的判断逻辑步骤之间通过跳转条件Transition连接。它在Simulink库里的路径是Simulink Dashboard Test Sequence拖到模型里之后双击进去你会看到上下两个区域上面是步骤列表和跳转关系的图形化视图下面是可以随步骤切换的脚本编辑器。每个Step可以包含三个部分Inputs输入声明这个步骤需要访问的外部输入信号。Outputs输出声明这个步骤需要驱动的外部输出信号。Transition跳转满足什么条件后跳到下一个Step以及跳转的优先级。这里有个很多新手都会踩的坑Test Sequence里的变量作用域和模型工作区不是一回事。你在Test Sequence脚本里声明的变量默认是局部变量只有通过Input/Output端口映射到模型信号线上数据才能进出。所以不要试图直接去读模型里某个Gain模块的参数名它根本看不见。2.2 设计Test Sequence时的三个核心原则原则一步骤间不要留“隐式状态”。如果两个Step之间没有显式的Transition条件Test Sequence默认在当前Step的仿真步长结束后直接进入下一个Step。这在某些场景下会引发非预期的行为比如你本来想等待一个外部信号稳定后再跳转结果因为少了条件当前Step一个步长就溜过去了。所以我的习惯是每个Step的Transition必须写清楚哪怕条件是恒为true也要写出来让阅读脚本的人知道这里是“直接通过”而非“漏写了条件”。原则二输出信号要有明确的默认值。Test Sequence在退出某个Step的时候该Step中赋值的输出会继续保持还是会归零答案是只有你在Step里显式配置了输出值的信号才会被记录和保持未配置的保持上一次的值。听起来有点绕实际上就是——如果你在Step 1里把brake_cmd置1在Step 2里没有配置任何关于brake_cmd的输出值那么信号继续保持1。这个特性很有用但也很危险。你需要在设计阶段明确哪些信号是“脉冲式输出”Step内赋值后自然保持哪些是“状态式输出”需要每次Step都重新赋值避免因为忘记赋值而让输出信号的语义变得模糊。原则三时间控制用duration属性不要用绝对时间。Test Sequence的每个Step有一个duration属性表示这个Step至少持续多少个仿真步长或多少秒然后才允许评估Transition条件。我用它来做时序控制比如“先给油门信号等0.2秒后再检查转速响应”就可以把Step 1的duration设为0.2Transition条件里再写转速阈值的判断。这样比在条件里写t 5.2这种绝对时间可靠得多因为模型运行的起始时间、步长变化都不会影响步骤的时序语义。2.3 外部模式下的联动测试如果你的测试对象是嵌入式代码生成后的目标硬件或者你想试验Test Sequence和真实硬件联动Simulink的External Mode外部模式是一个很关键的功能。外部模式允许Simulink模型和可执行目标之间实时通信你在Simulink中运行Test Sequence目标板上执行模型代码信号通过串口或以太网回传。用Test Sequence驱动外部模式测试时需要注意的是实时性和步长抖动PC端Simulink的仿真步长是软件时钟和目标板上的物理时钟之间存在偏移所以时序严格型的测试用例比如要求某个事件发生在精确的100ms时刻不建议放在外部模式下跑这会受到通信延迟的影响。注意外部模式下Test Sequence的跳转条件评估依然是在Simulink端完成的目标板只是实时计算模型输出。如果跳转条件需要高频采样比如1ms以内而通信通道的延迟高于这个量级可能出现“条件已满足但信号还没送达”的现象。所以外部模式更适合功能验证不适合性能边界测试。3. Excel测试用例设计从需求到表格的精简之道3.1 Excel表格结构怎么定既然要用Excel驱动测试表格本身的结构就是整个流程的地基。设计得不好后面的数据导入和参数映射会写出一堆烂代码。我常用的表格结构是这样的以Sheet命名和列名作为约定接口Sheet名用途关键列TestCases用例主表TestCaseID, Description, Priority, PreCondition, ExpectedResult, ToleranceInputSignals输入信号定义TestCaseID, SignalName, DataType, InitValue, TimeTable, DataFileOutputChecks输出检查定义TestCaseID, SignalName, ExpectedValue, Tolerance, CheckTimeModelConfig模型参数配置ParamName, ParamValue, DataType, ApplyToTestCase顶层Excel定位到你的TestCases那张Sheet每行一个用例TestCaseID是唯一的编号建议用类似于TC_Powertrain_001这种带模块前缀的格式方便过滤。Description写自然语言描述比如“验证油门踏板全开时发动机转速响应时间小于0.5秒”。PreCondition记录进入该用例前的初始状态条件比如“档位处于D挡车速为0”。ExpectedResult和Tolerance则用于后续的自动判定。InputSignals和OutputChecks是两张配套的子表以TestCaseID为主键关联。每条用例可以在InputSignals里占多行每行定义一个信号的加载方式。TimeTable列可以是指向另一个Excel文件或Sheet的引用也可以直接写数据的文件名比如throttle_profile.csv脚本读取到这一列后会自动解析这个文件并映射到Simulink的Signal Editor或From Workspace模块。3.2 Excel函数在测试用例管理里的大作用很多人对Excel在测试管理里的认知停留在“存数据”这个层面但实际上Excel的函数能力可以帮我们做很多自动化的辅助工作。比如用COUNTIFS做用例覆盖度统计。比如需求编号列是B列你可以用COUNTIFS(B:B, REQ-1001, D:D, Pass)统计某条需求对应的通过用例数甚至可以放在一个Dashboard Sheet里做实时统计。用VLOOKUP关联需求变更影响范围。当某条需求修改后如何快速找到受影响的测试用例在TestCases表里增加一列RelatedReq写上需求ID然后在另一个Sheet里用VLOOKUP反查或者用Excel的FILTER函数Excel 365动态筛选。用条件格式标记异常数据。比如Tolerance列如果为负数或零说明这条用例没有设定容差后面脚本跑出来的结果可信度存疑。用条件格式把这类单元格标红相当于在Excel层面就做了一轮数据校验。3.3 从Excel到Simulink的数据导入技巧MATLAB读Excel数据新版推荐用readtable读取速度快且对格式兼容性好。我的脚本逻辑一般是这样% 读取测试用例定义 caseDef readtable(test_definition.xlsx, Sheet, TestCases); % 读取输入信号定义 inputDef readtable(test_definition.xlsx, Sheet, InputSignals); % 根据当前要跑的用例ID筛选 curCase caseDef(caseDef.TestCaseID currentCaseID, :); curInputs inputDef(inputDef.TestCaseID currentCaseID, :);筛选完信号定义后根据每个信号指定的DataFile和TimeTable去加载实际数据。如果数据是Excel格式可以直接readtable后再用table2timetable转换成Simulink支持的输入格式如果是CSV生成的数据把第一列作为时间序列第二列作为信号值。这里有个关键的格式要求Simulink的From Workspace模块要求输入数据是带时间戳的向量通常用timetable或者[time, data]的双列矩阵。如果数据里掺了NaN或者时间步长不均匀仿真经常会报错所以我在脚本里统一做了插值重采样确保时间序列是均匀步长的。% 假设dataTable是读取到的原始时间序列 t_in dataTable.Time; y_in dataTable.Value; % 统一插值到固定步长 t_uniform (t_in(1):step:t_in(end)); y_uniform interp1(t_in, y_in, t_uniform, linear, extrap); signalOut [t_uniform, y_uniform];3.4 用例批量生成与参数化的三个技巧技巧一用Excel的公式批量生成XML或MATLAB结构体定义。如果你的测试用例定义非常规则可以写一个MATLAB脚本读取Excel后在内存里动态构建Simulink的输入参数结构体。不需要手动维护一份额外的配置文件真正做到“Excel即配置”。技巧二利用参数集Parameter Sets覆盖多工况。Excel里把工况名作为一个隐藏列比如“Normal”、“Overload”、“SensorFault”脚本读取后通过set_param或Simulink的Parameter Object对模型参数动态赋值这样一份模型可以跑出多种工况下的验证结果。技巧三用Excel的下拉菜单excel functionality而不是手打输入来保证枚举值合规。比如DataType列只允许选double、uint16、booleanPriority列只允许选High、Medium、Low。这能避免后面MATLAB脚本运行时因为拼写错误引发的各种莫名报错。4. 模型验证自动化执行把Script串成流水线4.1 从单个用例跑到批量回归的执行框架我跑测试的时候不会只测一两个用例通常是几十个甚至上百个一起跑。手动双击模型、改参数、跑仿真、记结果这种操作连试都不用试肯定会被项目拖垮。我的做法是写一个批处理执行脚本核心逻辑分三步加载被测模型和测试数据用load_system加载模型到内存保证不会在GUI中打开多个模型副本加载Excel中当前批次的测试用例定义到MATLAB工作区。动态配置仿真参数和输入根据用例的ModelConfig表通过set_param设置仿真时长、步长、求解器等参数根据InputSignals表将输入数据注入到模型的信号源模块或工作区变量。执行仿真并自动评分调用sim函数执行仿真仿真结束后调用断言评判逻辑比对模型输出和OutputChecks表中的期望值判定Pass/Fail把结果写入一个结果表。% 伪代码示意 for i 1:height(testCases) % 根据用例ID配置模型 applyModelConfig(modelName, testCases(i, :)); loadInputSignals(testCases(i, :)); % 执行仿真 simOut sim(modelName, StopTime, num2str(stopTime)); % 期望值判断 testResult evaluateTest(simOut, testCases(i, :)); % 记录结果 resultsTable [resultsTable; testResult]; end4.2 Simulink Test的迭代器与Test Sequence怎么配合Simulink Test里有一个非常重要的概念叫迭代器Iteration它允许你在一个测试用例里跑多组输入数据每组数据称为一次迭代。这和Excel驱动模式搭配起来简直完美Excel里一行输入数据定义就可以映射到Simulink Test的一次迭代。具体做法是在Simulink Test的测试用例中将输入数据源设置为“From workspace”或者“From file”并在迭代器中选择Custom迭代迭代变量就是从Excel读取的结构化数据集。这样Excel里有多少行测试数据Simulink Test就会自动创建多少次迭代每次迭代自动更新输入、运行仿真、记录结果。Test Sequence在每次迭代中生成仿真步的相关操作比如判断某个信号是否在期望时间窗口内达到目标值。测试用例的期望结果在Excel中定义好Test Sequence内部只负责把每一步的实际值记录下来并通过信号输出返回到Simulink Test由Simulink Test的Assessment块做最终断言。分层的职责是清晰的Excel → 用例数据Test Sequence → 时序激励与状态控制Simulink Test → 批量调度与结果判定。4.3 自动评分结果怎么判定才算可靠自动评分的核心是断言。Simulink Test中有专门的Assessment块可以在模型内或模型外交互式添加。但如果你和我一样希望把判定逻辑保留在MATLAB脚本里可以利用evaluate函数对照Excel的期望值和容差来执行。我对每种信号类型有不同的比较方法标量期望值直接计算模型输出与期望值的绝对误差或相对误差判断是否在容差范围内。相对误差的计算公式为abs(actual - expected)/abs(expected)注意当期望值为0时要退化为绝对误差否则会出现无穷大。波形/时间序列如果期望值本身是一条随时间变化的曲线我会先对模型输出和期望曲线做时间对齐然后计算点对点的误差均值或最大误差并和Tolerance设定值比较。这里的陷阱在于时间对齐因为仿真步长和参考数据的时间戳可能不对齐统一用interp1做插值。时序事件先检测事件发生的时间比如信号跨过阈值的那一时刻再和期望时间窗口比较。检测用上升沿或下降沿判断。function pass checkSignal(signalValues, timeValues, expected, tol) % 插值到期望时间点 actualAtTime interp1(timeValues, signalValues, expected.Time); diffVal abs(actualAtTime - expected.Value); if expected.Value ~ 0 relErr diffVal / abs(expected.Value); pass relErr tol; else pass diffVal tol; end end4.4 自动化测试里的“锁”和“解”并行与CI集成当你用例数量上到几百个单核跑仿真就太浪费了。MATLAB支持并行计算工具箱配合Simulink Test的并行迭代可以同时跑多个迭代理论加速比接近核心数。不过在并行跑之前有几个硬性条件要确认模型要在并行环境可读所有输入数据和参数配置都必须存储在工作区或文件里不能依赖任何GUI状态。输出数据要标明迭代编号多迭代并行跑时结果的标识很重要。我在结果表里一定会带上TestCaseID和Iteration编号方便出问题时精确定位到哪条用例、哪次迭代。避免全局变量冲突有些老模型用了全局变量或者evalin(base, ...)来访问数据并行环境下这些会崩溃或者串数据建议提前查一遍。如果团队有持续集成环境Simulink Test提供了命令行接口可以编写脚本让Jenkins或者GitLab CI在代码合入时自动触发模型测试。这样模型一更新Nightly Build之后自动跑一轮回归测试早上打开邮箱的时候就能看到测试报告。整个验证闭环就真正跑起来了。4.5 结果回写Excel的坑与规范跑完测试把结果回写Excel这一步看似简单但有几个细节很容易出问题。第一写Excel时不要覆盖原表的结构。如果用writetable直接写回原表格有时会清掉原有Sheet里的公式。我的做法是新建一个Results页或者写入到一个独立的结果文件里。测试结果和用例定义分开保存也方便做历史追踪。第二注意MATLAB和Excel之间的日期数据类型兼容。如果你在Excel里用日期时间格式MATLAB的readtable读取出来的可能是一个序列值反过来写回时也可能对不上。我建议测试表格里不直接放日期常用日期放文件名里比如TestReport_20240511.xlsx避免格式转换的麻烦。第三结果状态最好用Pass、Fail、Skip、Error四态。Error表示仿真本身出了问题比如模型报错、输入数据格式错误Fail表示仿真跑通了但结果不满足期望。这两个状态在统计通过率时要区分开否则你分不清是测试环境的问题还是模型功能的问题。% 汇总结果并写回Excel resultSummary struct2table(allResults); writetable(resultSummary, sprintf(TestReport_%s.xlsx, datestr(now, yyyymmdd)), ... Sheet, Results);5. 常见问题与排查技巧实录5.1 Test Sequence读不到Excel里的变量很多朋友第一次把Excel数据导入到模型后发现Test Sequence里引用变量名会报错“Undefined variable”。原因基本都出在数据作用域上。Test Sequence内无法直接访问MATLAB基础工作区的变量它只能访问自己定义的Input、Output和内部变量。解决办法是在Test Sequence模块的端口配置中手动添加Input端口并映射到模型的信号线上然后在Step里用InputName引用。5.2 仿真输出有NaN或Inf检查输入信号数据Excel里存在空单元格或者以文本格式存储的数字读进MATLAB后会变成NaN或字符串。所以Excel设计规范里建议在列头用“数据验证”限制单元格格式同时读取脚本里加上一段清洗逻辑把NaN统一替换成零或线性插值并且打印警告日志方便排查是哪一行数据出的问题。5.3 仿真速度太慢批量跑不动首查仿真步长和求解器设置。如果模型里存在大惯性环节且你设了固定极小步长比如1e-6跑几百步还好跑几十万步就很吃力了。批量回归时我通常会在保证精度的前提下适当放宽步长比如从1e-5放宽到1e-4配合高阶求解器如ode15s或ode45自适应步长速度提升明显。如果模型本身很大考虑把测试拆分成多个子系统级别的小模型用小模型的快速验证代替全模型的长时间仿真。5.4 Excel表格无法复制粘贴这不算技术问题但实战中遇到太多了。Excel的复制粘贴功能会被某些加载项或剪贴板冲突影响。解决的办法包括在Excel选项里禁用第三方加载项、重启Excel进程、用“选择性粘贴”的数值模式仅粘贴值绕过格式带来的冲突。如果某个工作表里包含大量图表对象复制粘贴卡顿的情况也会更频繁。经验上去掉公式、保留静态值的方式粘贴最稳妥。5.5 Test Sequence的Condition判定时序踩坑Test Sequence对Transition条件的评估往往是在当前Step的末尾进行的也就是说如果一个条件在仿真时间内满足了但你期望它“立即”满足再到下一个Step实际可能会延迟一个步长。这个步长延迟在采样时间大的模型里会被放大影响时序判断精度。解决思路是把关键条件判断放到独立的Step中并且该Step的duration设为0这样条件一满足就立刻跳转减少步长延迟带来的影响。5.6 外部模式和Normal模式结果不一致外部模式下模型的一部分被部署到目标硬件上运行因此数值结果和Normal模式全在PC上运行可能存在微小差异。排查时优先检查求解器设置是否一致、目标硬件的字长与浮点精度是否足够、模拟I/O的采样与通信丢包是否影响信号值。我遇到过几次外部模式下测试Fail、Normal模式Pass的情况最后定位都是通信丢包导致的信号毛刺和模型本身没有关系。6. 从Excel数据驱动到模型验证的完整闭环6.1 入门到落地的最佳学习路径如果第一次接触这套流程我建议按下面这条路走不用一上来就搞上百个用例的大工程先搭一个最小模型比如一个一阶惯性环节或者一个PID控制器模型输入用Step信号输出接Scope。在模型里拖入Test Sequence写一个简单的时序逻辑等待外部Step信号为1然后检查输出信号在0.1秒内超过某个阈值。用Excel定义这个测试用例的输入信号和期望结果用MATLAB脚本读取Excel、配置模型、跑仿真并在脚本里判断Pass/Fail。最后接入Simulink Test做批量运行和报告生成。四个步骤走通后你已经掌握了整个链条的核心环节。剩下的就是按项目需求把它放大和工程化增加用例数量、增加需求追溯列、接入CI、并行加速等等。这套流程我用了好几年每次从新项目起步时都会先跑通这条“最小链路”后面扩展非常顺。6.2 我踩过的几个“看起来不起眼但很致命”的坑第一个是Excel文件路径中的中文和空格。MATLAB对路径中的中文文件名支持得还行但某些旧版本的Excel通道会出编码问题。为了避免这类玄学问题我后来统一规定测试定义文件的文件名、Sheet名、列名全部用英文字母和下划线数据文件路径也尽量用相对路径或全英文路径。第二个是大家容易忽略的时区和日期格式问题。如果你用datetime(now)生成报告文件名要注意MATLAB默认时区和Excel显示时区的差异否则两个工具看到的文件名后缀可能不一样对账的时候很麻烦。我后来直接统一用datestr(now, yyyymmdd_HHMMSS)这种纯数字格式彻底绕开这个问题。第三个是仿真结果自动保存时的数据量爆炸。仿真时长长、记录点多的时候simOut里的时序数据可能占到大量内存批量跑几百条用例甚至会撑爆内存。我现在的做法是在仿真配置里只记录需要的信号其他信号不记录并且在每条用例跑完后立即释放不用的数据对象。6.3 这套体系还能怎么延伸整个Excel Test Sequence的框架本质上是“外部数据驱动模型测试”的一种实现所以它的扩展性是内生的。当我需要做基于场景的测试时在Excel里增加场景数据列比如道路坡度、风速、载荷质量Test Sequence里增加相应的输入端口跑仿真时脚本把场景参数注入进去就能在一套框架下实现多场景回归。需要做code Coverage时也能在Simulink Test里勾选覆盖率收集选项跑完直接生成覆盖率报告和Excel里的用例维度结合起来分析覆盖盲区。根据我个人的落地经验如果你正在犹豫要不要把手工模型测试改成自动化我的建议是不要一上来做完美方案先用两三个典型用例跑通链路看到效果后团队自然会愿意投入去完善。自动化的价值不是一步到位的“全自动”而是把重复劳动逐步替代掉把人的精力留给真正需要分析的问题。最后分享一个小技巧在你批量跑测试的时候把Excel里的期望结果和容差设计得越细后面排查Fail的时间就越短。我一般会把Notebook里记录到的“线索”比如某个信号在第几秒跳动直接记在Excel的Comments列这样回归测试发现Fail时哪怕不是自己写的用例也能快速定位到问题的大致范围。祝大家都能从Excel到模型验证这条路上少踩坑、早下班。