AI 到底能不能替车载测试工程师写测试用例?我做了个实验

事情是这样的。

这两天，我一直刷到一个很凶猛的说法。

AI 已经能替代 80% 的测试用例编写了。

80%。

这个数字很有杀伤力。一个刚做两三年车载测试的工程师，白天还在对着需求文档拆前置条件，晚上刷到这句话，心里多少都会咯噔一下。

辛辛苦苦学会 CAN、UDS、DoIP，刚能看懂一点状态机，好不容易不再被一屏十六进制报文吓住，结果人家告诉你，DeepSeek、ChatGPT、Codex 往这里一坐，几十秒就能把你一天的活干了。

不是哥们，那我这些年是在练什么？？？

我非常理解这种焦虑。

但我也有点不信。

不是不信 AI 会写用例。现在随便找个主流大模型，把一段需求贴进去，它确实能输出一张像模像样的表格。用例编号、前置条件、操作步骤、预期结果，一个不少，排版甚至比很多刚入行的测试工程师还整齐。

我不信的是另一件事。

写得像测试用例，和真的能拿去测车，是一回事吗？

所以我今天做了一个很小的实验。

先把边界讲清楚。这个实验没有使用任何企业项目资料，也不假装是什么真实量产项目。我临时编写了一条简化的自动落锁需求，用它观察 Codex 在不同信息量下会生成什么。

原始需求很短。

车辆启动后，当车速达到 15 km/h，且四门关闭时，车辆自动落锁。

就这一句话。

然后我把它原样交给 Codex，让它生成完整测试用例。

几秒后，它给了我 12 条。

有车辆启动、四门关闭、车速达到 15 km/h，验证成功落锁。

有车速低于 15 km/h，不落锁。

有任意车门打开，不落锁。

还有车速从 14 km/h 上升到 15 km/h、四门状态组合以及车辆未启动等场景。

说真的，第一眼看过去，我觉得还挺像那么回事。

如果任务只是把一句需求扩成一张测试用例表，它已经完成了，而且完成得很快。正常路径有了，反向路径也有了，边界值也知道卡在 14、15、16 附近。

愚钝如我，手工整理这一版，肯定比它慢。

但我盯着那 12 条看了一会儿，问题开始一个接一个冒出来。

15 km/h 到底用仪表显示车速，还是底盘发送的原始车速？

车速信号无效时怎么办？

信号超时怎么办？

车门在 14 km/h 时关闭，和在 16 km/h 时关闭，系统行为一样吗？

落锁以后减速到 0，再次加速到 15 km/h，要不要重复执行？

驾驶员手动解锁以后，车辆还在 20 km/h，系统是立即重新落锁，还是等下一次阈值穿越？

四门关闭的信号和车速越过阈值在同一个周期到达，谁先谁后？

电源模式从 ON 切到 ACC，再切回 ON，落锁状态是否重新初始化？

低电压、通信中断、执行器卡滞时，系统要不要报码？要不要重试？

最要命的是，原始需求根本没有回答这些问题。

AI 也没有。

它很聪明地给了我一份最符合常识的答案，却没有提醒我，这个常识可能不是项目里的真实规则。

 

这一下就很有意思了。

因为测试工作的价值，恰恰藏在这些没写出来的地方。

你想想看，如果这是一个普通网页的自动保存功能，漏掉一个边界条件，可能只是用户多点一下按钮。但在车上，同一句看起来很简单的需求，背后连接的是电源状态、网络通信、车身控制器、门锁执行器、故障诊断以及用户行为。

车不是一个页面。

它是一群控制器在几十种状态下同时说话，有时候还互相抢话。

于是我做了第二轮。

这次我没有只给一句需求，而是补充了信号定义、状态优先级、初始化条件、故障处理和测试输出规则。

我告诉 Codex，车速取指定 CAN 信号，信号状态包含有效、无效和超时。自动落锁只在当前点火周期第一次向上穿越 15 km/h 时触发。任何车门未关闭都禁止落锁，门状态恢复后，需要车速重新从阈值下方向上穿越。驾驶员手动解锁后不立即重锁。执行器反馈超时需要记录失败结果，但这次实验不自行假定诊断故障码。

我还要求它给每条用例标记需求来源、前置状态、输入时序、预期输出和待确认项。

第二轮，它生成了 28 条。

这次就不只是正常、异常、边界三个框了。

它开始覆盖阈值穿越，开始区分信号无效和超时，开始考虑门状态与车速状态的先后顺序，也把手动解锁后的行为单独拆了出来。

