标签: 测试用例

引言 测试是软件开发中的一个关键过程。为了确保软件产品的质量和功能，拥有结构良好且有效的测试过程是很重要的。在这种情况下， TPT 中的 状态机（ T estlet ） 已被证明是一种简化测试过程的有用方法。 什么是 状态机？ 状态机 是 TPT 中 封装了相关测试内容的容器。 它 可能是 —— 一个测试步骤， 一组步骤， 一个更全面的测试场景。 状态机 能帮助用户 通过将整个测试过程分解为更小、更易于管理的部分来 改进测试用例的组织 ， 简化测试过程。 举 个例子 如果您想测试 ECU 及其软件，有几个步骤和程序是必要的。首先， ECU 必须通电，以便为操作做好准备。这些操作与启动和登录 PC 类似 。为了达到这些前提条件的状态，必须描述各个测试步骤。但是由于这种情况在 ECU 的不同测试用例中一次又一次地发生，所以简单地描述一次是有意义的。在 TPT 中，这可以通过使用 状态机 ，然后在其他测试用例中重用它来完成。 其他测试用例使用 状态机 作为一种引用，然后再返回到该引用。在实践中，这个测试集可以被称为 “ 无错误初始化 ECU” ，并插入到各种测试用例中。 状态机 的优点 至关重要的是， 状态机 提供了一种单一 数据源的 方法。这意味着，如果测试过程由于需求和 / 或代码的变化而必须被调整，那么只有相应的 状态机 必须被更改。因此， 一些测试用例 不需要 进行 调整，这意味着维护方面的工作显著减少 （ 将测试工作减少到最低限度的 5 个秘密技巧 文章链接） 。 此外， 状态机 有助于更好地阅读和组织测试用例。通过将测试内容封装在逻辑容器中， 状态机 简化了测试过程，使其更容易理解和遵循。 由于 对测试的特定方面有明确的职责，团队协作 会 变得更加有效，因为它们可以很容易地分配和审查。 局限性及其解决方案 然而，在使用 状态机 时，重要的是要仔细管理所使用的 状态机 的数量，以免使整个测试过程复杂化。 此外，如果始终适当地定义 状态机 ，则可以避免测试过程中可能出现的冗余或不一致。如果 状态机 能够很好地适应软件产品的特定测试需求，那么测试就会成功。这样做的先决条件是对软件需求和测试目标的详细理解，以及对测试过程的清晰理解。 结论 状态机 是一种强大的工具，可以简化测试过程并提高整体软件质量。它们可以有效地与其他测试程序结合使用。 状态机 可以确保软件开发中的高产品质量和功能，同时减少测试所需的时间和精力。

汽车世界在不断发展，“软件定义的汽车”等新术语证明了软件对当今汽车的重要性。无论是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在不同测试级别和测试环境中有着什么功能？

