SIMULINK中大、中复杂度系统模型的单元测试和集成测试

Question

问题

我有一个相当大的液压-气动系统模型，由大约20-25个不同的子系统组成。然后，每个子系统由数字逻辑、边缘延迟块和到外部输出端口(真实输出)的网关组成。此外，一些小的构建块是作为S函数导入的遗留C代码，以最大化成本效益比。每个子系统模型都是在SIMULINK中使用基本块集设计的，即没有附加的商业块集(例如航空航天、simscape、simMechanics等)。使用。

主要的问题是我没有足够的知识在SIMULINK中测试模型。我知道Mathworks提供了一个定制的单元测试框架来进行测试和验证。问题是，我不太确定这将如何与我的领域相关。此外，我的子系统本身相当复杂，单元测试每个子系统都是一场噩梦。但是，如果输入和输出的黑盒测试是唯一的方法，那么就这样吧，我很高兴接受这一点。

虽然我的问题是关于在SIMULINK中测试大规模和复杂的系统，但我的目标是从经验丰富的SIMULINK用户那里获得建议，这些用户过去曾经这样做过，将来也会做得更多。我以前在SIMULINK中做过单元测试，但所有这些测试都离我正确的设计还差得远。

任何帮助都将不胜感激！

@PHILGODDARD评论后的更新

我忘记在上面提到，我对HIL和PIL很熟悉。然而，只有当您的目标实时平台可用于循环测试时，这些才有效。如果有人想要进行软实时测试呢？

我正等着在一两天内参加Mathworks大型系统测试网络研讨会。希望我能通过它得到一些更好的答案/建议？

@AM304评论后的更新

为了进一步澄清上下文，我们在软件中模拟所有相互作用的系统，而不涉及任何物理设备，即在软件中对所有系统进行建模和仿真，其输出显示在操作员/教师终端中……例如，我们有电气、空调和油气系统协同工作，但我们在软件中对它们进行了建模。因此，当我们模拟它时，所有必要的信号都是从软件模型的行为中生成的，没有实际的硬件/物理设备参与传递这些行为输出。

Answer 1

我会调查Simulink Design Verifier和Simulink Verification&Validation。具体地说，它们提供了自动测试生成和覆盖率分析等功能，我认为这些功能适用于您的问题。

顺便说一句。

关于你在文章中提到的matlab unit-testing framework，这基本上是xUnit框架的MATLAB实现。因此，如果您希望能够将xUnit设计模式应用于MATLAB代码的测试，那么它显然会派上用场。

该框架可用于为Simulink模型编写测试，但请记住，您必须能够用MATLAB代码编写测试。因此，这只意味着使用Simulink命令行界面(例如，set_param和sim等命令)来设置和练习您的模型，然后使用框架的验证方法(例如，verifyEqual)来比较实际和预期的结果。

Answer 2

C代码以及Simulink模型都可以使用TPT进行测试。在测试开发和测试评估中没有区别，但在测试执行环境中有区别。为了测试C代码，可以决定是否在Simulink中以所谓的SiL-模式测试C-代码，其中C-代码作为所谓的S-函数嵌入到Simulink中。S函数的生成可以由依赖于代码生成器的m脚本自动完成。

对于Simulink编码器，可以使用以下MATLAB命令来强制执行SiL：

set_param(<testFrameName>,'RTWSystemTargetFile','rtwsfcn.tlc');
set_param(<testFrameName>,'RTWTemplateMakefile','rtwsfcn_default_tmf');
rtwbuild(<subsystem to be tested>); 

对于TargetLink，脚本使用TargetLink命令“tl_built_host”和“tl_set_sim_mode”：

tl_build_host('Model', <testFrameName>, 'TlSubsystems', <subsystem to be tested>);
tl_set_sim_mode('Model', <testFrameName>, 'TlSubsystems', <subsystem to be tested>, 'SimMode', 'TL_CODE_HOST');

或者，在TPT中，可以通过另外两种方式测试C代码，这两种方式不需要Simulink，但需要一些手动编程和编译。

第一种选择是使用所谓的EXE平台，其中测试工具是用C代码构建的，并由用户通过自己的编译器进行编译。在TPT的EXE-platform配置对话框中支持测试线束的生成。

第二种选择是所谓的融合平台，它是一个协同仿真环境。FUSION是一个开放的体系结构，用户可以使用定义良好且有文档记录的API调整自己的被测C代码系统。C代码与API一起形成所谓的节点，该节点可以在FUISON平台上模拟为单个节点或与其他节点一起模拟。然而，在自动代码生成的情况下，大多数用户在Simulink中使用MiL和SiL测试，因为它可以完全自动完成，包括MiL和SiL之间的背靠背回归测试。

为什么应该测试C代码而不是模型？原因是大部分功能开发都是用浮点表示法完成的，而在目标ECU中的实现是用定点表示法完成的。缩放和定点计算的过程至少是在代码生成期间为TargetLink完成的。因此，浮点(MiL)结果将与定点实现(SiL)进行比较，因为从经验来看，缩放引入了许多错误。

如果语句或条件覆盖率为100%，则TPT中有一个称为TASMO的功能。TASMO试图自动生成测试用例，以满足Simulink或TargetLink模型的最大覆盖率。该算法是基于优化和基于搜索的。请注意，自动测试用例生成不应该取代功能测试用例。覆盖率目标可以通过使用代码覆盖率工具来检查，如CTC++，V&V工具箱或TargetLink，它们带来了自己的覆盖率度量。通过查看复盖结果，用户可以自行决定如何刺激盲点，并可以识别死代码。

我是TPT开发人员之一。有关TPT的更多信息，请访问我们的网站。

Answer 3

MathWorks在R2017b更改了其V&V产品供应(2017年9月)。我建议查看以下链接，看看它们如何帮助在Simulink/Stateflow中进行设计的单元和集成级测试。

1. Simulink Test -提供一个环境来测试您的Simulink/Stateflow design
2. Simulink Coverage -生成覆盖指标，以确定您的设计有多少已经过tested
3. Simulink Design Verifier -自动生成测试，以满足功能或覆盖标准

MathWorks网站上有一个概述页面，提供了有关verification, validation, and test整体产品的更多详细信息。