ISO 26262-6的第10章（软件集成与验证） 就是专门解决这个问题的------把各个软件单元"拼"成一个完整的嵌入式软件，验证它们组合在一起后是否仍然安全。
集成测试是什么？跟单元测试有什么区别？
集成测试的"终极目标"
软件集成测试的目标有两个：
-
集成软件元素
------把各个软件单元按架构设计组装成完整的软件组件
-
证明架构设计被正确实现
------验证软件体系结构设计确实被嵌入式软件实现了
简单说：单元测试证明"每块砖是好的"，集成测试证明"砌成的墙是稳的"。
单元测试 vs 集成测试：一张表看懂区别
| 对比维度 | 🧪 单元测试 | 🔗 集成测试 |
|---|---|---|
| 测试对象 | 单个函数/模块（最小可测试单元） | 多个单元组合成的软件组件或整个软件 |
| 核心目标 | 验证每个单元的设计规范是否正确实现 | 验证架构设计和高层需求是否被正确实现 |
| 关注重点 | 单元内部逻辑、接口功能 | 模块之间的接口交互、数据传递和整体功能行为 |
| 测试环境 | 开发环境（PC或仿真器） | 开发环境 → 逐步过渡到目标硬件 |
| 覆盖率要求 | 语句/分支/MC/DC覆盖 | 架构覆盖、接口覆盖、功能覆盖 |
核心区别：单元测试关心"每个零件好不好"，集成测试关心"零件之间配合得好不好"。
两种集成策略：自底向上 vs 自顶向下
ISO 26262没有强制规定集成策略，但行业里主要有两种方式。
策略一：自底向上（Bottom-Up）------"先搭底座，再盖高楼"
怎么做：先从最底层的单元开始测试，逐步移除桩模块（Stub），把多个单元组合成更高层的功能模块。
优点 ：底层单元测试充分，发现问题早
缺点：高层功能验证较晚，整体"长相"出来得慢
策略二：自顶向下（Top-Down）------"先搭框架，再填细节"
怎么做：先从高层模块或子系统开始测试，再逐步加入低层模块。
优点 ：系统整体架构验证早
缺点：需要大量的桩模块（Stub）来模拟底层功能
ACC控制器推荐策略：混合式
在实战中，大多数项目采用混合策略 ------关键底层模块用自底向上（确保基础牢固），核心功能链路用自顶向下（确保整体正确）。ACC控制器作为ASIL-D的安全关键系统，建议以自底向上为主------先把雷达数据采集、跟车距离计算等基础单元测扎实，再逐层向上集成到完整控制链路。
集成测试的"官方菜单"：ISO 26262推荐的方法
ISO 26262-6:2018的Table 3列出了集成测试用例的导出方法。等级越高，需要组合的方法越多。
| 方法 | ASIL A | ASIL B | ASIL C | ASIL D | 大白话 |
|---|---|---|---|---|---|
| 📋 需求分析 | ++ | ++ | ++ | ++ | "架构设计说啥就测啥" |
| 🔌 接口分析 | + | ++ | ++ | ++ | "模块之间怎么通信的？" |
| 📊 等价类分析 | + | + | ++ | ++ | "同类问题测一个代表" |
| 📐 边界值分析 | + | + | ++ | ++ | "边界最容易出问题" |
| 🧠 错误猜测 | + | + | ++ | ++ | "凭经验猜哪里容易翻车" |
| 🔗 功能依赖分析 | + | + | ++ | ++ | "A功能依赖B功能，B挂了A会怎样？" |
| 🔄 共因分析 | + | + | ++ | ++ | "多个模块会不会被同一个故障干掉？" |
| 🌍 环境与操作场景分析 | + | ++ | ++ | ++ | "不同环境条件下怎么表现？" |
| 📈 现场经验分析 | + | ++ | ++ | ++ | "从实际数据里找测试点" |
ASIL-D要用上几乎全部方法------这不是"选做"，是"必做"。
实战：ACC控制器集成测试用例设计
以ACC控制器的"雷达数据采集 → 跟车距离计算 → 安全状态管理"这条链路为例：
| 用例ID | 测试方法 | 测试内容 | 预期结果 |
|---|---|---|---|
| TC-INT-001 | 需求分析 | 雷达数据正确传递给跟车距离计算模块 | 数据传递无丢失、无延迟 |
| TC-INT-002 | 接口分析 | 两个模块之间的数据接口格式是否正确 | 数据类型、范围、单位一致 |
| TC-INT-003 | 边界值 | 雷达传来极远距离（250m）和极近距离（0m） | 系统正确处理边界值 |
| TC-INT-004 | 错误猜测 | 雷达模块发送数据格式错误 | 接收模块检测到错误，不崩溃 |
| TC-INT-005 | 功能依赖 | 雷达数据丢失时，跟车距离计算如何响应 | 触发超时报警，进入安全状态 |
| TC-INT-006 | 共因分析 | 电源波动同时影响雷达和控制器 | 两个模块是否同时失效？是否有隔离？ |
| TC-INT-007 | 环境分析 | 模拟高温环境下模块间通信 | 通信是否稳定？ |
嵌入式软件测试：为什么必须"上真家伙"？
集成测试在开发环境（PC）上完成之后，还有最后一道关卡------嵌入式软件测试（Testing of the Embedded Software） 。
嵌入式软件测试 = 把软件烧录到真实的ECU硬件上，在目标环境中验证它是否真的能跑。
为什么不能在PC上"凑合"？
| 问题 | PC环境 | 真实ECU环境 |
|---|---|---|
| ⏱️ 时序 | 跑得飞快，时序宽松 | 时钟频率受限，时序严格 |
| 💾 内存 | 内存充足 | RAM/Flash有限 |
| 🔌 外设 | 模拟的 | 真实的传感器、执行器、总线 |
| ⚡ 电气 | 稳定电源 | 可能存在电压波动、EMC干扰 |
| 🌡️ 环境 | 室温 | -40℃~85℃ |
PC上跑得好好的代码，烧到ECU上可能因为时序不同而出问题------这就是嵌入式软件测试不可替代的原因。
嵌入式软件测试的三大战场
根据ISO 26262-6:2018，嵌入式软件测试主要包含以下活动：
战场一：软硬件集成测试
把软件烧录到目标ECU上，验证软硬件接口（HSI）是否正常工作------SPI通信对不对、CAN报文能不能发、中断响应及不及时。
战场二：硬件在环（HIL）测试
把ECU接入HIL台架，模拟真实车辆的各种工况------前车急刹、传感器失效、总线通信中断等。
战场三：系统级测试
把ECU装到实车上，在封闭场地或转毂台架上验证整车功能。
HIL测试对功能安全尤其重要------可以在实验室里安全地模拟"雷达信号丢失""前车突然急刹"等危险场景，不用真上路冒险。
实战：ACC控制器从单元测试到嵌入式测试全链路
把以上所有内容整合起来，ACC控制器软件验证的完整路径是这样的：
Step 1：单元测试（PC环境）
测试对象 ：每个独立的函数
测试内容 ：get_radar_distance()、calc_safe_distance()、check_following()等
覆盖率目标 ：语句100%、分支100%、MC/DC 100%
工具：Tessy（PC仿真环境）
Step 2：集成测试（PC环境 + 部分目标环境）
测试对象 ：多个单元组合成的软件组件
测试内容：
-
雷达数据采集模块 → 跟车距离计算模块 的数据传递
-
跟车距离计算模块 → 安全状态管理模块 的接口
-
整个ACC控制算法的端到端行为
覆盖率目标 ：架构覆盖、接口覆盖
工具：Tessy（PC）+ 开始部分在目标板上运行
Step 3：嵌入式软件测试（目标ECU环境）
测试对象 ：完整的嵌入式软件（烧录到ECU）
测试内容：
-
软硬件接口（HSI）验证------SPI、CAN、GPIO是否正常工作
-
时序验证------任务是否在规定的截止时间内完成
-
内存验证------RAM/Flash使用是否在限制范围内
工具：目标ECU开发板 + 调试器
Step 4：HIL测试（ECU + HIL台架）
测试对象 ：ECU + 仿真被控对象
测试内容：
-
模拟前车急刹 → ACC能否及时响应
-
模拟雷达信号丢失 → 系统能否在100ms内进入安全状态
-
模拟CAN通信故障 → 通信监控是否触发报警
工具：HIL台架（dSPACE/NI PXI）
Step 5：实车测试（真实车辆）
测试对象 ：完整车辆
测试内容：安全确认（Safety Validation）------上一期已经讲过
集成测试中容易踩的"坑"
坑1：单元测试过了就直接跳到实车测试
❌ "单元测试都过了，直接上车试试"
✅ 必须逐级验证------单元测试→集成测试→嵌入式测试→HIL测试→实车测试，跳过任何一级都可能遗漏问题
坑2：集成测试还在用单元测试的用例
❌ 把单元测试的用例原封不动搬到集成测试
✅ 集成测试要关注模块之间的交互------接口、数据传递、时序、资源竞争
坑3：忘了测"资源使用"
❌ 只测功能对不对，不管内存和CPU
✅ ISO 26262要求资源使用评价------确认在最坏情况下，CPU时间、ROM、RAM是否充足
坑4：嵌入式测试只在PC上做
❌ 所有的测试都在PC上跑完就完事了
✅ 嵌入式软件测试必须在目标硬件上执行------PC仿真代替不了真实ECU