标签: 单元测试

在项目开发的前期针对软件单元/模块功能开展单元/集成测试，可以尽早地发现软件Bug，避免将Bug带入系统测试阶段，有效地降低HIL测试的测试周期，也能有效降低开发成本。单元/集成测试旨在证明被测软件实现其单元/架构设计规范、证明被测软件不包含非预期功能。经纬恒润测试团队拥有丰富的研发经验、严格的流程管控，依据ISO26262/ASPICE等开展符合要求的 单元/集成测试 工作。 ISO26262功能安全对于单元/集成测试的要求 ISO26262中对于单元/集成测试的要求涉及到测试用例设计方法，如基于需求/故障注入、测试覆盖度如语句覆盖/分支覆盖/调用覆盖等多方面，具体要求详见表格。 软件单元验证方法 软件单元用例设计 软件单元测试覆盖率 软件集成验证方法 软件集成测试用例设计 软件集成测试覆盖率 测试方案 依照ISO26262功能安全对于单元/集成测试的要求，使得代码符合硬件-软件接口规范要求、确保被测模块的功能完备性、防差错性以及故障处理功能、验证模型行为与代码行为的一致性；满足功能安全对单元/集成测试覆盖率的要求可以评估模块功能完整性、证明无非预期功能和孤立模块等。 单元测试方案 集成测试方案 嵌入式环境PIL测试方案 根据ISO26262对代码级单元测试、集成测试要求，针对不同的用户， 经纬恒润 提供定制化的咨询服务，主要包括：测试过程能力建设、测试技术咨询、测试工具链建设、第三方测试服务等。 了解更多： 请致电010-64840808转6117或发送邮件至market_dept@hirain.com（联系时请说明来自面包板）

