AI测试面试核心指南：能力模型、评测集与实战项目

这两年测试岗的面试风向变化很明显。以前问的是接口、自动化、性能三板斧，现在很多公司开始问“大模型怎么测”“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 建议准备的知识路线

按照“基础 → 概念 → 工具 → 实战”的顺序准备：

1. Python 基础与数据处理（Pandas、JSON 操作）
2. 传统测试技能（接口测试、自动化测试）
3. 机器学习与 LLM 基础概念
4. Prompt 工程与评测集设计
5. AI 自动化测试框架搭建
6. 智能体测试与数据质量分析
7. 真实项目实战与面试题复盘

不用贪多，但每一步都要能做出来。面试官经常让你现场写一段脚本或者讲一个项目的实现细节，纸上谈兵是过不了关的。

3. 核心概念：AI 测试高频考点拆解

3.1 模型评估指标

面试时，指标是必考点。建议至少掌握下面几组：

分类模型指标：

• 准确率（Accuracy）：预测正确的样本占总样本的比例。适用于类别均衡的场景。
• 精确率（Precision）：预测为正类的样本中，真正为正类的比例。关注“预测为正的有多准”。
• 召回率（Recall）：真实为正类的样本中，被正确预测出来的比例。关注“正类漏了多少”。
• F1 值：精确率和召回率的调和平均数，综合衡量模型效果。

为了便于理解，可以这样记忆：精确率是“宁缺毋滥”，召回率是“宁滥勿缺”。实际业务中，垃圾邮件拦截更关注精确率，癌症筛查更关注召回率。

大模型生成类指标：

• 幻觉率：模型生成内容与事实不符的比例。
• 答案准确性：人工或大模型裁判对答案正确性的打分。
• 检索命中率：RAG 系统中，正确文档是否被检索到。
• 引用准确率：模型给出的引用内容是否真实存在于检索文档中。
• 多轮一致性：多轮对话中，模型是否记住并正确使用前文信息。

3.2 评测集与 Prompt 设计

设计评测集是 AI 测试工程师的核心工作之一。面试中常见的追问是：“你怎么评估一个聊天机器人好不好？”

一个可复用的回答思路是：

1. 明确测试范围：先确定是单轮问答、多轮对话、还是带工具调用的 Agent 场景。
2. 构建评测集：从真实用户日志中抽取问题，覆盖常见问题、边界问题、恶意问题、模糊问题。
3. 定义评分标准：给每个维度打分，比如准确性 0~5 分，是否包含有害内容 0/1 判断。
4. 评估执行：把测试用例批量发送给模型，收集回答，由人工或大模型裁判打分。
5. 结果分析：统计各维度得分，分析 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 均可
• Python：3.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 openai

4.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": f"Bearer {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, json=payload, headers=headers, timeout=60) 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", encoding="utf-8") as f: return json.load(f) @pytest.mark.parametrize("case", load_cases(), ids=lambda 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", encoding="utf-8") as f: json.dump(report, f, ensure_ascii=False, indent=2) print(f"报告已生成：{output_path}")

这个模块的价值在于：面试时你可以展示“做了测试数据采集和报告输出”，而不是只说“我会用 pytest 跑用例”。

5.7 结果分析与实际应用

跑完测试后，重点不是看绿灯绿灯，而是分析失败用例。常见分析路径：

1. 失败原因是关键词没匹配上，还是模型回答为空？
2. 如果是模型没回答对，去查知识库有没有相关内容。
3. 如果是检索问题，看切块逻辑和 embedding 效果。
4. 如果同样的问题重复出现，沉淀为 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 概念类问题

“什么是大模型幻觉？如何测试和规避？”

答题思路：

1. 先解释幻觉：模型生成了与事实不符或没有依据的内容。
2. 再讲测试方法：构建含事实性问题的评测集，把模型回答与权威知识对比。
3. 最后讲规避手段：在 RAG 场景中加入引用溯源，强制模型回答必须附引用；对高风险问题设置拒答策略。

“RAG 和微调有什么区别？测试上有什么不同？”

答题思路：

• RAG 是在推理时检索外部知识，适合知识更新频繁的场景；微调是修改模型参数，适合风格和格式固定的场景。
• 测试 RAG 时重点测检索质量和引用准确性；测试微调模型时重点测任务特定指标和通用能力是否退化。

7.2 场景设计类问题

“给你一个客服机器人，你怎么制定测试方案？”

比较完整的回答框架：

1. 功能测试：基础问答流程、转人工流程、多轮会话保持。
2. 模型效果测试：准备评测集，评估准确性、完整性、拒绝率。
3. 边界测试：测试超长问题、空问题、错别字问题、多意图问题。
4. 安全测试：测试提示词注入、有害内容拒答、隐私数据泄露。
5. 性能测试：并发请求、响应时间、上下文长度超过限制时的表现。

按这个顺序回答，面试官能看到你的结构思维。

7.3 数据与效果分析类问题

“如果模型准确率从 90% 掉到 80%，你怎么排查？”

答题思路：

1. 先确认数据：评测集是否变更？参考答案是否过期？
2. 再确认环境：模型版本是否回滚？Prompt 是否被改动？检索库是否有更新？
3. 然后分组对比：按问题类型、文档来源、用户群体拆开分析，定位是哪部分能力退化。
4. 最后回归验证：用历史用例集跑一遍，确认问题是偶发还是持续。

这类问题考察的是“测试工程师的排查思维”，重点是逻辑要完整。

“测试 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", encoding="utf-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、沉淀下来的评测集。如果时间有限，优先做一个小而完整的项目，把“用例设计 → 自动化执行 → 结果分析 → 报告输出”整条链路跑通，这比刷一百道题更有效。