2026-07-16 04:50:22 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文以汽车自适应巡航控制(ACC)功能为例，详细阐述了基于ISO26262标准的ECU软件V型开发测试流程。从系统需求到软件需求、设计及代码实现，依次介绍了单元测试（含MISRA规则、功能测试及等价类边界值分析）、软件集成测试、硬件在环测试和实车测试的方法与工具。文章强调测试用例需覆盖所有逻辑分支和边界条件，并指出各阶段测试的侧重点与局限性，为汽车嵌入式软件测试提供了清晰的实践参考。 综合评分： 87 文章分类： 安全测试,安全建设,解决方案,技术标准,应用安全

cover_image

汽车ECU软件测试

谈思实验室

2026年7月15日 17:56 上海

在小说阅读器读本章

去阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

我们就以ISO26262软件部分描述的V型开发流程为线索，举一个实际例子来说明。对V型开发流程不熟悉的同学欢迎去看我以前写的文章和回答，这里就不再赘述了。

图1. V型开发流程

一、先编一个需求吧

假设现在我写了一个系统级的需求（System Requirement），也就是图1里的“Technical Safety Concept”:

(这里多说一句和测试无关的话，所有的Techincal Safety Concept都是系统级需求，不是软件需求，面试的时候别搞混了)

System Requirement

The Adaptive Cruise Control (ACC) function shall only be active when the ego-vehicle is traveling between 30kph and 120 kph.[ACC-SysReq 001]

Once ACC deactivated, it cannot resume automatically.[ACC-SysReq 002]

这家车企比较怂，它的自适应巡航功能只能在30公里到120公里每小时之间激活，并且一旦退出后不可再自动激活。

为了简单起见，我们先不管第二条需求了，只看第一条。下面我把这个系统需求写成软件需求（Software Requirement）：

Software Requirement

The signal ACC Active State shall be set to READY if the following conditions are fulfilled[ACC-Req 001]:

Safe Vehicle Speed is greater or equal to 30kph AND
Safe Vehicle Speed is less than or equal to 120kph.

The signal ACC Active State shall be set to SUPPRESSED if the following conditions are fulfilled[ACC-Req 002]:

Safe Vehicle Speed is less than 30kph OR
Safe Vehicle Speed is greater than 120kph.

再接下来软件设计文档里，也就是图1的Architectual Design里可以写：

Design Requirement

Acc_ActSt shall equal to READY if:

SafeVehSpd is greater or equal to 30kph AND
SafeVehSpd is less than or equal to 120kph.

Acc_ActSt shall equal to SUPPRESSEDif:

SafeVehSpd is less than 30kph OR
SafeVehSpd is greater than 120kph.

好了，这就是个最简单的需求例子。根据这个需求，你写了几行代码来实现。我们假设用C代码，在原有的C文件acc.c中加入了：

有同学可能会说，你有病啊写成这样，第一个if语句写完了直接写else不就完了嘛。对，但是我也不知道客户以后会怎么改这个需求，也许会对其他速度段增加新的状态，所以我就先写个else if在这里，方便以后扩展。

到这一步，”V”模型的左半边你就做完了，现在我们开始来测试。

二、单元测试

写完代码编译成功以后，先开始进行单元测试，也就是图中的“Software Unit Verification”。顾名思义，就是把你这个新编写或者修改过的单元（单独的C文件，在本例中是acc.c)与整个工程隔离开，单独测试其输入输出。

图2. 单元测试只关心某个具体的软件单元

汽车行业呢，首先就是做MISRA 规则测试。MISRA 测试是静态测试的一种，用来检验代码是否符合一系列具体的编程规则。这里我们假设用的测试工具是QAC。

就我写的这段，估计啊会报出一个warning, 因为 “else” 这个分枝事实上是无法触发的，而MISRA的其中一个规则就是所有代码都必须可触发，所谓“Accessible”。当然啦，这里我是有意为之，所以可以注释一下就放过去了。