CoverageMaster winAMS : 适用于嵌入式目标机代码的单元测试 / 集成测试 工具 全面支持嵌入式微机！验证嵌入式 C/C++ 软件 实施以模块为单位的自动化单元测试工具 不需要 HookCode 直接使用目标机代码进行单元测试 联合静态解析工具 ，提供 C0 （语句） ,C1 （判定） ,MC/DC 覆盖率报告，优化测试用例制作 已取得第三方认证机构 TUVSUD 对适用于汽车机能安全 ISO26262 软件工具的认证 产品概要 是以嵌入式软件的函数为单位，实施模块单元测试以及 C0/C1/MCDC 覆盖率测试（ coverage test ）的嵌入式软件自动化单元测试工具。目标机源代码通过交叉编译器生成目标机执行代码，通过跟实际处理器同样的模拟处理器环境进行单元测试，不需要对执行代码做任何变动，使高信赖性的模块测试成为可能。在汽车控制软件这样的对安全性要求极高的领域，单元测试已经成为不可缺少的一部分。使用目标机代码进行单元测试也是为了符合汽车行业中 ISO26262 功能安全认证标准。 产品特长 全面支持嵌入式微机！验证嵌入式 C/C++ 软件 实施以模块为单位的自动化单元测试工具 作为能够检验出仅凭系统测试以及整体测试无法发现的 的检测方法， 在嵌入式开发领域受到广泛重视。同时，单元测试也是汽车用软件功能安全（ ISO26262 ）领域中要求实施的认证项目之一。 直接使用通过交叉编译生成的目标机代码，在模拟处理器环境下进行单元测试。既能实现 C 语言程序的逻辑上的单元验证，又能够对嵌入式微机组装为产品后可能发生的问题等进行具有高信赖度的白盒（ white box ）测试。 不需要 HookCode 使直接使用目标机代码进行单元测试成为可能的业界唯一的工具 有些公司的单元测试工具往往采用在被测试对象的源代码中追加测试用代码或者测试用驱动器的方法，导致测试时所用的代码与组装为产品后的目标机用代码不同。虽然 ，但是从嵌入式开发的角度考虑，这样就如同对交叉编译所生成的经过优化处理的代码进行了加工，无法确保最终产品的质量。 Coverage master winAMS 是业界唯一的，具有 实施单元测试功能的工具，特别是在安全性要求高的领域中得到很高的评价。 不需建立单元测试专用的环境，可以在开发用交叉编译环境进行单元测试 Coverage master winAMS 不需要追加任何测试用驱动器或测试用代码，可以直接使用将组装成产品的目标代码进行单元测试。单元测试能够与软件开发使用共同的交叉编译环境，不再需要对测试资源进行专门管理，也不再需要建立其他专用环境。因此，既方便程序资源管理，又能够缩短准备测试环境所需的时间。 符合汽车功能安全标准（ ISO26262 ） 这一要求的最佳工具 ISO26262 是从 IEC61508 衍生出来的适用于汽车制造领域的功能安全标准。其中的 Part.6-9 包括了关于软件程序的构造覆盖率测试以及有关的规定项目。根据汽车安全标准（ ASIL ），提出了测试语句覆盖率（ statement coverage ），分支覆盖率（ branch coverage ）， MC/DC 覆盖率的推荐性事项。 其中的另一个推荐性事项是 的规定。如果在与目标环境不同的环境下进行单元测试，必须表明源代码与目标代码的差别，以及目标环境和测试环境的差别。因此，对于那些使用与目标微机不同的电脑进行编译和单元测试的其他公司的工具而言，这个要求很难满足。 还有些公司的单元测试工具虽然包括交叉编译环境及编译功能，而且也能够在与目标环境相同的环境下进行测试，但是所有的测试都需要插入测试用代码，进行再次编译，因此测试也只能在与目标环境不同的环境下实施。 GAIO 提供的单元测试工具 Coverage master winAMS 具有 ●采用全面支持嵌入式微机的微机化功能测试平台环境 ●不需要插入测试用代码直接使用目标机代码进行测试 的特征，提供符合 ISO26262 标准要求的必须功能。 GAIO 提供的 Coverage master winAMS 是符合 ISO26262 标准 这一要求的业界唯一的工具。 关于汽车机能安全 ISO26262 的对应以及认证的获得 已取得第三方认证机构 TUVSUD 对适用于汽车机能安全 ISO26262 软件工具的认证 2012 年 6 月 28 日，「 Coverage master winAMS / General 」测试工具获得由德国 TUVSUD 第三方认证机构，在汽车机能安全规格的 ISO26262 软件工具方面的认证，包括日本在内亚洲地区首次获得该项认证。 通过此项认证，说明本公司的单元测试工具「 Coverage master winAMS / General 」，以及程序分析工具「 CasePlayer2 」，在静态分析和单元测试领域，是符合所有安全度水准的工具，并由 TUVSUD 认证机构得到了保障。 ISO 26262 对于不同的开发用软件工具在工具置信水平（ TCL ），都需要开发者提供开发软件工具的认证书。此项认证适用于在工具认证当中，最为复杂的 TCL3 工具认证标准。因此，导入本公司的单元测试工具之后，不需要对 TCL 的部分进行认证，进而可以缩减手续跟时间。 主要的单元测试功能 采用 SSTManager 管理单元测试 project SSTManager 是 Coverage master winAMS 的应用功能，用于管理单元测试 project ，制作测试数据（ test data ）。 从设定测试环境开始，到报告测试结果为止，均由微机化功能测试平台（ ISS ）实施综合管理。 采用通用便利的 CSV 文件管理测试数据的输入输出 Coverage master winAMS 不需要插入测试用代码，直接使用目标机代码进行单元测试。采用通用便利的 CSV 文件管理函数测试时使用的输入输出数据。测试结束后，输出的测试结果和输出的期待值也将以相同的格式显示在 CSV 文件之中。 C0/C1 覆盖率报告的自动化制作功能（标准功能） 根据测试的输入输出数据自动报告相应源代码的 C0/C1 测试覆盖率结果。包括通过图形（ viewer ）显示测试数据，以及与其相应的被测试的源代码路径的功能，用于分析测试结果。 作为选项功能也包括MC/DC 覆盖率测试功能。 MC/DC 覆盖率的自动化测试功能（选项功能） 作为选项功能提供 MC/DC 覆盖率测试功能。 C0/C1 覆盖率测试不需要加工即可直接使用目标机代码。然而， MC/DC 覆盖率测试对于复合式的条件式，需要自动插入 HookCode 将复合式的条件式分解，才能对各条件式进行测试。这样就有可能导致测试用代码与目标机用代码的不同。为了验证 HookCode 的妥当性，在 MC/DC 覆盖率测试的同时，运行目标机代码，确认运行结果与期待值的一致性。 注 : 右图举例显示，第 2 个 if 句的复合条件式中， 30] 为 false 时的分支没有被测试到。以 C1 覆盖率测试来说，它的测试结果是 OK ；而对于 MC/DC 覆盖率测试来说，它的结果是 NG 。 注 : MC/DC 覆盖率测试功能不支持 C++ 程序。 单元测试的效率化功能 联合程序解析工具 CasePlayer2 ，实现代码参照解析作业的效率化 利用 CasePlayer2 生成的流程图表以及模块构造图（调用函数的构造图）与源代码的连接（ link ）功能，使单元测试用源代码的解析工作效率化。 能够自动检索被测试函数的外部变量，使测试条件设定效率化 联合程序解析工具 CasePlayer2 ，自动检索被测试函数所使用的外部变量。缩短了以往必须对源代码进行搜索找出输入条件的变量所需的工作。而且，能够防止人工操作导致的类似变量指定遗漏的的错误。 根据代码解析自动化制作 C0 ， C1 ， MC/DC 覆盖率测试计划 联合程序解析工具 CasePlayer2 ，自动化制作符合覆盖率测试要求的条件分支 if,switch,for,while 等的测试数据。可以将被测试函数中含有的条件式（ if 以及 switch 等）在数据制成图形 (Viewer) 上列表显示。 点击其中的条件，工具将自动开始检索与之相关的变量，进而从所设置的条件的境界值中自动生成覆盖率测试所需要的数据。 为了达到 C1/MCDC 覆盖率，测试时需要对各函数的数据进行组合。 利用 CasePlayer2 提供的解析结果，分析条件式的 net 构造，在重复性限制在最小限度下生成 C1/MCDC 覆盖率测试用数据。 支持 MPU 　 CoverageMaster winAMS Supported Processor List(English) 动作环境 ・ 操作 PC/OS ・ IBM PC/AT 兼容机 ・ Pentium( 相当 ) 2GHz 以上的 CPU ・ 存储器 512MB 以上（推荐值） ・ 显示器分辨率 XGA(1024*768) 以上（推荐值） ・ Windows XP, Windows Vista, Windows 7 （ 32bit/64bit ）（※ Windows 95/98/Me/NT/2000 未支持）

