标签: 模型动态测试

前言部分： 随着汽车电子技术的不断发展和普及,汽车电子系统的复杂度不断增加，对汽车电子系统的测试要求也越来越高,传统的测试方法已经无法满足对系统功能和性能的全面测试需求。TPT作为一种灵活、高效的测试工具，能够帮助测试工程师快速编写满足各类需求的测试用例，有效提高测试效率和覆盖率。 为了满足汽车行业日益增加的测试需求，走在测试技术前沿，TPT也在不断成长，以适应新的测试需求和挑战。 更新亮点 形式化需求 在TPT 19时我们已经体验到了形式化需求的高度自动化，在此基础上TPT 20支持MiL、SiL、PiL、HiL阶段所有平台使用形式化需求自动生成测试用例(例如:MATLAB、AUTOSAR、Lauterbach、CANoe、VeriStand等)，这一优化无疑会对我们的测试质量和效率的提升有很大帮助。 另外，形式化需求的编写也得到了优化，提供了一些新的步骤以便于满足各类需求。 例如：当需要的测试结果是检测两个信号是否相等时，新增的‘Shall Signal Compare’步骤就可直接满足这一需求。 图 1 新增步骤示例 形式化需求还新增一种生成未通过测试用例功能（满足功能需求输入，未得到期望结果），可以通过在TASMO自动生成测试用例界面选择开启该功能。 图 2 选择生成Failed测试用例 选择生成Failed测试用例后，生成界面会显示哪些需求存在未通过的情况，通过分析模型/代码，这样就可以快速发现/定位问题啦。 图 3 形式化需求自动生成用例界面（生成Failed测试用例示例） 自动生成测试用例 除形式化需求自动生成测试用例有更新外，其他测试用例自动生成也做了优化改进。 以‘Generate Test Cases from Equivalence Classes’为例： 我们现在可以选用等价类单个随机值做接口测试，在用边界值方法设计测试用例的时候选取三点边界值，从映射中检索量化数据。 图 4 选择测试方式 图 5 选择映射 在TPT 20中，我们不再需要通过复杂的配置组合去实现多类测试用例的生成，而是可以通过简单选择直接生成所需测试用例。 另外TPT 20还针对组合方式和生成用例形式提供了多个类型来满足我们测试的多种工况。 组合方式： Single value：单个信号的单个代表为一组； Pair two values：选择一对信号为一组； Combine values：选择所需信号的代表值为一组； 步骤列表： Embedded：将所有组合作为嵌入信号步骤的示例点嵌入一个步骤列表； Merged：将组合合并到一个用例中，在各组合间设置等待时间； Separated：为每个组合单独生成一个测试用例。 图 6 信号组合和用例形式选择 新增的'Generate Test Cases for Interface Testing' 功能是同时支持'Generate Test Cases from Equivalence Classes'和'Generate Test Cases from Value Ranges'的功能生成测试用例，可以更好的实现功能安全要求的接口测试和边界值测试。 图 7 Generate Test Cases for Interface Testing AUTOSAR 现在AUTOSAR新增TPT Coverage（TASMO）覆盖度统计方式，该统计方式可以直接使用并查看代码的SC、CC、DC、MC/DC覆盖率，无需另外购买商用覆盖度统计工具，避免繁琐的配置过程，节约成本的同时提高测试效率。 图 8 AUTOSAR覆盖度设置 自动生成完成后，执行相应测试用例，可以直观的看到代码结构的覆盖情况。 图 9 代码覆盖度报告查看 同时，AUTOSAR还支持了TASMO自动生成测试用例，并且提供了新的覆盖度标准‘Function coverage’，它满足了功能安全集成测试阶段的覆盖度统计要求，以便测试人员更好地查看代码中的函数是否执行。 图 10 Generate Test Cases for C/C++ or AUTOSAR 新功能 项目元素共享 当一个项目有多个TPT工程时，可以通过在子项目中设置父项目，将父项目的声明、命名数据类型、映射、函数和需求与多个子项目共享。 图 11 设置父项目 为了提高效率，将一个模型的功能分给不同的人测试时，可以通过此方法共享测试元素，分别进行需求测试，当父项目更新时，父项目中的调整也将应用于所有子项目。 图 12 共享元素 Function Wizard改进 ‘Channel steps’ and‘ Parameter steps’ 现在都可以使用TPT函数，例如 ：TPT.rampgradient()。此外，现在还可以为所有支持的整数数据类型生成Asymptote Functions 和 Ramp Functions以满足我们更复杂和多样的测试需求。 图 13 Function Wizard Python 3.0 TPT 20现在可支持Python 3.0用于测试评估。 图 14 新增功能函数 相比之前，TPT不仅可以使用Python 3.0来编写评估，Python 2.0在使用上也有优化。 举例： 现在可以将两个“TPTNumpy.array（）”对象用“==”进行比较，也支持了几个与时间相关的信号的并行分配。 图 15 示例 TPT项目文件的差异和合并 TPT 20支持TPT项目文件的比较和合并。通过’Diff and Merge view’视图，可以比较两个加载的TPT项目文件，并将偏差从一个文件转移到另一个文件。 图 16 对比项目文件 在测试的过程中，大家肯定避免不了会尝试修改各种设置和用例等来实现测试结果，这一过程也许会产生多个版本的项目文件，待测试成功后就可以使用该功能查看我们修改过的内容并做出总结，以便下次应用。 TPTBIN文件优化 在TPT 20中，优化了文件存储形式。相比前期版本缩小了文件大小，节省了空间，提高了测试效率。 图 17 TPT 20的BIN文件 如图所示，相同的文件在TPT 19中显示为6KB，但是在TPT 20中为3KB，显著缩小了文件大小。 图 18 TPT 19的BIN文件 总结 TPT 20的新功能就先介绍到这里了，每一次的更新和优化都是为了更好满足我们的需求和功能实现，给我们带来新的感受和体验，如果各位想要进一步了解TPT，欢迎联系我们，也希望能给我们带来新的建议和反馈。