更重要的是，它终于在几处写下了待确认。

比如执行器失败是否需要重试，需求未定义。

比如点火周期的判定事件，需求未定义。

比如多个车门状态同时变化时是否存在防抖时间，需求未定义。

看到这里，我反而比看到那张漂亮表格更兴奋。

因为一个靠谱的测试工程师，最有价值的输出，很多时候不是多写了几条用例，而是指出了需求里哪些地方根本没法测。

不会就是不会。

不知道就是不知道。

先把洞指出来，比靠常识把洞填上靠谱得多。

但第二轮也没有神奇到哪里去。

它能根据我给出的约束组合场景，却不知道真实车辆里哪个信号容易抖，哪个控制器在休眠唤醒时会晚几个周期，哪个执行器反馈在低温环境下会变慢。

它也不知道某个看起来很奇怪的测试步骤，是团队去年吃过一次亏以后才加进去的。

这些知识不在通用模型里。

它们散落在缺陷单、评审记录、台架日志、总线报文，以及一个老测试工程师看到异常波形时皱起的眉头里。

回到最开始的问题，AI 到底能不能替车载测试工程师写测试用例？

答案其实被这两轮实验劈成了两半。

能写。

但未必能负责。

如果你把测试用例理解成编号、步骤和预期结果组成的文档，那么 AI 已经很能打了。它整理得快，格式稳定，不嫌重复，还能在几秒钟里组合一批常规边界。

这部分工作，确实正在被压缩。

TesterHome 上那篇讨论 AI 测试的文章，标题里用了 80% 这个很刺激的数字。文章还汇总了一些效率和覆盖率案例，但不少案例没有公开企业名称、实验设计和原始数据，所以我不敢把 80% 当成整个行业的平均答案。

可是它传递出的方向，我认为没错。

大量重复性的用例整理工作，正在迅速变便宜。

阿里云开发者社区有篇文章讲得也很直接，未来的分水岭不是会不会让模型生成用例，而是能不能设计一套受控的生成体系。需要先把需求结构化，把字段和状态讲清楚，再让模型生成，最后加入自动校验。

当然，那篇文章是社区作者观点，不是阿里云官方结论。

但它和我这次实验撞在了一起。

第一轮，我只给模糊需求，AI 给了我 12 条看起来正确的用例。

第二轮，我把真实约束和判定规则补进去，AI 才给出 28 条更接近工程使用的结果。

模型没换。

变的是输入里的工程知识。

那这些工程知识是谁提供的？

还是测试工程师。

更扎心的证据来自 Autoware。

2025 年，一项针对自动驾驶开源软件 Autoware 的研究，收集了 8 个软件模块中的 1126 个函数，用大语言模型生成单元测试。

研究人员发现，只使用基础提示时，GPT-4o-mini 在 planning 模块生成测试的构建成功率低于 10%。生成代码最常见的构建错误，是搞错符号，比例达到 29.8%。简单理解，就是模型会调用不存在的函数和类，或者把现有接口用错。

低于 10%。

看到这个数，我寻思了一下我没寻思明白。

如果连编译都过不了，那张测试用例表排得再漂亮，又能说明什么呢？

但这项研究最有价值的地方，不是证明 AI 不行。

研究团队后来做了 AwTest-LLM，把 Autoware 项目里的依赖信息和测试示例一起提取出来，再交给模型。在 GPT-4o-mini 的实验里，8 个模块有 6 个模块的文件构建成功率和运行成功率得到提升。

所以问题不是 AI 能不能写。

而是你有没有把它放进一个能获得正确上下文、能编译、能执行、能反馈的闭环里。

NVIDIA DriveOS 团队做的 HEPH，也走的是这条路。

它不是让工程师把一句需求丢进聊天框，然后祈祷模型灵光一闪。HEPH 会从需求管理系统提取信息，再去软件架构文档和接口控制文档里找对应内容，建立需求与文档片段之间的追溯关系。

接着生成测试规范，生成 C/C++ 测试实现，编译，执行，收集覆盖率，再根据缺口继续补。

NVIDIA 在 2024 年的技术博客里披露，多个内部试点团队报告最多节省了 10 周开发时间。

这个数字来自 NVIDIA 自己的试点，没有公开完整样本和测量基线，所以不适合直接外推到所有团队。

但它至少说明了一件事。

真正厉害的不是让 AI 写一张表。

真正厉害的是，把需求、文档、代码、执行结果和人工反馈接成一条链。

 

