本文描述单元测试的概念,以及Test Harness建立的方法和简单的单元测试过程。
1 单元测试
单元测试,简单来说就是在Simulink模型中只测试一小部分单元的功能。关于单元测试的概念网上有很多资料了,这里不再赘述。博主从实际工作经验的角度来谈谈单元测试的价值。
1.1 场景举例
举个简单的例子,某个工程师需要设计一个逻辑,当毫米波雷达跟踪的目标的置信度大于等于90时,认为该目标是有效目标。于是该工程师设计模型如下:
工程师不小心把判断条件写成大于号,而不是大于等于号。这就导致了置信度为90的目标全部被视为Invalid,从而影响了后面一大片的算法丢失了重要的输入信息。如果没有单元测试,这个问题就会被带到开发流程的后期。例如,该模型生成代码、编译集成、刷到车上以后,实车测试的时候发现后面的功能状态机一直不激活,或者控制信号一直不激活。然后再回头一点点往前撸信号,查找半天才定位到模型中的这个小bug。
这种情况在工作中时常发生,而且并不能因此责怪工程师的水平不行,因为人总会犯错误,避免不了“写bug”这种情况。因此,需要从流程体系的角度来尽可能提早发现设计问题。单元测试就可以做到这样的保障,譬如给上图这一小部分单元输入一个数值为90的Confidence信号,通过模型仿真发现输出竟然是False,就可以快速地定位这个缺陷,尽早地修复他。
1.2 简单的测试方法
既然知道了要在模型中先测试一下,不了解Test Harness的人可能会这么做。把已有的模型改造一下,把inport和outport端口去掉,给他几个输入,再用Scope或者disp模块看看输出对不对。模型改造成如下所示。
仿真后可以看到disp中的结果。这么做确实看到了输出的结果,发现了输入的置信度为90时,输出的是0。但是这样操作模型会有很多问题:
·为了仿真改掉了原有的模型,测完了还得改回去;
· 测试用例不方便保留下来,以后复测的时候还得手动操作一番;
· 如果想要多个不同的测试输入得把输入改来改去,不好切换;
针对这些问题,可以直接使用Simulink Test工具箱里的Test Harness,为设计专属的单元测试环境,引用原来模型的某个子系统或者整个模型的算法。后文会用一个例子来说明搭建Test Harness的过程,然后直观地看到他的好处。
2 Test Harness建立
这一节用以前的一篇博客搭建的模型,来演示一下Test Harness的建立过程,并且通过简单的输入进行仿真。
2.1 模型配置
1)首先打开需要测试的模型,这里用以前博主做的一个模型来演示:《Simulink建模:LKA系统功能状态机建模》。
2)在模型设置里,需要设置为离散,并且仿真步长设置为和实际控制器中的调度周期一致;
这样的话,模型就配置完毕了。
2.2 创建Test Harness
创建Test Harness有两种做法,为整个slx模型创建,或者为模型中的某个子系统创建。
博主比较倾向于后者,因为单元更小一点,可以聚焦于这部分的功能进行测试。即使是想测试整个模型,也可以将整个模型的最上层打包成一个大型的子系统进行测试。后文就以顶层的子系统LKA_StateMachine为例,来创建TestHarness。
1)右键点击这个子系统,选中Create for XXX
2)在界面中定一个名字,企鹅定好输入输出的形式;
这里博主选择了输入为Signal Builder,因为用的比较顺手,也可以选择From Workspace导入外部数据,或者Test Sequence等等。Signal Builder的用法参照《仿真与测试:通过Signal Builder模块生成输入信号》。
另外,如果勾选了Save test harness extern选项后,会生成一个用来保存harness模型的外部文件,否则生成的harness会依附于当前的模型。博主习惯后者,减少一些文件的管理。
3)点击OK后生成了一个Harness模型,按照之前的选择配置了输入为Signal Builder,引用了原模型的子系统作为中间算法;
这样的话,就不需要对原来的模型进行改造,也能进行单元测试。
4)打开Signal Builder设计一个简单的测试用例输入;
测试用例输入表示,3s时开关打开,1-5s时,车速从0加到80。然后通过信号log可以看到输出的LKA_Status是否符合该输入的预期。
这样就完成了一个Test Harness的创建及一个简单的单元测试。这个测试环境可以和
3 总结
本文描述单元测试的概念,以及Test Harness建立的方法和简单的单元测试过程。本文只是一个简单的单元测试,还没有发挥出Test Harness的更多功能。Test Harness配合Test Manager和Design Verify,可以搭建一套成体系的测试方法。
作者:chhttty