最近一个月我几乎每天都在跟同一个幽灵较劲——公司自研的AI质检系统明明上一轮回归测试跑得好好的下一轮就突然给同一条客户对话打出了两个完全不同的风险分。一开始我以为是环境问题排查了半天最后发现是模型在自由发挥。这就是我想写这篇东西的原因测试AI和测试传统软件真的完全是两码事。如果你是一名软件测试工程师正准备接手AI产品或者你已经在AI测试项目里被各种不可解释的问题折磨得头秃这篇内容值得你花十分钟看完——我会把这段时间踩过的坑、试出来的方法、以及那些让我深夜怀疑人生的意外全部摊开来讲。1. 从一次见鬼的回归测试说起AI产品为什么这么难测1.1 同样的用例跑五次五个结果那天版本要上线验收之前我按惯例把100条核心回归用例跑了一遍。第一遍92条通过8条失败我不服气重跑90条通过10条失败再跑95条通过5条失败。同一个版本同一个环境同一条用例结果在两次执行里都能不一样。传统软件测试讲究可复现性——一个Bug复现不了提Bug单都要被开发驳回。但在AI产品上这条铁律直接失效了。后来我才明白LLM推理本身带有随机性。即便你固定住prompt和输入当模型做采样生成时每一步都会从概率分布中选取下一个token同一个输入在两次推理中可能走出完全不同的路径。这不是偶发故障而是模型的底层机制。我一度改用贪婪解码、temperature调到0结果仍然不可完全复现——因为浮点运算在不同算子实现下也会有细微差异更别提GPU的并行处理顺序了。这段经历给我上的第一课是测试AI产品之前你得先问一句——我们测的到底是确定性系统还是一个天生带有随机性的系统如果答案是后者你的整套测试策略都要跟着变。1.2 测试堡垒的坍塌断言无从写起传统功能测试的根基是断言。点击按钮弹出一个对话框字段值等于预期值这就叫通过。可AI产品的输出是自然语言面对请对这条客户投诉进行情感分析这样的输入模型可能回复客户情绪偏负面也可能回复语句中含有明确不满情绪建议回复时效性调高。这两段话语义相同但字符串完全不同。如果你拿精确匹配去断言AI输出的正确率会让你怀疑人生如果你拿包含关键词去断言模型换一种措辞绕过你预设的关键词断言就失效了。跟我搭过传统自动化框架的同事第一次写这类用例时是崩溃的他问我断言都没有测试还测什么我当时也答不上来但后来我意识到AI测试不是取消断言而是把断言从字符串层级提升到了语义层级。2. 测试AI的第一性原理从输出对不对到行为合不合规2.1 你要测的不是单条输出而是一个分布既然单次输出带有随机性那我们能测的只能是一个行为分布。我后来的做法是每条case跑N次一般N5或N10统计输出落在什么范围内的概率。比如一个风险评估任务模型5次里有4次给出高风险、1次给出中风险这条用例就不是简单通过或失败而是需要一个通过率或者一致性分数。这个转变非常关键。我举一个例子同样是电商客服的投诉识别单独跑一次看起来没问题但按分布去跑10次之后你会看到模型在退货原因和商品质量问题这两个类别上经常摇摆。这个摇摆频率本身就是最重要的测试结论——它可以转化为模型的置信度指标喂给开发去调优也让业务方知道模型在哪些边界情况下还不稳定。2.2 语义断言用模型去测模型解决断言没法定的办法是用模型来做语义评估。我们团队试过三种路子模板加正则适合非常固定的输出结构比如判断回复是否包含订单号这种用传统方式就够了。文本相似度计算用余弦相似度对比模型输出和人工参考答案的语义距离超过阈值算通过。轻量、快但对复杂逻辑比如是否漏掉了关键动作无能为力。LLM作为评估器写一个独立的评估prompt让它判断模型输出是否满足预设的业务要求输出是/否/不确定再配合人工抽检。这个方法最灵活也是AI产品团队现在最常用的。这里有个陷阱用模型评估模型评估模型本身也有偏见和幻觉所以你需要定期做评估器校准——拿一批已知标准答案的样本去验证评估器的打分准不准。我们在实践中发现某些评估prompt会倾向给长回复高分跟业务方的主观判断有偏差这就要调整评估器的评分标准而不是直接信任它。2.3 数据漂移监控测试不是上线前一次性的事传统功能上线之后你要关注的通常是服务是否挂了但AI产品上线之后哪怕服务没挂输入数据的分布也会变。你的线上客户一天比一天说话更AI化很多人找客服时自己先copy了一段AI生成的话或者某个地区突然推出新政策客服话术中多了大量新词汇——这时候模型在测试集上表现很好在线上却开始犯低级错误。所以我们后来搭了一个非常朴素但有效的监控每天随机采集100条真实线上输入跑一遍离线评测看关键指标准确率、拒绝率、平均置信度有没有明显回落。发现异常不要急着甩锅算法先做数据分析看是数据漂移还是模型退化这个动作让我们避免了好几次半夜被业务方电话叫醒的惨剧。3. 把幻觉当Bug上报之后非确定性缺陷的身份困境3.1 什么是可复现至少要对随机种子保持敬畏有一次测试环境里的AI写手功能凭空生成了一段客户要求退款并投诉媒体的内容但原始对话里完全没有这回事。我兴冲冲提了一个重大Bug开发回了一句你跑几次每次都复现吗结果我还真复现不出来。因为模型在低概率采样路径中编造了不存在的细节属于典型的幻觉它既不是每次必现也不是完全随机的而是概率性触发。后来我养成了一个习惯不管提什么Bug先做复现实验至少跑十次记录触发概率。如果触发概率低于某个阈值比如5%还不能算作严重缺陷而更像一个待优化的质量风险如果触发概率在30%以上就必须启动专题分析。这类概率触发的问题我会把触发样本的种子参数、模型版本、推理参数全部记录下来作为附件贴在Bug单上。虽然开发仍然可能因为环境不同复现不了但至少我们双方有了一批坏样本能过一起去分析模型的哪些环节产生了错误分支。3.2 记录坏样本比记录失败用例更重要在传统软件测试中一个失败的用例通常自带完整的输入和输出开发照做就能定位。但AI测试里哪怕你把同一个prompt发给开发开发用自己的模型版本跑一遍可能完全复现不了你的结果。所以你需要保存的是坏样本本身——模型在这个输入上给出了错误输出这个输出可能包含模型生成的完整日志、分布概率、甚至内部attention权重。我把这些坏样本组织成了一个坏样本集每次发版前用这个集合回归一遍。这个动作带来的收益立竿见影以前开发改一版模型我只能靠感觉判断是不是变好了现在直接用坏样本集在模型A和模型B上各跑一遍对比错误率有没有下降。所谓AI测试从某种角度讲就是不断扩充和清理这个坏样本集的过程。3.3 Prompt也是测试代码版本化你的测试输入我们团队有个很痛的教训。某个Prompt我们直接在线上改了两个字没有走配置下发流程结果所有测试用例的输出格式全变了一轮。排查半天最后发现是Prompt被直接改在了代码里甚至没有提交记录。那一刻我意识到Prompt对AI产品的行为影响不亚于一行核心逻辑代码——它是需要被版本管理、评审、回归测试的一级公民。现在我们的做法是所有Prompt统一走配置平台每一次修改都生成一个新版本号测试用例挂在具体的Prompt版本下面。一旦线上出了问题我们第一件事就是确认线上Prompt版本与测试基线是否一致这一步能在五秒内避免至少一个小时的瞎排查。4. 荒诞背后用AI测试AI的双向奔赴4.1 用大模型生成测试数据的实践测试AI产品最缺的就是测试数据。我们曾经为了构造愤怒客户对话样本人工写了整整两天也只写出了一百来条还带着强烈的人工味——句式工整、逻辑清晰、情绪表达过于明显跟线上真实数据完全不像。后来我们开始尝试用大模型生成对抗样本和变异数据把已有的种子样本喂给模型要求它改写成方言版本、口语化版本、语序错乱版本、含蓄不满版本等等。这一试就很上头。原来我们完全没想到模型在擦边表白式投诉这种语义含糊的样本上会这么脆弱——客户说你们这个质量呵呵模型居然判成了中性。这类样本用人工编写很容易被我们不自觉地写成经典抱怨句式但模型改写之后它把真实世界那种语言表达的多样性给带进来了。用AI生成测试数据不等于编造假数据而是用生成方式穷举真实可能出现的表达变体。4.2 多AI协作一个生成一个评估一个监督现在很多团队在做AI Agent我们的测试平台也在尝试多智能体协作。一开始我只想做个简单的自动化测试助手后来发现一个智能体根本不够用你让它生成测试用例它可能一本正经地编出了业务上不存在的场景你让它评估结果它可能被另一个模型的长篇大论带着走。于是我们搭了一个三方协作的结构用例生成Agent负责产出候选测试场景评估Agent负责对输出打分监督Agent负责抽样检查两边的质量判断生成Agent是否在捏造、评估Agent是否在误判。这个结构谈不上多高大上但它解决了一个核心问题——用模型去校验模型永远需要一个第三只眼否则错误会悄悄双向强化。4.3 测试开发的新技能树写评测脚本和调Prompt也是一种测试过去招聘测试工程师我重点看自动化脚本能力和对业务的理解现在面试经常有人问我你了解LLM评测吗你写过评估集吗这确实是一个新方向。作为一个老测试我的真实感受是我们的核心能力发现问题、定位问题、推动解决并没有变但解决问题的工具变了。最主要的两个新工具就是评测脚本和Prompt调优。多数情况下一条AI测试用例本质上就是输入文本 预期行为描述 评估标准全都写在调试Prompt的过程里。所以现在测试工程师和算法工程师的边界正在模糊——你不再只是找Bug你还要参与定义什么样的模型行为是及格的。这个定义工作传统测试很少参与但在AI测试里它恰恰是最高价值的环节。5. 找AI产品Bug的避坑清单都是拿真金白银换来的5.1 复现三板斧固定种子、锁定模型快照、冻结Prompt版本给AI产品提Bug先按下面的步骤做可复现实验避免被开发一句我这边好的啊打回来设置并记录随机种子如果框架支持或至少记录temperature、top_p等采样参数。锁定模型快照版本。模型迭代更新后同一个输入可能得到完全不同的输出所以必须记录模型版本号。冻结Prompt版本。线上Prompt和测试环境Prompt不一致是大量伪Bug的根源。每一个无法复现的偶现问题记录触发概率和坏样本比硬要一个结论更重要。这不是妥协而是AI测试的客观现实有些问题不是每一次都会出现的但它们累积起来会影响产品体验值得跟进。5.2 从热搜词看趋势物联网设备、银行项目、渗透测试都在变最近我注意到行业里的热门问题也在跟着变从前大家问软件测试怎么学、软件测试面试八股文现在已经开始问涉及物联网设备的软件测试怎么测、AI生成图片怎么测、Agent测试怎么测。我还看到有同行在琢磨怎么把Prompt和用例一起管理这跟我的体会完全一致——AI测试这条路其实是在把传统测试的成熟方法论搬到行为不可穷举的新系统上。物联网设备尤其如此。设备端的模型更新频繁网络环境五花八门一旦把AI嵌入到设备端传统测试搭一套固定测试环境的思路就失效了你必须建设一套支持多版本、多环境、多输入分布同时跑的测试矩阵。银行项目则更看重合规和安全这让我联想到渗透测试领域同样面临新挑战——Prompt注入本质上就是一种新型攻击面。这些方向在未来几年会持续缺人也是老测试工程师转型的好机会。5.3 三个至今仍然让我头疼的开放问题如果文章到此就结束有点过于岁月静好了说实话这些坑到今天也没有完美解法评估器本身的偏差到底怎么系统化消除我们的评估模型偶尔会放过明显的错误输出人工抽检也很难发现它的失误规律。语义冲突场景下怎么制定唯一正确的断言当模型对同一条影评既被要求判断情感又被要求判断是否包含广告倾向时两套标准的优先级冲突会让断言极其不稳定。回归测试成本怎么控每条用例跑N次意味着N倍的计算开销测试团队如果没有GPU资源AI回归测试可能排队排到天荒地老这需要平台能力和预算的支撑。这些问题目前没有标准答案我也不觉得短期内会有。它们就像传统软件测试当年面对自动化率怎么提升环境不稳定怎么处理一样是需要整个行业共同磨出来的。最后分享一个我自己的小习惯每次遇到AI产品意外输出我第一反应不再是想这Bug怎么提而是先截图、留存输入、记录参数然后顺手再喂十遍看看概率。这个动作帮我过滤掉了很多伪Bug也帮开发省下了大量无意义的定位时间。测试AI与其说是找Bug不如说是在给一个非确定性的黑盒画行为画像——画得越细产品就越可靠这大概就是这条路最迷人的地方。