下一个步骤是进行Polyspace测试。Polyspace工具可以进一步可以帮助判断算法在计算过程中，会不会产生诸如数组index超范围、overflow、被除数是零之类的bug 。我们这个例子中只有逻辑判断，所以其实不需要做Polyspace测试。

接下来进行功能测试。在功能测试中，我们要：

分析待测单元有哪些输入信号和输出信号
编写一系列的输入信号值，并同时写出这些输入信号值所对应的正确的输出信号值。我们把这个叫做“测试集”。
以测试集中的输入信号值为输入，运行单元代码。如果输出信号的值和测试集中的正确输出信号值相同，则功能测试通过。

编写测试集的一个基本原则是要把所有的代码都覆盖到，并且尽量测试所有判断逻辑。上面所示的例子非常简单，只有一个输入变量 SafeVehSpd 和一个输出变量 Acc_ActSt。

我们需要把输入变量按判断逻辑分成若干个Equivalent Class 。在这个例子中，（假设 SafeVehSpd 是 Unsigned int 型, 速度范围的上限是500 kph）输入信号SafeVehSpd 就可以分成三个 Equivalent Class:

i. [0, 30）

ii. [30, 120]

iii. (120,500]

于是在这三个Equivalent Class里随机各取一个值，就能测试所有代码逻辑了。但是实际测试中，我们往往还进一步要求进行边界测试, 也就取每个Equivalent Class的两端的值来进行测试。这就涉及到精度问题了。假设这段代码是定点运算，车速数值由10bit 表示，前述车速上限是500，于是车速的精度就是 500/（2^10） = 0.48828125。

所以严格来说，测试集需要测试的输入变量SafeVehSpd的值有6个，分别是 0 ，29.5117188 ，30 ， 120 ， 120.48828125 ， 500 。

当然，现在很多工具支持自动生成测试集，所以不用程序员费劲巴力的去算这些破玩意儿了。

需要说明的是，就算进行了完善的功能测试，也并不能保证功能就没有bug….因为实际工程中中各种输入信号的组合是无穷无尽的，再加上时序等等因素，功能测试不可能穷尽所有的实际情况，我们只是尽力而为。

汽车行业比较流行的单元测试工具有Cantata、VectorCAST 等等。

三、软件集成测试

单元测试完成以后，就要把测试好的软件单元放到整个工程里来测试。这一步对应了图1中的“software verification and integration”。

图3.集成测试关注整个系统的输入输出

在单元测试中，我们通过直接改变SafeVehSpd 的值来进行测试。而事实上，SafeVehSpd 数值的源头，来自CAN 总线上的车轮轮速数据。

假设如图3所示，从轮速传感器，由CAN总线传来的原始车轮轮速信号WheelSpdRaw 先经过通信接口模块 COM_IF.c处理，再经过车速计算模块VehSpd.c计算以后 ,才得到信号SafeVehSpd 。那么在集成测试中，我们需要通过更改WheelSpdRaw这个信号的数值来对acc.c中的代码进行测试。这是为了验证acc.c模块和其他模块的接口是否正确以及各个模块之间是否有冲突。

进行软件集成测试的时候，图示的三个模块其实合并在了一起形成了一个“黑盒”，我们只关心最初的输入信号WheelSpdRaw 和最终的输出信号Acc_ActSt 之间的逻辑。

在实际工程中，COM_IF.c、VehSpd.c 和 Acc.c 三个模块很可能是由三个工程师在同时并行开发的，这就可能导致任何一个模块单独进行集成测试都通过不了。这时候就需要由项目经理或者product owner提前进行沟通协调，确保所有功能都更新以后，三个模块一起进行集成测试。

软件集成测试流行的工具和单元测试一样，也是Cantata之流。

软件单元测试和软件集成测试都可以被称为软件在环测试（Software in the loop , SIL)。

四、硬件在环测试（HIL）

软件在环测试完成以后，下一个步骤就是硬件在环测试（Hardware in the loop, HIL），对应了图1中的 “Testing of embedded software”。有一些企业在HIL之前还会进行一次PIL （Processor in the loop）测试，这里就不讨论了。

