理论教育 汽车控制软件测试技术案例

汽车控制软件测试技术案例

时间:2023-08-26 理论教育 版权反馈
【摘要】:在这些测试可能性的范围之内,测试组件通常被用于不同的测试工件。图11.14 PedInt模型测试工具与间接刺激类似,“捕捉衍生信号”来代替测试对象输出可能是有意义的。

汽车控制软件测试技术案例

11.2.3.1 背靠背测试

传统意义上,基于代码的软件开发通常只产生一种“可执行文件”——软件本身。然而,另一方面,由于模型的演变,基于模型的设计通常为一种功能和相同的功能,产生多种可执行文件(例如设计模型、执行模型和生成代码)。此外,大多数这些不同的文件可以进行全面的测试(也称为系统测试)或部分测试(也称为模块测试)。在把这些“潜在的测试对象”与用不同的“执行平台”(例如PC主机、评估板)及“环境”(例如带模拟环境的开环、闭环模型;带真实环境的闭环模型)组合时,产生了一种所谓的“测验可能性”[BN03,GS05]。为了更加高效,对于一项全面的基于模型的测试,并不建议充分利用现有的所有测试可能性。而是选择一个全面考虑的子集。

在这些测试可能性的范围之内,测试组件通常被用于不同的测试工件。这使测试方法可以被实施,一个工件的系统反应可以被作为测试,来确定不同工件的期望输出。特别地,“不同工件之间背靠背测试”(等效测试)经常可以用来验证从一个模型进化阶段到下一个模型进化阶段的正确过渡。

如果一种测试方案被应用于不同的工件,那么使它适应特殊的测试对象是很有必要的。作为示范,下一章节将讨论测试方案如何被应用于模型级测试。

11.2.3.2 模型试验的测试工具生成

为了在Simulink/Stateflow表示的模型中,以定义的测试方案激励测试对象,需要一定的基础设施,用来对测试对象施加测试输入,并捕获系统反应。例如,这种基础设计由“模型测试工具”组成,且它本身又是一种仿真或状态流模型。

当创建测试工具时,在一个单独模型中的测试对象的复制是由仿真和信号记录模块来完成,因而一种扩展的“用于测试执行的可执行模型”——被称作测试工具模型就出现了(图11.14)。在测试设计过程中定义的激励信号通过测试工具转化为适用于模型测试的表示,并刺激测试对象的输入。与此同时,在输出一侧,对测试对象的相关输出信号以及再次转换为Simulink独立表示进行了记录。如果需要一个闭环测试执行,有必要把集成相应的模型组件(部分设备和环境模型)来模拟反馈回路并添加相关的信号流。

在“间接刺激”情况中,包含在激励模块中、传递给测试对象输入参数的、用于信号转换的模型部分,必须插入进来[Con04a,Con04b]。(www.daowen.com)

因此,比如如果需要作为测试对象的输入,那么通过采用求和模块,可以累计测试数据作为信号的真实值,可以累计信号设定值和真实值之间的差异来计算信号的设定值。间接刺激的其他的应用包括单位转换(如m/s到mile/h)或通过查表把踏板行程值转换为对应的转矩请求。

978-7-111-52251-5-Part04-21.jpg

图11.14 PedInt模型测试工具

与间接刺激类似,“捕捉衍生信号”来代替测试对象输出可能是有意义的。这样的例子是再一次的单位转换或记录滤波信号。

捕捉衍生信号的另一个例子是记录“看门狗”输出信号。看门狗是用于检测模型信号以及检查模型信号之间属性的模型部分。断定检测的信号背离指定性能的看门狗布尔输出,就是一个衍生信号,它可以被记录下来,用作进一步的分析。

用于其他表示形式的测试对象(也就是针对软件测试和嵌入式系统测试)的基础设施,也是通过上述规则创建的。然而,各个运行平台和环境的细节必须加以考虑。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