最近准备AI测试方向面试的测试工程师大概率会有一种共同感受上一轮还在问接口自动化、UI自动化的常规套路这一轮已经变成“请设计一个RAG系统的评测方案”“Agent 任务失败了怎么定位”“你会怎么构造一套覆盖真实场景的测试数据”。这不是面试变玄学了而是 AI 应用的测试形态正在快速切换招聘方已经把“能不能设计测试方案、能不能衡量模型质量、能不能推动问题闭环”当成了核心筛选标准。这篇文章想给你一个清晰判断2025 年 8 月的 AI 测试面试真正在卷的已经不是工具熟练度而是“系统工程思维 模型评测能力 可落地的测试设计”。读完你可以获得三样东西一份可对照自测的核心知识图谱、三类面试现场能直接写出来的代码示例、以及从准备到简历再到面试的完整避坑路线。1. AI测试面试到底在卷什么1.1 三个最明显的考察变化先看 JD 关键词的变化。两三年前测试岗位的 JD 高频词是 Selenium、Appium、JMeter、Pytest核心逻辑是“会不会用工具”现在的 AI 测试岗位高频词变成了 LLM、RAG、Prompt、评测指标、Agent、模型安全、测试数据质量。这不是说传统测试能力不重要而是它从“决定性因素”变成了“基础项”。再看面试流程的变化。过去面试题大量是“这个接口怎么测”“数据库主键怎么设计”现在则被替换成“你如何评测一次对话系统的回答是不是合格”“如果模型出现幻觉怎么从测试角度拦截”。这类问题没有标准答案面试官真正想看的是你有没有一套自己的分析和决策框架。最后是岗位定位的变化。传统测试更多是“守门员”在开发完成后验证质量AI 测试更像是“质量架构师”要参与数据构造、评测集设计、模型选型评估、Prompt 调优和线上监控方案设计。这个变化意味着不会写代码、不懂模型评测、只看 UI 的测试工程师在 AI 测试方向的竞争里会非常吃力。1.2 一句话判断从“执行型测试”转向“设计型测试”如果把这段变化压缩成一句话我会说AI 测试面试正在从“执行型测试”转向“设计型测试”。执行型测试的核心是“按需求写用例、按用例跑回归”价值在于规范和效率设计型测试的核心是“在不确定性中定义质量、设计评测方案、搭建度量体系”价值在于判断和决策。面试官不再只关心你会不会跑用例而是关心你能不能回答“什么算对、怎么度量、出了问题怎么定位、如何避免再次出现”。这也解释了为什么很多测试工程师在面试中感觉“准备了很多八股题但对方不按套路出牌”。因为 AI 系统的输出具有概率性它不像传统接口那样有一个确定的期望值你需要重新建立一套以评测为中心的质量保障思路。理解了这一点后面所有知识点和代码示例才有落点。2. 核心能力框架AI测试面试在考什么2.1 两条必须分清的技术主线准备 AI 测试面试第一个要分清的是“用 AI 做测试”和“测 AI 应用”的区别。这两条主线经常被面试题混在一起但能力要求完全不同。用 AI 做测试指的是借助大模型提高传统测试效率。比如用 LLM 生成接口测试用例、根据页面截图自动生成断言、智能分析失败用例这类岗位更看重你对测试流程的理解和提示词设计能力本质是把 AI 当作提效工具。测 AI 应用指的是把被测对象本身变成大模型或 Agent 系统。你需要设计评测集、定义评测指标、评估 RAG 的检索效果、测试 Agent 的工具调用准确性。这背后要求你理解模型能力边界、数据分布、推理链路测试思维从“对照预期”变成“设计度量体系”。两道题答案可能完全不同面试官问“怎么用大模型提升测试效率”答的是提示词工程和流程改造面试官问“怎么测试一个 AI 翻译产品的质量”答的是评测集、指标和人工评估体系。如果你把两者混在一起讲会显得思路不清晰。2.2 AI 测试工程师能力模型综合招聘要求和实际项目落地需求AI 测试工程师的能力模型可以拆成四层能力层具体要求典型考察方式测试基本功用例设计、缺陷管理、接口测试、自动化框架场景设计题、手写接口用例AI 基础认知模型推理过程、Token 机制、Prompt、评测指标名词解释、方案选择题工程落地能力Python、pytest、数据构造、日志与链路追踪手写测试脚本、排查链路质量架构能力评测集设计、回归策略、线上监控、安全合规开放设计题、项目复盘多数候选人能过前两层但挂在第三、第四层。尤其“质量架构能力”它需要你不只会写一条断言而是要能回答“这个 AI 系统上线后的质量标准是什么、靠什么指标度量、通过什么机制持续保障”。这里真正容易踩坑的地方是不要试图用一两个概念塞满所有层级。面试官追问“你的评测集如何构造、数据来源是什么、怎么标注、样本量不够怎么办”时只背概念的人会立刻露馅。所以后面每一部分我都会把概念对应到具体可操作的方案上。3. 核心知识图谱面试官高频追问的五个方向3.1 大模型基础与推理参数这一部分不要求你从零训练模型但必须知道模型推理会受哪些参数影响因为它直接决定了测试用例要覆盖哪些边界。核心概念包括 Token、Temperature、Top-p、Max tokens、System Prompt。以 Temperature 为例它控制输出的随机性值越高回答越发散。测试时你会遇到一个经典场景同样一条用例连续跑五次结果不完全一样。如果你不理解 Temperature 的作用就会把它当成缺陷报上去实际上这可能就是参数设计的预期行为。面试中常见的出题方式是给你一条 Prompt 和一个参数配置让你预测它在什么场景下会出现问题。这要求你不仅知道参数含义还能联想到具体业务场景。举个例子客服系统追求稳定话术Temperature 通常设得很低否则用户会得到每次都不一样的答案而文案生成类应用反而需要提高随机性来产出多样内容。测试设计必须基于这个前提展开。3.2 模型评估指标AI 测试面试中评测指标是绕不开的硬核内容。你需要分两类去掌握传统 NLP 评估指标和面向生成任务的评估指标。传统指标包括准确率、精确率、召回率、F1 值、BLEU、ROUGE。准确率只适合类别均衡、错误代价相同的基础分类任务精确率和召回率则分别代表“查得准”和“查得全”两者经常此消彼长所以要结合业务场景说明哪个优先。对 AI 客服而言误判用户投诉风险比漏报更严重就会优先提高精确率对批量筛选候选人简历的场景漏掉合适候选人比看错一个人的代价更高就要优先召回率。生成任务评估则复杂得多。BLEU 和 ROUGE 都是基于文本重叠的指标处理机器翻译和摘要还可以参考但面对开放式的对话回答经常“语义正确但字符不重叠”此时指标会失真。于是业界出现了 BERTScore、Self-BLEU 以及基于大模型判别的 LLM-as-a-Judge 思路。你需要记住的能力不是死背公式而是能说明每个指标的适用边界。指标评估对象主要局限Accuracy分类任务类别不平衡时失真Precision / Recall检索、分类需要明确哪个更重要F1精确率与召回率平衡不反映业务成本BLEU机器翻译对开放生成不友好ROUGE文本摘要只能捕捉词语重叠BERTScore语义相似度依赖模型表现LLM-as-a-Judge开放生成存在裁判模型自身偏好面试时不要把这些指标背完就结束还要能回答“你的项目里为什么选这个指标”“它有哪些失效场景”“线上和离线指标为什么不一致”。这一串追问才是真正的分水岭。3.3 RAG 系统测试RAG 检索增强生成现在是 AI 应用落地最常见的架构之一。它把大模型和外部知识库结合解决“模型不知道最新信息”和“无法引用依据”的问题。RAG 测试的核心不在模型本身而在“检索是否准、生成是否有依据”。检索链路主要关注召回率和排序准确性测试时可以用命中率、精确度、召回率、NDCG 这类指标来度量。你需要构造一批 Query 和对应期望文档的数据集运行检索链路后检查返回结果是否包含正确文档。一个典型问题是检索出来的内容相关但排序太靠后导致模型没有在限定上下文中看到回答仍然错误这类问题往往需要调整切分策略和重排逻辑。生成链路则要关注回答是否忠于检索到的上下文是否出现幻觉是否完整覆盖用户问题。测试方法通常是把检索结果和模型回答同时曝光让人工或裁判模型判断“回答有没有依据”。RAG 面试题的高频场景是“某个知识型问答系统回答质量下降你如何定位是知识库更新问题、检索问题还是模型问题”大多数候选人会直接猜模型但真正的完成思路是先看数据、再看召回、最后才看生成。3.4 AI Agent 与工具调用测试Agent 是当前 AI 测试面试增长最快的话题。Agent 和普通对话系统的最大区别在于它会主动调用工具、执行多步任务因此测试对象从“一段文字输出”变成“一系列动作和决策”。测试 Agent 必须覆盖几个维度任务完成率即最终目标是否达成单步正确性即每一步规划和工具参数是否合理工具调用准确性即该调用天气接口时有没有调用成别的工具参数传递正确性即工具入参是否完整多轮状态一致性即状态在多次工具调用之间是否丢失安全边界即是否尝试执行高风险操作。Agent 测试的数据构造比普通 LLM 测试更复杂。你需要准备一组合法请求、边界请求和恶意请求还要模拟工具异常、超时和参数错误。面试中比较吃亏的回答是只讲“我测了对话和返回结果”真正加分的回答是“我设计了从用户请求到工具调用再到观测结果的完整链路测试并且能自动化回归”。3.5 AI 安全与合规测试这一块在八月份面试中的占比明显在上升。安全测试不只包含传统的注入攻击还包含提示词注入、越权访问、敏感信息泄露、数据偏见等内容。提示词注入是面试必问项。攻击者可能通过用户输入覆盖 System Prompt诱导模型输出本不该执行的指令或者让模型忽略安全限制。测试时要构造恶意输入用例别只依赖 Prompt 层面的拦截还必须验证外围系统有没有做输入校验和权限控制。合规问题则集中在个人信息保护、内容安全、生成内容审计等方向。作为测试工程师你的责任是设计接口层面的风险校验用例确保系统在模型之前已经过滤敏感输入、在输出侧有审计日志。这个问题不需要你成为安全专家但必须能说清楚“谁在系统的最外层做防护、测试如何证明它有效”。4. 实操能力三类面试必写代码多数 AI 测试面试会安排手写代码环节最常见的是让候选人用 Python 写测试脚本。不要指望面试官只问概念以下几类代码最好能脱离 IDE 直接手写。4.1 LLM 输出断言测试这类代码考察的是你会不会把传统断言逻辑迁移到 AI 场景。核心难点在于生成结果不固定所以断言目标不是“等于某个值”而是“包含关键信息、长度合理、格式正确”。# 文件路径test_llm_output.py from openai import OpenAI def get_llm_response(client: OpenAI, prompt: str) - str: resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.0 ) return resp.choices[0].message.content def test_llm_answer_contains_key_info(): client OpenAI() prompt 请简短介绍RAG检索增强生成的核心组成 result get_llm_response(client, prompt) assert result is not None assert len(result.strip()) 20 for keyword in [检索, 生成, 知识库]: assert keyword in result, f关键词缺失: {keyword}这段代码的关键点有三个设置 temperature 为 0 或接近 0降低结果随机性让断言更稳定断言使用“包含关键信息”而不是“完全等于”对长度做基础过滤避免模型输出空内容或纯符号。面试时最好能主动说明第三个断言的作用这比代码本身更能体现测试思维。4.2 RAG 检索质量评估RAG 检索评估在面试代码题里出现频率很高因为它能同时考察你对测试数据、指标计算和业务理解的能力。# 文件路径evaluate_rag_retrieval.py from typing import List, Optional def hit_rate(retrieved_docs: List[str], ground_truth_docs: List[str]) - float: 召回是否命中正确答案文档 if not ground_truth_docs: return 0.0 hits len(set(retrieved_docs) set(ground_truth_docs)) return hits / len(ground_truth_docs) def precision_at_k( retrieved_docs: List[str], ground_truth_docs: List[str], k: Optional[int] None ) - float: 前 k 个返回结果中正确文档占比 if k: retrieved_docs retrieved_docs[:k] if not retrieved_docs: return 0.0 hits len(set(retrieved_docs) set(ground_truth_docs)) return hits / len(retrieved_docs) def average_recall(query_results: List[List[str]], ground_truths: List[List[str]]) - float: 多组查询的平均召回率 scores [ hit_rate(res, gt) for res, gt in zip(query_results, ground_truths) ] return sum(scores) / len(scores) if scores else 0.0写这类代码时要主动讲清楚测试集必须包含“期望命中文档”的标注为了线上回归方便通常会保存一个评测集并定期更新命中率只反映检索是否找到依据不能完全代表回答质量。如果你还能补一句“检索结果还要看排序质量必要时引入 NDCG”会让面试官对你的工程视野留下印象。4.3 Agent 工具调用测试Agent 测试代码的重点是验证“模型做出了正确的动作决策”而不是只看最终返回文本。# 文件路径test_agent_tool_call.py def test_agent_calls_weather_tool_for_city_query(): history [ {role: user, content: 北京明天天气怎么样} ] result agent.run(history) assert result.tool_calls, 应该产生工具调用 assert result.tool_calls[0].name get_weather, \ f调用工具错误: {result.tool_calls[0].name} assert 北京 in result.tool_calls[0].arguments, \ f参数缺少城市: {result.tool_calls[0].arguments}这道题背后考察的是你能否设计“断言动作、断言参数、断言顺序、断言状态”的测试体系。真实项目里不会只跑一条用例而是用几十条用例覆盖不同工具、不同参数边界、工具异常和超时场景。面试中如果能把话题从“一条断言”延伸到“Agent 回归测试套件怎么维护”你的答案就比多数候选人完整很多。4.4 代码题答题注意事项第一不要急着写代码。先确认被测对象是什么、模型能不能被 mock、需要断言的到底是什么这个交流过程本身就是面试官考察你的需求分析能力。第二代码要完整可运行至少要让面试官觉得你能快速落地而不是纸上写“伪代码”。第三主动说明测试设计原因比如“我把 temperature 调低是为了让断言稳定”这类句式会明显提升印象分。5. 高频面试题拆解答题思路与面试官真实意图5.1 开放设计题如何给 AI 客服设计测试方案这类题没有唯一答案但有一个推荐框架先划定测试范围再分层设计用例最后定义质量标准和监控方案。测试范围要区分基础对话、知识库问答、情绪安抚、转人工、拒绝回答等能力。分层设计可以分成功能层、模型层、数据层和工程层。功能层覆盖对话流程和人工介入逻辑模型层设计评测集评估回答质量和安全性数据层验证知识库更新、检索准确性工程层关注响应时间、并发、日志和降级方案。质量标准则需要量化回答准确性目标是多少、检索命中率目标是多少、安全风险用例通过率要求是多少。面试官真正想听的不是“我会写很多用例”而是“你知道质量是多维的而且每个维度都能被度量”。所以一定要在答案里加入指标和回归策略。5.2 排查题RAG 回答质量下降怎么定位这个问题最怕一上来就说“模型不行需要换模型”。合理思路是按数据、检索、生成三段式排查。先看输入问题是否受影响再检查知识库最近有没有更新更新后文档切分是否异常。然后看检索排序用几个典型 Query 手动调到检索结果接口确认相关文档是否还在返回列表里。最后再对比相似 Prompt 下模型回答变化确认是不是提示词调整或模型版本变化导致。如果前面的证据都正常最后才考虑模型本身。回答时如果能补一句“每个环节都要有日志和可观测性”是非常加分的工程意识。5.3 数据题如何评估一套测试集合不合格AI 测试面试越来越重视数据敏感度因为测试集直接决定评测结果可信度。可以从覆盖度、分布、标注一致性、时效性和可追溯性五个角度回答。覆盖度指是否包含正常、边界、异常、安全对抗等类型分布指正常样本和难例的比例是否符合真实业务如果生产上大多数是简单问答测试集却全是对抗样本评测结果就失真标注一致性可以抽样让两个人标同一批数据算一致率时效性指测试集是否需要随业务更新可追溯性指每条数据最好保留来源、标注人、日期和预期说明。如果面试官追问“测试集太小怎么办”你可以答小样本下优先人工评审加补充难例不能直接用大规模生成数据冒充真实分布。5.4 快速追问幻觉和偏见问题怎么测幻觉是 AI 应用最常见的质量问题测试重点是构造“模型可能编造事实”的场景。常见做法是让模型回答它不掌握的信息、日期类问题和需要引用来源的问题人工或裁判模型检查回答是否无中生有。还可以把检索结果和回答做一致性比对看回答内容是否存在超出上下文的断言。偏见测试则需要构造覆盖不同人群和敏感维度的输入数据集观察输出是否存在倾向性表述。需要提醒的是这类测试要非常谨慎尤其是涉及人群属性的内容应控制在正常业务合规讨论范围内不建议在面试中展开争议性案例。你的重点应该是“是否有偏见检测机制、数据如何构造、发现后如何反馈给模型和产品团队”。6. 常见雷区技术不错为什么还是挂6.1 只会写 Prompt不会设计测试方案有些候选人把大量精力花在“如何写 Prompt 让模型输出更好”面试时也大谈提示词技巧但被问到“怎么建立回归体系”“怎么衡量一次改动是否让系统变好”时却说不出来。AI 测试面试要的是质量保障能力不是提示词调优比赛。Prompt 是手段度量与回归才是核心。6.2 把模型评测理解成“跑一批准确率”准确率只是众多指标之一而且很多 AI 场景并不适合用准确率衡量。如果回答评测方案时只会说准确率、召回归类指标而说不清线上用户真实反馈怎么回流、坏例怎么沉淀进测试集面试官会怀疑你的方案是否真的落地过。6.3 忽略测试数据质量模型评测的效果高度依赖测试集质量。如果你不聊数据来源、标注规范、分布偏差和更新机制面试官会认为你对 AI 测试的理解停留在“跑 Python 脚本”层面。宁可数据样本量不大也要说清楚每条数据的构造逻辑和业务来源。6.4 不懂工具调用和链路可观测性Agent 测试中常见的问题是只测“最终回答”忽略“工具调用是否正确、参数是否完整、多轮状态是否一致”。加上很多 AI 系统内部链路复杂没有日志和追踪就想定位问题非常困难。回答时主动提链路追踪会显得你更接近生产环境。6.5 安全测试只会背定义能说出“提示词注入”不算完还要能给出测试用例样例和防护验证思路。回答里只堆安全概念但没有具体的构造方法和预期结果很容易被连续追问击穿。7. 八月份面试建议练到什么水平如果把准备目标拆成三个阶段八月份多数岗位要求至少达到第二阶段冲刺核心岗位要有第三阶段的能力。阶段能力描述建议人群第一阶段能解释LLM评测基础指标会写简单断言刚转岗投初级测试质量岗第二阶段能设计RAG/Agent测试方案写自动化评测脚本有1-3年测试经验投AI测试工程师第三阶段能搭建评测体系设计回归机制主导质量线有测试架构能力投高级/专家岗第二阶段的具体自测标准是能独立给一个知识型问答系统写测试方案涵盖功能、评测、安全、回归四个维度能写一个支持批量执行评测用例的 pytest 脚本能说清楚线上质量监控至少要看哪几个指标遇到回答质量下降能按数据、检索、生成、模型四部分排查。如果这些还没达标建议先用一个开源 RAG 项目练手把自己的测试方案做成项目放进简历比空背概念有用得多。如果你目标是第三阶段还要补充工程化内容评测集版本管理怎么做、坏例回流机制如何设计、模型版本升级的回归策略、评测成本如何控制。面试官会更关心你有没有带队推动质量体系的经历哪怕只是在一个小项目里完整落地过也比讲一堆大词更有竞争力。8. 常见问题与准备期排错思路问题现象可能原因排查方式解决方案简历写了 AI 测试但被追问项目细节就卡壳简历项目与实际经验脱节逐条复盘项目中的评测指标、数据来源只写真实参与过的模块补充完整方案面试官问评测方案只能答出“跑准确率”缺少指标相关背景重新学习 Precision/Recall/BLEU/ROUGE 使用边界对照业务场景练习指标选型手写代码被卡在 mock 模型接口对依赖管理不熟提前用 pytest 的 monkeypatch 模拟 API 返回熟悉 mock 思路把被测代码分为“模型调用层”和“逻辑层”不会回答 RAG 质量下降排查不熟悉系统链路画出“数据-检索-生成-展示”的调用链按链路分段准备排查问题模板开放设计题组织不出层次缺少分析框架练习按功能层、模型层、数据层、工程层拆解每个方向准备固定回答模板提到安全测试只会概念缺少用例体验手动构造一组提示词注入用例并记录防护效果把输入校验、输出审计纳入测试设计这里特别提醒一点不要为了“显得专业”在简历里堆 AI 名词。面试官一定会追问细节与其被打穿不如只写两三个真正研究过的方向把方案、指标、遇到的问题和结论讲完整。9. 总结与后续学习方向AI 测试面试的强度确实在上升但这个上升的方向很明确从“操作工具的人”变成“设计质量体系的人”。你需要掌握的不是某一个评测工具或某一段代码而是“定义质量、设计度量、构造数据、定位问题、推动闭环”这套完整能力。能答对一道题只能赢一次能给出可落地的测试方案才是真正的竞争力。建议下一步按三件事推进先拿一个开源 RAG 或对话项目做测试设计实践把评测集和脚本跑通再把项目中真实用到的指标、数据构造方式和问题排查案例整理成文档最后约几次模拟面试重点练开放题的表述节奏。等你发现自己能在没有标准答案的问题前依然能条理清晰地说出分析路径时再去投 AI 测试岗位胜算会明显高很多。
最近准备AI测试方向面试的测试工程师大概率会有一种共同感受上一轮还在问接口自动化、UI自动化的常规套路这一轮已经变成“请设计一个RAG系统的评测方案”“Agent 任务失败了怎么定位”“你会怎么构造一套覆盖真实场景的测试数据”。这不是面试变玄学了而是 AI 应用的测试形态正在快速切换招聘方已经把“能不能设计测试方案、能不能衡量模型质量、能不能推动问题闭环”当成了核心筛选标准。这篇文章想给你一个清晰判断2025 年 8 月的 AI 测试面试真正在卷的已经不是工具熟练度而是“系统工程思维 模型评测能力 可落地的测试设计”。读完你可以获得三样东西一份可对照自测的核心知识图谱、三类面试现场能直接写出来的代码示例、以及从准备到简历再到面试的完整避坑路线。1. AI测试面试到底在卷什么1.1 三个最明显的考察变化先看 JD 关键词的变化。两三年前测试岗位的 JD 高频词是 Selenium、Appium、JMeter、Pytest核心逻辑是“会不会用工具”现在的 AI 测试岗位高频词变成了 LLM、RAG、Prompt、评测指标、Agent、模型安全、测试数据质量。这不是说传统测试能力不重要而是它从“决定性因素”变成了“基础项”。再看面试流程的变化。过去面试题大量是“这个接口怎么测”“数据库主键怎么设计”现在则被替换成“你如何评测一次对话系统的回答是不是合格”“如果模型出现幻觉怎么从测试角度拦截”。这类问题没有标准答案面试官真正想看的是你有没有一套自己的分析和决策框架。最后是岗位定位的变化。传统测试更多是“守门员”在开发完成后验证质量AI 测试更像是“质量架构师”要参与数据构造、评测集设计、模型选型评估、Prompt 调优和线上监控方案设计。这个变化意味着不会写代码、不懂模型评测、只看 UI 的测试工程师在 AI 测试方向的竞争里会非常吃力。1.2 一句话判断从“执行型测试”转向“设计型测试”如果把这段变化压缩成一句话我会说AI 测试面试正在从“执行型测试”转向“设计型测试”。执行型测试的核心是“按需求写用例、按用例跑回归”价值在于规范和效率设计型测试的核心是“在不确定性中定义质量、设计评测方案、搭建度量体系”价值在于判断和决策。面试官不再只关心你会不会跑用例而是关心你能不能回答“什么算对、怎么度量、出了问题怎么定位、如何避免再次出现”。这也解释了为什么很多测试工程师在面试中感觉“准备了很多八股题但对方不按套路出牌”。因为 AI 系统的输出具有概率性它不像传统接口那样有一个确定的期望值你需要重新建立一套以评测为中心的质量保障思路。理解了这一点后面所有知识点和代码示例才有落点。2. 核心能力框架AI测试面试在考什么2.1 两条必须分清的技术主线准备 AI 测试面试第一个要分清的是“用 AI 做测试”和“测 AI 应用”的区别。这两条主线经常被面试题混在一起但能力要求完全不同。用 AI 做测试指的是借助大模型提高传统测试效率。比如用 LLM 生成接口测试用例、根据页面截图自动生成断言、智能分析失败用例这类岗位更看重你对测试流程的理解和提示词设计能力本质是把 AI 当作提效工具。测 AI 应用指的是把被测对象本身变成大模型或 Agent 系统。你需要设计评测集、定义评测指标、评估 RAG 的检索效果、测试 Agent 的工具调用准确性。这背后要求你理解模型能力边界、数据分布、推理链路测试思维从“对照预期”变成“设计度量体系”。两道题答案可能完全不同面试官问“怎么用大模型提升测试效率”答的是提示词工程和流程改造面试官问“怎么测试一个 AI 翻译产品的质量”答的是评测集、指标和人工评估体系。如果你把两者混在一起讲会显得思路不清晰。2.2 AI 测试工程师能力模型综合招聘要求和实际项目落地需求AI 测试工程师的能力模型可以拆成四层能力层具体要求典型考察方式测试基本功用例设计、缺陷管理、接口测试、自动化框架场景设计题、手写接口用例AI 基础认知模型推理过程、Token 机制、Prompt、评测指标名词解释、方案选择题工程落地能力Python、pytest、数据构造、日志与链路追踪手写测试脚本、排查链路质量架构能力评测集设计、回归策略、线上监控、安全合规开放设计题、项目复盘多数候选人能过前两层但挂在第三、第四层。尤其“质量架构能力”它需要你不只会写一条断言而是要能回答“这个 AI 系统上线后的质量标准是什么、靠什么指标度量、通过什么机制持续保障”。这里真正容易踩坑的地方是不要试图用一两个概念塞满所有层级。面试官追问“你的评测集如何构造、数据来源是什么、怎么标注、样本量不够怎么办”时只背概念的人会立刻露馅。所以后面每一部分我都会把概念对应到具体可操作的方案上。3. 核心知识图谱面试官高频追问的五个方向3.1 大模型基础与推理参数这一部分不要求你从零训练模型但必须知道模型推理会受哪些参数影响因为它直接决定了测试用例要覆盖哪些边界。核心概念包括 Token、Temperature、Top-p、Max tokens、System Prompt。以 Temperature 为例它控制输出的随机性值越高回答越发散。测试时你会遇到一个经典场景同样一条用例连续跑五次结果不完全一样。如果你不理解 Temperature 的作用就会把它当成缺陷报上去实际上这可能就是参数设计的预期行为。面试中常见的出题方式是给你一条 Prompt 和一个参数配置让你预测它在什么场景下会出现问题。这要求你不仅知道参数含义还能联想到具体业务场景。举个例子客服系统追求稳定话术Temperature 通常设得很低否则用户会得到每次都不一样的答案而文案生成类应用反而需要提高随机性来产出多样内容。测试设计必须基于这个前提展开。3.2 模型评估指标AI 测试面试中评测指标是绕不开的硬核内容。你需要分两类去掌握传统 NLP 评估指标和面向生成任务的评估指标。传统指标包括准确率、精确率、召回率、F1 值、BLEU、ROUGE。准确率只适合类别均衡、错误代价相同的基础分类任务精确率和召回率则分别代表“查得准”和“查得全”两者经常此消彼长所以要结合业务场景说明哪个优先。对 AI 客服而言误判用户投诉风险比漏报更严重就会优先提高精确率对批量筛选候选人简历的场景漏掉合适候选人比看错一个人的代价更高就要优先召回率。生成任务评估则复杂得多。BLEU 和 ROUGE 都是基于文本重叠的指标处理机器翻译和摘要还可以参考但面对开放式的对话回答经常“语义正确但字符不重叠”此时指标会失真。于是业界出现了 BERTScore、Self-BLEU 以及基于大模型判别的 LLM-as-a-Judge 思路。你需要记住的能力不是死背公式而是能说明每个指标的适用边界。指标评估对象主要局限Accuracy分类任务类别不平衡时失真Precision / Recall检索、分类需要明确哪个更重要F1精确率与召回率平衡不反映业务成本BLEU机器翻译对开放生成不友好ROUGE文本摘要只能捕捉词语重叠BERTScore语义相似度依赖模型表现LLM-as-a-Judge开放生成存在裁判模型自身偏好面试时不要把这些指标背完就结束还要能回答“你的项目里为什么选这个指标”“它有哪些失效场景”“线上和离线指标为什么不一致”。这一串追问才是真正的分水岭。3.3 RAG 系统测试RAG 检索增强生成现在是 AI 应用落地最常见的架构之一。它把大模型和外部知识库结合解决“模型不知道最新信息”和“无法引用依据”的问题。RAG 测试的核心不在模型本身而在“检索是否准、生成是否有依据”。检索链路主要关注召回率和排序准确性测试时可以用命中率、精确度、召回率、NDCG 这类指标来度量。你需要构造一批 Query 和对应期望文档的数据集运行检索链路后检查返回结果是否包含正确文档。一个典型问题是检索出来的内容相关但排序太靠后导致模型没有在限定上下文中看到回答仍然错误这类问题往往需要调整切分策略和重排逻辑。生成链路则要关注回答是否忠于检索到的上下文是否出现幻觉是否完整覆盖用户问题。测试方法通常是把检索结果和模型回答同时曝光让人工或裁判模型判断“回答有没有依据”。RAG 面试题的高频场景是“某个知识型问答系统回答质量下降你如何定位是知识库更新问题、检索问题还是模型问题”大多数候选人会直接猜模型但真正的完成思路是先看数据、再看召回、最后才看生成。3.4 AI Agent 与工具调用测试Agent 是当前 AI 测试面试增长最快的话题。Agent 和普通对话系统的最大区别在于它会主动调用工具、执行多步任务因此测试对象从“一段文字输出”变成“一系列动作和决策”。测试 Agent 必须覆盖几个维度任务完成率即最终目标是否达成单步正确性即每一步规划和工具参数是否合理工具调用准确性即该调用天气接口时有没有调用成别的工具参数传递正确性即工具入参是否完整多轮状态一致性即状态在多次工具调用之间是否丢失安全边界即是否尝试执行高风险操作。Agent 测试的数据构造比普通 LLM 测试更复杂。你需要准备一组合法请求、边界请求和恶意请求还要模拟工具异常、超时和参数错误。面试中比较吃亏的回答是只讲“我测了对话和返回结果”真正加分的回答是“我设计了从用户请求到工具调用再到观测结果的完整链路测试并且能自动化回归”。3.5 AI 安全与合规测试这一块在八月份面试中的占比明显在上升。安全测试不只包含传统的注入攻击还包含提示词注入、越权访问、敏感信息泄露、数据偏见等内容。提示词注入是面试必问项。攻击者可能通过用户输入覆盖 System Prompt诱导模型输出本不该执行的指令或者让模型忽略安全限制。测试时要构造恶意输入用例别只依赖 Prompt 层面的拦截还必须验证外围系统有没有做输入校验和权限控制。合规问题则集中在个人信息保护、内容安全、生成内容审计等方向。作为测试工程师你的责任是设计接口层面的风险校验用例确保系统在模型之前已经过滤敏感输入、在输出侧有审计日志。这个问题不需要你成为安全专家但必须能说清楚“谁在系统的最外层做防护、测试如何证明它有效”。4. 实操能力三类面试必写代码多数 AI 测试面试会安排手写代码环节最常见的是让候选人用 Python 写测试脚本。不要指望面试官只问概念以下几类代码最好能脱离 IDE 直接手写。4.1 LLM 输出断言测试这类代码考察的是你会不会把传统断言逻辑迁移到 AI 场景。核心难点在于生成结果不固定所以断言目标不是“等于某个值”而是“包含关键信息、长度合理、格式正确”。# 文件路径test_llm_output.py from openai import OpenAI def get_llm_response(client: OpenAI, prompt: str) - str: resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.0 ) return resp.choices[0].message.content def test_llm_answer_contains_key_info(): client OpenAI() prompt 请简短介绍RAG检索增强生成的核心组成 result get_llm_response(client, prompt) assert result is not None assert len(result.strip()) 20 for keyword in [检索, 生成, 知识库]: assert keyword in result, f关键词缺失: {keyword}这段代码的关键点有三个设置 temperature 为 0 或接近 0降低结果随机性让断言更稳定断言使用“包含关键信息”而不是“完全等于”对长度做基础过滤避免模型输出空内容或纯符号。面试时最好能主动说明第三个断言的作用这比代码本身更能体现测试思维。4.2 RAG 检索质量评估RAG 检索评估在面试代码题里出现频率很高因为它能同时考察你对测试数据、指标计算和业务理解的能力。# 文件路径evaluate_rag_retrieval.py from typing import List, Optional def hit_rate(retrieved_docs: List[str], ground_truth_docs: List[str]) - float: 召回是否命中正确答案文档 if not ground_truth_docs: return 0.0 hits len(set(retrieved_docs) set(ground_truth_docs)) return hits / len(ground_truth_docs) def precision_at_k( retrieved_docs: List[str], ground_truth_docs: List[str], k: Optional[int] None ) - float: 前 k 个返回结果中正确文档占比 if k: retrieved_docs retrieved_docs[:k] if not retrieved_docs: return 0.0 hits len(set(retrieved_docs) set(ground_truth_docs)) return hits / len(retrieved_docs) def average_recall(query_results: List[List[str]], ground_truths: List[List[str]]) - float: 多组查询的平均召回率 scores [ hit_rate(res, gt) for res, gt in zip(query_results, ground_truths) ] return sum(scores) / len(scores) if scores else 0.0写这类代码时要主动讲清楚测试集必须包含“期望命中文档”的标注为了线上回归方便通常会保存一个评测集并定期更新命中率只反映检索是否找到依据不能完全代表回答质量。如果你还能补一句“检索结果还要看排序质量必要时引入 NDCG”会让面试官对你的工程视野留下印象。4.3 Agent 工具调用测试Agent 测试代码的重点是验证“模型做出了正确的动作决策”而不是只看最终返回文本。# 文件路径test_agent_tool_call.py def test_agent_calls_weather_tool_for_city_query(): history [ {role: user, content: 北京明天天气怎么样} ] result agent.run(history) assert result.tool_calls, 应该产生工具调用 assert result.tool_calls[0].name get_weather, \ f调用工具错误: {result.tool_calls[0].name} assert 北京 in result.tool_calls[0].arguments, \ f参数缺少城市: {result.tool_calls[0].arguments}这道题背后考察的是你能否设计“断言动作、断言参数、断言顺序、断言状态”的测试体系。真实项目里不会只跑一条用例而是用几十条用例覆盖不同工具、不同参数边界、工具异常和超时场景。面试中如果能把话题从“一条断言”延伸到“Agent 回归测试套件怎么维护”你的答案就比多数候选人完整很多。4.4 代码题答题注意事项第一不要急着写代码。先确认被测对象是什么、模型能不能被 mock、需要断言的到底是什么这个交流过程本身就是面试官考察你的需求分析能力。第二代码要完整可运行至少要让面试官觉得你能快速落地而不是纸上写“伪代码”。第三主动说明测试设计原因比如“我把 temperature 调低是为了让断言稳定”这类句式会明显提升印象分。5. 高频面试题拆解答题思路与面试官真实意图5.1 开放设计题如何给 AI 客服设计测试方案这类题没有唯一答案但有一个推荐框架先划定测试范围再分层设计用例最后定义质量标准和监控方案。测试范围要区分基础对话、知识库问答、情绪安抚、转人工、拒绝回答等能力。分层设计可以分成功能层、模型层、数据层和工程层。功能层覆盖对话流程和人工介入逻辑模型层设计评测集评估回答质量和安全性数据层验证知识库更新、检索准确性工程层关注响应时间、并发、日志和降级方案。质量标准则需要量化回答准确性目标是多少、检索命中率目标是多少、安全风险用例通过率要求是多少。面试官真正想听的不是“我会写很多用例”而是“你知道质量是多维的而且每个维度都能被度量”。所以一定要在答案里加入指标和回归策略。5.2 排查题RAG 回答质量下降怎么定位这个问题最怕一上来就说“模型不行需要换模型”。合理思路是按数据、检索、生成三段式排查。先看输入问题是否受影响再检查知识库最近有没有更新更新后文档切分是否异常。然后看检索排序用几个典型 Query 手动调到检索结果接口确认相关文档是否还在返回列表里。最后再对比相似 Prompt 下模型回答变化确认是不是提示词调整或模型版本变化导致。如果前面的证据都正常最后才考虑模型本身。回答时如果能补一句“每个环节都要有日志和可观测性”是非常加分的工程意识。5.3 数据题如何评估一套测试集合不合格AI 测试面试越来越重视数据敏感度因为测试集直接决定评测结果可信度。可以从覆盖度、分布、标注一致性、时效性和可追溯性五个角度回答。覆盖度指是否包含正常、边界、异常、安全对抗等类型分布指正常样本和难例的比例是否符合真实业务如果生产上大多数是简单问答测试集却全是对抗样本评测结果就失真标注一致性可以抽样让两个人标同一批数据算一致率时效性指测试集是否需要随业务更新可追溯性指每条数据最好保留来源、标注人、日期和预期说明。如果面试官追问“测试集太小怎么办”你可以答小样本下优先人工评审加补充难例不能直接用大规模生成数据冒充真实分布。5.4 快速追问幻觉和偏见问题怎么测幻觉是 AI 应用最常见的质量问题测试重点是构造“模型可能编造事实”的场景。常见做法是让模型回答它不掌握的信息、日期类问题和需要引用来源的问题人工或裁判模型检查回答是否无中生有。还可以把检索结果和回答做一致性比对看回答内容是否存在超出上下文的断言。偏见测试则需要构造覆盖不同人群和敏感维度的输入数据集观察输出是否存在倾向性表述。需要提醒的是这类测试要非常谨慎尤其是涉及人群属性的内容应控制在正常业务合规讨论范围内不建议在面试中展开争议性案例。你的重点应该是“是否有偏见检测机制、数据如何构造、发现后如何反馈给模型和产品团队”。6. 常见雷区技术不错为什么还是挂6.1 只会写 Prompt不会设计测试方案有些候选人把大量精力花在“如何写 Prompt 让模型输出更好”面试时也大谈提示词技巧但被问到“怎么建立回归体系”“怎么衡量一次改动是否让系统变好”时却说不出来。AI 测试面试要的是质量保障能力不是提示词调优比赛。Prompt 是手段度量与回归才是核心。6.2 把模型评测理解成“跑一批准确率”准确率只是众多指标之一而且很多 AI 场景并不适合用准确率衡量。如果回答评测方案时只会说准确率、召回归类指标而说不清线上用户真实反馈怎么回流、坏例怎么沉淀进测试集面试官会怀疑你的方案是否真的落地过。6.3 忽略测试数据质量模型评测的效果高度依赖测试集质量。如果你不聊数据来源、标注规范、分布偏差和更新机制面试官会认为你对 AI 测试的理解停留在“跑 Python 脚本”层面。宁可数据样本量不大也要说清楚每条数据的构造逻辑和业务来源。6.4 不懂工具调用和链路可观测性Agent 测试中常见的问题是只测“最终回答”忽略“工具调用是否正确、参数是否完整、多轮状态是否一致”。加上很多 AI 系统内部链路复杂没有日志和追踪就想定位问题非常困难。回答时主动提链路追踪会显得你更接近生产环境。6.5 安全测试只会背定义能说出“提示词注入”不算完还要能给出测试用例样例和防护验证思路。回答里只堆安全概念但没有具体的构造方法和预期结果很容易被连续追问击穿。7. 八月份面试建议练到什么水平如果把准备目标拆成三个阶段八月份多数岗位要求至少达到第二阶段冲刺核心岗位要有第三阶段的能力。阶段能力描述建议人群第一阶段能解释LLM评测基础指标会写简单断言刚转岗投初级测试质量岗第二阶段能设计RAG/Agent测试方案写自动化评测脚本有1-3年测试经验投AI测试工程师第三阶段能搭建评测体系设计回归机制主导质量线有测试架构能力投高级/专家岗第二阶段的具体自测标准是能独立给一个知识型问答系统写测试方案涵盖功能、评测、安全、回归四个维度能写一个支持批量执行评测用例的 pytest 脚本能说清楚线上质量监控至少要看哪几个指标遇到回答质量下降能按数据、检索、生成、模型四部分排查。如果这些还没达标建议先用一个开源 RAG 项目练手把自己的测试方案做成项目放进简历比空背概念有用得多。如果你目标是第三阶段还要补充工程化内容评测集版本管理怎么做、坏例回流机制如何设计、模型版本升级的回归策略、评测成本如何控制。面试官会更关心你有没有带队推动质量体系的经历哪怕只是在一个小项目里完整落地过也比讲一堆大词更有竞争力。8. 常见问题与准备期排错思路问题现象可能原因排查方式解决方案简历写了 AI 测试但被追问项目细节就卡壳简历项目与实际经验脱节逐条复盘项目中的评测指标、数据来源只写真实参与过的模块补充完整方案面试官问评测方案只能答出“跑准确率”缺少指标相关背景重新学习 Precision/Recall/BLEU/ROUGE 使用边界对照业务场景练习指标选型手写代码被卡在 mock 模型接口对依赖管理不熟提前用 pytest 的 monkeypatch 模拟 API 返回熟悉 mock 思路把被测代码分为“模型调用层”和“逻辑层”不会回答 RAG 质量下降排查不熟悉系统链路画出“数据-检索-生成-展示”的调用链按链路分段准备排查问题模板开放设计题组织不出层次缺少分析框架练习按功能层、模型层、数据层、工程层拆解每个方向准备固定回答模板提到安全测试只会概念缺少用例体验手动构造一组提示词注入用例并记录防护效果把输入校验、输出审计纳入测试设计这里特别提醒一点不要为了“显得专业”在简历里堆 AI 名词。面试官一定会追问细节与其被打穿不如只写两三个真正研究过的方向把方案、指标、遇到的问题和结论讲完整。9. 总结与后续学习方向AI 测试面试的强度确实在上升但这个上升的方向很明确从“操作工具的人”变成“设计质量体系的人”。你需要掌握的不是某一个评测工具或某一段代码而是“定义质量、设计度量、构造数据、定位问题、推动闭环”这套完整能力。能答对一道题只能赢一次能给出可落地的测试方案才是真正的竞争力。建议下一步按三件事推进先拿一个开源 RAG 或对话项目做测试设计实践把评测集和脚本跑通再把项目中真实用到的指标、数据构造方式和问题排查案例整理成文档最后约几次模拟面试重点练开放题的表述节奏。等你发现自己能在没有标准答案的问题前依然能条理清晰地说出分析路径时再去投 AI 测试岗位胜算会明显高很多。
