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的创建及一个简单的单元测试。这个测试环境可以和