TPT作为一款全球知名的嵌入式模型动态测试工具，被国内外用户所熟知和使用，帮助客户更高效地完成模型测试任务。北汇信息在国内推广TPT已有十多年，具备完善的技术支持能力。为了更好地支持客户的TPT使用，可以针对不同需求，提供标准或者定制的培训服务。 基础培训： 旨在帮助用户快速上手，达到熟练地使用TPT进行MiL、SiL全流程测试。 面向对象：TPT新用户（开发及测试工程师） 培训时长：1-2天 培训内容： TPT整体功能简述 基础测试用例建模 测试执行（指定执行环境，如MATLAB/Simulink） 测试评估基础 基础测试报告创建 培训效果： 熟悉TPT工具整体功能 能够进行从测试环境搭建、测试设计到报告全流程的模型测试 提高模型及代码测试效率 高级培训： 提升用户对工具的使用能力和技巧，更高效地进行测试工作。 面向对象：有过TPT使用基础的用户（开发及测试工程师） 培训时长：2天 培训内容： 高级测试用例建模（多样化用例创建及自动生成） 测试用例、数据导入、导出 高级测试评估（脚本评估语法简介及应用） 背靠背测试执行（Simulink/AUTOSAR模型及代码） 使用TPT进行满足ISO26262标准的测试（如等价类、边界值等测试方法） 培训效果： 提高工具自动化使用程度，提高测试效率； 掌握工具多种进阶功能和高级使用方法，能够更加有效的开展测试工作； 能够使用TPT进行符合功能安全标准的模型及代码测试； 培训地点及模式： 我司集中培训：上海，面向华东及周边客户；北京，面向华北及周边客户。 客户现场集中培训。 线上会议形式。 培训师资： 北汇信息TPT培训讲师，均通过原厂TPT工具培训认证以及国际软件测试资质认证委员会（ISTQB）认证，并且具有一定的项目实战经验。 请发送邮件至marketing@polelink.com或者私信，联系我们安排2024年TPT收费培训： 选择基础还是高级培训？ 有多少位工程师参加培训？ 期望现场还是远程会议进行培训？ 是否有特定的培训需求？