对于一名汽车软件测试工程师，最关心的问题是如何高效完成产品测试。目前提高测试效率的方法主要有以下两个方向：一、提高测试建模的效率，最好能够实现“自动化”，并且测试用例能够复用于后续的SiL、PiL以至于HiL测试阶段。二、快速完成模型\代码覆盖度统计，并提升模型\代码结构覆盖度。TPT-TASMO，一款能够完美满足上述需求的神奇工具箱来了！ TASMO 的特性 TASMO 是T PT 中一个独立的 工具箱 ，能够 针对Simulink/Stateflow 、 TargetLink模型或C代码，基于 CC、DC、MC/DC 原则自动生成测试用例 、 进行 结构 覆盖度 统计 。 图1 TASMO测试用例自动生成 针对Simulink/Stateflow 、 TargetLink模型 、 C代码，自动进行模型或C代码 的结构 分析 ，确保测试完整性 自动生成测试用例，帮助 用 户节约大量时间和成本 用户可自定义测试用例的创建准则 提供详细的覆盖范围报告，包括测试集覆盖的以及未覆盖的 结构 支持 CC、DC、MC/DC 准则 应用一：自动生成测试用例 以灯控模型为例，在Simulink子系统中，分别有两个输入信号和一个输出信号，当开关处于ON或OFF状态时，头灯也随之打开或关闭；当开关处于AUTO状态时，头灯受到光照条件的影响打开或关闭。 图2 灯控模型 功能安全要求软件单元测试要进行基于需求的测试和接口测试，同时为了保证测试的完整性，还需尽可能满足结构覆盖度。TASMO的用例生成算法不断精进，同时利用静态分析技术，自动生成最少数量的测试用例来最大化遍历模型，满足上述要求的前提下还实现了“自动化”。用户只需要进行以下步骤： 点击 Generate Test Cases - for MATLAB/Simulink Models (TASMO) ，启动T ASMO 工具箱，选择当前测试的模型； 图3 TASMO界面-模型分析 点击 Input Specification ， 对输入 接口 的最大最小值、 步进长度、 信号组成方式进行配置 ，自动生成的用例会在配置的数值范围内实现遍历，覆盖接口测试； 图 4 输入信号配置 点击Coverage Goals Selection，选择生成用例的结构覆盖度目标，可选择CC、DC、MC/DC 准则 。以模型中的 O R 模块为例，如须满足 MC / DC准则 ，须包含如下情况： ①两个输入为false；②一个输入为true，另一个输入为false。T ASMO 可以分析出如下结构： 图5 灯控OR结构分析 图6 生成测试用例准则选择 点击 Generate，基于之前的配置一键生成测试用例。 图7 自动生成测试用例 测试用例生成完成后，只需根据功能需求逐条编写GUI评估，便可实现基于需求的测试。相比传统的测试方式，使用TASMO工具箱，不仅验证了模型设计符合功能需求设计，在测试建模效率上也得到了极大的提高。同时TASMO自动生成的测试用例也可以复用于后续的SiL测试，验证模型生成的代码是否符合功能预期。 应用二：模型覆盖度统计 TPT在统计结构覆盖度时提供了多种选择，对于模型测试，可以调用TargetLink、CTC++ for TargetLink和Simulink V&V工具统计结构覆盖度。除此之外，TASMO也具有统计结构覆盖度的功能 。 我们可 在MATLAB/Simulink平台配置中的TASMO Coverage Analysis选择覆盖度统计准则，无 需 集成 外部测试覆盖 度 工具，从而节省测试成本。 图8 覆盖度准则选择 TASMO会自动根据覆盖准则去分析模型结构，列出相应子层级下的关系运算符或逻辑块的输入和输出的组成情况，最后统计出当前运行的测试用例或测试用例集的覆盖情况，并在测试报告中展示出覆盖度详情页。 图9 模型覆盖度报告 应用三： C 代码覆盖度统计 TASMO工具箱不仅可以统计模型的结构覆盖度，对于C代码也同样适用。 在C/C++ Platform选择TPT Coverage，即可使用TASMO生成C代码的测试数据，统计当前测试用例或测试用例集的结构覆盖度。同样地，可选择CC、DC、MC/DC准则作为统计标准。 图10 C Platform覆盖度准则选择 如下图所示，测试报告展示了覆盖度详情页。点击link查看C代码的具体覆盖情况，对未覆盖的代码语句进行标红高亮显示，包括语句true和false的覆盖次数，帮助定位问题和基于覆盖度结果补充测试用例。 图 11 C代码覆盖度报告 图12 C代码覆盖度报告详情页 小结 本文介绍了TPT-TASMO在自动生成测试用例和统计模型/代码覆盖度方向的应用，帮助我们更高效、更完整地完成软件测试，节约测试成本。同时随着越来越多的小伙伴开始关注形式化需求，在TPT19中即将推出基于TASMO生成形式化需求的测试用例，我们诚邀您一起来体验TPT19强大的测试功能，敬请期待！