背景介绍 随着汽车行业的迅速发展，车载代码量以及复杂度不断飙升，如何保证软件的安全成为车辆功能安全迫切需要解决的问题。所以，在软件代码的开发过程中，为降低软件风险，提高代码质量，我们需要对代码实施静态测试和动态测试。 静态测试可以不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性以及对编码规范的遵循程度， Helix QAC 就是这样一款权威的静态测试工具，可以实现代码的自动化检测。 而我们今天要介绍的 VectorCAST 是一款权威的动态测试工具，通过实际的运行被测试程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符合。下面我们就来具体认识一下这款动态测试工具。 VectorCAST 简介 VectorCAST 是 Vector 公司旗下的一款代码测试工具，主要为嵌入式系统提供高度自动化的代码动态测试解决方案，尤其适用于对自身有高安全性和高可靠性要求的行业，比如汽车电子、航天航空、轨交医疗、工业控制以及物联网等领域。 在认证方面， VectorCAST 通过了南德 TÜV 认证，遵循相关的行业认证标准，比如 ASPICE ， Do178B, ISO26262 ， IEC61508 ， En50128 和 IEC62304 等，并提供了对应认证标准的验证包。 图 1 南德 TÜV 认证 VectorCAST 是主要用于 C/C++ 程序的自动化测试软件，能够运行在 Windows 和 Linux 等多种开发环境。 VectorCAST 基于 V 模型开发，实现了与 RAD 模型的丰富集成，在功能上覆盖了需求分析、单元测试、集成测试、覆盖率分析以及回归测试等软件项目测试所涉及的各个环节，同时也涉及了部分系统测试的功能，它最大的特点同时也是相比于其它同类工具最大的优势，就在于最大程序的自动化和更适合用于嵌入式环境。 针对客户不同的代码测试需求， VectorCAST 为客户提供了对应的解决方案，主要包括 VectorCAST/C++ 和 VectorCAST/QA 。其中， VectorCAST/C++ 主要用于代码的动态单元测试和集成测试，而 VectorCAST/QA 主要用于代码的系统测试，下面为大家详细介绍一下以上两个测试工具。 VectorCAST/C++ VectorCAST/C++ 是 VectorCAST 工具集中的动态单元测试和集成测试工具，适用于 C 和 / 或 C++ 语言，嵌入式开发人员使用它来验证安全和业务关键型嵌入式系统，可以显著降低测试过程中所必需的时间、工作量及成本。 VectorCAST 中的单元测试，实践中是以一个源文件作为被测对象，实际测试是基于源文件中的函数进行测试；而集成测试，测试的是一个模块，测试函数之间的接口，以验证功能为目的。 那 VectorCAST/C++ 是如何工作的呢？ VectorCAST/C++ 首先分析被测代码，然后调用代码生成器根据测试要求去自动构建一套完整并可执行的测试组件（ Test Harness ），这个测试组件中包括被测对象、测试驱动、桩函数和依赖条件，如图 2 所示。一旦测试组件被成功构建，用户可以使用 VectorCAST/C++ 构建和执行测试用例，显示代码覆盖信息并生成测试报告。 图 2 Test Harness VectorCAST/C++ 可以实现哪些功能呢？ 基于需求分析的测试 VectorCAST 可以与多种在线需求管理服务器比如 Polarion/DOORS/PTC/IBM 或者本地需求文档实现联调，导入测试需求，并链接 VectorCAST 测试用例，确保每条测试需求都能被测试用例覆盖，并管理每个需求对应的测试用例正确执行，实现测试用例和测试需求的双向追溯。 图 3 VectorCAST 需求管理服务工具 代码覆盖度分析 在测试过程中，如果没有代码覆盖工具，源代码的哪些部分被执行是很难确定的。 VectorCAST/C++ 提供集成的代码覆盖分析工具，在单个或者多个测试执行中，提供关于源代码语句的报告，为用户指明代码覆盖信息。 在源代码中，通过颜色标注代码的覆盖状态： 红色代表代码未被覆盖 黄色代表代码被部分覆盖 绿色代表代码被覆盖 在报告中，根据覆盖度需求，可通过颜色和百分比的方式统计多种测试覆盖率，包括 Statement （语句覆盖）、 Branch （分支覆盖）和 MC/DC 覆盖，如下图 4 所示。 图 4 VectorCAST 覆盖率统计 自动创建测试用例 自动创建测试用例不仅体现在 VectorCAST 支持用户以多种形式的输入输出参数自动生成测试用例，不需要用户编写测试代码，完全通过 GUI 窗口自动完成参数设定，还体现在可以基于不同的覆盖度需求自动创建测试用例，尽可能地达到覆盖度要求，包括基本路径、等价类、边界值和 MC/DC 测试用例。 对于未能覆盖的部分，用户可以根据工具提供的逻辑分析报告，自行添加少量测试用例即可达到 100% 的覆盖度。 说基本路径覆盖， VectorCAST 自动生成的测试用例可以达到 90%~100% 的覆盖 率对于 MC/DC 覆盖度， VectorCAST 会基于 MC/DC 覆盖度去分析代码结构，自动生成等价的 MC/DC 真值表，如下图 5 ，用户可根据 MC/DC 真值表去分析代码结构并创建测试用例 图 5 MC/DC 真值表 VectorCAST/RSP— 实时嵌入式测试 VectorCAST/RSP 是 VectorCAST 的工具套件中的实时支持包，支持在嵌入式目标板或是仿真器上直接进行实时应用测试，交叉编译生成可在目标板或仿真器上执行的测试组件，自动下载测试组件和测试用例到目标板执行，并将测试结果反馈到主机平台上，如图 6 所示。 图 6 VectorCAST/RSP 测试机制 VectorCAST 软件本身安装了 MinGW 编译链，同时支持业内最多种类（ 300+ ）编译器和目标芯片（比如 ARM ， CodeWarrior ， Green Hills 等），利用产品实际编译链进行编译测试，实现虚拟的 PIL 测试。 回归测试 所谓回归测试，就是旧代码修改之后，重新进行测试以确保修改没有引入新的错误或者是导致其他代码产生错误。 VectorCAST 具有强大的回归测试的功能，可通过 GUI—Incremental 或命令行的方式定期的执行测试用例，以增量的方式重构测试环境，检查代码变更，只执行被影响到的测试用例，节约项目测试时间，降低项目版本维护的成本。 图 7 回归测试报告 除了上述功能外， VectorCAST/C++ 还： 支持工具界面操作的故障注入、局部变量打印、断点调试 支持单步回放测试用例执行，分析代码覆盖和代码调试 支持 CSV 数据导入，批量生成测试用例 支持头文件、目标 / 库文件测试 支持对于无法通过测试用例覆盖的代码实行手动覆盖的方式（ CBA 功能） 可以与 Jenkins 联调，通过 Jenkins 构建测试工程，实现持续集成开发 / 测试 VectorCAST/QA VectorCAST/QA 主要用于嵌入式开发的自动化系统测试，为白盒系统测试提供了一个集成的工作流程。 VectorCAST/QA 通过集成用户软件编译 / 构建环境和已有的测试基础架构，进而获取软件在系统测试中的关键指标，如代码复杂度、代码变更频率、测试用例状态和代码覆盖度等。 VectorCAST/QA 的主要特点如下： 在系统测试期间自动捕获和维护代码覆盖率数据，从而帮助用户快速识别未被测试的部分，并确定提高测试完整性所需的资源 基于变更的测试，自动计算提供完整测试更改所需的最小测试集，或者是甄别出因代码变更而受影响的测试用例并重新执行 VectorCAST/QA 本身不能生成测试用例，但是它可以沿用客户已有的系统测试框架和测试用例 自动对客户的源码进行插桩，添加代码覆盖率接口；一旦添加覆盖率接口，源代码就会有所膨胀，插桩越细致，代码膨胀率越大，所以说系统测试对目标板的 RAM 和 Flash 有一定要求 在 Jenkins 持续不断地执行测试，实现持续集成 图 8 VectorCAST/QA Vector 简介 Vector Informatik 公司成立于 1988 年，总部位于德国汽车工业中心斯图加特，是全球领先的分布式系统设计开发工具、网络节点测试验证工具和嵌入式软件组件提供商，为 ECU 的开发、测试、标定和诊断等过程提供一系列强有力的软硬件工具和组件，在全球范围内，来自汽车、商用车、工程机械和控制工程领域的客户都在应用 Vector 提供的解决方案和产品。 北汇信息作为 Vector 中国的合作伙伴，不仅提供相应的工具和技术支持服务及培训，还针对不同的应用提供相应的解决方案，助力中国客户的研发效率提升。 Source: Vector 参考文献 VectorCAST/C++ TM--- Unit and Integration Test for C/C++. Version 2.1, Vector, May. 2019.https://assets.vector.com/cms/content/products/VectorCAST/Docs/Datasheets/English/VectorCAST_C___A4_01.pdf VectorCAST RSP TM---Real-Time Software Testing. Version 2.0, Vector, June. 2017. https://assets.vector.com/cms/content/products/VectorCAST/Docs/Datasheets/English/VectorCAST_RSP_A4.pdf VectorCAST/QA TM---Complete Test Automation. Version 2.0, Vector, Nov.2019. https://assets.vector.com/cms/content/products/VectorCAST/Docs/Datasheets/English/VectorCAST_QA_A4_v2.pdf

