标签: 嵌入式软件测试

上篇我们介绍了被测对象、动态测试和测试用例的概念，还提出了如何省时省力评估自动生成的测试用例的话题。事实上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 测试最多的程序。 如果您想了解我们的灯控制器， 欢迎联系我们 申请免费试用。

汽车世界在不断发展，“软件定义的汽车”等新术语证明了软件对当今汽车的重要性。无论是MiL、SiL、PiL、HiL、还是单元测试、集成测试，汽车软件测试的世界有很多技术术语，本文将从一款专业的汽车软件测试工具TPT出发，带大家从实际应用的角度掌握汽车测试术语。 什么是测试对象或被测系统（SUT, System under test）？ 测试对象、被测系统和测试元素通常是同义词。根据ISTQB，一个测试对象一般被定义为“待测试的工作产品”。因此，测试对象可以是： 一个 控制 单元 ， 几个控制单元组成的网络 几个 集成网络组成 的 系统 ， 一 辆整 车， 任何其他被测对象 TPT是全球知名的基于模型的嵌入式系统测试工具，用于电控系统软件应用层功能测试。不论是单元模型还是几个控制单元组成的集成模型，又或是整个系统模型，TPT都可以加载并导入接口，为后续的测试做准备。 什么是动态测试（Dynamic testing）？ 动态测试是测试对象的执行。在动态测试中，创建并执行测试用例，用测试数据激励测试对象。激励导致测试对象要么执行计算，要么改变其状态。在动态测试中记录测试对象的反应，并与期望值进行比较。如果反应与期望相等，则认为测试用例通过；如果不相等，就认为用例失败。 TPT就是一款基于模型的动态测试工具，可以一键执行测试用例，模型仿真结束后TPT回采测试数据，并将其与期望值进行对比，自动输出测试结果。 既然提到了执行测试用例，那么—— 什么是测试用例（Test case）？ 一个测试用例总是至少包含以下两部分信息： 1. 定义如何激励测试对象的测试数据。 2. 测试对象的期望值，它定义了被测对象在接收到测试激励后有哪些计算/状态。 其中，针对第一项给定信号激励往往需要测试人员有着丰富的测试经验。一个专业的测试工具也能帮助测试人员实现事半功倍的效果。 TPT就支持非常多种测试用例搭建方式，可实现测试场景的可视化，也能够实现基于等价类/边界值/遍历等方法自动生成测试用例。 1) 基于测试步骤手写测试用例 TPT支持测试人员针对测试过程进行手写测试用例，测试人员可以通过“直接定义”、“测试用例列表”以及“引用”自然语言等方法进行测试用例的编写。提供 Signal preview，直观显示信号在整个测试过程中的曲线情况，掌握整个测试过程，避免出现测试用例人为错误。 图1.基于测试步骤搭建测试用例 在实际项目中，针对简单的测试需求，可以使用测试列表的方法来进行测试用例搭建，比常规的Excel 测试用例更简洁更直接。 2）基于State的图形化测试用例搭建 在实际项目中，针对给出的需求，要考虑条件满足时的测试（Positive Testing）和条件不满足时的测试（Negative Testing），在TPT中可以设置State，为信号设定不同的取值状态，还可以设置跳转条件、增加执行路径，这样通过切换信号状态和执行路径就能覆盖不同的测试场景。 图2. 基于State搭建图形化测试用例 采用State建立测试用例，除了可以更方便快捷的搭建测试用例之外，还可以大幅度提高测试用例的可读性，这对于测试用例的后期维护和评审带来了极大的便利。 3）TPT中提供一系列自动化的测试用例生成工具箱，可以确保整个测试过程更加便捷、高效，实现测试过程标准化： 基于等价类：ISO26262 针对模型的测试方法提到了等价类测试。TPT针对这一要求，设计了等价类生成工具箱，这个工具箱支持根据用户的等价分类一键生成测试用例，避免了传统方式上的人工重复操作，测试效率得到极大的提升。 图3.为信号创建等价区间 图4.基于等价类自动生成的测试用例 基于数值范围：在针对接口测试时，往往要针对数据的数值范围进行测试，以验证模型接口是否正确。针对这样的测试用例，TPT 可以根据数值范围自动生成测试用例，用户只需要关注数据范围以及步进长度，就能实现数值范围内的遍历。同时可以结合边界值及数据精度自动生成符合边界值要求的测试用例，来测试边界是否出现不符合预期功能的情况。 图5.设置接口的数据范围以及步进长度 图6.基于数值范围自动生成的测试用例 基于TASMO工具箱：能够分析模型结构并自动生成测试用例，会采用最少数量的测试用例来最大化遍历模型。同时TASMO还能够作为结构覆盖度统计工具，帮助统计当前运行的测试用例或测试用例集的覆盖情况，并且生成相应的结构覆盖度统计报告。 在TPT19中，还支持基于形式化需求自动生成测试用例，用户只需要从导入的需求中提取关键字，TPT就能自动覆盖与需求相关的场景，生成对应的测试用例。 图7.基于形式化需求自动生成的测试用例 基于状态机组合：在项目中，针对一些逻辑类的功能测试，从需求的角度，一般就是一些输入条件的排列组合。TPT 可以基于这些条件排列组合，自动生成测试用例，这可以的极大的提升测试效率。如图8示例模型，三个输入信号需遍历true/false的取值并进行排列组合，此时可使用基于状态机组合的方式，一键自动生成8条测试用例。 图8.基于状态机组合自动生成用例示例模型 图9.基于状态机组合自动生成测试用例 在实际的项目应用中，可以自由选择和搭配上述搭建测试用例的方式，满足功能测试的需求。多种自动生成用例的方法能够让测试人员“解放双手”，避免重复性工作，提高测试效率和质量。 有了测试用例，还需要针对测试对象编写合理的期望值，这个过程我们也称为测试评估。那么如何省时省力评估自动生成的测试用例呢？TPT为我们提供了解决方案，具体内容将在下篇介绍。 总结 本文借由基于模型的动态测试工具TPT带大家了解了测试对象、测试用例和动态测试这些术语的含义，并且介绍了TPT在编写和自动生成用例方面的优势。 敬请期待下篇：什么是测试级别和测试环境？以及TPT在不同测试级别和测试环境中有着什么功能？

