AI 工具在测试中的＂可用边界＂:用真实案例说话

最近两年尤其是今年以来，AI 在测试领域的讨论热度一直很高。但一线工程师的真实体验往往很复杂——生成内容不稳定、结论难以追溯、数据合规有隐患。

这篇文章不讲大道理，直接上案例。核心观点还是一句：AI 是辅助，不是判定依据。

一、需求理解与测试点梳理

案例1：车载ECU功能安全测试

某 Tier1 供应商开发新一代域控制器，ISO 26262 ASIL-B 等级，测试团队需要基于 HARA 分析报告梳理测试点。

工程师把 HARA 文档和《功能安全测试规范》喂给 AI，指令是："列出所有需要验证的安全机制，包括故障注入点、预期行为和验收标准。"

AI 在 20 分钟内输出了 80+ 条测试点，其中有一条让工程师眼前一亮："在 CAN 总线负载率 >80% 时注入 ECU 通信超时，验证看门狗是否在 100ms 内触发安全状态切换。"

这个场景测试经理之前漏掉了——AI 从文档里"读"出了"高负载下故障检测延迟可能增加"这个隐含风险。

但这条测试点能否纳入正式用例，必须由功能安全工程师确认：看门狗超时阈值到底是不是 100ms？安全状态切换的具体行为是什么？AI 不知道，它只是在"推理"。

案例2：BMS 电池管理系统测试用例

某动力电池厂商开发新一代 BMS，测试团队需要覆盖过充、过放、过温、短路、绝缘检测等安全场景。

AI 辅助生成了 120 条测试点，其中一条是："在 -30°C 低温环境下模拟单体电压采样线断路，验证 BMS 是否在 500ms 内切断主继电器并上报故障码。"

这条用例的价值在于：低温下采样线电阻变化、断路检测阈值漂移，是实际售后故障的高发场景。AI 从历史故障数据库里"学"到了这个模式。

但 500ms 这个阈值对不对？继电器切断后是否需要保持故障锁定状态？这些必须由 BMS 算法工程师确认。

二、日志与波形辅助分析

案例3：2GB CAN 日志，8 小时 → 50 分钟

某国内头部车企的故障分析项目，车辆在路试中偶发通信丢失，日志大小 2GB（ASC 格式），要求 1 天内定位根因。

传统方式预估需要 2-3 天：用 CANoe 打开日志（30 分钟）、人工筛选异常报文（1 小时）、逐个分析错误帧（2 小时）、关联分析相关信号（3 小时）、编写分析报告（1 小时）。

这次用了 AI 辅助：Python 脚本预处理日志（10 分钟）→ AI 自动检测异常（5 分钟）→ AI 生成分析报告（5 分钟）→ 人工确认根因（30 分钟）。总计约 50 分钟。

最终定位到的问题是：某个 ECU 在特定温度下会重启，导致通信丢失。

但关键一步是"人工确认根因"——AI 给出了"ECU 重启"的推测，工程师必须回到原始日志和硬件行为去验证，不能直接把 AI 的结论写进报告。

案例4：偶发 CAN 信号冲突复现

某新能源车企遇到一个头疼的问题：车窗升降偶尔失灵，故障概率只有万分之一，靠人工反复触发+盯日志，测了一周都没复现。

他们用 AI 工具采集了 3 天的总线数据，让 AI 学习"异常信号的波形、出现时间、伴随的其他 ECU 交互"规律。AI 自动生成了 100+ 组模拟信号，精准复现了"车速 80km/h + 空调开启时的信号冲突"故障，整个过程仅用 4 小时。

最终定位到是网关 ECU 的滤波参数设置不合理。

但这里有一个重要边界：AI 生成的模拟场景能帮助复现问题，仿真数据不能替代实车耐久与极限验证——真实道路载荷、温差突变、量产件离散性这些物理因素，仿真环境无法完整复刻。

案例5：示波器波形异常检测

某电源模块测试中，工程师需要监测输出电压纹波。传统做法是人工盯着示波器看波形，或者设置简单的阈值告警。

他们引入了 AI 波形分析工具：把示波器采集的波形数据喂给 AI，让它学习"正常纹波"的模式。运行一天后，AI 标记了 17 个"异常波形片段"——这些片段在时域上看起来正常，但频域分析显示存在间歇性高频振荡，频率约 2MHz，幅度只有 50mV。

人工复查确认：这是 MOSFET 驱动电路在特定负载下产生的寄生振荡，长期运行可能导致 EMI 超标。

但 AI 标记的 17 个片段中，有 5 个是探头接触不良导致的噪声，不是真实异常。AI 只能提示"这里可能有问题"，最终判断必须靠工程师用示波器重新测量验证。

三、脚本与测试程序生成

案例6：LabVIEW 测试序列生成

某产线 EOL（End of Line）测试工位需要测试 30 项功能：电压检测、CAN 通信、继电器吸合、传感器校准……传统做法是工程师手动拖拽 LabVIEW 模块搭建测试序列，一个工位需要 2-3 天。

他们尝试用 AI 辅助：把测试规范和设备清单喂给 AI，让它生成 LabVIEW 测试序列的框架代码。AI 在 1 小时内生成了 80% 的框架——模块连接、参数配置、数据记录结构都搭好了。

但剩下的 20% 花了工程师 2 天：

• AI 生成的 CAN 通信模块没有处理"总线关闭"异常；
• 继电器测试序列里没有加入"吸合时间测量"，只做了"通断检测"；
• 数据记录格式不符合公司 MES 系统要求。

AI 能帮你搭框架，但硬件测试里的"细节"——时序、异常处理、设备兼容性——必须人工补全和验证。

案例7：Python 自动化测试脚本

某电池包测试工程师需要写一个脚本，控制充放电柜按特定工况运行，同时采集电压、电流、温度数据，并在异常时触发保护。

他让 AI 生成脚本框架，AI 很快给出了代码。但跑第一次就出问题了：

• AI 用的充放电柜通信协议版本是旧的，新设备返回的数据格式不一样，脚本解析失败；
• 脚本没有处理"设备通信超时"的情况，一旦充放电柜短暂断连，脚本直接崩溃；
• 保护逻辑里只判断了"电压超限"，漏掉了"温升速率超限"这个关键保护条件。

工程师花了半天时间逐行审查、修改、在测试环境验证，才让脚本真正可用。AI 生成的测试脚本必须经过人工审查和本地运行验证，绝不能直接部署到产线或实验室。