目录 软件与车辆：高度复杂 测试对象，测试用例和动态测试 测试级别 测试环境 无论是 MiL 、 SiL 、PiL、 HiL 、单元测试、软件测试还是集成测试: 汽车软件测试的世界 有 很多技术术语，所以可能会 出现 两个人在同一个术语 下理解 不同的 情况 。误解可能会发生，使有效的合作变得困难——我们也知道类似的情况。让我们把事情弄清楚一点，从头开始讲。 汽车世界在不断发展，“软件定义的汽车”等新术语证明了软件对当今汽车的重要性。 在发展过程中，以前纯粹的机械领域逐渐扩展到包括软件和数字功能。汽车的功能和行为现在几乎完全是通过软件来实现的。伴随着这一点，当人们谈到软件时，测试也会立即被提及。但是为什么是软件和测试呢? 软件也只能在车上的硬件上运行，它们一起组成了一个ECU(电子控制单元)。这些车辆配备了多达150个 ECU ，大约有1亿行代码(LOC)。 ECU 之间相互通信和交互，以实现车辆的特定功能，并使其对客户 具象化 。 有这么多编程代码，还能出什么问题? 让我们来看一个客户可以直接体验的车辆功能示例:在仪表盘中显示交通标志。 它是这样工作的: 照相机拍摄照片并对其进行评估。 检测到的交通标志被传达到一个显示控制单元，并 进行 可视化。 此信息同时传递给其他控制单元上的其他功能，并进行处理。 所有传感器、执行器和控制单元的连接被称为网络架构，该架构至少需要三年的时间来开发一辆汽车，直到准备好量产。所有传感器、执行器和控制单元之间的正确交互自然会塑造车辆的功能和质量。为了测试正确的交互作用，必须在多个阶段重复和迭代地测试车辆。 最大的挑战是，汽车的部件往往更多地是作为产品而不是作为项目来开发的，因此，来自几个公司和部门的许多人都参与到汽车的创造中来。 总之，这意味着汽车的开发比人们最初想象的要复杂得多。这一方面是由于组织框架条件，另一方面是由于大量的系统组件具有软件内容。复杂性进一步增加，因为可以通过几个系统组件的 交互来 体验功能。 为了弥补这一切，需要对车辆进行许多测试。测试什么，具体地说，在哪个测试级别上，以及如何进行测试 会在后文中提到 。 什么是测试对象或被测试系统? 测试对象、被测系统和测试元素通常是同义词。根据ISTQB，一个测试对象被非常一般地定义为“待测试的工作产品”。因此，测试对象可以是 ： 一个单元 几个软件部分 的集合 ， 一个完整的软件程序， 一个控制单元， 几个控制单元组成的网络， 一整辆车， 任何其他被测试的对象 在下文中，我们将术语“测试对象”和“被测试系统”同义地用于要测试的所有内容。 什么是测试用例? 一个测试用例总是至少包含以下两部分信息: 1 . 定义如何刺激测试对象的测试数据。 2 . 测试对象的期望值，它定义了测试对象在模拟过程中应该假设哪些计算/状态。 而且 可以 选择 用进一步的相关信息来丰富测试用例。测试对象“ECU”的典型前提条件:ECU处于唤醒状态并准备接收消息。 测试数据和期望值是所有测试级别的测试用例和以这种形式执行的测试用例所需要的。期望值是由各种各样的信息来源给出的——也称为测试预言。测试 预言 可以是现有的系统(作为基准)、规范或个人的专业知识。在任何情况下，被测试的代码都不应该作为信息的来源。 什么是动态测试? 动态测试是测试对象的执行。大多数人将测试与动态测试联系在一起。 在动态测试中，创建并执行测试用例，用测试数据刺激测试对象。刺激导致测试对象要么执行计算，要么改变其状态。在动态测试中记录测试对象的反应，并与期望值进行比较。如果反应与期望相等，则认为测试用例已通过。如果不相等，就认为失败了。 与动态测试相对的是静态测试。在静态测试中，测试对象不是模拟的，而是静态分析的。静态测试的一个例子是源代码文件的审查。 什么是测试级别？ A SPICE间接地将测试级别分配给它的过程模型，并 包含 以下五个过程: 1 . 软件单元验证(SWE.4) 2 . 软件集成与集成测试(SWE.5) 3 . 软件 资质 测试(SWE.6) 4 . 系统集成与集成测试(SYS.4) 5 . 系统 资质 测试(SYS.5) 当根据ASPICE进行分配时，应该注意 ： 流程期望更多的活动而不仅仅是动态测试。 但是测试用例实际上是在哪个测试级别上执行的，目的又是什么?我们从最小的层 级 开始:编码。这些是最早可以测试的测试对象。 软件编程之后是与开发相关的单元测试。它们也被称为模块测试、功能测试或单元测试。在单元测试中，测试最小的软件组件，即单元 。 单元经常变化，因此单元测试必须经常调整、补充并再次执行。单元测试有两个主要目标: 早期质量保证 快速检测代码更改中的交叉影响 单元测试通常是软件开发中首先自动化的。 因为软件或软件组件是永久地 调整 和更改的，所以在持续集成方法框架内的一致性是非常有用的，并且已经建立起来了。无论测试级别如何，测试的重复总是被称为回归测试，并且在ASPICE中，软件单元验证是必需的。实现回归测试的最简单方法是自动化测试并在持续集成环境中执行它们。 单元测试之后是软件集成测试。集成是单个软件组件的组装及其测试。这里的重点是软件组件之间的兼容性。集成测试通常分几个阶段进行。根据整个软件的程度，在几个中间阶段到几百个中间阶段之间提供集成测试。中间阶段的数量和选择最终取决于软件体系结构和软件设计 。 元素和级别越多，集成测试的中间阶段就越多。 通常，集成测试是自底向上开发的，首先相互集成和测试几个单元(大约3-5个)。然后，所得到的复合 体 与其他已经测试过的复合 体 或其他单元集成在下一个中间阶段，并再次测试。这个迭代 链一直 持续到ECU的整个软件被构建和测试完毕。 大量的集成测试一开始听起来工作量很大，但它有一个明显的优势，就是可以更快更好地发现错误。在我们的经验中，在集成测试中建立一个额外的中间阶段所需要的工作， 可 在最初建立测试阶段时，通过减少创建测试用例所需的工作来得到补偿。 还有什么是支持集成测试的? 发现的错误可以更容易地缩小到其原因，从而大大简化了分析。 最重要的是: 经验表明，大多数软件错误都是在集成测试中发现的。 对于那些还不相信的人来说，任何持续集成方法都提供了这些测试阶段。 集成测试完成后，软件测试紧随其后，软件测试通常在目标硬件上执行。软件测试中的测试对象与集成测试中的最后一个测试对象相同:它是完全集成的软件。然而，它们各自的目的将两个测试级别彼此区分开来。 1. 集成测试的目的:检查软件组件之间的兼容性。 2 . 软件测试目标:检查软件是否符合要求，例如与传感器和执行器的兼容性， 3 . 信号处理 4 . 软件行为改变参数等方面 软件测试之后是进一步的集成测试。但是，这一次不是在软件级别，而是在系统组件级别。该过程与软件集成测试相同。ECU与一个或多个传感器或执行器一起测试，然后一点 一点 地添加其他组件，直到系统就位。 最后的测试在系统测试中进行。在此过程中，将所有系统组件集成到一个系统中并进行测试。系统测试的重点是确定是否符合系统需求和系统的可交付性。 在汽车开发中，现在有一些额外的组织挑战，例如: 什么是系统? 对于汽车OEM来说，它就是一辆车。但是，提供子系统(如动力系统或软件组件)的供应商如何回答这个问题呢? 在这 种情况下，必须为测试阶段更紧密地指定测试对象。 从合同的角度来看，还有一个进一步的测试阶段: 验收测试，由客户进行。从合同的角度来看，验收是对开发(软件、硬件、系统等)符合合同标准的声明。验收合格后，剩余款项到期，保修开始。 什么是测试环境？ 测试环境就像测试对象及其参与者的训练场。它应该尽可能接近真实的生产环境，以便测试在与其他玩家、状态和信号 交互时 的重要性尽可能高。 在这种情况下，经常会讨论 在环 测试，例如 模型在环（ Model-in-the-loop ， MiL ） 软件在环（ Software-in-the-loop ， SiL ） 处理器在环（ Processor-in-the-loop ， PiL） 硬件在环（ Hardware-in-the-loop ， H iL ） “in- in- loop”之前的术语代表测试对象的类型。“在环”指的是测试对象与模拟生产环境的组件之间的一种特殊类型的交互。在“ 在环测试 ”中，环境对测试对象的状态和计算做出反应。因此，这些测试与开环测试相反，开环测试没有模拟环境的反应。 与开环测试相比，“在环测试”的优点是更接近真实的生产环境。但是，在 环环境 的设置更加复杂。 在汽车环境中，开发通常是基于模型的。大多数模型是用MATLAB/Simulink或 TargetLink 创建的。这些模型通常在开发环境中直接以单元和软件集成测试的形式作为 模型在环 ( MiL )进行验证。 这种类型的动态测试可以发现控制策略和逻辑中的错误。嵌入式系统的仿真是在同样 仿真 的环境模型中执行的。这种非常早期的测试的优点是可以快速检测到模型构建中已经存在的错误，并有可能对其进行修正。 在 软件在环测试（ SiL ） 中，测试代码是在PC上测试的。这要么是手写的，要么是从模型生成的。这两种代码的作用域是不同的。 1 . 测试生成的代码:检查代码生成器是否正常工作。生成的代码的功能应该尽可能接近模型。 2 . 对于手动代码， SiL 是第一个可能的测试级别。与 MiL 一样，目标是在早期阶段发现错误。 SiL 用于测试阶段的单元测试、集成测试，在某些情况下也用于软件测试。硬件在这个阶段还不适用。 在 SiL 中测试的代码不能在嵌入式ECU上执行。为了执行，必须为目标处理器编译代码。在这个过程中生成的代码可以通过两种方式进行测试: 1 . 通过一个评估板与 有 未来目标环境的处理器。 2 . 在PC上模拟处理器的虚拟环境中。 在这两种情况下，都提到了处理器 在环 (PiL)，实际上是指为目标处理器架构构建的软件测试。严格地说，测试阶段因此也可以称为目标软件在环。 处理器在环测试的主要目标是检测编译器错误，或者在软件组件非常接近硬件的情况下，例如驱动程序或执行器的控制，在早期阶段检查硬件和软件组件的兼容性。 下一个逻辑步骤是测试硬件: 也就是说，在带有外围设备的物理ECU上完成软件。现在的重点是输入和输出、通信总线和其他接口如何实时交互。这种 测试 的术语是硬件在环( Hardware-in-the-Loop ， HiL )。 HiL 测试从ECU开始，可以实现到系统网络级别。 HiL 试验台 架 可以 对整车进行测试， 但设置 和操作成本相应较高。尽管如此，他们还是很成熟的，因为进行手动车辆测试也很昂贵，而且更费时 。 在车辆测试中，ecu、执行器和传感器组件在最终目标环境中进行测试。车辆大多在寒冷、温暖和炎热地区的不同环境条件下进行测试。即使在今天，这些测试也主要是手动执行的。在某些情况下，测量结果会被自动记录，然后在工具的帮助下进行评估。这个测试阶段发生在每个OEM。要进行车辆测试，车辆及其所有部件必须可用。然而，由于手动测试需要训练有素的司机和车辆，测试的可扩展性较差。 总结 术语和信息的密集使得一件事很清楚: 背景知识、过程和项目之间的沟通是有效和高效地开发、测试和成功实现嵌入式系统的关键。 在汽车软件测试中，有许多方法和方法，在我们看来，没有对与错，而是有利与不利。当然，这取决于各种参数，涉及的组织，最终取决于一起工作的人。 我们是早期测试的支持者，我们建议直接从单元测试级别开始。进一步说到集成测试，可以测试不同的功能以获得开发的直接反馈。所有这些都导致了快速、合作的产品开发。

