我有一个相当大的Hydro-Pneumatic系统模型，由大约20-25个不同的子系统组成。然后，每个子系统由数字逻辑，边缘延迟块和到外部输出端口的网关（实际输出）组成。此外，一些小构建块是作为S函数导入的遗留C代码，以便最大化成本效益比。每个子系统模型都是在SIMULINK中设计的，使用了基本的模块集，即没有使用附加的商业模块集（例如航空航天，simscape，simMechanics等）。
主要问题是我对SIMULINK中的测试模型知之甚少。我知道Mathworks提供了一个定制的单元测试框架来进行测试和验证。问题是我不太确定这与我的域名有什么关系。此外，我的子系统本身非常复杂，单元测试每个子系统都是一场噩梦。但如果使用输入和输出进行黑盒测试是唯一的方法，那就这样吧，我很乐意接受它。
虽然我的问题在于测试SIMULINK中的大型复杂系统，但我的目标是从过去已经完成它的经验丰富的SIMULINK用户那里获得建议，并且将来会做很多事情。我以前在SIMULINK中进行过单元测试，但所有那些测试甚至都不在我的正确设计附近。
任何帮助将不胜感激！
我忘了在上面提到我熟悉HIL和PIL。但是，只有当您的目标实时平台可用于循环测试时，这些才有效。如果有人想进行软实时测试怎么办？
我等待在一两天内完成Mathworks大规模系统测试网络研讨会。有意思的是，我可以通过它获得更好的答案/建议吗？
为了进一步阐明背景，我们在软件中对所有交互系统进行建模，而不涉及任何物理设备，即软件中所有系统的建模和仿真，输出显示在操作员/讲师终端中....例如我们有电气，空调和液压气动系统协同工作，但我们已经用软件对它们进行了建模。因此，当我们模拟它时，所有必要的信号都是从软件模型的行为中产生的，在提供这些行为输出时不涉及实际的硬件/物理设备。
答案 0 :(得分：2)
我会调查Simulink Design Verifier和Simulink Verification&Validation。具体来说，它们提供了自动测试生成和覆盖率分析等功能，我认为这些功能适用于您的问题。
作为旁注......
关于你在帖子中提到的matlab unit-testing framework，这基本上是xUnit框架的MATLAB实现。因此，如果您希望能够将xUnit设计模式应用于MATLAB代码的测试，它显然会派上用场。
该框架可用于为Simulink模型编写测试，但请记住，您必须能够在MATLAB代码中编写测试。所以这只是意味着利用Simulink命令行界面（例如set_param和sim之类的命令）来设置和运用你的模型，然后使用框架的验证方法（例如{{1} }）比较实际和预期的结果。
答案 1 :(得分：0)
可以使用TPT测试C代码和Simulink模型。测试开发和测试评估没有区别，但在测试执行环境中没有区别。为了测试C代码，可以决定是否应在Simulink中以所谓的SiL模式测试C代码，其中C代码嵌入在Simulink中，即所谓的S函数。 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平台配置对话框支持生成测试工具。
第二种选择是所谓的FUSION平台，它是一种协同仿真环境。 FUSION是一种开放式架构，用户可以使用定义明确的API在测试C代码下调整自己的系统。 c代码与API一起形成所谓的节点，其可以在FUISON平台上作为单个节点或与其他节点一起模拟。 在自动代码生成的情况下，大多数用户在Simulink中使用MiL和SiL测试，因为它可以完全自动完成，包括MiL和SiL之间的背靠背回归测试。
为什么要测试C代码而不是模型？原因是大多数功能开发是以浮点表示法完成的，而目标ECU中的实现是以定点表示法完成的。缩放和定点计算的过程至少对于TargetLink在代码生成期间完成。因此，浮点（MiL）结果将与定点实现（SiL）进行比较，因为根据经验，缩放会引入许多错误。
如果100％声明或条件覆盖，则TPT中存在称为TASMO的功能。 TASMO尝试自动生成测试用例，以最大限度地覆盖Simulink或TargetLink模型。该算法基于优化并且是基于搜索的。请注意，生成自动测试用例不应取代功能测试用例。可以使用代码覆盖工具（如CTC ++，V＆amp; V工具箱或TargetLink）来检查覆盖率目标，这些工具带来了自己的覆盖率测量。通过查看覆盖结果，用户可以自己决定如何刺激盲点并且可以识别死代码。
我是TPT开发人员之一。有关TPT的更多信息，请访问我们的网站。
答案 2 :(得分：0)
MathWorks在R2017b（2017年9月）更改了它的V＆amp; V产品。我建议您查看以下链接，了解它们如何帮助Simulink / Stateflow中的设计进行单元和集成级测试。
MathWorks网站上有一个概述页面，其中提供了有关verification, validation, and test整体服务的更多详细信息。