A ssesslet s 是一种测试文档 的新 方法，它定义了在单 一 位置 进行 测试的预期结果，允许它们在多个测试用例中被重用。这节省了大量的时间和精力，并提高了准确性。然而，创建 A ssesslet s 可能非常耗时，并且它们可能不适合每个测试场景。团队应该根据具体情况评估其潜在的好处和缺点。 Assesslets 还可以作为测试数据生成的推动者，允许自动生成测试数据和高效有效的测试。总的来说，与传统的预期结果文档方法相比， Assesslets 提供了显著的优势，并且可以提高复杂汽车系统的可靠性和安全性。 简介 随着汽车行业的不断发展，对更高效的测试方法的需求也在不断增加。测试的一个最重要的方面是文档，特别是当涉及到预期结果的计算时。在传统的测试方法中，这个过程可能很耗时，而且容易出错。然而，随着 Assesslets 的引入，出现了一种测试文档 的新 方法。在本文中，我们将深入 阐 述 A ssesslet s 是什么、它的优点和缺点、如何减轻它们的缺点，并将对传统方法和预期结果文档进行比较。 什么是 Assesslets ? Assesslets 是记录测试中预期结果的一种独特方式。与传统方法不同，传统方法需要手动计算预期结果，作为比较步骤实现，并与测试用例一起记录，而 Assesslets 本身包含预期结果的定义。这意味着不必为每个单独的测试用例计算预期的结果，它 只需 被定义一次，然后 可以 在所有相关的测试用例中使用。 Assesslets 的 优势 Assesslets 最大的 优势 之一是它的效率。因为预期的结果被定义一次 即可 跨多个测试用例重用，所以没有必要为每个测试用例重新计算预期结果。这可以节省大量的时间和精力，特别是在多个测试用例需要相同预期结果的测试场景中。 Assesslets 还提高了预期结果文档的准确性。通过在单 一 位置定义预期结果，可以更容易地识别和纠正错误和不一致。另外，由于 Assesslets 可以链接到需求，因此可以快速识别需求的 变更 ，以更新相应的 Assesslets 。 Assesslets 的潜在缺点 Assesslets 的一个潜在缺点是，创建它们可能很耗时。在需求复杂而广泛的情况下，可能需要将自然语言需求形式化为形式化符号。这可能是一项重要的任务，特别是对于不熟悉 形式化 符号的 团队 。 另一个潜在的缺点是， Assesslets 可能不适合每种类型的测试场景。例如，在预期结果简单且易于计算的情况下，与传统方法相比， Assesslets 可能无法提供显著的优势。 减轻 Assesslets 的缺点 减少创建 Assesslet s 耗时的一种方法是使用一种可以将自然语言需求形式化为形式化符号的工具。 TPT 18 和 TPT 19 提供了此功能，允许将自然语言需求形式化到 TPT 中并进行自动检查。此外，一旦创建了 Assesslet s ，就可以跨多个测试用例和场景重用，从而在长期运行 中节省时间和精力。 在 Assesslets 可能不适合特定测试场景的情况下，根据具体情况评估潜在的优点和缺点是很重要的。在某些情况下，传统方法可能更合适，而在其他情况下， Assesslets 可能 会 提供显著的优势。 Assesslets 与传统方法的比较 在传统的测试方法中，预期结果是手动计算的，作为比较步骤实现，并与测试用例一起记录。这种方法可能很耗时，容易出错，并且难以维护，特别是在具有大量测试用例和预期结果的测试场景中。 Assesslets 为预期结果文档提供了更有效 、更 准确的方法。通过在单 一 位置定义预期结果并跨多个测试用例重用它， Assesslets 可以节省大量的时间和精力。 测试数据生成的 促成器 除了 针 对测试文档的 优势 之外， Assesslets 还可以作为测试用例生成的推动者。通过 Assesslets 描述被测系统，自动生成测试数据成为可能。由于预期结果已经在 Assesslets 中定义了，因此可以将生成的测试数据与预期结果进行比较，从而实现高效和有效的测试。这不仅节省了测试用例生成的时间，而且还确保了测试用例覆盖场景的全面范围，提高整体的测试覆盖率。 总结 在测试自动化领域， Assesslets 是一个强大的工具，它提供了一种简化的方法来定义和管理测试数据的期望值。与记录期望值的传统方法相比，它们提供了许多优势，包括改进测试用例 的 可维护性、减少重复工作和更容易 的 更新需求。然而，像任何工具一样，它们也有一些潜在的缺点，包括创建和维护 Assesslets 的初 期 时间投资，以及需要清晰和明确的需求来确保准确的期望值。 为了克服这些挑战，我们建议团队采用系统的方法来创建和管理 Assesslet s 。这包括定义清晰和明确的需求，为 Assesslet s 的创建和使用建立最佳实践，并定期检查和更新 Assesslet s ，以确保它们保持准确和最新。 与记录期望值的传统方法相比， Assesslets 提供了许多 优势 ，可以 导向 更高效 更 有效的测试自动化。通过将 Assesslets 与强大的测试自动化工具 ( 如 TPT) 结合使用，团队可以实现更精简 更 有效的测试自动化工作流程，从而帮助确保复杂汽车系统的安全性和可靠性。 Assesslets 还可以作为测试数据生成的推动者，允许自动生成测试数据和高效有效的测试。总的来说，与传统的预期结果文档方法相比， Assesslets 提供了显著的优势。 如果您正在寻找一种方法来改进测试自动化工作流程，并确保对汽车系统进行更准确、更有效的测试，那么我们强烈建议 您探索 Assesslets 和 TPT 的功能。有了这些强大的工具，您可以将测试自动化提升到一个新的水平，并在汽车软件开发项目中实现可靠性和安全性的新高度。