上篇我们介绍了单元级软件的PiL测试（ PiL测试实战（上） 模型生成代码的单元级PiL测试-面包板社区 (eet-china.com) ） ，对于集成级的PiL测试，其流程和单元阶段基本一致。然而，对于一些带有反馈控制逻辑的集成测试（如电机控制器MCU），PiL阶段会将控制算法（Controller Model）刷入目标板，那如何带着位于PC端的Plant Model一起进行闭环测试呢？ 图1 PiL阶段的闭环测试流程 下面我会为以一个座舱温度控制（ClimateControl）软件为例，为大家展示基于TPT Fusion-Platform的PiL阶段闭环测试解决方案。 ClimateControl软件功能介绍 ClimateControl软件可以通过设定温度和当前座舱温度自动的控制汽车座舱的空调、暖风开启/关闭以及风机的转速，从而实现自动调节座舱温度的功能。其中Controller Model为主要控制逻辑的实现。 为了对Controller Model的功能在仿真条件下进行验证，我们搭建了模拟座舱环境的Plant Model，Plant Model通过一些预设条件以及Controller Model的控制来模拟座舱温度的变化。其中Plant Model输出的座舱温度信号会反馈到Controller Model实现反馈控制。 图2 ClimateControl控制逻辑示意图 在进行PiL测试时，我们会将Controller Model进行代码生成、编译并刷入目标板，而Plant Model依然在PC端运行。那么如何实现不同环境下的Controller Model和Plant Model之间的通讯呢？ TPT Fusion-Platform Fusion-Platform是TPT提供的控制软件的软件集成平台。它允许将多个软件模块（称为“节点”）相互连接，并将它们作为单个系统执行。Fusion节点一个接一个地处理，共享Fusion平台内存，进行数据交换。 这些节点可以支持dll、UDE、Trace32、XiL API、CAN等类型的平台，因此可以很方便的实现不同环境下的软件间的通讯。 图3 TPT Fusion-Platform 基于TPT Fusion-Platform的强大功能，我们可以很方便的实现ClimateControl软件的闭环测试，即：位于目标板的Controller Model（PLS UDE节点）+位于PC端的Plant Model（dll节点）。 测试环境配置 首先我们需要在TPT中新建一个Fusion-Platform。并对运行步长、最大运行时间进行简单的配置。 Custom Node dll节点配置 对于Plant Model，由于需要在PC端运行，我们可以将其转成dll的格式（TPT提供了把模型生成dll的tlc文件，并且可以在TPT端实现从模型到dll的一键生成）。在Fusion-Platform新建一个Custom Node dll节点，并加载dll文件，导入接口信号。 图4 Custom Node dll节点配置 图5 Plant Model的接口信息 PLS UDE节点配置 Controller Model我们需要将其进行代码生成、编译后刷入目标板。TPT可以通过UAD与目标板进行通讯，因此我们需要在Fusion-Platform中再新建一个PLS UDE节点。PLS UDE节点中的接口信号可以通过c文件导入，其他配置过程和我们上篇中的PLS UDE Platform的配置过程完全一致。 图6 PLS UDE节点配置 不同环境间的信号Mapping 在我们配置好Fusion-Platform的节点之后，便可以实现不同节点之间的信号交互。但是由于不同节点之间的信号接口数量、接口名称存在不一致的情况，因此我们需要做一些简单的信号Mapping工作： 仅在一个节点中存在的信号（例如发动机转速信号，仅存在于Plant Model）：需在另一个节点中对该信号进行Hidden； 两个节点中均存在但名称不同的信号（例如反馈信号，Controller Model中为“IntTemp_K”，Plant Model中为“IntTemp_K_”）：需要在“External_Name”中设置其外部名称进行Rename。 图7 信号Mapping 闭环测试的实现 做好这些配置工作之后，我们便可以在TPT中搭建测试用例，来进行闭环测试了。TPT会同时调起两个不同环境下的节点，实现PiL阶段的闭环测试。 这里我在TPT中搭建了一个简单的测试场景：外界温度-5摄氏度，座舱设定温度18摄氏度。我们可以运行测试用例在TPT中观测各信号的变化情况。 图8 “-5到18摄氏度”升温测试 图9 信号变化情况 通过信号窗口可以看出，当座舱温度低于设定温度时，Controller Model会控制暖风机使能信号使能，打开暖风机。与此同时，Plant Model会通过发动机转速、扭矩等信息计算出座舱温度变化并反馈至Controller Model，实现闭环反馈控制。 so...这个方案是不是很完美？感兴趣的小伙伴快来试一试吧。

