最近有个测试朋友去面一家做智能客服系统的公司回来之后跟我说了句话整场面试没有被问一个具体的接口怎么测、用例怎么写反而所有问题都绕着同一个主题——“你懂模型吗你怎么验证一个 AI 功能是对的”他说自己面试了这么多年第一次觉得测试的抓手全都不见了。这不是个例。从算法工程师要求测试参与模型评估到普通业务系统开始接入大模型能力再到各种 AI Agent 工具出现在日常开发流程里“测试岗要懂 AI”已经从一句提醒变成了很多企业的实际面试题。今天这篇文章我想从一个测试工程师的视角把这类面试背后真正在考的东西拆开讲清楚顺便聊聊一个更本质的问题AI 测试面试题到底想筛出什么人。1. 先搞清楚 AI 测试面试题背后的真实考点1.1 面试官问的不是“会不会 AI”而是“能不能建立新的验证逻辑”很多人一听说 AI 测试面试题第一反应是去背卷积神经网络、Transformer、注意力机制这些概念。但根据我看到的真实面试反馈面试官很少让你背模型结构。他们要看的是你拿到一个 AI 功能后能不能设计出验证方法。传统测试的思维方式通常是逻辑驱动的。用户登录时输入正确账号密码系统返回成功输入错误密码系统返回错误提示。每一步都符合预期结果可以精确复现。但 AI 功能不一样它的核心是统计模型做出的概率判断。同一个输入模型输出的结果可能带有一定随机性数据分布一旦变化模型表现可能明显波动。面试官想确认的是你能不能从“对错二元”的测试思路切换到“概率分布 指标阈值 样本集合”的验证思路。这比单纯记忆概念难得多。它不是背出来的能力而是需要你在实际项目里动手踩过坑、调过样本、对比过指标才能真正建立起来。1.2 这类面试更看重测试工程师的一个转变从验证者变成质量守护者传统测试中测试工程师的职责是验证开发完成的功能是否符合需求。但 AI 系统的质量不再是一个固定不变的版本而是一个会随数据漂移、模型更新、用户群体变化而持续变化的状态。所以面试题里那些关于“样本不平衡怎么办”“模型准确率高但实际不好用怎么办”“训练集和线上数据分布不一致如何处理”的问题真正想考察的是你有没有意识到AI 系统的测试不可能在某个时间点“测完”。它是一个持续观察、持续验证、持续回归的过程。如果你只是把 AI 测试当成“对模型跑一遍测试用例”那就理解偏了。面试官要看到的是你有没有能力围绕一个模型建立一套质量保障机制包括数据准备、离线评估、上线前验收、上线后监控。这个转变决定了一个测试工程师在 AI 项目里的不可替代性。2. 高频 AI 测试面试题背后的思路拆解我没有办法列出一份所谓的标准答案清单因为不同公司、不同方向的 AI 测试面试内容差异很大。但把常见的面试问题归类后你会发现它们集中在五个维度上。2.1 模型评估类怎么判断一个模型好不好模型评估是 AI 测试面试中最常见的问题常见出题形式包括准确率、召回率、F1 值分别是什么什么时候不能只看准确率AUC 是什么为什么模型在测试集上表现好到线上就变差这类问题并不是让你背公式而是考察你能不能结合业务场景选择合适的评估指标。面试经典陷阱是一个二分类模型准确率非常高但实际业务里根本没有发挥作用原因可能是类别不平衡。比如一个欺诈检测系统正常样本占 99.9%异常样本只占 0.1%。不管你模型怎么预测“都是正常”准确率都高达 99.9%但显然毫无价值。这个时候应该关注召回率——异常样本中有多少被找出来了以及精确率——模型判定的异常中有多少是真的。F1 值则是两者之间的平衡。我的建议是回答这类问题时不要只说指标定义。你先说传统指标是什么再说为什么在 AI 场景里会失效最后补一句“如果业务更在意漏报我会优先看召回率如果更在意误报对用户的打扰我会优先看精确率”。这才是面试官想听的答案。2.2 数据与样本类测试 AI 时最大的难点其实在数据AI 模型的表现高度依赖训练数据但测试工程师在实际验证模型时面对的往往不是训练数据而是一批需要设计出来的测试数据。面试中围绕测试数据的问题通常会有这么几个方向测试数据从哪里来如何保证测试数据的覆盖度和代表性样本不平衡时怎么处理当模型在测试样本上表现良好但上线后效果明显变差你会怎么排查先说数据来源。常见的测试数据来源包括线上真实请求脱敏后的数据、公开数据集、人工构造的边界场景数据、基于规则生成的组合数据。真正关键的是你不能只依赖其中一种因为真实用户产生的数据才能反映线上分布人工构造的数据才能覆盖边界场景。再看样本不平衡。面试时比较稳妥的回答路径是先分析业务本身对哪类错误更敏感再考虑要不要用重采样、合成少数类样本、调整分类阈值或者更换评估指标。不要一上来就说用 SMOTE 造数据很多业务场景里合成数据反而会影响模型在真实分布上的表现。关于线上效果变差的问题核心排查链路是数据分布是否发生漂移、特征是否出现缺失或异常、模型有没有被错误版本覆盖、线上逻辑和离线评估逻辑是否一致。这类问题没有标准答案但有一个明确的排查顺序先核对输入再核对环境再核对参数最后再怀疑模型本身。顺序反了很容易浪费时间。2.3 AI 在测试中的应用类不是问“你会不会写脚本”而是问“你会不会用 AI 重构测试流程”这一类面试题现在已经成了很多公司的必考内容。比较典型的问法包括你了解 AI 自动化测试吗有没有用 AI 生成过测试用例AI 编程工具你觉得能替代测试工程师吗先说 AI 生成测试用例。这个方向听起来很酷但面试官真正关心的是AI 生成的用例你是不是只会复制到工程里就完事了。一个合格的测试工程师应该关注边界条件、异常输入、数据依赖和前置状态。AI 能帮你生成的是基于常见模式的用例框架但里面的业务约束和异常场景仍然需要人来补充。更值得关注的是 AI 编程工具对测试工作的实际影响。现在很多测试工程师已经在用 AI 编程工具辅助写接口自动化脚本、生成页面对象、补充断言逻辑。这类工具确实能提升编码效率但面试官不希望听到“AI 能自动写完所有测试”这种判断。它不能替代你对业务逻辑的理解也不能替代你对缺陷的敏感度。比较好的回答思路是把 AI 定位成“效率放大器”而不是“智力替代品”。比如我会用 AI 编程工具快速生成脚本模板然后花费更多精力在梳理业务场景、设计异常用例和校准断言的正确性上。这样既展示了你会用工具也说明你没丢掉测试工程师的核心判断力。2.4 质量保障与回归类模型更新之后如何保证不出问题AI 系统的质量保障与传统软件有一个很大的不同传统软件只要不改代码行为就不会变但 AI 系统就算代码完全没有改动只要上游数据变化、模型重建、特征逻辑调整行为就可能变化。面试中常见的题型包括模型版本升级你怎么做回归测试如何保证新旧模型的效果不下降有没有遇到过模型上线后表现波动的情况这类问题考察的是你有没有建立“AI 持续测试”的心智。回答时可以提到三层回归策略第一层是离线回归用历史样本集同时跑旧模型和新模型对比关键指标确认没有明显退化。第二层是小流量验证通过 A/B 或灰度发布让一部分真实流量进入新模型观察业务指标和监控指标。第三层是线上监控建立针对模型表现的数据监控关注预测分布、置信度、转化率、用户反馈等指标一旦出现漂移就触发告警。这个三层策略几乎是 AI 质量保障的核心思路。如果你此前没有 AI 项目经验至少要把这个框架记下来面试时能按这个顺序展开说明你具备体系化的思考能力。2.5 工程化与部署类AI 测试不只是写在本地 notebook 里的验证脚本随着 AI 项目进入生产环境面试官开始关注测试工程师对部署链路和工程化质量的理解。经常出现的问题包括模型推理服务的接口怎么测如何评估模型服务的性能AI 服务的稳定性如何保障模型推理服务的接口测试和普通接口测试类似但仍然有差异。普通接口的返回结果通常是明确的 JSON 结构测试时可以断言某个字段的具体值但模型推理服务返回的是概率、列表或生成文本断言时要更多关注返回结构是否完整、结果是否符合基本约束、耗时是否在合理范围内。比如一个推荐模型你很难断言某个具体商品绝对应该被推荐但你可以断言推荐列表长度、类别多样性、响应时间上限。性能测试方面需要关注 GPU 或 CPU 资源占用、推理延迟、并发能力与模型复杂度之间的平衡。这里的难点不在于压测工具本身而在于如何设计合理的并发模型。如果只是把请求数拉到很高然后看平均延迟意义不大。更合理的做法是把请求分成不同特征分布观察模型的推理耗时是否受输入长度、批次大小、温度参数等因素影响。3. 把面试题还原成实际工作流一个 AI 功能从验证到上线的通用思路3.1 先跑通一条最小验证链路而不是一上来就搭完整测试框架很多测试工程师第一次接触 AI 项目时习惯性先搭自动化框架、写测试计划、设计一大堆用例。但 AI 功能最大的特点是效果不稳定你必须在掌握基本输入输出之前先手动走一遍验证流程。我的建议是拿到一个 AI 功能先准备 5 到 10 条足够多样化的输入样例手动调用一次模型把输出记录下来。这个过程的意义不是做测试而是帮助你理解模型在真实输入上的表现边界。你会慢慢发现模型对某些表述特别敏感对换行、标点、措辞变化会产生完全不同的输出。先跑通这个最小链路你才能知道后续的测试数据应该怎么设计评估指标应该怎么选断言应该怎么写。如果跳过这一步直接写自动化用例很可能出现的问题是你以为在测 AI实际上只是在测 API 接口是否有返回。3.2 建立样本集和预期输出这是 AI 测试最重要的基础设施AI 测试中测试用例的概念会被“样本集”部分取代。样本集不是简单的输入输出对而是包含多条覆盖不同场景的输入数据以及对应的预期表现描述。预期的表示方式不需要像传统测试那样精确到值。比如一个文本分类模型样本集里可以这么写输入纯正面的用户评价预期类别应该是正面置信度不应该低于某个阈值备注用于验证基础正确性输入包含反讽、谐音、错别字的评价预期不应直接被判定为负面备注边界情况用于验证模型的鲁棒性这样的样本集需要长期积累。每发现一个线上问题就把出问题的输入加入样本集形成回归样本库。这比一次性写几百条用例更有价值因为它是随着真实业务逐步完善起来的能覆盖真实用户的实际表达。3.3 确定评估指标和验收基线没有指标的测试等于没有门禁AI 功能的验收不能拍脑袋说“感觉效果还行”。你需要先在项目初期确定评估指标并和产品、算法、测试三方共同确认一个基线值。这个基线值不一定是最高指标但一定是可接受的最低标准。评估指标的确定需要结合业务目标进行分析。一个搜索推荐场景你可能关注点击率、曝光到点击的转化、个性化程度一个内容审核场景你可能关注误判率、漏判率和审核响应速度。务必区分离线指标和线上业务指标因为离线指标好不一定线上业务指标好。从工程经验看可以按以下顺序确定验收标准明确业务目标这个功能是为了提升效率、降低成本还是提升用户体验。定义指标口径准确率、召回率、置信度、耗时、人工修正率等。跑一次基线版本用当前已上线的旧逻辑或 v0 版本跑出当前水平。设置验收阈值以基线版本为参照要求新模型在关键指标上不明显低于基线在目标优化指标上有所提升。不要在项目开发后期才开始讨论评估指标。否则很容易出现模型已经训练完了测试才发现没有明确的验收标准最终只能凭感觉决定能不能上线。3.4 持续回归和线上监控这是 AI 测试最容易被忽视的部分AI 模型上线后测试工作并没有结束。实际上模型上线后才真正进入测试价值最大的阶段线上数据的真实分布和离线样本集往往存在差异模型可能遇到训练数据里从未出现的模式。我建议测试团队至少做三件持续的事情定期用线上日志中的真实请求更新回归样本集跑回归测试观察关键指标是否有明显变化。建立预测分布监控统计模型输出的类别分布、置信度分布、拒绝率等指标设置环比告警。关注业务层指标比如模型参与决策的有效率、用户反馈、误报率、人工修正率这些指标比模型本身的准确率更能反映真实质量。如果发现线上效果下降排查顺序建议是先看输入数据是否有变化再看特征处理代码是否被改动然后看模型版本和配置是否正确最后再看是否存在数据漂移或样本分布变化。按这个顺序排查通常能快速定位大部分问题。4. 我不觉得“不会 AI 就要被淘汰”但这几种能力确实会重新分层4.1 先破除一个焦虑AI 淘汰的不是“不会写代码的测试”而是“只会照着步骤执行的人”“还不会 AI 的测试要被淘汰了”这种说法我觉得更像是一种夸张的表达。真正的行业现实是AI 在测试领域确实越来越有用但它的主要价值是替代重复性高、逻辑固定、执行成本低的工作比如从大量日志中找出异常根据历史缺陷预测高风险模块生成常见格式的脚本代码。真正容易被替代的是那些只做重复操作、不参与设计、不思考根因的测试岗位。而具备业务判断力、能深入理解系统边界、能设计复杂验证方案的人反而会因为 AI 工具的普及把单点执行效率提高很多成为团队里更重要的人。所以问题不是“你会不会 AI”而是“你会不会用 AI 把原本低价值的重复工作压缩掉把时间投入到高价值的测试设计、风险判断和质量基础设施搭建上”。4.2 测试工程师的能力分层从执行者到质量架构师按我现在对行业的观察AI 时代测试工程师大概会分化成三个层次第一层是执行层。会使用 AI 工具辅助写测试脚本、生成测试数据、搜索资料。这个层次的门槛最低学习周期最短但可替代性也最高。第二层是设计层。能针对 AI 系统设计测试策略知道何时用规则验证何时用样本集评估何时做 A/B 实验。这一层开始掌握面试题里最常出现的内容。第三层是策略层。能建立一套完整的 AI 质量保障体系把数据、评估、回归、监控、风险分析串成一套可持续运转的流程。这一层需要大量项目积累也是多数测试工程师应该努力的目标。如果你现在还在第一层不用焦虑。从第一层到第二层的路径非常清晰找到一个 AI 测试项目从最小链路开始做积累样本集和评估经验慢慢形成自己的方法。从第二层到第三层才是真正的挑战因为它需要你跳出测试岗位本身以全局视角理解模型生命周期中的每个环节。4.3 面试准备建议与其突击背题不如做一次真实的 AI 测试练习如果要准备 AI 测试面试我最推荐的做法不是刷题而是找一个开源模型或在线 API用两周时间完整跑一遍 AI 功能验证流程。具体可以这么做选一个小场景比如文本情感分类或文章摘要生成。准备一份包含 20 到 30 条输入数据的样本集覆盖正常、边界、异常情况。手动调用模型记录输出结果建立初步印象。选择 2 到 3 个评估指标比如准确率、响应耗时、异常输出占比。尝试改变输入措辞、数据格式和参数配置观察模型表现变化。写一份简短的测试报告说明你的验证结论和潜在风险。这个过程做完之后你会发现面试里大部分问题都有了具体的例子可以支撑。面试官问你“样本不平衡怎么处理”时你能说出你实际遇到过的场景和调整思路问你“模型上线后怎么监控”时你能结合自己的实践给出可执行方案。真实的项目经验永远比背答案有说服力。5. 面试题会变判断力不会过时从“怎么测登录功能”到“怎么测推荐模型”测试面试题的变化本质上反映的是被测对象的变化。AI 系统的到来不是让测试变得不重要而是让测试的难度明显提高了。传统系统可以用一条用例断言一个死值AI 系统需要你用一组样本和一系列指标来判断“效果是否达到预期”。传统系统可以明确区分测试阶段和运维阶段AI 系统必须把测试延伸到上线后的每一次数据变化中。传统系统可以依靠个人经验直接判断缺陷AI 系统必须依赖数据统计和业务认知来识别“隐形缺陷”。回到最初那个朋友的问题AI 测试面试题到底在考什么我觉得考的是你有没有具备一套跟得上技术变化的思维框架。背题只能帮你通过上一次面试但真正让你在测试行业走得更远的是你是否具备把陌生问题拆解成输入、环境、指标、边界、风险的能力。如果你现在正准备一场 AI 测试面试别急着收集一百道题。先花时间理解一个问题当一个系统给出的答案不再稳定时你还能不能有底气地说出“这个系统质量不合格”或者“这个模型可以上线”。这个底气来自你对评估指标的把握、对测试数据的理解、对回归和监控体系的设计。这些才是所有 AI 测试面试题背后的标准答案也是测试工程师不被技术浪潮冲走最可靠的锚点。