这两年测试岗的面试风向变化很明显。以前问的是接口、自动化、性能三板斧现在很多公司开始问“大模型怎么测”“AI 智能体怎么验收”“RAG 检索效果怎么评估”。不少同学在简历里写了“熟悉 AI 测试”结果面试官一问到数据标注、模型评估指标、Prompt 评测集构建就答不上来。本文结合近期热门的 AI 测试面试题整理了一份从能力模型到项目实战的完整准备思路。不管你是功能测试想转 AI 测试还是有自动化经验想往智能测试方向发展都可以照着这份清单查漏补缺。1. 先搞清楚AI 测试到底在测什么1.1 AI 测试的两层含义很多面试者一开始就容易混淆概念。所谓“AI 测试”现在通常包含两个方向第一层用 AI 技术辅助测试。比如用大模型生成测试用例、通过 AI 分析日志和报错、借助智能体自动执行回归测试。核心是“用 AI 来测软件”。第二层测试 AI 系统本身。被测对象是推荐系统、大模型应用、OCR 识别引擎、AI 智能体等。核心是“测 AI 软件好不好用、对不对、稳不稳定”。面试时先问清楚对方岗位要求的是哪一层。大多数中大型公司招聘的“AI 测试工程师”既要求你懂传统测试的基本功又要求你能评估模型效果和 AI 应用的质量。1.2 AI 系统和传统软件的核心差异传统软件测试中输入是明确的预期输出也是明确的。比如登录功能输入账号密码预期就是登录成功或提示错误。但 AI 系统存在三个显著不同输出不确定。同一个问题模型可能给出不同表达但语义等价。评判标准不唯一。模型回答是否“好”需要从准确性、完整性、有害性等多个维度判断。数据驱动质量。模型质量不仅取决于代码更取决于训练数据、Prompt 设计、检索库内容。所以 AI 测试工程师不能只写用例还要懂怎么构建评测集、怎么设计评测指标、怎么分析 bad case。1.3 常见应用场景结合当前招聘需求AI 测试岗位主要覆盖这些场景场景测试重点大模型对话机器人回答准确性、拒答合理性、幻觉率、多轮一致性RAG 知识库问答检索命中率、引用准确性、答案与文档一致性AI 智能体Agent任务规划合理性、工具调用正确性、异常恢复能力图像识别/OCR准确率、召回率、边界样本表现推荐系统点击率、多样性、离线评估与在线效果一致性数据标注平台标注质量、标签一致性、验收流程准备面试时不要只背概念至少选一个场景做出可演示的实战项目这是加分项。2. AI 测试工程师的能力模型与知识清单2.1 面试官最看重的四类能力从近期面试反馈来看AI 测试岗位的考察点集中在以下四个维度第一测试基本功。用例设计、缺陷管理、接口测试、自动化测试、性能测试方法论不能丢。AI 系统也是软件基础测试能力依然是门槛。第二AI 基础认知。了解机器学习基本概念比如训练集、验证集、测试集了解模型评估指标比如准确率Accuracy、精确率Precision、召回率Recall、F1 值。如果面试的是大模型方向还要理解 Token、Prompt、RAG、微调、幻觉等概念。第三数据评测能力。能独立设计评测集能标注 bad case能分析模型错误原因。面试官经常会问“如果模型回答错了你怎么定位是 Prompt 问题、检索问题还是模型本身的问题”第四AI 工具与工程化能力。会用 Python 写脚本会用 Pytest 搭自动化测试框架会调用大模型 API了解常用的评测框架和测试工具。2.2 建议准备的知识路线按照“基础 → 概念 → 工具 → 实战”的顺序准备Python 基础与数据处理Pandas、JSON 操作传统测试技能接口测试、自动化测试机器学习与 LLM 基础概念Prompt 工程与评测集设计AI 自动化测试框架搭建智能体测试与数据质量分析真实项目实战与面试题复盘不用贪多但每一步都要能做出来。面试官经常让你现场写一段脚本或者讲一个项目的实现细节纸上谈兵是过不了关的。3. 核心概念AI 测试高频考点拆解3.1 模型评估指标面试时指标是必考点。建议至少掌握下面几组分类模型指标准确率Accuracy预测正确的样本占总样本的比例。适用于类别均衡的场景。精确率Precision预测为正类的样本中真正为正类的比例。关注“预测为正的有多准”。召回率Recall真实为正类的样本中被正确预测出来的比例。关注“正类漏了多少”。F1 值精确率和召回率的调和平均数综合衡量模型效果。为了便于理解可以这样记忆精确率是“宁缺毋滥”召回率是“宁滥勿缺”。实际业务中垃圾邮件拦截更关注精确率癌症筛查更关注召回率。大模型生成类指标幻觉率模型生成内容与事实不符的比例。答案准确性人工或大模型裁判对答案正确性的打分。检索命中率RAG 系统中正确文档是否被检索到。引用准确率模型给出的引用内容是否真实存在于检索文档中。多轮一致性多轮对话中模型是否记住并正确使用前文信息。3.2 评测集与 Prompt 设计设计评测集是 AI 测试工程师的核心工作之一。面试中常见的追问是“你怎么评估一个聊天机器人好不好”一个可复用的回答思路是明确测试范围先确定是单轮问答、多轮对话、还是带工具调用的 Agent 场景。构建评测集从真实用户日志中抽取问题覆盖常见问题、边界问题、恶意问题、模糊问题。定义评分标准给每个维度打分比如准确性 0~5 分是否包含有害内容 0/1 判断。评估执行把测试用例批量发送给模型收集回答由人工或大模型裁判打分。结果分析统计各维度得分分析 bad case定位问题根因。3.3 大模型评测中的“以 LLM 评 LLM”实际项目中纯靠人工评测成本高、耗时长。现在业界常用大模型裁判LLM-as-a-judge做初筛再由人工抽检。下面是一个简化示例思路def judge_with_llm(question, answer, reference): prompt f 你是一个评测助手。请根据参考答案判断模型回答的质量。 问题{question} 模型回答{answer} 参考答案{reference} 请从准确性0-5分和完整性0-5分两个维度评分。 输出 JSON 格式例如{{accuracy: 4, completeness: 3}} # 调用大模型接口获取评分 result call_llm(prompt) return parse_json(result)这段代码的核心思路是“模型生成的内容很难用规则做判断那就让另一个模型做初评人工抽检兜底。”这是目前大模型测试的主流实践之一面试时提到会非常加分。4. 环境准备与工具链搭建4.1 建议环境版本需要根据你的实际情况调整本文示例以常见环境为例重点展示实现思路。操作系统Windows / macOS / Linux 均可Python3.9 或以上依赖库pytest、requests、pandas、openai或其他模型 SDK开发工具PyCharm 或 VS Code模型服务可以使用国内大模型平台的 API也可以使用本地部署的开源模型4.2 安装依赖创建一个虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install pytest requests pandas openai4.3 项目结构建议按下面的结构组织 AI 测试工程项目ai_test_project/ ├── config/ │ └── settings.py # 配置文件 ├── data/ │ ├── cases.json # 测试用例集 │ └── bad_cases/ # 失败用例归档 ├── core/ │ ├── llm_client.py # 模型调用封装 │ ├── judge.py # 评测逻辑 │ └── report.py # 结果报告生成 ├── tests/ │ ├── test_accuracy.py # 准确性测试 │ └── test_rag.py # RAG 测试 └── main.py # 入口脚本这个结构的好处是用例数据、模型调用、评测逻辑、报告输出分离方便后续维护和扩展。5. 完整实战搭建一个 AI 对话模型测试框架这部分是文章的重点。我们以一个“企业知识库问答机器人”为例实现一套可运行的 AI 自动化测试框架。5.1 需求描述被测对象是一个基于 RAG 的知识库问答机器人。测试目标是检验模型回答的准确性。检验模型是否引用了知识库文档。统计整体通过率输出测试报告。5.2 准备测试用例集在data/cases.json中准备测试用例[ { id: case_001, question: 公司年假政策是什么, reference: 员工入职满一年后每年享有5天带薪年假。, expect_has_keyword: 年假 }, { id: case_002, question: 报销流程需要哪些材料, reference: 报销需要提供发票、审批单和银行账户信息。, expect_has_keyword: 发票 } ]这里三个字段的含义question输入给模型的问题。reference参考答案用于评测。expect_has_keyword期望回答中包含的关键词。说明这个字段是规则校验的辅助手段不能作为唯一标准但可以作为自动化初筛。5.3 封装模型调用在core/llm_client.py中统一封装模型请求import requests class LLMClient: def __init__(self, api_url, api_key, model_name): self.api_url api_url self.api_key api_key self.model_name model_name def chat(self, question: str) - str: headers { Authorization: fBearer {self.api_key}, Content-Type: application/json } payload { model: self.model_name, messages: [ {role: user, content: question} ], temperature: 0.3 } response requests.post(self.api_url, jsonpayload, headersheaders, timeout60) response.raise_for_status() data response.json() return data[choices][0][message][content]注意三点请求地址、模型名称等参数从配置读取不要硬编码在代码里。设置超时时间避免模型响应过慢导致测试卡死。temperature设置为较低值减少回答的随机性方便测试结果对比。5.4 编写评测逻辑在core/judge.py中实现评测函数def contain_keyword(answer: str, keyword: str) - bool: return keyword in answer def accuracy_score(answer: str, reference: str) - int: # 简化版参考答案中每个关键词是否出现在回答中 keywords extract_keywords(reference) hit_count sum(1 for k in keywords if k in answer) if len(keywords) 0: return 0 return round(hit_count / len(keywords), 2)实际项目中extract_keywords可以改用大模型从参考答案中提取关键词也可以直接用 jieba 分词后选取核心词。这里为了示例简单用了一个占位思路。5.5 编写 Pytest 测试用例在tests/test_chatbot.py中编写测试import json import pytest from core.llm_client import LLMClient from core.judge import contain_keyword # 注意实际使用时这些配置应放在 config/settings.py 中 API_URL https://your-llm-api.example.com/v1/chat/completions API_KEY your-api-key MODEL_NAME your-model client LLMClient(API_URL, API_KEY, MODEL_NAME) def load_cases(): with open(data/cases.json, r, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_cases(), idslambda c: c[id]) def test_answer_keyword(case): answer client.chat(case[question]) assert contain_keyword(answer, case[expect_has_keyword]), \ f回答中未包含关键词{case[expect_has_keyword]}实际回答{answer}运行测试pytest tests/test_chatbot.py -v预期输出是每个用例的名称和 PASS/FAIL 状态。5.6 生成测试报告为了更直观地展示测试结果我们在core/report.py中写一个简单的报告生成函数import json import datetime def generate_report(results: list, output_path: str): report { generated_at: datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S), total: len(results), passed: sum(1 for r in results if r[passed]), failed: sum(1 for r in results if not r[passed]), details: results } with open(output_path, w, encodingutf-8) as f: json.dump(report, f, ensure_asciiFalse, indent2) print(f报告已生成{output_path})这个模块的价值在于面试时你可以展示“做了测试数据采集和报告输出”而不是只说“我会用 pytest 跑用例”。5.7 结果分析与实际应用跑完测试后重点不是看绿灯绿灯而是分析失败用例。常见分析路径失败原因是关键词没匹配上还是模型回答为空如果是模型没回答对去查知识库有没有相关内容。如果是检索问题看切块逻辑和 embedding 效果。如果同样的问题重复出现沉淀为 bad case加入回归用例集。这个“分析闭环”才是 AI 测试工程师和普通自动化测试工程师的核心区别面试时一定要讲出来。6. AI 自动化测试实施落地的核心思路6.1 自动化测试在 AI 场景中的落地路径很多同学写了“AI 自动化测试”在简历上但面试官追问“怎么落地”就说不清楚。这里给一个通用实施路径第一阶段用例管理线上化。把散落在 Excel 和文档里的测试用例集中到测试平台或 Git 仓库统一版本管理。第二阶段接口级自动化。先做模型接口层的自动化测试每次模型版本更新后自动跑回归集保证基础能力不退化。第三阶段效果评测体系化。引入评测集和大模型裁判机制输出多维度的质量报告。这一步本质上是把“效果评估”从人工模式变成半自动模式。第四阶段测试流程融入研发流水线。在模型发布前自动触发评测达标后放行。这时候 AI 测试就从“事后发现”变成了“事前拦截”。6.2 测试数据的管理AI 测试对数据的依赖远高于传统测试。建议重点准备以下几点数据来源优先从线上日志脱敏后提取真实用户问题不要只靠人工编造。数据标注如果是检索类任务需要标注“哪些文档是正确结果”否则无法计算命中率。数据版本评测集要像代码一样做版本管理数据集变更时必须记录变更原因和影响范围。数据质量定期检查评测集是否过期。比如产品政策变了之前的参考答案可能已经不适用。6.3 测试 AI 智能体时的特殊关注点AI 智能体Agent和普通大模型问答不同它涉及任务规划、工具调用和结果返回。测试时建议增加这些检查维度任务拆解给智能体一个复杂指令检查它是否被拆解成合理的子任务。工具选择智能体是否选择了正确的 API 或工具比如查天气时调用了天气接口而非物流接口。参数传递工具调用参数是否完整、正确。异常处理工具调用失败时智能体是优雅降级还是直接报错。最终结果综合所有工具返回后智能体给出的总结是否准确。这部分的测试难度高因为步骤多、链路长。建议先用录制真实调用的方式收集路径再逐步构造异常场景。7. 高频 AI 测试面试题与答题思路根据近期热门的 AI 测试面试题合集我整理了几类出现频率最高的问题并给出答题思路。7.1 概念类问题“什么是大模型幻觉如何测试和规避”答题思路先解释幻觉模型生成了与事实不符或没有依据的内容。再讲测试方法构建含事实性问题的评测集把模型回答与权威知识对比。最后讲规避手段在 RAG 场景中加入引用溯源强制模型回答必须附引用对高风险问题设置拒答策略。“RAG 和微调有什么区别测试上有什么不同”答题思路RAG 是在推理时检索外部知识适合知识更新频繁的场景微调是修改模型参数适合风格和格式固定的场景。测试 RAG 时重点测检索质量和引用准确性测试微调模型时重点测任务特定指标和通用能力是否退化。7.2 场景设计类问题“给你一个客服机器人你怎么制定测试方案”比较完整的回答框架功能测试基础问答流程、转人工流程、多轮会话保持。模型效果测试准备评测集评估准确性、完整性、拒绝率。边界测试测试超长问题、空问题、错别字问题、多意图问题。安全测试测试提示词注入、有害内容拒答、隐私数据泄露。性能测试并发请求、响应时间、上下文长度超过限制时的表现。按这个顺序回答面试官能看到你的结构思维。7.3 数据与效果分析类问题“如果模型准确率从 90% 掉到 80%你怎么排查”答题思路先确认数据评测集是否变更参考答案是否过期再确认环境模型版本是否回滚Prompt 是否被改动检索库是否有更新然后分组对比按问题类型、文档来源、用户群体拆开分析定位是哪部分能力退化。最后回归验证用历史用例集跑一遍确认问题是偶发还是持续。这类问题考察的是“测试工程师的排查思维”重点是逻辑要完整。“测试 AI 智能体时数据处理如何测试”这是近期的热搜词之一。智能体数据处理包含输入数据解析、中间状态存储、工具返回数据清洗等环节。测试重点是输入异常传入非法 JSON、字段缺失、类型错误时智能体是否能正确处理。中间状态多步骤任务中状态传递是否遗漏或串改。输出数据工具返回的结果是否被正确解析和引用。数据一致性一次任务中多次调用工具同一字段的值是否一致。7.4 代码与工具类问题面试中经常要求现场写代码。下面是两道常见题目题目一统计一批模型回答的通过率def calc_pass_rate(results): total len(results) if total 0: return 0.0 passed sum(1 for r in results if r[passed]) return round(passed / total * 100, 2)题目二读取 JSON 评测集提取所有包含特定关键词的用例import json def filter_cases(case_path, keyword): with open(case_path, r, encodingutf-8) as f: cases json.load(f) return [c for c in cases if keyword in c.get(question, )] filtered filter_cases(data/cases.json, 报销) print(len(filtered))这类题目的考点不是算法而是文件读取、JSON 解析、列表推导式等基本功。熟悉这些写法能减少现场写码时的紧张感。8. 常见问题与排查思路8.1 接口超时导致测试失败问题现象常见原因解决思路测试用例大量超时模型推理慢、并发过高调大超时时间、降低并发数、使用异步调用偶发超时网络波动、服务限流加入重试机制记录失败日志部分用例返回空内容模型侧限流或参数错误检查 API Key 和请求参数查看服务端日志8.2 关键词断言不稳定问题现象常见原因解决思路语义正确但关键词不匹配模型换了一种表达改用语义相似度或大模型裁判关键词匹配但答案错误关键词过于宽泛增加核心实体校验使用参考答案综合评估同一用例时过时不过模型随机采样降低 temperature多次执行取多数结果8.3 面试中问到的数据集类问题“测试数据不够怎么办”参考思路从线上日志脱敏提取真实问题。用大模型生成候选问题经人工审核后入库。注意生成的问题必须人工验收否则会把噪音带进评测集。借助开源数据集做基础集再补充业务数据。9. 最佳实践与工程建议9.1 评测集要持续维护不要建完评测集就不管了。每发现一个新的 bad case就补充进去。每发布一个新的模型版本就重新跑一遍全集并对比历史得分。评测集就是 AI 测试工程师的“测试资产”它比测试脚本本身更有长期价值。9.2 评估体系要分层次建议把评估分成三层第一层自动化规则校验。比如是否包含关键实体、是否为空、响应时长是否达标。第二层大模型裁判评分。对语义质量做初筛。第三层人工抽检。对高风险场景和争议结果做人工复核。三个层次结合既能控制成本又能保证质量。9.3 结果数据必须可追溯每条测试结果都要记录模型版本Prompt 版本检索库版本评测集版本执行时间完整输入输出只有数据可追溯模型效果波动时你才能快速定位原因。建议用固定的报告格式并把报告存档。9.4 代码质量与可维护性AI 测试代码同样要做代码评审。要注意配置和代码分离API Key 不要提交到仓库。公用的模型调用逻辑封装成独立模块不要在用例里重复写 requests 请求。测试数据不要散落在测试函数里统一放到数据文件。失败用例要自动归档方便后续分析。10. 面试准备清单与学习路线10.1 面试前自查清单下面这份清单可以在面试前几天快速过一遍[ ] 能解释 AI 测试的两个方向测 AI 和用 AI 测[ ] 能说出准确率、精确率、召回率、F1 的区别[ ] 能现场写出一个调用模型接口并做断言的小脚本[ ] 能完整描述一个 AI 测试项目的测试方案和落地过程[ ] 能说明 RAG 系统的测试重点和常见问题[ ] 能画出 bad case 的分析排查链路[ ] 能说出评测集维护和模型版本管理的具体做法如果以上 7 条都能做到面试时基本不会慌。10.2 后续学习方向从 AI 测试入行后续可以往两个方向发展深度方向深入研究大模型评测体系比如 RAG 评测、Agent 评测、多模态模型评测。广度方向把 AI 测试能力扩展到性能测试、安全测试、数据测试成为全栈测试工程师。建议选择一条主线深耕。目前市场上对“大模型应用测试”和“AI 智能体测试”的需求增长很快值得投入时间。最后想说AI 测试面试准备最忌讳的是只背题不实践。面试题只能帮你建立知识框架真正的竞争力来自你亲手跑过的脚本、分析过的 bad case、沉淀下来的评测集。如果时间有限优先做一个小而完整的项目把“用例设计 → 自动化执行 → 结果分析 → 报告输出”整条链路跑通这比刷一百道题更有效。