图1 德国测试委员会基础级专业领域汽车软件测试工程师大纲脑图
一、 测试工作参与的阶段
毫不意外地，除了用户的使用阶段外，测试工作和测试人员要参加全生命周期的其它所有阶段，也就是：系统生命周期中的六个常规阶段除了使用阶段外要全程参与。
一辆汽车以及汽车的所有组件（部件）的系统生命周期都是从产品概念开始，以退役而终止。这一点和软件工程中的软件产品是完全一致的。在整个生命周期过程中，涉及到开发过程、业务过程、以及与制造技术有关的工艺过程。
六个阶段为：
概念（测试计划）；
开发（测试分析、设计、实施、执行、评估和报告）；
生产（终检/下线测试）；
使用（无测试活动）；
维护（维护测试）；
退役（迁移测试）。
其中，维护测试主要发生在软件产品发布之后的维护阶段，和回归测试概念上有一定的重合。这一阶段的测试旨在确保对软件进行的任何修改、升级（比如OTA或者4S店升级）或扩展不会对现有的功能造成负面影响。换句话说，维护测试的目标是验证系统在经过变更后仍然能够正常运行，并且所有功能都保持完好无损。
前一款产品退役，并不意味着其软件和数据都没有用了，恰恰相反，其软件和数据都是宝贵的信息资产。这些信息资产的迁移和复用过程是迁移测试的用武之地。迁移测试是指在数据或系统从一个环境迁移到另一个环境时进行的测试过程。这种类型的测试主要用于确保数据在迁移过程中保持完整性、一致性和准确性。此外，迁移测试还关注迁移过程的安全性，以防止敏感信息在迁移过程中泄露或丢失。迁移测试通常发生在软件生命周期的退役阶段，这时可能需要将数据从旧车型迁移到新车型，或者从本地服务器迁移到云端。迁移测试不仅限于数据层面，还包括对迁移过程中使用的工具和方法的验证，以确保整个迁移过程顺利进行。
二、测试策略和回归测试策略
回归测试是一种软件测试方法，主要用于验证在系统或应用中引入新的更改或修复后，原有的功能是否仍然正常工作。其核心目的是确保最近的代码更新、错误修复或新功能添加不会对应用程序的现有功能产生负面影响。回归的意思就是测试测出问题来给开发，开发修改后回归给测试，也就是还给测试再测一遍，看看以前bug是否修复并且没有引入新bug。
ASPICE的基本实践要求为每个测试（包含回归测试）专用过程制定测试策略。
测试策略包括：
1、功能测试验证软件是否满足需求规格说明书中的所有功能要求。例如，对于电动汽车的电池管理系统（BMS），需要测试其充电控制逻辑、电量估算等功能是否正常工作 。
2、性能测试评估软件在高负载或极端条件下的表现。例如，车联网系统（TSP）在大量用户同时连接时的响应时间和吞吐量是否符合预期。
3、可靠性测试检查软件在长时间运行中的稳定性。例如，IVI（车载信息娱乐系统）在连续使用8小时后是否仍能保持无故障运行 。
4、安全性测试确保软件能够抵御潜在的安全威胁。例如，TBOX（远程信息处理单元）的数据加密机制是否有效防止了数据泄露。
5、兼容性测试验证软件在不同硬件平台、操作系统版本上的兼容性。例如，车载APP在iOS和Android设备上的功能一致性测试 。
回归测试策略包括：
回归测试是在软件修改后重新测试已有功能，以确保没有引入新的错误。确保没有引入新的错误主要是重复旧用例而不是开发新用例，所以主要是自动化策略和持续集成CI策略。
1、使用自动化测试工具（如VectorCAST）来执行回归测试，可以显著提高效率并减少人为错误。例如，在每次代码提交后，自动运行一组核心功能的测试用例，确保这些功能未受影响 。
2、选择关键测试用例，根据历史缺陷数据和功能重要性，选择一组关键的回归测试用例。例如，对于电动汽车的电池管理系统，重点测试充电性能、放电曲线等核心功能。
3、持续集成环境中的回归测试
在持续集成（CI）环境中定期执行回归测试，确保每次代码变更都能被及时验证。例如，每天晚上运行一次全面的回归测试套件，涵盖所有主要功能模块 。
4、测试用例更新机制
随着软件的发展和本企业的积累，不断更新和扩展回归测试用例库。每当新增一个功能或修复一个缺陷时，相应地添加或调整测试用例和对应文档。
表1 测试和回归测试策略简要总结
测试类型
描述
示例
功能测试
验证软件是否满足所有功能需求
电动汽车BMS的充电控制逻辑测试
性能测试
评估软件在高负载下的表现
车联网系统TSP的响应时间测试
可靠性测试
检查软件在长时间运行中的稳定性
IVI系统连续8小时无故障运行测试
安全性测试
确保软件能够抵御安全威胁
TBOX的数据加密机制测试
兼容性测试
验证软件在不同平台上的兼容性
车载APP在iOS和Android上的功能一致性测试
回归测试
在软件修改后重新测试已有功能
自动化工具VectorCAST运行核心功能测试用例
三、 静态测试与动态测试
1、静态测试技术
静态测试主要是对代码的静态检查和对需求的质量评审。
代码静态检查包括 MISRA-C:2012 指南，含可验证规则和指令，分建议、要求、强制三个级别；而需求评审依据 ISO/IEC 29148 标准的质量特性，如可验证性、明确性等，可制定检查表发现缺陷。
MISRA-C:2012 指南是目前开发人员在编程时遵循的最先进的指南之一（这个2023年的大纲并没有提及更高级的AUTOSAR c++ 14规范）。ISO 26262标准也建议对安全相关的软件使用该指南。这些编码标准有助于避免软件中出现异常，而这些异常可能会导致软件中出现缺陷。 同时还有助于开发人员提高软件的可维护性和可移植性。
MISRA-C:2012指南中包含C语言的编程指南。它定义了两种类型的指南：
a、可通过静态分析工具进行验证的规则。例如，源代码不包含嵌套注释。
b、无法通过静态分析工具完全验证的指令。静态检查无效的原因在于，这些指令更多的涉及开发的过程和软件的外部文档。例如，开发人员是否完整且正确地记录了其实现的功能（行为），以及随着代码修改而更新对应的文档。可以参考文章《代码实例辨析｜autosar cpp14编程规范和 MISRA C++:2008编程规范》
https://mp.weixin.qq.com/s/Ujr2rIu0NPe_K2fdI3mqew
每条指南都被归类为以下三个级别中的一个：
建议：在工作量允许的情况下，开发人员应该遵守。
强制：开发人员必须遵循。无一例外。
要求：只在开发人员可以确切地阐述不遵守这项规则的原因的情况下，才可以忽略。
公司组织可以单独强化一条规则或一条指令的要求，但不能降低其要求。
而对需求的质量评审主要是看规格说明说得清不清楚。清楚与否的标准按照ISO/IEC/IEEE 29148:2011描述如下：
可验证性：每个需求都可以通过静态或动态测试来进行验证。
明确性：每个需求都包含明确的测试条件。
一致性：每个需求内部以及它与其他需求之间都保持一致。
完整性：每个需求都要考虑所有可能的情况（包括错误、中止和异常场景）。同时，对使 用的所有图表都进行了标注；定义了缩写和术语的含义。
可追溯性：每个需求都有明确标记（例如，通过ID）。这是可以进行影响分析的前提，并 且测试用例的覆盖度也是透明和明了的。
边界性（针对一组需求）：明确定义了开发和测试的范围。
原子性：无法再将需求进一步细分成有意义的更小部分。
这组标准为需求的规格说明是否清晰提高了评审和判断依据。
2、动态测试技术
1）基于需求的测试
基于需求的测试旨在确保软件功能符合预先定义的需求规格。它通常通过检查需求文档来设计测试用例，并验证软件是否满足所有需求。
实例：假设一个需求是“当车速超过50km/h时，自动开启巡航控制功能。” 测试人员会设计测试用例，模拟不同车速条件下的行为，以确认系统是否正确响应。
2）等价类划分
等价类划分是一种将输入数据划分为若干组的技术，每组中的任意一个值都可以代表该组的所有值进行测试。
实例：对于汽车空调温度设置功能，可以将温度范围（如16°C到30°C）划分为几个等价类，例如低温（16°C-20°C）、中温（21°C-25°C）和高温（26°C-30°C）。选择每个类中的一个值进行测试即可覆盖整个范围。
3）边界值分析
边界值分析专注于测试输入或输出的边界条件，因为错误往往发生在边界附近。
实例：继续使用空调温度设置的例子，测试边界值如15°C（低于最低值）、16°C（最低值）、29°C（最高值前一位）、30°C（最高值）和31°C（高于最高值），以确保系统处理这些特殊情况的能力。
4）语句测试
语句测试要求执行程序中的每一行代码至少一次，以确保代码覆盖率。
实例：在车辆防抱死制动系统(ABS)的控制逻辑中，测试人员需要确保每一条控制路径都被执行过，例如不同的刹车力度和路面摩擦系数组合下的控制逻辑。
5）判定测试
判定测试确保程序中的每个决策点（如if-else语句）都至少被执行一次，且每个分支都被测试。
实例：对于自动变速器控制系统，测试人员需要验证当检测到特定速度变化时，系统是否正确地选择了升档或降档操作。
6）MC/DC覆盖测试
MC/DC（Modified Condition/Decision Coverage）测试确保每个条件的独立影响都被测试到，并且每个决策的结果都被测试。
实例：在电动车电池管理系统中，如果有一个规则“如果电池温度过高或电量不足，则触发警告”，则需要分别测试温度过高但电量充足、温度正常但电量不足以及两者都不满足的情况，确保每个条件都能单独影响决策结果。
7）错误推测
错误推测是一种基于经验和技术知识预测可能存在的错误并设计相应测试用例的方法。
实例：考虑到某些车型可能会出现因信号干扰导致的仪表盘显示错误问题，测试人员可以故意引入信号干扰，观察系统是否能够正确识别并恢复。
8）故障注入
故障注入是指故意向系统中引入故障，以评估系统的容错能力和恢复能力。
实例：在测试分动箱ECU时，可以通过自动化故 障注入工具模拟传感器故障（如轮速传感器失灵），然后观察ECU如何响应并采取适当的措施。
9）背靠背测试
背靠背测试是通过比较两个相同或相似系统的行为来验证被测系统正确性的方法。
实例：对于一款新型电动汽车的动力总成控制系统，可以将其与已知良好性能的传统动力总成控制系统进行对比测试，确保两者在相同条件下表现出一致的行为模式。
四、XiL测试环境
X代表模型，软件，处理器，硬件、车辆等等
汽车行业的测试环境远比软件行业复杂。在汽车行业中，会使用以下类型的XiL测试环境：X = [Model,software，processor，hardware，vehicle]之一。
模型在环（MiL, Model in the Loop）
模型在环测试是在开发初期阶段进行的一种验证方法，一般是MBD（model based development）方式开发的simulink模型或者其他编程语言表达的数学模型。它通过使用数学模型来模拟控制器和被控对象的行为，从而验证控制算法的逻辑和功能是否满足需求。这种测试通常不涉及任何物理硬件或生成代码，而是完全基于软件模型进行。
假设正在开发一种新的自适应巡航控制系统（ACC）。在MiL环境中，可以创建一个车辆动力学模型和交通场景模型，并将这些模型与ACC算法连接起来形成闭环。然后，可以通过改变道路坡度、前方车辆速度等参数来测试ACC算法的响应是否符合预期 。
软件在环（SiL, Software in the Loop）
软件在环测试是用于验证自动生成的代码与原始模型之间的一致性。在这种测试中，控制器的软件运行在主机PC上，而不是目标硬件上。通过这种方式，可以在没有硬件的情况下对软件进行广泛的测试，包括单元测试和集成测试。
继续以ACC为例，在SiL环境中，可以将从MiL阶段验证过的算法转换为嵌入式C代码，并在PC上运行该代码。然后，可以使用相同的交通场景模型来测试生成的代码是否表现出与MiL阶段相同的行为。
处理器在环（PiL, Processor in the Loop）
处理器在环测试是为了评估目标处理器上的软件性能。在这种测试中，生成的代码运行在实际的目标处理器上，但其余的仿真仍然在主机PC上执行。这使得开发者能够检查代码在特定硬件上的行为，例如实时性能和资源消耗。
对于ACC应用，在PiL环境中，可以将ACC算法的代码加载到实际的ECU处理器上，并通过PC模拟交通场景。这样可以观察到代码在真实处理器上的执行时间和内存使用情况，确保其满足实时性和资源限制要求。
硬件在环（HiL, Hardware in the Loop）
硬件在环测试一般是在测试台架上进行，是对整个控制系统进行最终验证的关键步骤。在此阶段，控制器硬件和软件都被部署到真实的ECU上，而其余的环境（如传感器输入、执行器输出）则由仿真模型提供。这种方法允许在接近真实的条件下测试控制器的功能和性能。
在HiL环境中，ACC系统的ECU会被连接到HiL仿真器上，该仿真器模拟雷达传感器的数据输入和其他车辆动态。通过这种方式，可以测试ECU如何处理实际的传感器数据并输出正确的控制信号给执行器。
图2 HIL示意图，图片来自网络
车辆在环（ViL, Vehicle in the Loop）
车辆在环测试结合了真实的车辆和虚拟环境（比如巨型台架或者试车场），以进一步验证各种实车功能，比如高级驾驶辅助系统（ADAS）或自动驾驶功能。在这种测试中，真实的车辆装备有传感器和执行器，并在虚拟环境中运行，以便测试复杂的交通场景和极端条件下的系统表现。
图3 巨型台架上的VIL，图片来自网络
图4 试车场上的VIL，图片来自网络
比如对于一辆配备了ACC功能的测试车，在ViL环境中，可以将其放置在一个包含虚拟交通参与者的模拟城市环境中，比如在试车场摆放纸板假人、充气假车辆和模拟交通灯。通过这种方式，可以测试ACC系统如何应对各种复杂场景，如紧急刹车、变道和交通拥堵。
五、测试环境和测试环境的常规组件
测试工程师需要尽早开始测试,以便尽早发现开 发程中的缺陷｡同时，测试工程师还需要在尽可能真实的环境中测试系统,以找出成品中可能会出现的缺陷｡测试工程师可以使用与不同开发阶段相匹配的测试环境来解决此矛盾，也就是从前面描述的Xil中选一个合适的X｡为此,测试工程师可以在量产或开发的电控单元(ECU)完全可用之前,实施和执行个别测试任务｡测试工程师通过使用不同的测试环境,可以模拟场景并执行在实际车辆环境中难以展现的测试用例,例如, 电源线短路和断路,或网络通信过载｡
若要能够执行测试，需要一个可以模拟缺失组件的测试环境。在这个测试环境中，测试工程师可以触发输入并观察输出，也称为“控制点”（PoC）和“观察点”（PoO）。
根据ISO/IEC/IEEE 29119，测试环境由以下组件构成：
测试环境的硬件（上位机、具备实时处理能力的计算机（如需要）、测试台、开发工具包等）；
测试环境软件（操作系统、仿真软件、环境模型）；通信设施（网络入口、数据记录仪）；
工具（示波器、测量工具）；
实验室（防止电磁辐射和噪音）。
测试环境的最重要组件是环境模型，属于测试环境软件之一。该模型也是虚拟测试环境的重要组成部分。它模拟了真实环境的必要元素，例如发动机、变速箱、车辆传感器和电控单元，甚至是驾驶员或道路状况。测试环境还包含不同的访问接口，可以使用这些接口来测量和观察被测项。
假设对一款自动驾驶汽车的控制单元进行功能与性能测试，该系统需要验证其在不同环境条件下的响应能力和稳定性。
具体的测试环境组成如下：
1. 测试环境硬件
上位机：一台高性能工作站，用于运行测试脚本和管理测试流程。
具备实时处理能力的计算机：一台嵌入式工控机，模拟车辆控制单元的实际运行环境。
测试台架：一套硬件平台，包括传感器接口板、电机控制器以及模拟车辆动力系统的设备。
开发工具包：提供API接口和调试工具，支持自动化测试脚本编写。
2. 测试环境软件
操作系统：Linux（实时版本），确保测试过程中的时间同步性和可靠性。
仿真软件：CarMaker，用于生成虚拟驾驶场景并模拟传感器输入。
环境模型：MATLAB/Simulink中的车辆动力学模型，用于预测车辆行为。
3. 通信设施
网络入口：千兆以太网交换机，连接所有测试设备。
数据记录仪：高速数据采集卡，用于记录车辆控制单元的输出信号。
4. 工具
示波器：Tektronix MSO58，用于捕捉和分析电压波形。
测量工具：数字万用表和压力传感器校准装置。
5. 实验室
电磁屏蔽室：减少外部电磁干扰对测试结果的影响。
消声室：降低背景噪音，保证测试精度。
在以上环境中，比如测试验证自动驾驶汽车在雨天湿滑路面上的紧急制动性能。
测试步骤：
使用CarMaker创建雨天湿滑路面的虚拟场景，并通过仿真软件向车辆控制单元发送传感器数据（如速度、加速度、雨量传感器读数）。
启动嵌入式工控机上的控制算法，并记录其输出信号。
使用示波器捕获控制单元的刹车指令信号，并通过数据记录仪保存数据。
在实验室中模拟实际雨天环境，重复上述步骤以验证系统的一致性。
测试结果评估：
检查刹车响应时间是否符合设计要求。
分析刹车力度曲线是否平稳且满足预期。
图5 制动力曲线，图片来自网络
以上举例的测试案例的参考标准如下：
ISO/IEC/IEEE 29119: 软件测试国际标准。
IEEE Std 1057: 数据采集系统指南。
SAE J3016: 自动驾驶分级标准。
六、ASPICE测试能力评估维度
就像自动驾驶级别分级一样，ASPICE通过一个包含六个级别的评估系统对过程能力进行评估（以级别显示）。
级别0级到3级的定义如下：
L0（过程不完整）：过程不存在或不能实现过程的目标。示例：测试工程师只检查了小部分的需求。
L1（已执行过程）：所执行的过程实现了过程目标（但执行方式与原计划可能不一致）。示例：没有测试过程的完整计划。但是，测试工程师可以展示需求的满足程度。
L2（已管理过程）：项目对过程进行了规划，并在执行过程中进行了监督。在某些情况下，为了实现目标，会在执行过程中调整行动计划。确定了对工作产品的要求。项目成员检查了工作产品并进行了核准。示例：测试经理确定了测试目标，规划了测试活动，并监督了测试过程。如有偏差，他会采取相应的措施。
L3（已确定过程）：项目采用标准化的过程，并使用结果和反馈不断改进和提升。示例：测试经理为整个组织制定了一个通用测试策略。测试完成后，测试经理会进一步对它进行开发和改进。
能力级别4和5目前不在汽车行业重点关注范围之内。
4,5没有覆盖主要是个性价比问题。
能力级别4要求全面定量管理过程。组织需要对过程性能进行量化管理，并基于统计数据来预测和控制过程的结果。然而，在汽车行业，由于项目的多样性和不确定性较高（例如供应商的变化、法规的更新等），完全依赖量化管理可能难以实现。量化管理的成本和资源投入很高，需要专门的大数据人员和采集设备，而汽车行业通常希望保持较低的成本投入。
能力级别5要求组织需要持续优化过程，以达到最佳实践水平。然而，汽车行业更注重的是“够用即可”，而不是不计成本追求最优解。过多的优化可能会导致资源浪费，且无法带来显著的额外收益。
所以说ASPICE的能力级别1到3已经能够覆盖大多数汽车软件开发的需求。这些级别能够保证基本的过程质量、管理和改进，而无需进一步提高到4和5。
七、 总结
相比于IT/ICT行业的测试人员，车辆行业测试工程师的工作和硬件绑定较深，技术栈也更复杂。这一点也体现在薪酬上。根据职友集的数据，53.5% 的IT软件测试工程师（大专）岗位拿 8000 - 15000 元 / 月，年薪 10 - 18 万；而车辆行业测试工程师70.5% 的岗位月薪在 8 - 20K，年薪约 10 - 24W。无论是总额还是平均值，车辆行业测试工程师都高于自己在IT行业的同行一些。
比如车辆测试工程师需要了解不同 XiL 测试环境（MiL、SiL、HiL等等）的适用场景。MiL 适用于开发早期测试功能性系统设计，可测试单个组件或整个系统；SiL 用于测试基于模型生成源代码的软件实际行为与预期行为的差异，常见测试类型有功能测试、接口测试和回归测试；HiL 用于测试有原型或已完成开发的测试对象，可进行组件测试、集成测试和系统测试，发现软件和硬件中的缺陷。
而这些场景需要额外的软件、硬件和系统知识。比如MiL模型在环测试，特别是闭环控制测试，就相比于IT界的同行，需要知道如下额外知识：
1、控制系统理论：理解控制系统的基本原理，包括滤波、反馈控制、前馈控制、稳定性分析等。能够运用控制理论对系统模型进行分析和设计，以确保系统在各种工况下的性能和稳定性。
2、数学基础：不同于IT界，大部分信号和数据都是离散的，车辆系统的数据和信号多数是连续的，并且涉及运动，所以涉及大量的微分积分和矩阵计算，所以需要如线性代数、微积分、概率论与数理统计等知识，用于模型的建立、分析和求解，以及对测试结果进行数据处理和分析。而且理解控制论本身就需要深厚的数学功底。
3、建模与仿真知识：因为模型一般就是指simulink仿真模型，极少数情况是其他编程语言，所以需要熟练掌握 MATLAB/Simulink 建模和仿真的基本方法，能够将实际系统使用simulink的各种block抽象和组合为数学模型，还要会搭建仿真环境，生成模拟数据来通过仿真来验证模型的准确性和有效性。IT和ICT行业除了研究人员，MATLAB/Simulink用得相对少得多。
4、汽车电子系统知识背景：针对汽车领域的 MiL 测试，需要了解汽车电子系统的架构、功能和通信协议（特别是can协议）。熟悉汽车的各种传感器、执行器的工作原理，以及电子控制单元（ECU）的功能和编程。
这些知识和技能相当考验从业人员的知识功底和操作能力。
来源：焉知汽车
作者：咖啡鱼