这条链一旦跑起来，AI 才不是一个嘴很快的实习生，而是研发流程里真正能干活的一环。

车载测试还有一道更高的墙。

安全。

ESREL 2026 收录的一篇研究，讨论了如何在 ISO 26262 功能安全开发流程中使用 AI。论文认为，AI 可以辅助危险分析、需求工程、系统与软件架构，以及验证确认活动中的信息提取、分类和一致性检查。

听起来很美。

但研究同时强调，AI 仍面临解释不清、结果难以重复、缺少明确工具资格认可程序等问题。作者给出的方向也很克制，逐步引入，明确验证方法，保留人工监督，并定期评估。

注意这里的姿态。

是辅助。

不是把功能安全经理从会议室里请出去，让模型坐在签字席上。

因为安全相关测试不是多生成几条异常用例就结束了。需求从哪里来，用例为什么能覆盖它，执行环境是否受控，结果能不能重复，异常由谁判断，最终证据由谁承担责任，这些都得留下可以检查的链条。

AI 可以生成答案。

责任不能自动生成。

写到这里，我突然想到工业革命早期的工厂。

电动机刚出现的时候，不少工厂只是把原来的蒸汽机换成电动机，生产组织、设备布局和管理流程都没怎么变。机器换了，效率却没有想象中飞起来。

后来真正吃到电力红利的工厂，不是单纯换了一台更先进的机器，而是围绕电力重新设计整套生产方式。

今天不少团队用 AI 写测试用例，也有点像把蒸汽机换成电动机。

以前工程师手工写 Excel，现在让 ChatGPT 写 Excel。

表格快了。

流程没变。

需求还是散的，接口文档还是旧的，缺陷经验还是躺在聊天记录里，生成结果没人校验，执行结果也回不到模型。

然后大家看着那几十条一秒生成的用例，兴奋地说，测试效率革命了。

革命了个寂寞。。。

我自己的感受是，车载测试工程师接下来真正要练的，可能不是和 AI 比谁打字更快。

你可以从今天就做一件很小的事。

别再只问 AI，帮我根据下面需求生成测试用例。

把需求拆成可验证的输入。

告诉它测试对象是什么，信号从哪里来，合法值和无效值是什么，状态怎样迁移，冲突时谁优先，故障后如何恢复，哪些内容没有定义。

再要求它把每条用例绑定到具体需求，让它主动列出假设和待确认项。

生成完成以后，不要先数有多少条。

先问四个问题。

它有没有偷偷补写需求？

它有没有漏掉状态恢复？

它有没有把常见经验当成项目规则？

它生成的结果，能不能在台架、仿真环境或实车上执行并重复？

一开始这么做，可能比直接手写还慢。

你得整理需求，补充上下文，设计输出格式，还得一遍遍纠正模型。说实话，刚开始甚至会怀疑，我折腾半天，就为了让它帮我写一张表？

但坚持一段时间以后，你留下来的不只是一批用例。

你会慢慢得到一套团队自己的需求模板、检查规则、领域词典、历史缺陷库和自动评估方法。

到那时，换一个车型，换一个控制器，甚至换一个模型，这套能力还在。

这才是测试工程师真正应该握在手里的东西。

所以 AI 会不会替代车载测试工程师？

我现在的答案，比实验前更乐观，也更残酷。

它不会一口气替代一个完整的测试岗位。

它会一点一点拆掉岗位里那些能够被标准化、重复执行和自动校验的工作。

先是格式整理。

再是基础场景扩写。

然后是脚本生成、执行分析和回归推荐。

最后留下来的，是需求追问、风险判断、系统建模、工程取舍，以及对结果负责。

如果一个人的全部价值，就是把别人写好的需求改成测试用例格式，那确实危险。

但如果你知道需求哪里没写，知道哪个边界最容易出事，知道如何把一次缺陷变成以后不会再漏的规则，还能把这些知识教给 AI，那么你不是被它替代的人。

你是那个决定它能不能进入测试流程的人。

回到今天那条只有一句话的自动落锁需求。

第一轮，AI 很快给了我答案。

第二轮，我才意识到，真正重要的不是它写出的 28 条。

而是我们一起找出的那些问号。

测试工程师的价值，从来不只是回答问题。

很多时候，是比别人更早发现，问题还没有被问对。

大时代啊，朋友们。

别和 AI 比谁写得快。

去做那个知道该测什么、为什么测、出了问题谁负责的人。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。