为什么要 在云 端 Linux 环境中 测试 Simulink 和 Targetlink ？ 它更快，可扩展，并且可以节省高达 60% 的成本。 测试总是需要三 个要素 ： 1. 测试对象 ， 即 要测试的东西 2. 用来刺激、测量和评估测试对象的基础设施 3. 测试用例，最好 能 产生有意义的刺激 测试对象是您想要检查的对象。如果您使用 Simulink 或 Targetlink ，则需要测试相应的模型。 测试的速度也取决于基础设施。要测试 Simulink 或 Targetlink 模型，您需要 TPT 、 Matlab 、操作系统、计算单元，如果有必要，还需要连接外围设备。 为了测试 MATLAB / Simulink 模型，需要 MATLAB 作为测试环境。如果您希望软件测试是高效和有效的， TPT 也是必不可少的。 然后 是操作系统和计算单元。对于操作系统，您可以选择 Windows 和 Linux 。但是测试在 Linux 上运行得更快。 因为在 Linux 中运行测试中断更少，内存消耗更少，等等。 重要的是模型的测试现在可以在 Linux 中 使用 TPT 19 和 MATLAB 运行。 如果在云中运行可 扩展性 测试，您可以获得更快的速度。为此，我们为 TPT 无头版 本提供 了一个 Docker 脚本。 Docker 将 为 测试 提供更多的优势。 而且 ，在 Linux 上测试 Simulink 模型也适用于虚拟机 (VM) 。在 AWS （ Amazon W eb Services ） 中 ，这些被称为 Amazon Machine Images (AMI) 。 在 VM 中做测试 的优点是，您不必立即编写脚本， 并 可以提前测试 映像 。 与 Windows AMI 实例相比， Linux AMI 实例的操作成本要低得多 ( 高达 60%) ( 参考 AWS 中 EC2 的价格 ) 。 您 已经有 TPT 的经验了吗 ？联系我们获取最新 T PT19 试用 。我们的无头版本可以 在 官网 下载 部分找到。 您 还不知道 TPT ？ 让我们展示给 您看 。 欢迎 联系北汇信息 获取更多 T PT 相关资讯。