上次我们分享了单元测试用例的复用（ 单元测试用例复用到集成测试？Testlet Library来助力！-面包板社区 (eet-china.com) ） ，单元测试的用例可以复用到集成测试，那单元测试的评估是否也可以复用到集成测试？答案是可以的。 TPT中提供了多种多样的评估方式，其中的脚本评估使我们复用测试评估成为可能。脚本评估，使用的是基于Python的类Python语言，能够实现筛选评估区间，评估输出，报告定制化等功能，是一种非常灵活，使用起来十分方便的评估方式。 通过脚本评估，在某些模型测试中，我们可以将单元测试的评估，也复用到集成测试中。 应用场景一：单元测试的测试评估复用到集成测试 针对上次用例篇中的demo模型，我们可以在单元测试时就使用脚本评估来评估整个模型，这里以Cruise Control介绍使用脚本评估来评估计算模块的方法。 一般情况下，对于计算模块我们使用定值来测试评估，为了保证测试的充分性，需要若干组数据，这会导致我们需要多次重复计算过程来得到预期的输出，以完成评估。这是我们在测试计算模块时的痛点，有没有可能通过一些方法来自动化这部分重复的过程？答案是有的！通过脚本评估，我们可以将需求中的计算逻辑复现，以此来实现计算模块的自动化评估。 图 1 集成级模型 1 . 声明评估变量 在脚本评估中声明需要的评估变量，将部分中间计算量赋值给这些评估变量，以方便在后续计算中使用。 图 2 在脚本评估中声明评估变量 2. 复现计算逻辑 TPT的脚本评估中内置了很多计算函数，也支持Python基本库中的数学函数，方便我们去复现整个计算逻辑。通过模型中的计算逻辑，使用脚本复现其计算过程。这里以其中一部分逻辑举例介绍， 图 3 模型计算逻辑及TPT中复现的逻辑 3 . 评估 使用一个CruiseControl _ output的评估变量，将TPT计算出的Cruise Control单元的理论输出值赋值给CruiseControl _ output。 图 4 模型理论输出值赋值给 CruiseControl _ output 4. 对输出进行验证 在最后使用TPT .assertAlways 和TPT .hose 两个函数的组合来实现验证模型实际输出是否和理论输出值相等，这样就能检查模型实际输出和需求是否一致，并且能够评估输入的所有组合。两个函数中前者检查表达式的返回值是否为真，后者检查目标信号和参考信号的值是否一致，若一致则返回值为0。所以使用TPT. assertAlways 检查TPT. hose 的返回值等于0，即可证明模型输出值和理论输出值相等。 图 5 评估输出 5. 将单元测试的评估复用到集成测试 应用上面的方法，将Vehicle这个单元也使用脚本进行评估。这样在进行集成测试时，单元测试阶段的 eng_torque 将变成Local量。可以将Cruise Control 的脚本评估和Vehicle的脚本评估使用这样的语句进行拼接，即可将单元测试的测试评估，复用集成测试。 1）将两个单元的脚本评估复制到集成测试的工程中。 图 6 将单元测试的脚本评估赋值到集成测试的工程 2 ）将CruiseControl脚本中的评估输出eng _torque 的语句注释掉，因为此时该信号变成了Local。 图 7 注释CruiseControl中的相关语句 3 ）对于Vehicle单元，输入信号e ng_trq 变成Local量，是由Cruise Control单元计算得到的。所以在Vehicle的脚本中，将CruiseControl脚本中计算出的en g_torque 的值赋值给eng _t rq，即可将两部分脚本评估拼接，完成评估的复用。 图 8 传递参数 4 ）运行测试用例得到测试结果。从下图中可以看到用例时间为1 0 s，评估区间也是1 0 s且测试通过。 图 9 集成测试用例的测试结果 应用场景二 自定义脚本库 TPT的脚本评估不仅提供了非常多方便我们评估的内置函数，还支持自定义函数库，方便我们自已定义一些个性化的评估函数。这里以饱和模块为例，简述TPT是如何自定义函数库的。 1 . 编写自定义函数 首先在一个新建的脚本评估中编写我们要定义的函数（主要是方便控制缩进），TPT脚本评估的语法和Python大体类似。 图 10 编写好自定义函数 2 . 保存文件并修改文件格式 新建t xt 文本，将编写好的自定义函数复制到该文件中保存，将文件后缀名修改为. tptp y。 图 1 1 保存自定义函数文件 3 . 在TPT中加载函数库 1）在Preference / General /Assessment Library中添加自定义函数文件的路径。 图 1 2 在Preference / General /Assessment Library添加自定义函数路径 2 ）在工程的Assessment Library中激活函数库。这样就可以在工程中使用我们刚刚编辑好的函数库中的函数了。 图 1 3 在工程 Assessment Library 中激活函数库 3 ）在脚本评估中使用“自定义函数的文件名+. + 函数名称”的语法即可调用刚刚自定义好的函数。 图 1 4 在脚本评估中是自定义函数 4 ）使用示例。 图 1 5 使用示例及结果 总结 本文主要介绍了测试评估从单元测试复用到集成测试和自定义脚本库，这两者同样能帮助我们提升测试时的效率。通过用例复用和评估复用不难发现，TPT在做模型测试时具备巨大的优势，可以通过多种方式提高测试的速度和效率，减少重复的工作。并且TPT支持测试的多个阶段——MiL，SiL，PiL等，能够将同一工程复用到不同的测试阶段，这同样也能提高我们测试的效率！感兴趣的小伙伴快动起来吧！