随着汽车行业日新月异的发展，软件定义汽车已逐渐成为大家的追求目标，汽车中的嵌入式软件版本不断迭代，功能也不断增强。为了顺应行业的高速发展和满足客户复杂多变的需求，TPT也在悄悄成长，又一次完成蜕变。接下来随我一起走进TPT19的新世界。 首先，我们通过一则短片，了解TPT19的新特性。 PART01 更新亮点 形式化需求 其实早在TPT18时，形式化需求就已经作为预发布功能和大家见过面了，如今在TPT19中，形式化需求以更加成熟的姿态问世。功能也有了较大的提升。 基于功能需求的测试占据着主体地位，工程师们在体验了众多自动生成测试用例方法后，也常常会提出，测试工具如何基于功能需求自动生成测试用例呢？那么TPT19的实现方式是 形式化需求+TASMO工具箱 ，并且操作步骤简单，达到测试的高度自动化。 相信对TPT比较熟悉的伙伴对上述流程中的导入需求和TASMO自动生成两步都有所了解，而新增形式化的过程也相对简单。所以，对于某些应用场景来说，基于形式化需求自动生成测试用例可以发挥其巨大的作用。 举两个例子： 做基于功能需求的单元测试，我们可以利用这种方式生成一系列功能性较强的测试用例来验证功能，然后再利用基于模型结构作为补充，以达到边界值测试、结构覆盖度等等要求； 做集成测试，主要关注集成级功能需求覆盖度，那基于形式化需求的测试方法无疑是最好的选择。 总的来说，只要我们有完整的需求文档，那么形式化需求功能就可以利用起来，同时与其他自动生成用例 的方法 相结合，可大大提高测试的自动化程度。 AUTOSAR AUTOSAR平台配置新增按钮，可以选择子组件进行测试，新增的这个功能是非常实用的，以往的版本中对于AUTOSAR模型，只能测试整个集成的模块或者某单一组件，在TPT19中，我们可以任意选择想要测试的组件，这样一来，避免了为达到不同工况去集成不同组件进行测试，减少了不少模型封装工作。 AUTOSAR的另一个新增功能也同样非常实用，在进行MATLAB和AUTOSAR平台B2B测试时，通过Preference Model，可以在AUTOSAR平台导入接口时快速复用MATLAB平台已导入的接口，省去了大量接口mapping工作。 另外，TPT19可从ARXML文件中导入查表模块的值，并且支持具有可选元素的结构体数据类型。 参数集设置 相信大家在测试工作中会经常遇到此类问题——为了验证模型在不同工况下的输出情况，经常需要修改参数标定。 对此，TPT19做出了调整，在执行界面新增了“Parameter set”，我们可以为 多个 Parameter建立参数集，在 每个 参数集中去定义我们需要的所有可能取值。那么，在用例执行时选择参数集便可以 覆盖多种工况， 满足我们的测试需求。 举例：对于灯控模型，想要分别验证模型在延时1s、2s、3s后打开头灯的功能，TPT19中不再需要 对每一条用例一一修改“头灯打开延时”参数 ，设置参数集即可：设置 “头灯打开延时”参数集 ==〉 在执行界面下拉菜单中选择对应的参数集 ==〉 运行 。 PART0 2 功能 优化 压力测试 可以在执行界面输入用例的执行次数，达到压力测试目的，可以发现系统的性能瓶颈，优化系统的设计和配置，提前识别和解决潜在的性能问题，以确保系统能够在实际使用中稳定运行并满足用户的需求。 C/C++平台 支持更多的数据类型（例如：外部指针常量（ extern int* const x) 、常量指针、函数参数指针、联合数据类型等）和特性 支持所有目标编译器； 支持更丰富的交叉编译链。 首选项配置 TPT19可以设置MATLAB、ASCET等平台，C、Eclipse等编译器的默认版本，在测试中如未选择则保持默认。 Signal Viewer 信号防堆叠展示； 可均衡窗口高度； 可分离信号。 Simulink in Linux 可以在Linux操作系统上通过Docker容器方式运行TPT软件和MATLAB/Simulink平台的容器镜像，达到可以在Linux操作系统进行MiL测试的目的。 PART0 3 优势功能 测试数据导入导出 针对Excel形式的测试用例和其他软件导出的测试数据（如INCA等），TPT支持导入并生成可执行的测试用例。 单文件导入 创建测试用例时，若需导入外部数据作为用例中的输入条件，可以利用import signal步骤来实现，但一个import signal步骤只能导入一个信号值，那么借助import signal from file来导入文件就可以很好的实现一次导入文件中多个接口的信号值。 点击import signal from file按钮，选择需要导入的文件，TPT能够自动识别文件中所有的信号名称，选择需要导入的信号并做好与本地接口的mapping，就能在TPT用例中生成一个包含所选接口的import signal步骤，实现多接口外部数据导入。 多文件导入 上述步骤大家可能也发现了，虽然可以针对多接口，但也只能选择一个文件，那么面对多sheet或者多文件的外部数据时，TPT如何实现快速导入呢？这就要借助于generate test cases from test data功能。 在基于测试数据生成用例的窗口中，我们选择完文件夹，TPT会识别路径中数据文件数量，并针对每一个文件生成对应的测试用例，用例形式以import signal步骤展示，一键实现多文件同步导入。 测试用例导出 对于TPT测试工程中所有的用例，我们可以以格式化文本将其步骤、属性等导出成Excel文件，供我们复用、评审和管理等。 图 13 导出的用例文件 篇幅所限，本次TPT19的新功能和优化项暂时介绍到这里。总的来说，TPT的每一次更新和优化，都是我们扎根客户，关注用户体验，了解用户需求带来的成果，TPT的开发者们也专注研发，致力于将TPT打造成一款功能强大、自动化程度高的嵌入式软件动态测试工具。 纸上得来终觉浅，各位看官如果想要进一步了解TPT，请联系我们，也欢迎新老用户提出宝贵建议和意见。 ​—END—

