AI 测试岗“先混进去再说”我没法完全反对但进去之后你不能真的一直“混”。最近和不少准备转岗测试的同学聊天他们的思路惊人地一致现在大模型这么火AI 测试岗位缺口大、面试官自己也未必懂先把简历改成“AI 测试”混进去再说。说实话这个判断有一半是对的。AI 测试确实缺人而且当前很多团队的 AI 测试体系都不成熟进去之后有大量重新定义规范和标准的空间。但另一半很残酷很多“混进去”的人在试用期就暴露出了问题——不会设计评测集、不理解模型输出的不确定性、不会写自动化测试用例最后要么被转岗要么被迫疯狂补课。这篇文章不劝你“不要混”因为机会窗口确实存在这篇文章只做一件事把 AI 测试岗位背后真正需要掌握的能力拆开给你一套可以照着练、照着用的技术路径。读完你会明白AI 测试的门槛不是“会调用 API”而是“怎么让 API 的输出变成可信任的测试结论”。这也是 AI 测试和传统测试最本质的区别。1. “先混进去”没有错但你能在里面活过试用期吗我见过不少以“混”为前提进入 AI 测试岗位的人他们的共同点是简历上写着熟悉大模型应用测试实际工作里只会打开网页版对话窗口把 Prompt 粘贴进去然后人工判断回答对不对。这种工作方式在面试时可能蒙混过关但进入真实项目后会立刻暴露三个问题。第一个问题是效率。真实项目里的大模型能力不是聊天而是被封装成 API、Agent、RAG 应用一次改动可能影响几十个场景。一个人工点击、人工判断的方式一次回归要一整天而产品迭代频率是每天发布。第二个问题是标准。人工判断“回答对不对”非常主观同一个回答有人觉得可以接受有人觉得是幻觉最后测试结论完全靠争论不靠数据。第三个问题是无法自动化。测试工程师的核心价值之一是回归能力如果每次都要人工操作那和产品体验官没有区别。所以我的判断是AI 测试岗位确实可以“先混进去”因为需求大于供给但想在里面活过试用期必须快速补上三样东西——测试用例设计能力、自动化执行能力、可量化的结果判断能力。这篇文章后面给出的每一个示例都是围绕这三样东西展开的。如果你准备面试 AI 测试岗位或者已经在岗位上但感觉每天在“瞎测”这篇文章建议收藏按步骤实践。你会发现AI 测试并不是一个全新的领域它只是把传统的测试方法论叠加到了一个新的被测对象上。2. AI 测试到底测什么对象变了测试的核心逻辑没变很多人一听“AI 测试”第一反应是“测试大模型”第二反应是“那我是不是要会训练模型”。这是一个非常大的误解。AI 测试的对象通常不是模型本身而是基于大模型构建的应用系统。换句话说你要测的是一个软件系统只不过这个系统里有大模型参与逻辑决策。如果团队在训练自有模型那是算法工程师和评测工程师的工作和大多数应用层的 AI 测试岗位关系不大。为了把概念讲清楚我们可以把传统测试和 AI 测试做一个对比。维度传统功能测试AI 应用测试被测对象确定性函数、接口、UI 流程大模型 API、Agent、RAG、Prompt 链路核心挑战输入确定断言输出是否正确输入确定输出不确定可能多个结果都合理测试用例设计等价类、边界值、场景法场景法 Prompt 覆盖 知识库边界 对抗样本断言方式状态码、返回值、数据库字段语义相似度、关键词规则 人工抽检 评估指标回归测试自动化稳定执行自动化执行 非确定性容忍 结果抽样复核测试数据静态数据、固定数据动态数据、知识库切片、Prompt 模板、历史对话从这个表格能看出一个关键变化传统测试的难点在于“设计出覆盖全的用例”AI 测试的难点则变成了“面对不确定输出如何设计出可执行的断言”。这里要引入两个测试行业已经在使用的概念测试左移和测试右移。测试左移是指把测试活动往前推进到需求、设计、开发阶段。在 AI 应用里左移意味着你需要在 Prompt 设计阶段就介入测试不同 Prompt 模板的输出差异而不是等开发把功能做完了才开始测。测试右移是指把测试延伸到线上通过线上日志、用户反馈、指标监控来发现和补充测试场景。对于一个 AI 应用来说右移尤其重要因为模型在训练数据里没见过的边缘场景只有上线后被真实用户触发你才能发现。AI 测试工程师真正要做的事情是构建一个“评测闭环”设计用例 → 构造输入 → 调用系统 → 收集输出 → 自动或人工判断 → 反馈给开发或算法团队 → 修改后再回归。这篇文章后面的实战部分就是帮你把这个闭环跑通。3. AI 测试需要什么基础不会大模型也能开始的四个能力块很多测试工程师担心自己没有大模型背景做不了 AI 测试。实际上大部分 AI 测试岗位需要的基础并不是机器学习理论而是四个能力块。第一个能力块是“场景拆解”。你需要把一个真实的用户需求拆成可以在测试环境里复现的输入组合。比如测试一个 AI 客服不能只测“用户问退货政策”还要测“用户上传了一张模糊的订单截图”“用户用英文问中文知识库”“用户连续追问三个相关问题”。这些场景拆解能力做过功能测试的人都具备只是需要迁移到 AI 应用上。第二个能力块是“用例组织”。AI 测试的用例可以是一条 Prompt也可以是一组配有预期要点的 JSON 数据。你不需要把它们放在 Excel 里等开发来认领而是应该用代码组织成可自动执行的测试集。这意味着你需要一点 Python 基础加上 pytest 这类框架的使用经验。第三个能力块是“结果判断”。这是 AI 测试和传统测试分水岭最大的地方。传统测试可以用断言判断返回是否等于预期值AI 测试必须回答一个更模糊的问题“这个回答虽然不是预期文本但语义上是不是合格的”你可以用规则来做初筛比如是否包含关键实体、是否拒绝回答、是否包含敏感词也可以用大模型自己做裁判用 GPT-4 级别的模型给被测模型的输出打分。把主观判断变成分级判断、抽样判断是 AI 测试工程师的核心技能。第四个能力块是“工具链使用”。你至少要会用 Python 写脚本调用 OpenAI 或其他大模型 API会处理 JSON 格式的返回结果会配置环境变量能在命令行跑测试脚本。这些技能不需要达到开发工程师的水平但必须自己动手跑通。如果你这四块都是零基础也可以从这篇文章的示例开始先跑通一个最小链路再逐步补充。AI 测试的起步门槛并没有网上渲染的那么高但它确实不会停留在“点一点、看一看”的阶段。4. 环境准备与最小工具栈开始动手之前先确定一个原则AI 测试和传统测试一样优先在本地跑通最小场景再考虑接入 CI/CD 或测试平台。这样可以降低调试成本也能让你对工具链的每一步都有控制感。我建议的最小工具栈如下Python 3.9 及以上版本。版本以你本机实际安装为准建议不低于 3.9主要是为了保证类型注解和依赖兼容性。pytest 测试框架。用于组织用例、运行用例、收集报告。requests 或 openai Python SDK。用于调用大模型 API。如果你只是先跑通流程用 requests 直接调 HTTP 接口更容易理解底层逻辑如果你们团队已经接入某个云厂商的模型服务就以官方 SDK 为准。python-dotenv。用于管理 API Key 等敏感配置避免把密钥写死在代码里。安装命令如下pip install pytest requests python-dotenv如果你使用 openai SDK可以追加安装pip install openai环境变量示例在项目根目录创建.env文件# 文件路径.env # 注意此文件不要提交到 Git 仓库 API_BASE_URLhttps://api.example.com/v1 API_KEYsk-your-key-here MODEL_NAMEgpt-3.5-turbo这里提醒一句无论你接入的是哪家大模型服务API Key 都属于敏感信息。生产项目的密钥应该放在密钥管理系统里本地开发也至少用.gitignore把.env排除掉。搭建好环境后可以先写一个最简单的连通性测试确认 API 能通# 文件路径test_api_connect.py import os import requests from dotenv import load_dotenv load_dotenv() def test_api_connect(): url os.getenv(API_BASE_URL) /chat/completions headers { Authorization: fBearer {os.getenv(API_KEY)}, Content-Type: application/json } payload { model: os.getenv(MODEL_NAME), messages: [{role: user, content: 你好请回复连接成功这四个字}], temperature: 0 } resp requests.post(url, headersheaders, jsonpayload, timeout30) assert resp.status_code 200, fAPI 调用失败状态码{resp.status_code} content resp.json()[choices][0][message][content] assert 连接成功 in content print(API 连接测试通过返回内容, content)这个用例的价值不在于测出什么 bug而在于帮你确认网络、密钥、模型服务都正常。如果这一步失败后面的所有内容都无法开展。常见原因包括 API Key 配置错误、网络代理问题、模型名不存在、请求超时排查顺序就是按这个优先级来。5. 从“跑通 API”到“自动执行测试用例”的完整示例环境没问题之后接下来要做的是把 AI 测试的关键能力串起来用测试数据驱动调用把返回结果变成可断言的结论。下面用一个非常典型的场景做示例假设你负责测试一个基于大模型的客服问答系统系统内部接入了企业知识库用户提问后系统返回答案。5.1 封装一个统一的调用函数不管被测系统是直接调大模型 API还是经过一层业务封装测试端最好都统一走一个函数。这样后续用例改造、模型切换、加日志都只需要动一个地方。# 文件路径ai_client.py import os import requests from dotenv import load_dotenv load_dotenv() def chat(prompt: str, system_prompt: str 你是一个企业客服助手) - str: 调用大模型 API返回模型生成的文本内容。 url os.getenv(API_BASE_URL) /chat/completions headers { Authorization: fBearer {os.getenv(API_KEY)}, Content-Type: application/json } payload { model: os.getenv(MODEL_NAME), messages: [ {role: system, content: system_prompt}, {role: user, content: prompt} ], temperature: 0.2 } resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content]这个封装非常薄但它做了三件重要的事加载环境变量、统一 URL 拼接、解包返回文本。你只需要在测试用例里调用chat(prompt)不需要关心 HTTP 细节。5.2 设计测试用例文件这里要说明一个 AI 测试的重要思想AI 测试的用例不一定要像传统测试那样写“输入、输出”更实用的组织方式是“场景、Prompt、关键断言点”。# 文件路径test_qa_cases.py import pytest from ai_client import chat test_cases [ { id: case_001, scenario: 正常咨询退货政策, prompt: 我在你们平台买了一双鞋尺码不合适想退货请问流程是什么, must_contain: [退货, 7天, 申请], should_not_contain: [不支持退货] }, { id: case_002, scenario: 咨询客服上班时间, prompt: 请问人工客服几点上班, must_contain: [9:00, 18:00, 客服] }, { id: case_003, scenario: 用户表达不文明情绪, prompt: 你们这个平台太垃圾了我要投诉, must_contain: [抱歉, 反馈, 专员], should_not_contain: [闭嘴, 不关我们的事] } ] pytest.mark.parametrize(case, test_cases, ids[c[id] for c in test_cases]) def test_qa_responses(case): response chat(case[prompt]) print(f\n[{case[id]}] {case[scenario]}\n用户{case[prompt]}\n助手{response}\n) for keyword in case[must_contain]: assert keyword in response, f关键词 {keyword} 未出现响应内容不满足要求。响应{response} for keyword in case.get(should_not_contain, []): assert keyword not in response, f禁止关键词 {keyword} 出现响应内容不符合规范。响应{response}这段代码的核心逻辑是关键词断言。虽然模型输出没有固定结构但企业客服场景中答案通常必须包含某些关键实体比如退货政策、时间、联系渠道。如果模型完全没有提到这些实体那基本可以判断回答不合格即使两个句子在语义上非常接近。但关键词断言有一个明显的盲区模型可能用同义词替换了关键词导致断言失败。这种情况不要急着改断言先人工看一下完整响应再决定是候选词列表需要扩充还是模型真的答错了。AI 测试的常见坑之一就是滥用关键词断言把合理的同义表达误判成 bug。5.3 引入大模型作为裁判关键词断言能覆盖一部分场景但要判断一个回答是否“语义准确”更进阶的方法是引入一个裁判模型。# 文件路径test_with_judge.py import pytest from ai_client import chat judge_system_prompt 你是一个测试评审专家。我会给你一个用户问题、一个标准答案和一个模型回答。 请判断模型回答是否在语义上正确回应了用户问题。 如果回答正确输出 PASS如果不正确或存在明显偏差输出 FAIL。 只输出 PASS 或 FAIL不要解释。 def judge_answer(question: str, expected_answer: str, actual_answer: str) - str: judge_prompt f 用户问题{question} 标准答案{expected_answer} 模型回答{actual_answer} 请给出判定结果。 result chat(judge_prompt, system_promptjudge_system_prompt) return result.strip() def test_answer_with_judge(): question 你们平台怎么申请售后 expected_answer 用户可以在订单详情页点击申请售后填写原因后等待审核一般 1 到 3 个工作日处理。 actual_answer 在订单详情里找到售后按钮提交申请就行审核大概需要一两天。 result judge_answer(question, expected_answer, actual_answer) print(\n裁判模型判定, result) assert result PASS, 裁判模型判定模型回答不通过。这种做法本质上是“用模型测模型”被测模型生成回答裁判模型判断回答是否合格。它比关键词断言更灵活也更能发现语义层面的问题。但它有一个很大的副作用——裁判模型本身也会误判而且会消耗额外的 token。所以实际项目中裁判模型更推荐用在“抽检”和“批量评估”环节而不是每一条请求都实时调用。这也是为什么很多团队会把评测结果保存下来再做一轮人工抽检。5.4 场景化测试构造一个简单的 RAG 评估流程如果你要测试的不是单轮问答而是带检索增强的 RAG 应用测试重点会发生变化。RAG 的核心链路是“用户问题 → 检索知识库切片 → 拼接 Prompt → 模型生成”。测试时既要验证检索结果相关性也要验证最终回答是否忠实于检索到的内容。下面这个示例模拟一个批量评估流程使用 pytest 参数化读取用例文件对每个用例调用被测系统并将结果保存到 JSON 文件# 文件路径test_rag_evaluation.py import json from pathlib import Path import pytest from ai_client import chat def load_rag_cases(): case_file Path(rag_test_cases.json) with open(case_file, r, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_rag_cases(), idslambda c: c[id]) def test_rag_evaluation(case): question case[question] expected_points case[expected_points] response chat(question) passed_points [] failed_points [] for point in expected_points: if any(keyword in response for keyword in point[keywords]): passed_points.append(point[name]) else: failed_points.append({name: point[name], keywords: point[keywords]}) print(f\n用例ID{case[id]}) print(f问题{question}) print(f回答{response}) print(f通过要点{passed_points}) print(f未通过要点{failed_points}) result { id: case[id], question: question, response: response, passed_points: passed_points, failed_points: failed_points } output_file Path(rag_results.json) output_file.write_text(json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8) assert not failed_points, f以下要点未命中{failed_points}对应的用例文件rag_test_cases.json可以这样组织[ { id: rag_001, question: 刚买的手机可以 7 天无理由退货吗, expected_points: [ { name: 明确退货时限, keywords: [7天, 七天] }, { name: 提及申请渠道, keywords: [申请, 订单, 客服] } ] }, { id: rag_002, question: 发票抬头可以修改吗, expected_points: [ { name: 说明允许修改的条件, keywords: [开票, 修改, 抬头] } ] } ]这个流程把“一个用例要覆盖哪些信息点”显式地建模出来了比单纯判断关键词是否出现更有指导意义。测试报告中能明确看到哪类信息点没被覆盖到方便反馈给开发或者知识库维护方。6. 运行结果与效果验证怎么判断测试真的有效用例写完了怎么运行pytest test_qa_cases.py -v预期会看到每个用例的执行结果test_qa_cases.py::test_qa_responses[case_001] PASSED test_qa_cases.py::test_qa_responses[case_002] PASSED test_qa_cases.py::test_qa_responses[case_003] PASSED测试通过不代表你的测试有效只能说明这组输入没有被系统“明显答错”。要判断测试本身是否有效建议关注以下三个维度。第一个维度是“失败是否可解释”。如果某个用例失败检查响应内容应该能快速定位是模型幻觉、Prompt 理解偏差还是测试断言过严。如果你看到一个失败用例却说不清楚失败原因那说明用例设计有问题。AI 测试最怕的不是失败而是失败原因难以理解。第二个维度是“用例是否覆盖到高价值场景”。高价值场景包括核心业务主流程、异常输入、情绪化输入、多轮上下文、知识库边缘情况、敏感话题边界、恶意攻击注入。你可以定期检查用例清单看是否覆盖了这些类别。第三个维度是“执行成本是否可控”。记录每次回归的调用次数、token 消耗、执行时长。如果一条用例需要几十秒才能跑完那批量回归上千条用例就不现实应该考虑分层策略冒烟级用少量用例快跑完整级用大批量用例定期执行。这里还要补充一个非常重要的认知AI 测试的“Pass”和“Fail”并不是绝对的。由于模型输出的不确定性同一条用例跑三次可能出现一次失败两次通过。因此在项目实践中建议引入“重跑机制”和“抽检机制”。重跑机制指失败用例单独再跑 2 到 3 次确认是否是偶发波动抽检机制指通过用例中按比例抽取一部分人工检查回答质量是否确实过关。把两者结合起来才能在速度和质量之间取得平衡。7. 常见问题与排查思路AI 测试在执行过程中会遇到很多传统测试没有的问题。下面这张表是基于真实项目中高频出现的问题整理的排查思路。问题现象可能原因排查方式解决方案同一条用例反复失败/通过模型输出非确定性、temperature 设置过高用不同 temperature 复跑记录多次结果将 temperature 调到 0 或 0.2并对通过率做统计判定断言包含关键词但回答明显错误关键词规则过于宽松或模型生成了看似相关但语义无关的内容人工查看完整响应分析是否出现张冠李戴增加必含实体数量或引入裁判模型做语义判定API 调用频繁超时网络不稳定、单次请求耗时长、并发过高查看响应耗时日志确认是否有限流策略增加超时时间、控制并发数、接入重试机制测试成本过高用例数量大、每条 prompt 太长、批量执行过于频繁统计 token 消耗和执行耗时分层执行低风险场景用少量用例完整回归放夜间任务模型回答包含敏感信息RAG 检索到不该出现的内容或模型从训练数据中泄露知识检查知识库切片来源验证 Prompt 系统提示是否明确限制了范围在系统 Prompt 中加入边界约束并在测试用例中加入敏感词断言新功能接入后旧用例大量失败被测系统 Prompt 或知识库变更导致原有输出语义偏移对比变更前后的响应记录查看 diff确认变更是预期行为后同步更新用例预期并记录变更原因裁判模型与人工判断不一致裁判模型本身能力边界、裁判 Prompt 不够明确抽检不一致的样本统计裁判准确率优化裁判 Prompt提供更明确的评价标准和示例排查思路的总原则是先确认“是系统的问题还是测试自身的问题”再确认“是偶发波动还是系统性退化”。这个原则听起来简单但在 AI 测试中特别容易被忽略。因为输出不稳定很多人会把系统 bug 当作用例波动或者把测试断言问题当成系统 bug最后浪费大量时间去修复一个本来不存在的问题。8. 从“能跑”到“跑得好”AI 测试工程师的能力进阶路径如果你已经能跑通上面这些示例说明你已经完成了“从 0 到 1”的阶段。接下来要想在职场上站稳还需要一个更系统的能力进阶路径。第一阶段是“用例工程师”。你能把业务场景转化为可执行的测试用例能设计关键词断言和基本场景覆盖。这个阶段的核心目标是稳定跑通批量回归能输出清晰的测试报告。大多数刚转岗的人应该先在这个阶段沉淀至少一两个月。第二阶段是“评估方案设计者”。你能针对不同业务场景选择合适的评估方式什么时候用关键词规则什么时候用裁判模型什么时候人工抽检以及如何设计抽检比例和通过阈值。你开始理解准确率、召回率、幻觉率这些指标的测试含义并且能把它们翻译成测试团队可以执行的方案。这个阶段你已经不是“会跑用例”而是“能设计评测体系”。第三阶段是“质量策略负责人”。你能从整个产品生命周期出发把模型评测、Prompt 调优、知识库质量、线上监控串联起来。你知道模型上线前需要过哪些关卡上线后哪些指标必须盯用户反馈回流后如何反哺测试集。到这个阶段AI 测试不再是独立环节而是产品迭代质量闭环的一部分。对应这三个阶段你可以梳理自己的技能缺口。如果你的 Python 还不太熟先去补 Python 基础如果你不懂 Prompt 工程去学系统提示词和少样本示例的写法如果你不会设计评估指标去查一查大模型评估中的精确率、召回率、BLEU、ROUGE 等指标含义。路径并不神秘缺哪块补哪块。有一个建议想特别强调不要把“会调用大模型 API”这件事当成终极技能。API 调用只是最底层的基础设施真正体现你价值的是“如何设计测试任务、如何解释结果、如何推动质量改进”。面试官真正想看的是你能不能把一个模糊的“帮我测试一下 AI 功能”变成一套可执行、可量化、可回归的测试方案。9. 总结与入行建议回到标题AI 测试岗是不是都是“先混进去再说”我的答案是把“先跑起来”作为入行策略是可以理解的因为它让你走到了牌桌上但如果你想在这个岗位上长期发展最终还是要回到测试工程的基本功和 AI 应用的独特挑战上。AI 测试本质上是传统测试方法论在大模型时代的延伸它需要你在不确定性中找到确定性在模糊输出中建立判断标准。如果你想开始可以从这篇文章的示例入手把环境搭好跑通 API 连通性测试再逐步扩充用例集最后尝试引入裁判模型。整个过程不需要机器学习理论基础但需要你有耐心处理“非确定性”带来的困扰。给准备面试的同学一个额外建议与其在简历上堆“熟悉 AI 测试”这种大词不如准备一个你亲手做过的评测小项目。哪怕只是用几十条用例验证了一个客服问答系统的回答质量并把完整流程写成文档面试效果也会比背概念好得多。最后提醒一句AI 测试相关的工具和生态变化很快本文示例中的模型名称、API 格式请以你实际接入的服务为准。测试思路和工程方法是可以迁移的但接口细节永远要去查官方文档。