一、CarMaker脚本化测试概述
什么是脚本化测试
脚本化测试，说白了就是用代码来替你做测试。
你想想看，平时我们在CarMaker里做测试，是不是这样：打开GUI，点几个按钮，设置场景，然后点运行？一次两次还行，但当你需要跑几百个场景时，手都点酸了。
脚本化测试就是把这些操作写成脚本。CarMaker里用的是Python或TCL脚本。脚本一跑，测试自动执行。结果自动保存。你只需要坐在旁边喝杯咖啡。
我个人习惯把脚本化测试分成三层：
- 底层：控制CarMaker的API调用，比如启动仿真、读取传感器数据
- 中层：测试逻辑，比如判断碰撞时间、检查制动距离
- 上层：测试管理，比如批量调度、结果汇总
我在项目中遇到过一件事。有个同事手动测试了200个场景，花了整整两周。结果客户说参数要调一下。他当场崩溃。后来我们用脚本重写了一遍，参数调整只需要改一个配置文件，重新跑一遍，半天搞定。
核心要点：脚本化测试不是把手工操作翻译成代码，而是用代码思维重新设计测试流程。
为什么需要批量生成
这个问题其实很直接。你想想看，一个ADAS功能要验证多少场景？
| 测试维度 | 参数数量 | 组合数 |
|---|---|---|
| 车速 | 5个值（30/50/70/90/120 km/h） | 5 |
| 目标类型 | 3种（轿车/卡车/行人） | 3 |
| 天气 | 3种（晴天/雨天/雾天） | 3 |
| 道路曲率 | 3种（直道/弯道/连续弯） | 3 |
| 总计 | 135种组合 |
135个场景，手工搭？搭一个场景平均10分钟，那就是1350分钟，22.5个小时。而且人还会出错。
我曾经有一次手工搭场景，搭到第80个时，脑子已经糊了。结果把两个场景的参数搞反了，导致整个测试结果作废。嗯，从那以后我再也不手工搭批量场景了。
批量生成的好处很明显：
- 速度快：脚本生成一个场景只要几毫秒
- 不出错：参数组合由代码控制，不会漏也不会重复
- 好维护：需求变了，改一行代码就行
- 可复现：同样的脚本，谁跑结果都一样
小技巧：我建议用Excel或CSV管理参数组合。脚本读文件，自动生成场景。这样测试工程师也能参与参数设计，不用写代码。
CarMaker测试框架简介
CarMaker的测试框架，其实就三块东西：
- TestManager：测试管理器，负责调度测试用例
- TestRun：测试执行引擎，跑具体的场景
- DataManager：数据管理器，存测试结果
它们之间的关系，我画了张图：
这张图你看懂了吗？我解释一下：
- TestManager 是大脑。它决定先跑哪个用例，后跑哪个。支持并行执行，也支持依赖关系。
- TestRun 是手脚。它负责加载场景、启动仿真、采集数据。每个TestRun实例跑一个测试用例。
- DataManager 是记忆。它把测试结果存成文件，支持CSV、MAT、HDF5等格式。
脚本层在中间，连接用户和框架。你写的Python脚本，通过CarMaker提供的API，调用TestManager、TestRun、DataManager的功能。
注意：CarMaker的API文档有几百页。别想着全看完。我刚开始时也试图通读，结果看了三天，啥也没记住。后来我总结了一个方法：先写一个最简单的脚本跑通，然后遇到问题再查文档。这样效率高得多。
举个最简单的脚本例子：
# 一个最简单的CarMaker脚本
import carmaker
# 创建测试管理器
tm = carmaker.TestManager()
# 加载测试用例
tm.load_test_case("AEB_Straight_30kph")
# 设置参数
tm.set_parameter("ego_speed", 30) # km/h
tm.set_parameter("target_distance", 50) # 米
# 运行
tm.run()
# 获取结果
result = tm.get_result("collision_time")
print(f"碰撞时间: {result} 秒")这段代码虽然简单，但包含了脚本化测试的核心流程：加载、配置、执行、获取结果。后面的章节，我们会一步步把它扩展成能批量生成几百个测试用例的完整框架。
我的经验：刚开始写脚本时，别追求完美。先让一个用例跑通，再考虑批量。跑通一个用例，你就掌握了80%的知识。剩下的20%，是在踩坑中学会的。
公众号:蓝海资料掘金营，微信deep3321