上篇我们介绍了被测对象、动态测试和测试用例的概念，还提出了如何省时省力评估自动生成的测试用例的话题。事实上TPT能够实现测试用例和评估解耦，为每条用例/多条用例创建符合其场景的测试评估：可以通过GUI界面来进行信号对比、事件查询、信号边界检查、信号序列的正确性判断以及信号调理；也可以通过脚本语言实现复杂场景的评估。 本文会介绍测试级别和测试环境，并带大家进一步了解模型动态测试工具——TPT。 什么是测试级别？ ASPICE定义了以下五个测试级别： 1. 软件单元测试(SWE.4) 2. 软件集成与集成测试(SWE.5) 3. 软件合格性测试(SWE.6) 4. 系统集成与集成测试(SYS.4) 5. 系统合格性测试(SYS.5) 软件单元测试也被称为模块测试或功能测试。在单元测试中，测试对象是最小的软件组件，即单元。单元经常变化，因此单元测试必须经常调整、补充并再次执行。单元测试有两个主要目标： 1. 早期质量保证 2. 快速检测模型/代码更改中的交叉影响 因为软件或软件组件是永久地调整和更改的，并且后续的回归测试也总是充满了重复性，因此最简单的方法是在持续集成环境中自动化执行单元测试。 TPT可以通过与Jenkins的集成实现自动化测试，提高测试效率。主要可实现的功能包括：基于TPT的Jenkins节点环境导入测试接口；自动生成TPT测试框架；自动执行TPT工程测试用例；自动生成测试报告。用Jenkins自动执行测试工程代替测试工程师手动执行，既能缩短测试周期，又能避免重复性劳动。 图1. Jenkins端TPT测试结果 单元测试之后是软件集成测试。 软件 集成是单个软件组件的组装 ， 这里的重点是 测试 软件组件之间的兼容性。集成测试通常分几个阶段进行 ， 根据整个软件的 结构 ，在几个中间阶段到几百个中间阶段之间提供集成测试。中间阶段的数量和选择最终取决于软件体系结构和软件设计 。 元素和级别越多，集成测试的中间阶段就越多。 通常，集成测试是自下向上开发的，首先集成和测试几个单元(大约3-5个)。然后，所得到的单元组合与其他已经测试过的单元组合或其他单元集成在下一个中间阶段，并再次测试。这个迭代链一直持续到ECU的整个软件被构建和测试完毕。 图2. 集成测试迭代图 大量的集成测试一开始听起来工作量很大，但它有一个明显的优势，就是可以更快更好地发现错误。而在TPT中，单元的测试用例能够一定程度上复用到集成测试，为用户减少集成测试阶段的工作量。在 单元测试用例复用到集成测试？Testlet Library来助力！-面包板社区 (eet-china.com) 一文中介绍了详细操作方法。 集成测试的 另一大优势在于，集成测试阶段 发现的错误可以更容易地 定位 到其原因，从 而大大简化了 问题 分析。经验表明，大多数软件错误都是在集成测试中发现的。 集成测试完成后，软件 合格性 测试紧随其后 。 软件 合格性 测试通常在目标硬件上执行。软件 合格性 测试中的测试对象与集成测试中的最后一个测试对象相同:它是完全集成的软件。然而，它们各自的目的 不同： 1. 集成测试的目的 ： 检查软件组件之间的兼容性。 2. 软件 合格性 测试目 的： 检查软件是否符合要求，例如与传感器和执行器的兼容性 。 软件合格性测试之后是进一步的集成测试。但是，这一次不是在软件级别，而是在系统组件级别。该过程与软件集成测试相同。ECU与一个或多个传感器或执行器一起测试，然后逐步添加其他组件，直到系统层面。 最后 是系统合格性测试 。在此过程中，将所有系统组件集成到一个系统中并进行测试。系统测试的重点是确定是否符合系统需求和系统的可交付性。 什么是测试环境？ 测试环境是指执行测试所需要的环境，包括硬件、仪器、模拟器、软件工具和其他支持要素。测试环境应该尽可能接近真实的生产环境，以便 更准确地模拟实际环境中的操作和运行情况 ， 从而确保软件在生产环境中的可靠性和稳定性。 在这种情况下，我们经常会讨论在环测试，例如： 模型在环（ Model-in-the-loop ， MiL ） 软件在环（ Software-in-the-loop ， SiL ） 处理器在环（ Processor-in-the-loop ， PiL ） 硬件在环（ Hardware-in-the-loop ， H iL ） “在环”指的是测试对象与模拟生产环境的组件之间的一种特殊类型的交互。在“在环测试”中，环境对测试对象的状态和计算做出反应。 TPT可以灵活适应于MiL/SiL/PiL/HiL/ViL整个在环测试阶段，并且支持各阶段的开发平台。 图3. TPT在环测试支持平台总览 现代新能源汽车软件的开发往往基于模型，而大多数模型是用MATLAB/Simulink/TargetLink或ASCET创建的。这些模型通常在开发环境中直接以单元和软件集成的形式作为模型在环(MiL)进行验证。 这种类型的动态测试可以发现控制策略和逻辑中的错误。嵌入式系统的仿真是在同样 仿真 的环境模型中执行的。这种非常早期的测试的 优点是可以快速检测到模型构建中已经存在的错误，并有可能对其进行修正。 TPT在MiL环境能够自动从Simulink、TargetLink及ASCET模型获取接口信息并生成测试框架，通过测试框架将测试用例定义的输入信号激励给到被测模型，再回采被测模型的输出结果并对其进行评估，整个过程由TPT自动完成，无需用户自定义。 图4. 基于MATLAB/Simulink的TPT MiL测试过程 在 软件在环测试（ SiL ） 中，测试代码是在 PC 上测试的。这要么是手写的，要么是从模型生成的。这两种代码的作用域是不同的。 1. 测试 模型 生成的代码 ： 检查代码生成器是否正常工作。生成的代码的功能应该尽可能接近模型。 2. 对于手 写 代码， SiL 可能 是第一个测试级别。与 MiL 一样，目标是在早期阶段发现错误。 对于第1种模型生成的代码， 为了验证生成的代码与原模型的等效性，应当进行背靠背测试。在 T PT 中，背靠背测试尤为便捷。以 Simulink 模型为例，用户只需要点击 FUSION DLL 就能调用 S imulink 生成代码，并且一键生成 SiL 测试平台，同时运行 M iL 和 SiL 平台，还能自动实现对两个平台测试数据的对比，完成等效性验证。 图5. TPT背靠背测试过程 在 SiL 中测试的代码 还 不能在嵌入式 ECU 上执行。为了执行，必须为目标处理器编译代码。在这个过程中生成的代码可以通过两种方式进行测试 ： 1 . 通过 调试器与目标芯片环境 。 2 . 在 PC 上模拟处理器的虚拟环境。 在这两种情况下，都提到了处理器 在环 (PiL) ， 实际上是指为目标处理器架构构建的软件测试。处理器在环测试的主要目标是检测编译器错误，或者在软件组件非常接近硬件的情况下，例如驱动程序或执行器的控制，在早期阶段检查硬件和软件组件的兼容性。 在 PiL测试实战（上） 模型生成代码的单元级PiL测试-面包板社区 (eet-china.com) 一文中介绍了TPT做PiL测试的解决方案。简单来说，TPT将测试用例数据发送到UDE，并读取UDE从目标板读到的输出信号数据进行评估。这个过程中可以直接复用MiL/SiL环境的测试用例，单元级软件测试可实现同一测试工程覆盖MiL/SiL/PiL所有阶段。 图6. TPT+UDE PiL测试方案 下一个逻辑步骤是硬件 测试 ，即 在带有外围设备的物理 ECU 上完成软件 测试 ， 重点是输入和输出、通信总线和其他接口如何实时交互。这种 测试 的术语是硬件在环 ( Hardware-in-the-Loop ， HiL ) 。 HiL 测试从 ECU 开始，可以实现到系统网络级别。 图7. TPT与VECTOR CANoe集成 TPT支持通过XiL-API接口与HiL设备进行集成，包括：VT System、dSPACE、NI Veristand、Concurrent iHawk、Speedgoat。可以发送测试用例到HiL设备执行，接受测试数据进行评估，支持实时测试、故障注入，也可以通过CANape/INCA对ECU进行标定和测量。 总结 在汽车软件测试中，有许多术语和方法。在我们看来，掌握这些背景知识、合理运用测试工具和测试方法，是成功实现嵌入式系统测试的关键。本文带大家从工具的层面出发，介绍了TPT在不同测试级别和测试环境中的作用。北汇信息之前也发布了许多测试方法、实践经验等文章，欢迎大家订阅，并留言与我们交流！