HIL test也是集成测试的一种。前面说的软件集成测试，是运行在PC 仿真环境中的，而实际ECU无论是算力、内存、各种硬件性能等等方面和PC环境都有很大的不同，所以相同的功能还要继续在实际硬件环境中再测试一遍。

也就是说，HIL test与软件集成测试最大的不同在于，前者运行于实际硬件中，而后者只是运行在计算机仿真环境下。

硬件在环测试的主要工具是实际的零部件。比如测试ACC功能的话可以是ADAS控制器，或者是集成了ACC功能的毫米波雷达、摄像头等。除此之外还要有一个实验台架提供必要的运行环境、电力供应和总线接口。

常用的HIL test工具比如dspace的那些死贵死贵的测试环境，dspace control desk。

和软件集成测试一样，HIL test也是改变原始的CAN信号（例子中的WheelSpdRaw）来进行测试，只不过，这一次不是直接改变WheelSpdRaw在内存中的数值，而是通过HIL test 台架真的向ECU通过CAN 发送真实的WheelSpdRaw信号。

HIL test的测试集，也就是测试用例（test case）需要和软件需求 Software Requirement 严格对应，可以是一对一，一对多或者多对一都可以。所有的 HIL test case 都必须根据一条对应的Software Requirement 写出，但是条件就没有单元测试时候那么苛刻了。

比如为了测试需求ACC-Req 001，HIL test case 可以写成：

Turn ECU on;
Set all wheel speed at 0;
Turn ACC function on;
Observe ACC status to be SUPPRESSED;
Gradually increase all wheel speed to 31 kph;
Observe ACC status change to READY after 30 kph;
Gradually increase all wheel speed to 121 kph;
Observe ACC status change to SUPPRESSED;
Gradually decrease all wheel speed to 119 kph;
Observe ACC status change to READY below 120 kph;
Gradually decrease all wheel speed to 29 kph;
Observe ACC status change to SUPPRESSED;
Turn ECU off.

需要把trigger和recover的情况都覆盖到。事实上这个测试用例也可以用来测试ACC-Req 002，这就是“一对多”的情况。

五、实车测试

实车测试就很好理解了，在所有前述测试都通过以后，工程师上车来实际测试相关功能。这对应了图1中的“System and item integration and testing”。实车测试用例需要根据系统需求来制定。

对于本文的例子，可以写成：

1.着车后打开ACC功能，保持车辆静止。观察仪表盘，ACC 功能未启动。

将汽车加速至30kph，再次打开ACC 功能，观察仪表盘，ACC启动。将汽车减速至29kph，观察仪表盘，ACC 功能退出。
将汽车加速至110 kph，打开ACC 功能，观察仪表盘， ACC 启动。将汽车加速到121kph，观察仪表盘，ACC 功能退出。

来源：知乎@木城

https://zhuanlan.zhihu.com/p/336330751

end

谈思汽车媒体门户

精品活动推荐

AutoSec系列沙龙

专业社群

部分入群专家来自：

新势力车企：

特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……

外资传统主流车企代表:

大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……

内资传统主流车企：

吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……

全球领先一级供应商：

博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……

二级供应商(500+以上)：

中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……

人员占比

公司类型占比

文章

不要错过哦，这可能是汽车网络安全产业最大的专属社区！

关于涉嫌仿冒AutoSec会议品牌的律师声明

一文带你了解智能汽车车载网络通信安全架构

网络安全：TARA方法、工具与案例

汽车数据安全合规重点分析

浅析汽车芯片信息安全之安全启动

域集中式架构的汽车车载通信安全方案探究

系统安全架构之车辆网络安全架构

车联网中的隐私保护问题

智能网联汽车网络安全技术研究

AUTOSAR 信息安全框架和关键技术分析

AUTOSAR 信息安全机制有哪些？

信息安全的底层机制

汽车网络安全

Autosar硬件安全模块HSM的使用

首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：谈思实验室《汽车ECU软件测试》