2. ADAS基础认知

做ADAS测试这几年，我越来越觉得——测试不是最后才做的事。它应该从一开始就参与进来。今天聊的三个概念：测试金字塔、V模型开发流程、还有那些测试类型，说白了就是帮你回答三个问题：测什么？什么时候测？怎么测？

2.1 测试金字塔模型

Mike Cohn提出的测试金字塔，在ADAS领域特别实用。它把测试分成三层，越往下越细、越便宜、越容易自动化。

我个人习惯把金字塔倒过来看——越往上的测试，越接近真实场景，但也越贵、越慢。举个例子，一个AEB功能：

• 单元测试：测单个传感器的目标检测算法，跑一次几毫秒
• 集成测试：测传感器融合模块和决策模块的配合，跑一次几秒
• 系统测试：整车在环测试，跑一个场景可能要几分钟甚至更久

2.2 V模型开发流程

V模型在汽车行业用得特别多。它把开发和测试对应起来，左边是设计，右边是验证。你想想看，这其实就是在说：测试计划应该在写代码之前就定好。

V模型的关键在于“对应关系”。系统需求分析阶段，就要开始写验收测试用例。架构设计阶段，系统测试用例就要定下来。这样做的好处是——测试不是事后补的，而是从一开始就参与设计。

2.3 测试类型详解

测试类型按粒度分，主要有四种。在ADAS领域，每种类型都有它的独特之处。

测试类型	测试对象	ADAS典型场景	执行频率
单元测试	函数、类、模块	车道线检测算法、卡尔曼滤波	每次提交
集成测试	模块间接口	传感器融合、CAN信号解析	每日构建
系统测试	完整系统	AEB、ACC、LKA全场景	每周/每版本
验收测试	整车/客户需求	Euro NCAP场景、客户路试	每版本/里程碑

2.3.1 单元测试

单元测试测的是最小可测试单元。在ADAS里，可能是一个目标跟踪算法、一个信号滤波函数、或者一个状态机转换逻辑。

// 示例：AEB决策模块的单元测试
void test_AEB_trigger_when_TTC_less_than_threshold() {
    // 给定：TTC = 1.2s，阈值 = 1.5s
    float ttc = 1.2f;
    float threshold = 1.5f;
    
    // 执行：判断是否触发AEB
    bool result = AEB_decision(ttc, threshold);
    
    // 验证：应该触发
    assert(result == true);
}

2.3.2 集成测试

集成测试关注的是模块之间的配合。ADAS系统里，传感器融合模块和决策模块的接口、控制模块和执行器的通信，都是集成测试的重点。

• 数据流测试：检查传感器数据能否正确传递到决策模块
• 时序测试：验证各模块的时钟同步和延迟是否在容忍范围内
• 异常处理：模拟某个模块失效，看系统如何降级

2.3.3 系统测试

系统测试是ADAS测试的重头戏。它要在完整的系统上验证功能、性能和安全性。说白了，就是让车跑起来，看它能不能应对真实世界的各种情况。

2.3.4 验收测试

验收测试是最后一道关。它回答的问题是：这个系统真的满足客户需求吗？在ADAS领域，验收测试通常包括：

1. 功能验收：逐条核对需求规格书中的功能点
2. 性能验收：在标准测试场跑一遍性能指标
3. 法规验收：满足各国法规要求（比如UN R152对AEB的要求）
4. 用户体验验收：让真实驾驶员在典型场景中试驾

2.4 三种模型的关系

测试金字塔、V模型、测试类型，这三者不是孤立的。它们共同构成了ADAS测试的策略框架：

• 金字塔告诉你测试的分布比例——底层多、上层少
• V模型告诉你测试的时间点——左移、对应、尽早
• 测试类型告诉你测试的具体内容——单元、集成、系统、验收

我个人习惯把这三者画在一张图上。金字塔的每一层对应V模型的一个阶段，而每个阶段又对应特定的测试类型。这样，整个测试策略就清晰了。