在 PikeTec ，我们有一个示例来展示我们的测试自动化工具 TPT: 灯光控制器。 这些信息正在等着你 : 1. 为什么是这样一个简单的例子 ? 2. 灯控制器 演示模型 的主要功能 3. 灯控制器 演示模型 的接口 4. 灯控制器 演示模型 的行为 5. 特殊情况 - 更改为自动模式 6. 特殊情况 - 在自动模式 下改变光强 7. 不同的实现类型 8. 在哪里可以找到它 ? 9. 快速上手指南 10. Fun-Fac t 为什么是这样一个简单的例子 ? 选择 用这个 乍 一看很简单的例子 ，我们 有 如下 几个理由 : 简单 : 灯光控制器的操作简单易懂。因此， 它是一个能让人 将全部注意力集中在 TPT 的功能 的 理想 模型 。 可管理的范围 : 它提供了在汽车软件开发中发现的 典型实现 机制的清晰而简洁的演示，例如滞后时间、阈值、可调参数和内部状态 汽车相关性 : 灯光控制器代表了典型的汽车功能，使其与行业专业人士相关。 灯控制器 演示模型 的主要功能 主要功能是计算前灯的控制。输出值可以是 on 或 off 。这个计算考虑了两个输入 : 光开关的位置和光强度。 灯控制器 演示模型 的接口 · 灯的开关有三个位置 : 开、关和自动模式。 · 光照强度范围为 0% ~ 100% 。 · 灯光控制器内部将光强度分为三个区域 : 明亮，黄昏和黑暗 ； · 使用两个参数 :MIN_LIGHT_ON( 默认 :60) 和 MIN_LIGHT_OFF( 默认 :70) 。 灯控制器 演示模型 的行为 当灯开关处于关闭位置时，应关闭大灯。当灯开关处于 On 位置时，应打开大灯。 特殊情况 - 更改为自动模式 当灯开关从任何位置设置为自动模式时，前照灯应在黑暗时打开，在明亮时关闭。 特殊情况 - 在自动模式 下改变光强 当灯开关处于自动模式时，光线强度发生变化，应防止前照灯闪烁 ( 快速开灭 ) 。 相反，前灯的变化应该只发生在可配置的黑暗或亮度后。举例来说，这可以确保当汽车行驶在有不同 树荫 的小巷时，前灯不会不停地打开和关闭。 这个所谓的滞后时间可以通过两个参数来设置。 参数 HYSTERESE_TIME_ON( 默认 :2s) 确保只有当它连续黑暗至少 2s 时，前灯才会打开。 参数 HYSTERESE_TIME_OFF( 默认值 :3s) 确保只有在车头 灯连续亮 了至少 3 秒后才会关闭。 参数通常是为了使软件适应各自的系统，而不必改变软件。您可以在这里了解更多关于参数的信息 : 参数—— 参数——汽车软件开发中最大的挑战之一-面包板社区 (eet-china.com) 不同的实现类型 虽然功能看起来很简单，但测试它有时可能很复杂。开始使用 TPT 对你来说应该尽可能容易。 因此，我们将不同变体 (Simulink 模型， C 或 C ++ 代码， Autosar 软件组件等 ) 的灯光控制器 演示模型 直接集成到我们的 TPT 中。 为了展示某些方面，我们的示例在某些情况下进行了扩展，例如，展示使用和不使用缩放数据类型的差异。但主要功能总是相同的。 在哪里可以找到它 ? 您可以在 TPT 的 examples 选项卡下直接访问所有示例。在我们的 TPT 用户指南中，我们还 展示 了一些例子。 快速上手指南 这里有一个关于如何做到这一点的简短教程 : Fun-Fac t 顺便说一下，我们也用照明控制的例子来教 新 同事 ， TPT 这样做已经超过 15 年了。 所以我们的灯光控制器可能是使用 TPT 测试最多的程序。 如果您想了解我们的灯控制器， 欢迎联系我们 申请免费试用。