目录
1 范围....................................................................................................................1
2 规范性引用文件................................................................................................1
3 术语与定义........................................................................................................1
4 测试过程要求....................................................................................................1
测试准备阶段要求.................................................................................1
主要活动......................................................................................1
测试计划......................................................................................2
测试准则......................................................................................3
测试环境准备..............................................................................4
测试实施阶段要求.................................................................................5
主要活动......................................................................................5
需求解析......................................................................................5
测试用例设计及管理..................................................................6
测试执行......................................................................................9
测试结束阶段要求 ...............................................................................11
主要活动 ....................................................................................11
测试总结 ....................................................................................11
测试报告....................................................................................12
5 测试工具介绍..................................................................................................13
总线监控工具.......................................................................................13
CANoe.........................................................................................13
INTEWORK VBA ......................................................................13
Wireshark ....................................................................................14
Vehicle Spy..................................................................................15
静态代码分析工具...............................................................................15
Helix QAC ..................................................................................15
StatiCode .....................................................................................16
单元测试工具.......................................................................................17
Tessy ..................................................................................................17
Google Test.........................................................................................18
Catch2 .........................................................................................18
集成测试工具.......................................................................................19
Tessy ..................................................................................................19
VectorCAST ....................................................................................20
Cantata.........................................................................................20
性能测试工具.......................................................................................21
AbsInt ..........................................................................................21
RVS..........................................................................................................22
Gliwa T1......................................................................................23
DT10 ...........................................................................................23
安全测试工具.......................................................................................24
Cybellum.....................................................................................24
AFL .............................................................................................25
Honggfuzz ...................................................................................25
SFuzz...........................................................................................26
SCA.............................................................................................26
测试管理工具.......................................................................................27
禅道.............................................................................................27
JIRA ............................................................................................28
INTEWORK TAE&TPA.....................................................................29
附录......................................................................................................................31
附录1：测试人员的要求............................................................................31
主要贡献单位......................................................................................................34
1 范围
本指南适用于汽车基础软件的测试工作，包括但不限于车载操作系统、汽车
电子控制单元软件、汽车通信软件等，涵盖了汽车基础软件测试的全生命周期，
包含测试计划的制定到测试报告的生成，以及测试过程中的各个环节。
本指南适用于 AUTOSEMO 下各个组织进行测试活动。
2 规范性引用文件
本文件实施过程中，下列标准或规范是必须遵循或参考的。其中，注日期的
引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本
（包括所有的修改单）适用于本文件。
GB/T -2020 系统与软件工程 软件测试 第1 部分：概念和定义
GB/T -2020 系统与软件工程 软件测试 第2 部分：测试过程
GB/T 15532 计算机软件测试规范
GB/T -2022 道路车辆 功能安全 第 6 部分：产品开发：软件层面
3 术语与定义
GB/T -2020 界定的术语和定义适用于本文件。
需求：测试输入在不同的测试阶段对应不同的文件类型，如单元测试阶段为软
件的详细设计文档，集成测试阶段为软件的架构设计文档，合格性测试阶段为软
件的需求文档，验收测试阶段为客户需求文档等内容。为方便表述和理解，本文
的需求广义的代表不同测试阶段的输入要求。
4 测试过程要求
测试准备阶段要求
主要活动
测试准备阶段的主要活动如下：
制定测试计划
设置测试准则
准备测试环境
测试计划
制定合理的测试计划应提前明确以下内容：
1) 目标确定
明确测试的总体目标，如确保软件功能符合汽车行业标准和车辆制造商的要求
、性能满足汽车运行的实时性和稳定性需求、安全性达到汽车功能安全等级等。根据
不同类型的汽车基础软件，将总体目标分解为具体的子目标，如车载操作系统的稳
定性测试目标、ECU 软件的可靠性测试目标、汽车通信软件的安全性测试目标等
。
2) 测试范围
详细列出需要进行测试的功能模块、接口、协议等。确定测试的边界，明确
哪些部分属于测试范围，哪些部分不在测试范围内。例如，对于汽车通信软件，
需要明确测试的通信协议范围，如 CAN 总线、LIN 总线、以太网等。
3) 进度规划
制定详细的测试进度计划，包括各个测试阶段的开始时间、结束时间和里程碑
。将测试工作分解为具体的任务，如需求分析、用例设计、测试执行、缺陷修复等
，并为每个任务分配合理的时间。同时，考虑到汽车基础软件测试可能受到车辆硬
件环境、测试设备等因素的影响，可以适当预留一定的缓冲时间。例如， 可以制定
一个甘特图，清晰地展示各个任务的时间安排和进度情况，并在后续的实施过程中持
续跟进。
4) 协调资源
确定测试所需的人力资源、硬件资源和软件资源等。根据汽车基础软件测试
的规模和复杂程度，合理安排测试人员的数量和技能组合。确保测试环境所需的
硬件设备（如诊断工具、仿真设备等）和软件工具（如测试管理工具、自动化测
试工具等）准备就绪。对于人力资源，需要根据测试人员的技能水平和经验，分
配不同的测试任务。例如，经验丰富的测试人员可以负责复杂的安全测试和性能测
试，而初级测试人员可以负责一些简单的功能测试。具体测试人员的要求可参
见附录 1。
5) 风险评估
识别可能影响测试进度和质量的风险因素，如需求变更、硬件故障、测试环
境不稳定等。对每个风险因素进行评估，确定其发生的可能性和影响程度。制定相
应的风险应对措施，如建立需求变更管理流程、提前准备备用硬件、优化测试环境等
。具体举例，对于需求变更的风险，可以建立严格的需求变更管理流程， 要求所有的
需求变更都必须经过评审和批准，并及时更新测试计划和测试用例。
测试准则
测试准则对于确保测试活动的有效性和准确性至关重要，制定标准的测试准
则可以指示具体的测试行为。
1) 测试准入准则
-- 测试环境应已搭建完毕，包括硬件设备、软件平台、网络配置等，且能够正
常运行；
-- 测试用例应已编写完成，并经过评审和修订，确保其覆盖率和有效性；
-- 测试人员应已接受相关的培训，熟悉测试流程和方法，以及待测试系统的
功能和特性；
-- 待测试的系统或功能模块应已完成开发，并经过初步的代码审查和静态
分析，确保没有明显的语法错误和逻辑漏洞。并由提测方提交测试申请，包括版本
说明、被测物基线描述、冒烟测试记录、新增/变更项描述、未修改的缺陷说明等
。
2) 测试中止准则
-- 测试过程中发现大量严重缺陷，以至于没有继续测试的意义；
-- 测试环境出现故障或不稳定，影响测试结果的准确性和可靠性；
-- 测试资源不足，如人力、时间、设备等，无法继续进行测试；
-- 需求发生重大变更，需要重新进行测试规划和设计。
3) 测试再启动准则
-- 导致测试中止的问题已得到解决，测试环境已恢复正常；
-- 对需求变更进行了评估和处理，更新了测试用例和测试计划；
-- 获得了足够的测试资源，能够继续进行测试。
4) 测试结束准则
-- 所有的测试用例都已执行完成且全部通过；
-- 已达到预定的测试覆盖率和质量目标；
-- 相关的文档和记录已整理完毕，便于后续的维护和管理；
-- 完成测试报告、被测对象发布及发布总结会。
测试环境准备
测试环境，指为了完成软件测试工作所必需的计算机硬件、软件、网络设备
等资源的总称，简而言之，测试环境=硬件+软件+网络+数据准备+测试工具。
1) 硬件环境搭建
根据被测对象的运行要求，选择合适的测试平台、诊断工具、仿真设备等硬
件设备。确保硬件设备的性能和配置能够满足测试的需求并搭建测试网络环境，
确保被测对象能够在预定的网络环境下进行。在测试启动之前，需要绘制一个硬件
环境架构图，清晰地展示硬件设备的连接方式和配置情况，并详细记录使用硬件的型
号、版本等信息。
2) 软件环境配置
安装和配置测试所需的操作系统、编译器、代码调试器等软件。安装测试管理
工具、自动化测试工具等辅助软件，提高测试效率和质量。例如，对于通信软件的
测试，需要安装和配置相应的通信协议分析工具，以便监测和分析通信数据。同时，
安装测试管理工具可以帮助管理测试用例、缺陷和测试进度。
3) 环境验证
对搭建好的测试环境进行验证，确保其能够正常运行，满足汽车基础软件的
测试要求，可进行功能测试、性能测试等。及时解决环境中出现的问题，确保测试
工作的顺利进行。例如，可以编写一些简单的测试用例，对测试环境中的各个硬
件设备和软件组件进行功能测试，确保其能够正常工作。
测试实施阶段要求
主要活动
需求解析
测试用例设计及管理
测试执行
需求解析
需求解析是根据功能描述文件进行条目化工作，从文档中将相对独立的功能
描述内容提取出来构成一个单独的条目，同时明确该功能的前置条件。根据测试目
的以及需求本身可能带来的影响，针对条目化的内容逐一编写用例设计要求。
1) 需求文档审查
审查被测对象的需求规格说明书、用户故事、业务流程图等需求文档。确保
需求文档的完整性、准确性和一致性。对需求文档中模糊不清、相互矛盾的地方
进行标记和反馈，要求相关人员进行澄清和修改。
例如，可以组织测试人员和开发人员共同审查需求文档，对需求文档中的每个
功能点和业务流程进行详细的讨论和分析。对于模糊不清的需求，可以通过与相
关人员沟通、用户调研等方式进行澄清；对于相互矛盾的需求，可以通过召开需
求评审会议，邀请相关人员进行讨论和决策，确定最终的需求方案。
2) 需求分解
将需求文档中的功能点和业务流程进行分解，形成详细的需求列表。对每个
需求进行编号和描述，明确需求的优先级和重要程度。根据需求的类型和复杂程
度，将其分配给不同的测试人员进行测试。
例如，可以采用功能点分解法、业务流程分解法等方法，将需求文档中的功能
点和业务流程进行分解。对于每个需求，可以进行详细的描述，包括需求的背景
、目标、输入、输出、约束条件等。同时，根据需求的优先级和重要程度，可以将
需求分为高、中、低三个等级，以便合理安排测试资源和时间。
3) 需求跟踪
建立需求跟踪矩阵，将需求与测试用例进行关联。确保每个需求都有对应的
测试用例进行覆盖，并且每条用例也要有需求进行关联。在测试过程中，及时更
新需求跟踪矩阵，记录需求的测试状态和结果。
例如，可以使用需求管理工具或表格形式建立需求跟踪矩阵，将需求文档中的
每个需求与相应的测试用例进行关联。在测试过程中，根据测试用例的执行情况
，及时更新需求跟踪矩阵中的测试状态和结果。
测试用例设计及管理
1) 用例设计方法选择
根据被测对象特点和测试需求，选择合适的用例设计方法，如等价类划分、
边界值分析、因果图、判定表、错误推测等。对于复杂的业务流程，可以采用场景
法进行用例设计。对于性能测试和安全测试，可以采用专门的测试方法和工具进行用
例设计。例如，对于汽车电子控制单元软件的输入信号测试，可以采用等价类划分和
边界值分析的方法，确定输入信号的有效范围和边界值，设计相应的测试用例。对于
车载操作系统的用户操作流程测试，可以采用场景法进行用例设计，模拟不同的用户
操作场景，如正常启动、异常关机、多任务切换等，设计相应的测试用例。
同时在测试用例设计的过程中要考虑国标和行业标准的要求，如下是
GB/-2022 道路车辆功能安全中对于测试用例设计方法的要求
图 -1 嵌入式软件的测试方法
2) 用例编写规范
图 -2 嵌入式软件测试用例的生成方法
制定用例编写规范，明确用例的格式、内容和编写要求。用例应包括用例编
号、用例名称、测试目的、初始条件、测试步骤、预期结果、优先级等内容。
例如，可以制定一个用例模板，规范用例的格式和内容。用例编号可以采用统
一的编号规则，便于管理和查找。用例名称应简洁明了，能够准确反映用例的测
试内容。测试目的应明确用例的测试目标和重点。测试步骤应详细描述用例的执行
过程，包括输入数据、操作步骤、预期结果等。预期结果应明确用例的期望输出，
以便与实际结果进行比较。
表 -1 测试用例规范示意
用例编号 用例名称 测试目的 初始条件 测试步骤 预期结果 优先级
CF-01-001
CF-01-002
3) 用例评审
对编写好的用例进行评审，邀请需求人员、架构师、测试人员等相关人员参
加。评审用例的完整性、有效性、可执行性等。对评审中发现的问题进行及时修改
和完善。
例如，可以组织用例评审会议，对用例进行逐一审阅和讨论。评审人员可以从
不同的角度提出意见和建议，如用例的覆盖范围是否全面、测试步骤是否清晰、预期结
果是否准确等。对于评审中发现的问题，用例编写人员应及时进行修改和完善，确
保用例的质量和有效性。
4) 用例筛选
在不同的测试阶段，可能需要对用例进行筛选，以提高测试效率。但是用例
筛选也需综合多方面因素进行考量，以确保测试的全面性、有效性和针对性。
首先，需求覆盖是基础。要确保所选用例能够全面覆盖软件的功能需求、性
能需求和安全需求等。尤其关注关键业务流程和高风险区域，挑选具有代表性的
用例进行测试，保证系统的核心功能得到充分验证。
其次，进行风险评估。依据项目的风险评估结果，优先选择可能对系统稳定性
和可靠性产生重大影响的用例。新功能、复杂业务逻辑及与外部系统集成的部分
应重点关注，这些区域往往存在较高的风险。
再者，参考历史经验。选择曾经出现过问题的功能点对应的用例以及经过验证
有效的用例，可以提高测试的效率和准确性，避免重复出现类似问题。
从用户场景出发，考虑不同用户角色和使用场景，选择能够覆盖各种典型用
户操作的用例。
例如，在首轮测试时，应选择对系统功能和稳定性至关重要的用例以及新增 功
能相关的用例。首轮测试旨在验证系统的主要功能，及时发现严重缺陷。对于 复杂业
务流程和高风险区域可适当增加用例数量和覆盖度。在后续的回归轮次中， 要重点选
择曾经出现过问题的用例、与变更部分相关的用例以及关键业务流程的 用例。回归
测试的目的是验证缺陷是否得到修复以及变更是否对系统其他部分产 生不良影响。根
据变更的范围和影响程度，合理调整用例选择策略，提高回归测 试的针对性和效率。
5) 用例维护
用例维护是确保测试有效性和准确性的重要环节。以下是用例维护的一些要
点：
及时更新：当需求发生变化、功能进行调整或发现新的问题时，应及时修改
相应的用例，以保证用例与实际系统的一致性。
版本管理：对用例进行版本管理，记录每次用例的修改历史和原因，便于追溯
用例的变更过程，也有助于在需要时恢复用例到特定版本。
用例评审：当用例修改后，要及时组织用例评审，邀请相关人员对用例的完整
性、准确性和有效性进行审查。通过评审可以发现用例中的问题和不足，并及时进
行改进。
清理无效用例：对于已经不再适用的用例，应及时进行清理。可以避免用例
库的混乱和冗余，提高用例的执行效率。
6) 用例追溯
用例追溯是建立用例与需求、缺陷之间关联的过程，有助于提高测试的可追
溯性和管理水平。以下是用例追溯的方法和步骤：
需求追溯：将每个用例与相应的需求进行关联，明确每个用例所测试的功能
点和需求项。
缺陷追溯：当发现缺陷时，应将缺陷与相关的用例进行关联，以便分析缺陷产
生的原因，确定是用例设计问题还是系统本身缺陷。同时，也有助于在回归测试时
重点关注这类用例。
追溯管理：建立用例追溯矩阵或使用测试管理工具，对用例的追溯关系进行管
理和维护。这样可以方便查询和统计用例与需求、缺陷之间的关联情况，为项目管
理和决策提供依据。
测试执行
1) 测试准备
在正式开始测试之前，测试团队需要做好充分的准备工作。这包括但不限于
以下几个方面：
确定测试环境：确保测试环境与实际生产环境尽可能相似，包括硬件配置、
软件版本、网络环境等。
准备测试数据：根据测试用例的需求，准备足够的、真实的测试数据，以确
保测试的有效性和准确性。
培训测试人员：对测试人员进行培训，使其熟悉测试流程、测试工具、测试
方法和被测对象，以便提高测试过程中的效率及质量。
2) 测试执行
在测试执行过程中，测试人员应严格按照测试用例进行操作，记录测试结果，
并及时反馈问题。具体包括以下几个方面：
按照测试计划和测试用例进行测试，确保每个用例都得到执行。
记录测试过程中的问题和异常情况，包括问题描述、出现环境、复现步骤等。
分析问题出现的原因，并确定问题的严重程度和影响范围。
提交缺陷管理系统及时向项目团队反馈问题，并跟踪问题的解决进度。
3) 测试情况检查
在测试实施过程中，测试负责人需要定期对测试情况进行检查，以确保测试
工作的顺利进行。检查内容包括以下几个方面：
测试进度检查：检查测试计划的执行情况，了解测试进度是否符合预期。如
果发现进度滞后，应及时分析原因并采取措施加以调整。
测试用例执行情况检查：检查测试用例的执行情况，确保每个用例都被执行。
已执行的用例，是否有完整的测试证据信息。
问题处理情况检查：检查问题的处理情况，了解问题的解决进度和质量。对
于未解决的问题，应督促开发团队及时处理。
4) 缺陷管理
缺陷管理是测试实施过程中的重要环节，有效的缺陷管理可以提高测试效率
和质量。以下是缺陷管理的重点说明：
缺陷处理流程：定义缺陷的状态，缺陷状态可以包含新建、已解决、已验证、已
拒绝等状态，便于不同角色的人员进行缺陷的处理。明确缺陷处理流程，能够让
缺陷在不同的状态和人员之下流转起来，缺陷提交之后如何流转处理。图 -
3 为基础的缺陷处理流程，可供参考。值得注意的是，如缺陷当前版本不解决，
缺陷应仍为新建状态，并变更缺陷里程碑，待后续版本中解决。后续解决时仍需要
按照上述流程进行。
图 -3 缺陷处理流程示意图
缺陷报告：测试人员在发现缺陷后，应及时填写缺陷报告。缺陷报告应包括缺
陷的描述、出现的环境、复现步骤、严重程度、优先级等信息，确保缺陷报告的准
确性和完整性，以便开发人员能够快速定位和解决问题。
缺陷确认：开发人员在收到缺陷报告后，应及时对缺陷进行确认。如果确认是
缺陷，应将其分配给相应的开发人员进行修复；如果认为不是缺陷，应与测试人员
进行沟通，说明原因并调整缺陷状态。
缺陷修复及验证：开发人员在修复缺陷后，应进行充分的测试，确保缺陷得
到彻底解决。修复后的缺陷应调整至已验证状态并及时反馈给测试人员，并同时反
馈本次修改的影响范围。
缺陷跟踪：测试人员应跟踪缺陷的修复进度，确保缺陷在规定的时间内得到解
决。对于严重的缺陷，应及时向上级领导汇报，采取相应的措施加以解决。
缺陷统计分析：在测试过程中，应定期对缺陷进行统计分析。分析缺陷的分
布情况、严重程度、修复情况等，以便了解系统的质量状况，为后续的测试和开发
工作提供参考。
测试结束阶段要求
主要活动
测试总结
测试报告
测试总结
测试结果分析：对被测对象测试过程中发现的问题进行分类和统计，分析问题
的分布情况和严重程度。评估被测对象的质量状况，确定软件是否满足发布标准
，如果不满足发布标准，提出进一步的改进建议和措施。
例如，可以制作问题分布图表，直观地展示不同类型问题在各个模块中的数量
和比例。根据问题的严重程度评估软件的质量风险，提出针对性的改进建议， 如优
化代码结构、加强安全防护机制、提高性能优化等。同时可以根据缺陷分布和发现的
角度，指示测试人员对用例进行升级调整、对环境进行优化管理。
经验教训总结：总结测试过程中的经验教训，包括测试方法、测试工具、沟
通协调等方面的经验和教训。提出改进测试工作的建议和措施，为今后的测试工
作提供参考。
例如，可以回顾测试过程中遇到的难题和解决方案，总结有效的测试方法和技
巧。分析沟通协调方面的问题，提出改进团队协作的建议，如建立更高效的问题反
馈机制、加强与开发团队的沟通合作等。
测试报告
测试报告应包括测试的目标、被测对象版本及内容简述、方法、进度、结果、结
论等内容。详细描述测试过程中发现的问题和缺陷，以及问题的严重程度和修复情
况。对软件的质量进行评估，提出是否可以发布的建议。
例如，测试目标可以明确本次测试针对哪些方面进行，如功能完整性、性能稳
定性、安全性等；测试范围说明测试覆盖的汽车基础软件模块和功能点；测试方法
介绍采用的测试技术和工具；进度部分展示测试的各个阶段的时间安排和完成情况；
结果部分详细列出发现的问题和缺陷，包括问题的描述、出现的场景、严重程度等；
结论部分综合评估软件的质量，给出是否可以发布的建议。
报告格式：测试报告应采用规范的格式，包括封面、目录、正文、附录等。
正文应采用清晰的结构和语言，便于阅读和理解；附录可以包括测试用例、测试结
果截图、问题跟踪记录等。
例如，封面可以包含报告的标题、测试项目名称、报告日期等信息；目录列出
报告的各个章节和附录的内容；正文按照测试报告的内容要求进行详细阐述； 附录
提供相关的支持材料，方便读者进一步了解测试过程和结果。
报告审核与发布：测试报告应由测试负责人审核后发布给相关人员，确保测试
报告的准确性和客观性。根据测试报告的结论，决定被测对象是否可以发布。如果
需要进一步改进，制定改进计划并跟踪改进情况。
例如，测试负责人需要对测试报告的内容进行仔细审核，确保数据准确、分析
合理、结论客观。发布测试报告后，相关人员可以根据报告的结论进行决策， 如决
定是否发布软件或要求进行进一步的改进。如果需要改进，制定详细的改进计划，并
跟踪改进情况，确保问题得到有效解决。
5 测试工具介绍
总线监控工具
CANoe
CANoe 软件是 Vector 公司针对汽车电子行业推出的总线分析工具，其在软
件的开发、测试的各个环节都有广泛应用，下述为 CANoe 具体的功能特点：
图 -1 CANoe 界面示意图
广泛的总线支持：支持多种车用网络协议，如 CAN、LIN、FlexRay、以太
网、MOST 等，以及一些基于 CAN 的通讯协议，如 J1939、CANopen、ARINC825
和 ISOBUS 等，能满足汽车电子系统中复杂的总线通信需求。
强大的仿真能力：可在实验室环境下模拟整车网络通信，帮助工程师在开发
初期对 ECU 的功能进行评估，也可用于系统的功能分析、测试以及总线系统和
ECU 的集成，以便尽早发现并解决问题。
高效的测试功能：具有测试功能集，能够简化或自动进行测试，并自动生成
测试报告，方便工程师对测试结果进行分析和评估。
全面的诊断功能：可与 ECU 进行诊断通信，帮助工程师分析诊断通信过程
中的问题，对 ECU 的诊断功能进行验证和测试。
INTEWORK VBA
VBA（INTEWORK VBA）是由经纬恒润推出的一款国产化的总线分析工具，
近几年在市场中有不错的表现，具体的功能特点有：
基本监控与分析：能够对 CAN、CANFD、LIN、以太网等总线数据进行监
控和分析，实时采集总线上的报文，并解析报文中的单个信号，帮助工程师掌握总
线通信的详细情况。
节点仿真功能：可以模拟车辆电子控制单元（ECU）的行为，在总线上发送
和接收报文，方便进行系统的集成测试和验证。
报文发送与回放：支持用户手动发送特定的报文到总线，用于测试总线系统
对特定指令的响应，还可以将之前监控到的总线数据保存下来进行离线回放，以
便深入研究历史数据。
脚本编程支持：基于 Python 脚本开发环境，用户可以根据自己的需求编写
脚本，实现自动化测试、数据处理和复杂的仿真场景，具有较高的灵活性和可扩展
性。
图 -2 VBA 界面示意图
Wireshark
Wireshark 是一款免费、开源的网络数据包分析工具，主要应用在汽车网络
通信分析的场景。
Wireshark 可以捕获汽车以太网总线上的数据包，对数据包进行详细的分析
和解读，帮助工程师了解网络通信的细节，例如分析网络通信中的协议、数据格
式、通信频率等。不过，与专业的汽车总线监控工具相比，Wireshark 在汽车领
域的应用可能需要更多的配置和专业知识。
Vehicle Spy
Vehicle Spy 是一款综合功能强大且易于上手的软件工具，在工作中有广泛的
应用。
功能特点：可用于执行诊断、节点/ECU 仿真、数据采集、自动测试、存储
器编辑或校准以及车辆网络总线监控等方面。几乎支持所有汽车网络，包括
CAN、CANFD、汽车以太网、LIN、FlexRay、K-Line 等。它能够满足汽车电子
系统开发和测试过程中的多种需求，为工程师提供了全面的解决方案。
静态代码分析工具
Helix QAC
QAC 工具是一款主要用于 C/C++代码的自动化静态分析工具，可以提供编
码规则检查、代码质量度量、软件结构分析、测试结果管理等功能。其功能特点
如下：
代码规则检查全面：能够对 C/C++代码规则进行自动检查，报告所违反的编
程标准和准则，可发现 1200 多种 C 语言问题、800 多种 C++的问题。能准确发
现危险的结构、维护和移植中可能发生的问题，帮助开发人员在开发阶段提高代码
质量。
支持多种标准和扩展：支持多种编程标准（如 ISO、MISRA C/C++、CERT
C/C++、CWE C/C++、AUTOSAR C++等）以及多种其他行业编程规则。
便捷的操作和报告：产品界面简洁直观，操作简单，建立工程后加入代码即
可进行分析。分析报告形式多样，可输出为 excel、word、pdf、图表等。
图 -1 QAC 静态分析结果
StatiCode
StatiCode 是一款静态代码分析工具，可以提供多种语言的质量安全分析和
代码度量分析，也可以提供编程标准合规分析。其特点有：
图 -2 StatiCode 静态分析结果
支持 C/C++/Java/C#/JavaScript/TypeScript/Golang/PHP/Python 等多种语言。
采用全路径扫描、并行程序分析、数据流、符号执行、抽象解释、作用域分
析等检测技术，能够检查内存崩溃、未初始化变量、资源泄露、空指针引用、控
制流缺陷、程序假死、除零错误、类型溢出等运行时缺陷。
软件可以从问题严重等级、Top10 统计、趋势、处理状态分布等多种维度展
示检测结果，支持多条件组合缺陷查询。展示缺陷上下文细节，帮助技术人员复盘
缺陷的产生过程。
单元测试工具
Tessy
Tessy 是一款主要用于动态单元测试的工具，其主要特点如下：
多种测试用例设计方式：除了在简洁的界面中手动输入测试用例之外，还支
持从 Excel 中导入测试数据，也可以通过脚本编辑器编写测试用例。
支持多种覆盖度分析：提供 C0、C1、MC/DC 等多种覆盖情况，可以帮助测
试人员全面了解测试的覆盖程度。
图 -1 Tessy 工具执行单元测试效果图
Google Test
Google Test（简称为 gtest）是 Google 开发的一个用于 C++程序的单元测试框
架。它帮助开发者通过编写和运行测试来验证代码的正确性，并提供了丰富的功能
来支持各种测试需求。以下是 Google Test 的一些关键特点：
简单的测试编写方式：开发者可以通过定义测试函数来编写单元测试，测试
函数一般用 TEST 宏来定义。Google Test 让编写测试变得直观且容易理解。
丰富的断言支持：Google Test 提供多种断言类型来验证测试结果，如
EXPECT_EQ、EXPECT_TRUE、ASSERT_EQ 等。EXPECT_*断言允许测试继续
执行，即使断言失败；而 ASSERT_*断言则会在失败时立即停止测试。
测试分组：可以通过测试用例组将相关的测试组织在一起，便于管理和执行。
每个测试组可以包含多个单独的测试。
Fixture 支持：通过测试夹具（Test Fixture），可以为一组测试设置通用的初
始化和清理代码。使用夹具有助于减少测试中的重复代码，并确保每个测试在相
同的初始条件下运行。
跨平台支持：Google Test 可以运行在 Linux、Windows、macOS 等多种平台
上，具备良好的跨平台兼容性。
Catch2
Catch2 是一个专门针对于 C++设计的单元测试框架，它能够帮助开发者高
效地编写和管理单元测试用例，提高代码的质量和可靠性，其具体特点如下：
自动注册测试用例：能够自动发现和注册测试用例，无需手动管理测试用例
的列表或执行顺序，简化了测试代码的编写和维护。
支持多种测试场景：允许以结构化的方式组织测试，可描述不同的测试场景
和条件，能够有效的提高复杂的业务逻辑测试覆盖度和效率。
良好的文档和教程：拥有详细的文档和丰富的教程，对于初学者来说易于上
手，能够快速掌握框架的使用方法。
集成测试工具
Tessy
Tessy 工具除了能够进行单元测试之外还有着强大的集成测试功能。工具
内包含了一系列专门的集成测试套件，这些套件符合 ISO 26262 功能安全标
准，专注于ECU（电子控制单元）的模块交互测试和通信协议（如 CAN、
LIN）的集成验证。Tessy提供的测试套件涵盖了模块之间的交互、接口验证、
数据流测试和系统行为验证等方面。其集成测试的优势在于：
测试用例生成和执行自动化，适合复杂的汽车基础软件； 提
供 FC/CPC 覆盖率，满足 ISO 26262 等功能安全标准；
支持主流编译器和调试器，与汽车基础软件工具链无缝集成；
直接在目标硬件上运行测试，确保与真实环境一致；
自动生成符合 ISO 26262 的测试报告，便于审核和验证。
图 -1 Tessy 工具执行集成测试效果图
VectorCAST
VectorCAST 是一款专门用于嵌入式软件测试的自动化工具，广泛应用
于汽车、航空航天、铁路、医疗等领域，尤其适合对安全性、可靠性要求比
较高的系统。
采用高度模块化的设计，以独立模块协同工作的方式实现高效的测试功
能。其核心模块包括：
VectorCAST/C++ 和 VectorCAST/Ada：分别支持 C/C++ 和 Ada 语言的
单元测试和集成测试，进而提供自动生成测试用例的功能。
VectorCAST/QA：集成测试模块，专注于代码覆盖率分析和回归测试。
此外，通过与 CI/CD 工具链结合，完成测试过程的持续集成和质量保证。
VectorCAST/Manage：项目管理模块，用于管理多个测试环境、报告生成
和测试进度跟踪。
Stub 和 Mock 支持模块：提供对外部依赖的模拟功能，实现未完成模块的
隔离测试。
图 -2 VectorCAST 工具图
Cantata
Cantata 是一款功能强大的 C/C++ 软件测试工具，特别是在嵌入式和高
可靠性领域中表现出色。其软件设计具有高度模块化、用户友好性和自动 化的
特点，其架构和功能的设计完全针对嵌入式系统和复杂集成测试的需求。具体模
块介绍如下：
测试框架模块：这是Cantata核心设计之一，让用户只需关注测试逻辑的
设计。测试框架包括测试用例函数、初始化代码和断言代码。
Stub 和 Mock 模块：专为嵌入式开发设计，支持模块间依赖的隔离测
试。Stub 和 Mock 功能能够动态生成，方便用户模拟未实现模块或硬件接
口。
数据驱动模块：支持导入外部测试数据文件（如 CSV、Excel），将测
试逻辑与测试数据分离，实现数据驱动测试。
此外，Cantata 内置的回归测试机制，能够自动检测代码变更，识别受
影响的测试用例并重新运行，从而确保代码更新后的系统稳定性。
图 -3 Cantata 管理视图
性能测试工具
AbsInt
AbsInt 是一款应用于性能测试的静态分析工具，该工具能够在代码开发、控
制器集成阶段评估资源使用率，指导芯片选型和工程优化、保证堆栈空间分配合
理性、保证任务周期的稳定性，规避软件中函数执行时间的不合理风险。
在AbsInt 工具中集成丰富的功能套件，能够支持用户应对不同的使用场景：
AIT WCET Analyzer：最差情况执行时间分析工具，针对特定的处理器和编
译器，能够分析出接近实际运行情况的最差执行时间。
StackAnalyzer：最差情况堆栈使用量分析工具，可针对特定的处理器族和编
译器，自动分析出任务的最差堆栈使用量，防止堆栈溢出或资源浪费。
TimingProfiler：代码执行时间分析工具，针对特定的处理器族和编译器，能
从初期开始对代码执行时间进行持续分析和评估。
特点优势：作为代码静态分析工具，可直接导入编译后的二进制可执行文件进
行自动分析；具有图形化显示功能，可为优化提供依据；能遍历所有程序执行路
径，对所有场景有效且无需提供测试用例。
图 -1 AbsInt 执行方案
RVS
RVS（Rapita Verification Suite）工具是一款嵌入式系统在板测试工具，其能
够进行自动化时间性能分析，并为复杂嵌入式系统提供可视化任务调度和时序追
踪，其功能套件主要有：
RapiTime：软件时间性能分析工具，可提供函数级、代码段级的最差情况执
行时间、最大执行时间、最小执行时间、平均执行时间、高水位执行时间的测量和
统计，帮助用户定位性能瓶颈和软件优化重点。
RapiTask：软件任务调度和事件分析工具，可视化软件任务调度和事件跟踪，
帮助用户解决在使用复杂调度行为（如多核、多线程）的嵌入式系统时可能面临
的挑战，如定位时序错误、系统容量和负载问题等。
特点优势：产品符合 ISO-26262、DO178B/C、IEC-61508 等行业标准，兼容
多种操作系统和编程语言，广泛支持各类编译环境及各类目标芯片。
图 -2 RVS 系统级分析效果图
Gliwa T1
Gliwa T1 可以满足开发流程中不同阶段对嵌入式时间的需求，对函数执行时
间、控制器负荷、多核稳定性等均具备成熟资质，Gliwa T1 工具包含如下几类分
析内容：
静态代码分析：分析时间工具读取应用程序源代码或二进制代码，计算指定代
码段执行的时间下限 BCET 和时间上限 WCET。
代码仿真：模拟某种MCU 下给定二进制代码的运行，并考虑流水线与缓存，
再结合嵌入式测试环境，真实模拟最差工况。
调度分析：基于某个 RTOS 的调度器模型，将内核执行时间最小/最大值和
应用模型作为输入，输出为 WCRT。
借助 Gliwa T1 工具实时显示时间要素，对用户应用软件执行过程中复杂的
任务调度、中断、事件发生的情况以时间轴进行显示。通过显示和分析，用户可以
变更系统设计参数，通过对比，进行调试和优化系统时间性能表现。
DT10
DT10 是一个用于软件研发的动态测试和跟踪调试工具，一般需要搭配 DT10
高速采集设备和软件共同使用。
性能评估和测试：可监测每个函数的执行时间和周期时间，也能够监测系统
中任意两行代码之间的执行时间以及周期时间。对于多任务的汽车软件系统，
DT10 还可监测 CPU 压力。通过对这些性能指标的监测和分析，测试人员可以了
解软件的性能瓶颈和优化方向。
覆盖率统计：可以帮助用户获取程序运行时的覆盖率，包括语句覆盖和分支覆
盖。通过 DT10 的覆盖率统计功能，在测试人员执行测试用例之后，可以统计相
关测试之后的代码覆盖率情况。
错误定位和回溯：具有强大的缺陷回溯定位能力，能够跟踪和检测软件执行
过程中的路径、变量和各种中间状态。当软件出现故障或异常时，DT10 可以帮
助测试人员快速定位问题的根源，分析问题的发生过程和原因。
图 -3 DT10 实施流程图
安全测试工具
模糊测试（Fuzz Testing, Fuzzing）是一种重要的信息安全测试技术，广泛应
用于计算机系统、网络通信系统等复杂系统的安全测试，也是渗透测试的必备方
法之一，下面介绍几种模糊测试的工具：
Cybellum
Cybellum 是一款信息安全测试与管理的工具，能够帮助 OEM 及其供应商在
车辆的整个生命周期内大规模评估和降低安全风险。它无需访问源代码，通过
Cyber Digital Twins 技术检测开源软件与第三方应用程序的安全风险，并提供可
实施的修复建议。Cybellum 检测漏洞的来源广泛，支持 CVE、CWE、CNNVD
等漏洞库；可以从组件、产品、系统三个层面进行风险与漏洞管理；能够进行开源
漏洞、零日漏洞评估。
图 -1 Cybellum 软件看板效果图
AFL
AFL（American Fuzzy Lop）是一款基于覆盖引导的模糊测试工具，它通过
记录程序执行的路径信息，对输入样本进行变异操作，如位翻转、字节替换等多
种方式，不断生成新的测试用例来探索程序可能存在的漏洞。AFL 速度相对较
快，能有效发现软件中的多种漏洞，如缓冲区溢出等；近年 AFL 的 Windows 版本
也同样问世，使用者可以使用它对 Windows 下载的软件进行测试并尝试发现漏
洞。
Honggfuzz
Honggfuzz 是一种基于进化的模糊测试工具，它可以从初始的输入种子集合开
始，通过多种变异策略（如随机修改字节、插入块等）来生成新的测试用例， 然
后根据程序的反馈来引导新测试用例的生成。工具可以支持多进程的模糊测试， 利
用多核处理器的优势来提高测试效率，并且该工具支持多种平台，包括 Linux、
MacOS、Windows 等。
SFuzz
SFuzz 是一款基于模型的通用模糊测试工具。其采用框架式结构设计，支持
丰富的模糊测试模型，包括文件格式、网络协议、工业控制协议、硬件设备及物
联网设备等，基于这些模型 SFuzz 可以快速的对各种软硬件系统的组件进行自动
化安全测试，识别其潜在漏洞。SFuzz 具有效率高、可并发、可扩展、可回溯等
优点，能够自动产生大量边界用例、畸形用例、随机用例等，通过这些测试用例发
现被测对象是否存在潜在安全漏洞。
图 -2 SFuzz 软件看板效果图
SCA
SCA(Software Composition Analysis）是软安科技用于软件供应链安全和合规
检测的工具，能够在软件整个生命周期内、针对软件源码项目和二进制文件检测， 为
OEM 提供可视化、透明化软件物料 SBOM，评估软件安全、合规风险，协助处置
最紧要的威胁、持续监测安全情报，使 OEM 实时保障产品安全。
图 -3 软安 SCA 检测全景图
测试管理工具
测试管理工具可用于测试的各个阶段，包括用例管理、测试执行、缺陷管理、
版本管理等。通过在测试中应用这些工具，可以提升测试效率并确保测试的规范性
。
禅道
禅道是一款功能全面的国产项目管理工具，具备项目管理、需求管理、测试
用例管理、缺陷管理、自动化测试和效能管理等多项功能，能够满足各个阶段和不
同测试类型的需求。同时，作为一款开源工具，用户可以根据自身的需求进行二次
开发，满足不同场景的个性化需求。
图 -1 禅道工具的看板界面
JIRA
JIRA 是一款基于 Java 架构的管理系统，具备项目管理、问题跟踪与管理、敏
捷流程管理、团队协作、报告与分析等功能。该系统具有高度的可定制和可扩 展性
，能够根据不同项目的需求进行定制化配置和工作流开发。此外，JIRA 还支持对不
同的用户和角色进行精细的权限管理，以确保项目数据的安全和保密性。
图 -2 Jira 任务列表示意图
INTEWORK TAE&TPA
TAE（INTEWORK TAE）和 TPA（INTEWORK TPA）是经纬恒润自主研发
工具链中用于项目管理与测试管理的一套工具链。
TPA 工具主要应用于项目管理、流程监控与管理、用例管理、执行管理、缺
陷管理等方面。TPA 具备良好的数据共享与协同性，方便团队成员之间的数据共
享和协同工作，同时，它具有灵活的权限管理功能，可以根据不同的角色权限设置
不同的查看和操作权限。
图 -3 TPA 测试用例集管理界面示意图
TAE 工具主要是应用于自动化测试用例搭建、测试执行与监控、测试报告定制
生成等方面。TAE 具备故障注入、标定、测量、诊断、模型在回路测试（MIL） 等一
系列与 ECU 测试相关的功能，能够满足汽车电子领域对 ECU 测试的多种需求。并
支持用户将可重用的测试步骤封装成用户库，提高测试序列开发的效率。
图 -4 TAE 车手互联测试场景
附录
附录 1：测试人员的要求
在汽车行业，软件测试工程师的工作涉及确保汽车相关的软件系统（如
ADAS、车载信息娱乐系统、电控单元等）的安全性、可靠性和性能。这一领域
的测试工作通常可以分为多个阶段，每个阶段的工作内容和技能要求有所不同。
以下是常见的几个阶段划分：
初级软
件测试
工程师
中级软
件测试
工程师
高级软
件测试
工程师
功能安
全/质量
保证专
家
1. 初级软件测试工程师
特点：
入门级测试人员，主要从事手动测试任务，通常是刚毕业或有少量经
验的工程师；
对测试方法和工具的掌握相对基础，工作内容多为执行现有的测试用
例，记录测试结果。
职责：
根据测试规范，执行测试用例，验证软件的基本功能；
记录缺陷并协助开发人员定位问题；
学习汽车行业特定的协议和标准等，如 AUTOSAR、ISO 14229、ISO
15765、ISO 26262、ISO 21434 等。
技能要求：
基础的编程能力（如 C/C++、Python），并进行一些简单的自动化测试；
了解软件开发生命周期和测试基本流程；
具备 POSIX 等系统的常规使用。
2. 中级软件测试工程师
特点：
具备一定的行业经验，能够独立设计测试用例，并进行部分自动化测
试；
开始参与测试流程的优化和工具的开发，负责更复杂的系统功能测试。
职责：
分析需求，设计详细的测试方案和用例；
使用自动化测试工具（如 CAPL、CANoe、dSPACE 等）执行测试；
参与车载系统（如 ECU、通信总线）的集成测试，确保各模块间的协
同工作；
根据标准（如 ISO 26262、ISO21434）对安全相关的软件进行测试和
验证。
技能要求：
熟练使用测试工具和硬件模拟器（如 HIL、SIL）；
掌握常见的汽车行业通信协议（CAN、LIN、FlexRay）；
掌握更多编程语言（如 C/C++、Python、Matlab/Simulink）以开发自动
化测试脚本。
3. 高级软件测试工程师
特点：
具有丰富经验，能够承担项目中的重要角色，负责整个系统或复杂模
块的测试工作；
深度参与软件测试的各个阶段，并可能负责指导初级或中级测试工程
师的工作。
职责：
负责整个项目的测试计划和策略制定；
设计和实施复杂的测试架构，领导关键系统（如 ADAS 或动力系统）
的集成和性能测试；
优化自动化测试流程，并编写高效的自动化测试脚本；
协同开发团队，分析和解决系统级别的问题；
确保符合行业安全标准和功能安全要求。
技能要求：
深入了解汽车电子架构和功能安全、信息安全标准（如 ISO 26262、
ISO21434）；
精通多种测试工具和平台，能够开发复杂的自动化测试环境；
能够进行深层次的性能测试和压力测试。
4. 功能安全/质量保证专家
特点：
专注于功能安全（Functional Safety）和质量保证（Quality Assurance）
的高级角色，参与高安全性或关键系统的评估与测试。
职责：
评估系统的安全性，确保符合 ISO 26262、ISO 21434 的安全要求；
设计和执行安全相关测试，确保系统在故障条件下能够安全工作；
分析安全故障树和失效模式，确保系统的鲁棒性；
负责与外部审核员、认证机构的沟通与合作，确保系统通过认证。
技能要求：
对 ISO 26262、ISO 21434、ASIL、TARA 分析、ASPICE 有深入理解；
熟悉安全评估方法和工具，能进行 FMEA（失效模式及影响分析）、
FTA（故障树分析）等；
丰富的测试经验和强大的系统级别思维能力。
当然，这些阶段并不是绝对分割的，随着项目需求和公司规模的不同，测试工
程师的职责和技能要求可能会有所变化。