前言 汽车ECU（动力域、底盘域、ADAS、电子电器等）的研发最后一个阶段测试往往为ViL（车辆在环）测试，为确保产品的功能和性能正常，通常需要大量的测试。 一般的ViL测试过程 在涉及到发动机、变速箱、底盘等需要特殊场地和驾驶要求的控制器测试时，往往我们需要专业试车员和测试人员一同配合完成。 测试人员整理测试用例（excel、word），使用总线监控设备（如Vector公司的CANoe和VN1640A）连接整车，由试车员按照编写好的测试用例执行，采集整车报文数据，测试人员在测试完成后进行评估。 整个测试过程主要存在如下不足： 编辑的测试用例可能需要翻译成中文，影响测试效率 测试用例不能实现语音输出及可视化 试车员忘记了下一步测试步骤是什么 测试人员需要编辑大量测试用例，所需时间较长 人工判断和评估效率不高 整理报告时间太长 …… TPT Autotester-ViL测试过程 测试人员在TPT中编写状态机测试用例和Assesslets评估，通过FUSION平台的CAN接口访问其他的CAN通信及标定软件（如Vector公司的CANoe、CANape或ETAS公司的INCA）来实现与实车的通信 。 在测试过程中，试车员根据中文语音提示进行操作，通过Autotester界面获取测试信息，软件自动检测车辆状态是否达到预期，并在测试完成后，根据Assesslets进行评估，并且自动生成测试报告。 图 1 TPT Autotester-ViL测试过程示意图 我们来具体了解一下TPT Autotester的特性和功能： 高效且 灵活多样的状态机测试用例 无论多复杂的测试用例都是按照先后顺序执行的，状态机测试用例可以清晰的将测试的各个阶段及转移条件展现出来。 下图中，状态机表示测试的各个阶段，状态转移线表示各个阶段的转移条件，只有满足线上的条件时，才能进入下一个测试阶段。 80%），才能进入阶段3。 状态机表示当前测试进行到的阶段在测试的某一阶段，判断信号是否达到期望值。比如，阶段3到阶段4，发动引擎，使用Compare判断转速（也可使用 Assesslets评估） 状态转移线上可以编辑一个或多个条件，编辑其他测试用例时选择不同状态即可状态转移线上的名称能够语音输出，提示试车员操作转移线上的条件支持自定义图形化显示 图 2 状态机测试用例 测试用例支持 简体 中文显示及中文播报 Autotester测试用例中的状态机和转换条件名称均能支持简体中文显示，并且，转换条件名称支持中/英文语音输出。试车员只需按照中文语音提示操作即可，无需查看测试用例。 图 3 切换中文（简体）/英语（美式）语音输出 图 4 状态机测试用例测试过程 注：状态转移线名称用以语音提示 支持信号名称及图像自定义 TPT Autotester支持信号名称和图像自定义功能。 Auto Tester Setup中： “Name”指Autotester界面中的信号名称 “Channel”对应的是导入TPT中的信号名称（dbc中的信号名称） 每个信号右侧对应的“Icon Path”可以为每个信号自定义图像。 图 5 Autotester中定义的信号 图 6 信号对应的图像 支持设置 测试开始前的 初始条件 在Auto Tester Setup中，可以设置测试开始的初始条件（Option），Precondition test case中选择的测试用例会被首先执行并评估，只有当Precondition中的测试用例通过时，才能执行其他测试用例。 比如，工程中选择Precondition test cases测试用例为Precondition， 测试用例含义为检测钥匙状态是否为Power On档位，只有当钥匙在Power On档，测试用例才能从“初始化”到“阶段1”，并且评估引擎转速是否<900rpm/min。只有Precondition测试用例通过，才能执行其他测试用例。 规避偶然因素 在实际ViL测试过程中，经常会受到环境的影响，为了避免偶然因素，可以设置测试用例忽略或者重复的次数。 比如： 设置MaxIgnoreConsecutiveFails的数值为2，含义为最大忽略连续失败的次数为2次 如果测试用例执行了3次，前2次失败，但第3次通过，则最终结果为通过。 设置MinConsecutivePassed的数值为2，含义为最小连续通过次数 如果测试用例共执行3次，第1次失败，后2次通过，则最终结果为通过。 MaxTestRun，含义为最大测试用例执行次数 一般情况下：MaxTestRun=MaxIgnoreConsecutiveFails+MinConsecutivePassed。 例如： 测试用例Shift Gear 3 to 4，为了避免然因素，需执行5次后才能判定最终结果，图中只执行了1次。 测试数据自动保存，报告自动生成 测试完成后，数据会以blf格式保存在zip文件中 评估完成后，右键打开测试报告（报告支持自定义） 通过以上步骤，进行ViL测试时，试车员根据语言提示操作即可，测试完成后当场即可进行评估，并自动化生成报告，提高车辆在环测试效率。 Piketec 公司简介 PikeTec公司是全球知名的基于模型的嵌入式系统测试工具TPT的软件供应商，总部位于德国柏林，其创始人均在戴姆勒公司拥有十多年的软件测试经验。TPT作为针对嵌入式系统的基于模型的动态测试工具，支持众多业内主流的工具平台和测试环境，可应用于整个嵌入式软件开发周期，实现各种异构环境下的自动化测试。无论是在测试建模，测试环境还是测试评估，测试报告方面，都占据强大优势。 北汇信息作为PikeTec的中国合作伙伴，将帮助中国客户借助TPT提升嵌入式控制系统的开发效率。