“央视财经那条AI智能体开发人才需求涨了244%的新闻在测试群里炸开锅之后我收到的私信大概率可以总结成三个问题这个AI测试开发到底是做什么的我现在的测试经验还剩多少能用以及……我现在转还来得及吗”我的回答一直是同一个来得及而且窗口期可能比你想的更宽。244%这个数字反映的其实是一个很现实的问题——AI应用正在从前期的“模型炫技”阶段快速切换到“工程化落地”阶段。而一旦到了工程化落地需求侧最先卡脖子的往往不是算法不是产品而是测试。因为AI应用的实际行为充满不确定性你敢上线吗你敢让它直接接进核心业务流程吗这时候能设计评测集、能做自动化验证、能定位链路故障的测试开发价值一下子就凸显出来了。这篇文章我不打算讲那些“AI测试前景广阔”之类的正确的废话。我想结合我实际做过的AI应用测试项目用一个真实可复现的案例把“测试人转AI测试开发”这件事拆成三个部分先看清岗位到底要什么能力再对照你手里的牌看缺什么最后直接上手跑通一个最小可用的AI测试基线。文末会放一些踩坑排查经验希望能帮你少走点弯路。1. 需求暴涨244%背后的真实信号AI测试开发到底在测什么1.1 先搞清楚AI智能体开发和你熟悉的业务系统开发不是一回事这两年“AI智能体”“Agent”“大模型应用”这些词满天飞但很多人其实没想明白智能体开发和传统软件开发到底差在哪。传统软件的逻辑是确定的你传一个参数代码走一个分支输出一个结果整个过程可预期、可复现。而智能体应用是个典型的概率系统——你给我同一个问题它两次回答的措辞可能完全不一样甚至偶尔会出错。它还会自己拆解任务、决定先调用哪个工具、观察结果之后再决定下一步干什么具备一定的自主决策能力。这就带来一个很要命的测试难题被测对象的行为开始变得不可穷举。你不能像以前那样写100条用例、跑一遍、比对预期结果就完了。你得面对一个“聪明但偶尔会撒谎”的系统去设计一套能够约束它、评价它、度量它的方案。这正是AI测试开发存在的意义也是这个岗位薪资水涨船高的核心原因。所以所谓“AI测试开发人才需求大涨”本质上不是市场突然想要一批会写代码的测试而是AI应用要真正进入生产环境必须有这么一群人能把模型的不可控行为框进可控的测试管线里。谁先掌握这套方法谁就握住了这波红利。1.2 AI测试开发与传统测试开发的本质差异我接触过很多想转岗的测试同学第一个误区就是觉得“AI测试开发嘛就是把Selenium换成Prompt把接口自动化换成调大模型API。”真要这么简单需求就不会涨244%了。两者的差异我用一个表格直接对比一下对比维度传统测试开发AI测试开发被测对象逻辑确定的代码系统行为不确定的模型代码组合体预期结果有明确Expected Output可直接断言往往只有“好/坏”的相对标准需要设计评价规则测试数据根据业务规则手工造数据即可需要构造覆盖边界、对抗样本的评测集自动化稳定性用例编写完成后结果基本固定模型版本一变、Prompt一改结果可能全部变化缺陷定位定位到代码行、接口、数据库即可需要区分是模型能力问题、Prompt问题、工具链路问题还是数据问题上线标准用例通过率、Bug率、性能指标评测集分数、Bad Case率、人工抽检满意度等综合判断从表里能看出传统测试的很多基本功——用例设计能力、代码能力、稳定性保障意识、缺陷分析思路——在AI时代不仅不过时反而是转型的重要基础。你需要新学的东西本质上是一套围绕“模型行为”的测试方法论而不是另起炉灶。我自己带过两个从功能测试转过来的同事一个之前是做电商后台功能测试的一个是做银行接口自动化的。他们刚接触AI测试时都挺慌觉得自己不懂算法。但跑了两个迭代之后反而状态越来越稳原因很简单AI应用测试里“测试功底”的分量比“算法功底”重得多。你能设计出好的测试场景能搭出稳定的自动化框架能定位问题是出在哪个环节这些恰恰是传统测试训练出来的核心肌肉。2. 转岗前的自我盘点测试老底子哪些能迁移哪些必须推倒重来2.1 盘点存量技能别从零开始焦虑很多测试同学的问题不是没有积累而是不知道自己手里的技能在AI测试里对应什么价值。我建议你先别急着报课、买书而是花一个下午把自己过去做过的测试工作逐条列出来对应到下面这张迁移表里你现有的测试能力在AI测试开发中的对应能力业务需求分析和用例设计设计AI应用的评测场景、拆解用户真实意图、构造边界与异常输入接口测试经验测试模型API的出入参、鉴权、限流、错误处理以及Function Calling的参数传递自动化框架搭建搭建评测用例调度、批量执行、结果汇总的自动化管线测试数据构造能力构造高质量评测集包括正例、反例、模糊表达、多轮对话等缺陷定位与分析对Bad Case做根因分析区分模型问题、提示词问题、链路问题性能测试经验测试模型响应延迟、并发表现、降级策略、Token消耗成本我见过一个做支付接口测试的同学转型后最受益的能力居然是“对超时和异常返回的敏感度”。因为AI应用里模型经常抽风返回超时、返回空、返回一堆JSON以外的杂数据这类异常处理太需要经验了。另一个做金融业务测试的同事以前天天分析业务规则转岗后做AI客服测试时用她多年积累的“用户会怎么问”的直觉设计用例比很多只会问标准问题的人强太多。所以第一条建议盘点存量能力而不是否定存量能力。你做功能测试时养成的严谨、做自动化时积累的工程化思维、做业务测试时沉淀的领域知识这些AI测试开发全都需要只是表达方式变了。2.2 需要补的硬技能和学习路线存量能力能迁移但有三个新知识域是绕不开的。我觉得按优先级排分别是第一块大模型基础认知。你不需要会训练模型但必须懂Token、上下文窗口、Temperature、Top-p、System Prompt与User Prompt的消息结构、模型的幻觉机制。因为测试用例断言怎么写、结果怎么判全都依赖这些基础概念。比如你在断言一个客服AI的回答时如果不理解“Temperature调高会让输出多样性变强”这件事就很容易把随机波动当成Bug提上去闹笑话。第二块提示词工程基础。做AI测试不是只负责发现问题很多时候你得能自己动手调Prompt验证“是不是这么改就能解决Bad Case”。所以你需要能读懂System Prompt、会写结构化Prompt、了解角色设定、示例Few-shot、思维链Chain-of-Thought这些基础技巧。我甚至建议你自己动手改一版被测应用的Prompt再跑一遍用例看效果变化这是理解模型行为最快的方式。第三块智能体框架与工具链认知。现在的AI应用很少是“一问一答”的纯聊天机器人大多是会调用工具、会查知识库、会操作业务流程的智能体。市面上常见的开发框架迭代很快比如AutoGen、LangGraph、Dify、Coze以及各种不断出现的新框架你不需要都精通但至少要理解它们的共性节点编排、工具注册、上下文传递、记忆管理。你只需要知道被测对象是怎么构建出来的才能设计出针对性的测试策略。编程方面我建议你只需要把Python和pytest练熟。很多测试同学已经有Python基础那会轻松很多如果Python不太熟也不要慌张AI测试开发的日常是写用例、写断言、写评测脚本这些对编程深度的要求其实低于后端开发但对代码规范性、调试能力有一定要求。我自己给团队定的转型路线是四周速通第一周学大模型基础概念顺带每天调用几次模型API把“对话消息结构”玩熟第二周学提示词工程开始写Prompt并观察不同参数下的输出变化第三周用pytest写一个最小的AI用例脚本跑通“调API-拿结果-写断言”的闭环第四周把用例扩充成20条左右的小评测集并加上一个简单的批量执行脚本。这四周下来你已经具备AI测试开发的入门骨架了。3. 实操一次AI测试开发全流程从手写用例到跑通基线3.1 搭建一个可复现的最小测试环境知道一堆概念不如亲手跑通一条链路。下面我带你从零搭一个非常轻量的AI测试环境整个过程不需要GPU不需要买昂贵算力只需要你有一个可调用的大模型API本地部署的或云端的均可按你自己的资源来。我建议的项目结构长这样保持极简ai_qa_demo/ ├── agent_demo.py # 被测对象一个极简智能体 ├── test_agent_basic.py # pytest 基础用例 ├── eval_dataset.json # 评测集 └── requirements.txt # 依赖先写一个最简单的被测对象。这里我用一个简化的“客服智能体”来演示它的逻辑很简单调用一个大模型如果用户提问涉及“查订单状态”就让大模型输出一个固定的工具调用意图否则走普通问答。注意这里我刻意省去了复杂实现目的是让你看清测试的对象长什么样。# agent_demo.py from openai import OpenAI client OpenAI(base_urlhttp://your-model-endpoint/v1, api_keyyour-key) def simple_agent(user_input: str, history: list None) - dict: 极简智能体 1. 使用 system prompt 约束行为 2. 如果用户需要查订单返回 tool_call 意图 3. 否则返回普通回答 system_prompt 你是一个电商客服助手。 当用户询问订单状态时必须返回JSON格式的意图识别结果格式为 {intent: check_order, order_id: 用户提到的订单号或null} 其他问题正常回答语气友好不超过50字。 messages [{role: system, content: system_prompt}] if history: messages.extend(history) messages.append({role: user, content: user_input}) resp client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.3, ) return { raw_response: resp.choices[0].message.content, usage: resp.usage.total_tokens, latency_ms: resp.response_ms if hasattr(resp, response_ms) else None, }这段代码里我故意用了占位符你需要换成自己的模型地址和模型名。写它的目的是让你有一个可以真实运行、真实修改的“被测对象”而不是对着别人的文字干瞪眼。很多测试同学转型失败不是学不会方法而是始终没有一个能动手的“靶子”。3.2 用例设计逻辑四层测试思路与评测集构造有了被测对象接下来就是设计用例。传统测试讲究等价类和边界值AI测试也有自己的分层思路。我自己习惯把AI应用测试分成四层每一层的侧重点不一样第一层功能正确性测试。这是基线。给定明确的输入期望一个明确的输出结果或明确的行为。比如“查订单”意图识别输入“我要查订单”就期望返回check_order意图。这类用例可以自动化用结构化断言。第二层鲁棒性与对抗样本测试。这是AI测试最有意思的部分。你需要设计一些模糊表达、错别字、多轮对话、语义陷阱看被测系统会不会被带偏。比如问“我的order单号是12345帮我看看”或者故意用“那个。。。我买了东西就是想问问到哪了单号忘了怎么办”这种现实中用户会问的表达。这类用例的目的不是验证“标准答案”而是暴露模型的边界。第三层链路完整性测试。智能体不只是模型还有工具调用、知识库检索、上下文传递。你要测试工具被正确触发了吗参数传对了吗工具返回异常时智能体能兜住吗如果你在测一个有RAG检索增强生成的应用还要关注检索命中率、上下文长度、引用可溯源。第四层性能与稳定性测试。大模型接口普遍慢动辄几秒并发能力也有限。你需要关注响应时间、并发吞吐、超时重试、降级策略。这一层很像传统性能测试但多了“Token消耗”这个成本指标。评测集Eval Dataset是AI测试开发的弹药库。我建议你按下面的结构维护评测集这个结构是我实际项目中仍在使用的[ { id: case_001, category: intent_recognition, input: 我要查一下订单状态, expected: {intent: check_order}, difficulty: easy }, { id: case_002, category: robustness, input: 那个东西啥时候发货啊单号我找不到了, expected: {intent: check_order, note: 允许不返回order_id}, difficulty: hard } ]每条用例包含唯一ID、类别、输入、期望结果和难度标记。难度标记在后续做回归分析时非常有用你可以随时知道“是难题变好了还是简单题退步了”。接着用pytest把它们串起来。我写一个最小可运行的测试脚本# test_agent_basic.py import json import pytest from agent_demo import simple_agent def load_cases(patheval_dataset.json): with open(path, r, encodingutf-8) as f: return json.load(f) def parse_response(raw: str): 尝试从模型输出中解析JSON意图 try: return json.loads(raw) except json.JSONDecodeError: return None pytest.mark.parametrize(case, load_cases(), idslambda c: c[id]) def test_agent_basic(case): result simple_agent(case[input]) raw result[raw_response] # 1. 必须有响应 assert raw is not None and len(raw) 0, 空响应 # 2. 链路时长硬限制避免接口卡死 assert result[latency_ms] is None or result[latency_ms] 5000, 响应超时 # 3. 根据类别做结构化断言 if case[category] intent_recognition: parsed parse_response(raw) assert parsed is not None, f预期是JSON实际是: {raw} assert parsed.get(intent) case[expected][intent] else: # 鲁棒性用例只要求非空且不过长具体质量走人工抽检或模型评分 assert len(raw) 100, f回答过长后续可能触发截断: {raw} assert 订单状态 not in raw or 查不到 in raw, 疑似拒绝回答这个测试脚本里我特意没有把所有断言都做成“硬断言”因为AI应用的很多回答语义上正确、表面上不一定能写死。所以我的原则是对能结构化的输出做严格断言对开放性的回答做弱断言然后配合人工抽检和模型评分来补足覆盖。实际测试中断言体系设计得合理不合理直接决定后续维护成本高低。跑一遍之后你可能会看到有些用例失败有些通过。你还会发现一个现象同一段代码同一个用例多跑几次结果可能不完全一样。这就是概率系统的常态所以我在工程里通常做“多次抽样取稳定率”而不是“一次定生死”。关键用例跑三遍三遍都通过才算稳定通过这个习惯建议你从一开始就养成。3.3 智能体特有的测试点工具调用与RAG链路验证如果只测“模型问答”那还停留在应用层测试。真正的智能体复杂度在于它和外部工具、知识库之间的交互这部分是传统测试完全没覆盖的场景。以Function Calling工具调用为例你要重点验证四件事触发条件对不对该调工具的时候有没有调不该调的时候有没有乱调比如用户只是问“你们的退货政策是什么”结果Agent去调了一个下单接口那就是严重事故。参数传递对不对工具调用时需要提取实体和填充参数比如”帮我查一下昨天买的那个红色外套到哪了“Agent需要正确解析出用户标识、商品信息、查询时间任何一个字段提取错后续工具执行都会出错。工具异常兜底工具接口超时或返回错误时Agent是能给用户一个合理的解释还是直接崩掉或胡说工具结果使用是否合理工具返回了一堆结构化数据Agent是否基于这些数据回答还是无视工具结果自己编RAG知识库类应用还要额外测三件事检索命中给定一个知识库范围内的问题能不能检索到正确文档段。引用可溯源回答里的关键信息是否真的来自检索到的文档而不是模型自己编的。上下文截断检索到的内容太多、超出上下文窗口时系统是平滑截断还是直接把后文丢了导致回答信息缺失。这部分测试很难完全自动化我的经验是“自动化跑框架 人工抽核心链路”。自动化主要负责收集原始数据比如把每次工具调用的请求参数、返回结果、Agent决策过程全部记录下来人工用这些trace来做判断。没有trace记录工具的AI项目测试起来就是瞎子摸象。4. 常见问题与避坑实录转型期最容易踩的几个坑4.1 典型问题与排查思路速查做AI测试开发和传统测试有很大不同传统测试的Bug是确定性的AI测试的很多问题则模糊不清排查起来容易走弯路。我把实际中高频遇到的几个问题整理成速查表问题现象排查思路定位方向同一个用例今天过明天挂检查模型版本是否变化、服务是否切换环境一致性用例失败但人工看觉得没问题断言设计过严只适配了单一表达断言合理性提示词一改几十条用例全崩缺少回归基线用例和提示词耦合过深变更管理与回归集回答质量差但说不清差在哪没建评测集评价标准完全靠主观感觉评测体系建设工具调用参数提取老出错实体识别提示词不够明确缺少Few-shot示例Prompt优化模型接了个无关问题也能胡答System Prompt约束不够边界控制如果你遇到第一个问题我建议先别慌着改测试脚本而是先把环境锁死模型用固定版本、固定参数、固定部署节点。AI测试的环境一致性比传统测试更敏感模型端的任何变动都会体现在测试结果里。如果你遇到第二个问题大概率是你的断言写得“太像传统测试”了。比如要求答案必须包含某个关键词但用户其实换了个说法语义完全正确这就造成了误报。我的做法是宁可漏报也不要误报。误报太多会让团队对自动化结果失去信任AI测试用例里的断言只有两种情况适合写死——结构化输出和明确的禁止性行为其他情况一律交给人工抽检或模型打分。4.2 几条掏心窝的实操心得第一先攒“黄金评测集”再谈自动化。很多团队一上来就折腾花哨的自动化和报表却连100条高质量用例都没有这是本末倒置。如果你只能做一件事就把你业务里最典型的50-100个问题整理成评测集然后定期跑一遍看看整体分数趋势。这个习惯持续三个月你对产品稳定性的掌控力会超越绝大多数测试团队。第二用例制度宁精勿多。我见过有人一口气写了2000条AI测试用例但大量用例是重复的都在问“你好”“在吗”这类无意义输入。AI测试的用例质量比拼数量重要得多。我建议你把精力集中在头部场景用户问得最多的30个问题、最容易出错的20个边界问题、以及10个对抗性攻击样本。50条用好了比500条水用例有价值得多。第三把“模型能力问题”和“测试没做好”分开。这是AI测试开发在团队协作中非常重要的一环。传统测试里Bug归开发AI测试里模型答错了可能是模型能力问题、Prompt问题、知识库数据问题甚至测试数据本身就有问题。如果你不区分清楚很容易背锅。我一直在用的方法是把问题按“模型层、提示词层、工具链路层、数据层”四个维度标记错了就记录到对应层级的标签下这样责任归属清晰改进方向也明确。第四别急着追求“全自动”。AI测试的终点不是全自动而是“自动化收集结果 人做关键判断”。你花一个月训练一个自动评分模型可能还不如让产品和开发每周抽20条Bad Case一起看效果更直接。自动化应该用在脏活累活上比如批量回归、数据收集、结果汇总、异常告警核心判断留给人来做。写在最后转型这件事今天就能动起来我在带团队时反复说一句话AI测试开发不是一个神秘的岗位它是“测试思维 AI认知 工程能力”的组合体缺一不可。你不需要先去读个机器学习学位再转岗那太慢了而且没必要。聪明人做法是把现有测试能力作为杠杆在AI领域里找到一个支点然后快速补齐应用层知识在实战中迭代。如果你今天看完这篇文章只记住一个行动那我建议你把你自己最熟悉的业务里用户最常问的10个问题整理出来试着设计成JSON格式的评测集然后随便找一个大模型API跑一遍看看系统会怎么答。这不需要任何审批、任何预算你下班后花两个小时就能完成。做完这一步你就不再是一个“对AI测试一无所知的测试”而是一个“已经跑通一个最小AI测试闭环的人”。AI应用的浪潮不会等任何人但也不会辜负那些提前整理了第一份评测集的测试人。 
长河君 · 2026/9/8 21:17:59 · 阅读 1.2k 测试人转AI测试开发：从智能体测试到评测集实战全指南
“央视财经那条AI智能体开发人才需求涨了244%的新闻在测试群里炸开锅之后我收到的私信大概率可以总结成三个问题这个AI测试开发到底是做什么的我现在的测试经验还剩多少能用以及……我现在转还来得及吗”我的回答一直是同一个来得及而且窗口期可能比你想的更宽。244%这个数字反映的其实是一个很现实的问题——AI应用正在从前期的“模型炫技”阶段快速切换到“工程化落地”阶段。而一旦到了工程化落地需求侧最先卡脖子的往往不是算法不是产品而是测试。因为AI应用的实际行为充满不确定性你敢上线吗你敢让它直接接进核心业务流程吗这时候能设计评测集、能做自动化验证、能定位链路故障的测试开发价值一下子就凸显出来了。这篇文章我不打算讲那些“AI测试前景广阔”之类的正确的废话。我想结合我实际做过的AI应用测试项目用一个真实可复现的案例把“测试人转AI测试开发”这件事拆成三个部分先看清岗位到底要什么能力再对照你手里的牌看缺什么最后直接上手跑通一个最小可用的AI测试基线。文末会放一些踩坑排查经验希望能帮你少走点弯路。1. 需求暴涨244%背后的真实信号AI测试开发到底在测什么1.1 先搞清楚AI智能体开发和你熟悉的业务系统开发不是一回事这两年“AI智能体”“Agent”“大模型应用”这些词满天飞但很多人其实没想明白智能体开发和传统软件开发到底差在哪。传统软件的逻辑是确定的你传一个参数代码走一个分支输出一个结果整个过程可预期、可复现。而智能体应用是个典型的概率系统——你给我同一个问题它两次回答的措辞可能完全不一样甚至偶尔会出错。它还会自己拆解任务、决定先调用哪个工具、观察结果之后再决定下一步干什么具备一定的自主决策能力。这就带来一个很要命的测试难题被测对象的行为开始变得不可穷举。你不能像以前那样写100条用例、跑一遍、比对预期结果就完了。你得面对一个“聪明但偶尔会撒谎”的系统去设计一套能够约束它、评价它、度量它的方案。这正是AI测试开发存在的意义也是这个岗位薪资水涨船高的核心原因。所以所谓“AI测试开发人才需求大涨”本质上不是市场突然想要一批会写代码的测试而是AI应用要真正进入生产环境必须有这么一群人能把模型的不可控行为框进可控的测试管线里。谁先掌握这套方法谁就握住了这波红利。1.2 AI测试开发与传统测试开发的本质差异我接触过很多想转岗的测试同学第一个误区就是觉得“AI测试开发嘛就是把Selenium换成Prompt把接口自动化换成调大模型API。”真要这么简单需求就不会涨244%了。两者的差异我用一个表格直接对比一下对比维度传统测试开发AI测试开发被测对象逻辑确定的代码系统行为不确定的模型代码组合体预期结果有明确Expected Output可直接断言往往只有“好/坏”的相对标准需要设计评价规则测试数据根据业务规则手工造数据即可需要构造覆盖边界、对抗样本的评测集自动化稳定性用例编写完成后结果基本固定模型版本一变、Prompt一改结果可能全部变化缺陷定位定位到代码行、接口、数据库即可需要区分是模型能力问题、Prompt问题、工具链路问题还是数据问题上线标准用例通过率、Bug率、性能指标评测集分数、Bad Case率、人工抽检满意度等综合判断从表里能看出传统测试的很多基本功——用例设计能力、代码能力、稳定性保障意识、缺陷分析思路——在AI时代不仅不过时反而是转型的重要基础。你需要新学的东西本质上是一套围绕“模型行为”的测试方法论而不是另起炉灶。我自己带过两个从功能测试转过来的同事一个之前是做电商后台功能测试的一个是做银行接口自动化的。他们刚接触AI测试时都挺慌觉得自己不懂算法。但跑了两个迭代之后反而状态越来越稳原因很简单AI应用测试里“测试功底”的分量比“算法功底”重得多。你能设计出好的测试场景能搭出稳定的自动化框架能定位问题是出在哪个环节这些恰恰是传统测试训练出来的核心肌肉。2. 转岗前的自我盘点测试老底子哪些能迁移哪些必须推倒重来2.1 盘点存量技能别从零开始焦虑很多测试同学的问题不是没有积累而是不知道自己手里的技能在AI测试里对应什么价值。我建议你先别急着报课、买书而是花一个下午把自己过去做过的测试工作逐条列出来对应到下面这张迁移表里你现有的测试能力在AI测试开发中的对应能力业务需求分析和用例设计设计AI应用的评测场景、拆解用户真实意图、构造边界与异常输入接口测试经验测试模型API的出入参、鉴权、限流、错误处理以及Function Calling的参数传递自动化框架搭建搭建评测用例调度、批量执行、结果汇总的自动化管线测试数据构造能力构造高质量评测集包括正例、反例、模糊表达、多轮对话等缺陷定位与分析对Bad Case做根因分析区分模型问题、提示词问题、链路问题性能测试经验测试模型响应延迟、并发表现、降级策略、Token消耗成本我见过一个做支付接口测试的同学转型后最受益的能力居然是“对超时和异常返回的敏感度”。因为AI应用里模型经常抽风返回超时、返回空、返回一堆JSON以外的杂数据这类异常处理太需要经验了。另一个做金融业务测试的同事以前天天分析业务规则转岗后做AI客服测试时用她多年积累的“用户会怎么问”的直觉设计用例比很多只会问标准问题的人强太多。所以第一条建议盘点存量能力而不是否定存量能力。你做功能测试时养成的严谨、做自动化时积累的工程化思维、做业务测试时沉淀的领域知识这些AI测试开发全都需要只是表达方式变了。2.2 需要补的硬技能和学习路线存量能力能迁移但有三个新知识域是绕不开的。我觉得按优先级排分别是第一块大模型基础认知。你不需要会训练模型但必须懂Token、上下文窗口、Temperature、Top-p、System Prompt与User Prompt的消息结构、模型的幻觉机制。因为测试用例断言怎么写、结果怎么判全都依赖这些基础概念。比如你在断言一个客服AI的回答时如果不理解“Temperature调高会让输出多样性变强”这件事就很容易把随机波动当成Bug提上去闹笑话。第二块提示词工程基础。做AI测试不是只负责发现问题很多时候你得能自己动手调Prompt验证“是不是这么改就能解决Bad Case”。所以你需要能读懂System Prompt、会写结构化Prompt、了解角色设定、示例Few-shot、思维链Chain-of-Thought这些基础技巧。我甚至建议你自己动手改一版被测应用的Prompt再跑一遍用例看效果变化这是理解模型行为最快的方式。第三块智能体框架与工具链认知。现在的AI应用很少是“一问一答”的纯聊天机器人大多是会调用工具、会查知识库、会操作业务流程的智能体。市面上常见的开发框架迭代很快比如AutoGen、LangGraph、Dify、Coze以及各种不断出现的新框架你不需要都精通但至少要理解它们的共性节点编排、工具注册、上下文传递、记忆管理。你只需要知道被测对象是怎么构建出来的才能设计出针对性的测试策略。编程方面我建议你只需要把Python和pytest练熟。很多测试同学已经有Python基础那会轻松很多如果Python不太熟也不要慌张AI测试开发的日常是写用例、写断言、写评测脚本这些对编程深度的要求其实低于后端开发但对代码规范性、调试能力有一定要求。我自己给团队定的转型路线是四周速通第一周学大模型基础概念顺带每天调用几次模型API把“对话消息结构”玩熟第二周学提示词工程开始写Prompt并观察不同参数下的输出变化第三周用pytest写一个最小的AI用例脚本跑通“调API-拿结果-写断言”的闭环第四周把用例扩充成20条左右的小评测集并加上一个简单的批量执行脚本。这四周下来你已经具备AI测试开发的入门骨架了。3. 实操一次AI测试开发全流程从手写用例到跑通基线3.1 搭建一个可复现的最小测试环境知道一堆概念不如亲手跑通一条链路。下面我带你从零搭一个非常轻量的AI测试环境整个过程不需要GPU不需要买昂贵算力只需要你有一个可调用的大模型API本地部署的或云端的均可按你自己的资源来。我建议的项目结构长这样保持极简ai_qa_demo/ ├── agent_demo.py # 被测对象一个极简智能体 ├── test_agent_basic.py # pytest 基础用例 ├── eval_dataset.json # 评测集 └── requirements.txt # 依赖先写一个最简单的被测对象。这里我用一个简化的“客服智能体”来演示它的逻辑很简单调用一个大模型如果用户提问涉及“查订单状态”就让大模型输出一个固定的工具调用意图否则走普通问答。注意这里我刻意省去了复杂实现目的是让你看清测试的对象长什么样。# agent_demo.py from openai import OpenAI client OpenAI(base_urlhttp://your-model-endpoint/v1, api_keyyour-key) def simple_agent(user_input: str, history: list None) - dict: 极简智能体 1. 使用 system prompt 约束行为 2. 如果用户需要查订单返回 tool_call 意图 3. 否则返回普通回答 system_prompt 你是一个电商客服助手。 当用户询问订单状态时必须返回JSON格式的意图识别结果格式为 {intent: check_order, order_id: 用户提到的订单号或null} 其他问题正常回答语气友好不超过50字。 messages [{role: system, content: system_prompt}] if history: messages.extend(history) messages.append({role: user, content: user_input}) resp client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.3, ) return { raw_response: resp.choices[0].message.content, usage: resp.usage.total_tokens, latency_ms: resp.response_ms if hasattr(resp, response_ms) else None, }这段代码里我故意用了占位符你需要换成自己的模型地址和模型名。写它的目的是让你有一个可以真实运行、真实修改的“被测对象”而不是对着别人的文字干瞪眼。很多测试同学转型失败不是学不会方法而是始终没有一个能动手的“靶子”。3.2 用例设计逻辑四层测试思路与评测集构造有了被测对象接下来就是设计用例。传统测试讲究等价类和边界值AI测试也有自己的分层思路。我自己习惯把AI应用测试分成四层每一层的侧重点不一样第一层功能正确性测试。这是基线。给定明确的输入期望一个明确的输出结果或明确的行为。比如“查订单”意图识别输入“我要查订单”就期望返回check_order意图。这类用例可以自动化用结构化断言。第二层鲁棒性与对抗样本测试。这是AI测试最有意思的部分。你需要设计一些模糊表达、错别字、多轮对话、语义陷阱看被测系统会不会被带偏。比如问“我的order单号是12345帮我看看”或者故意用“那个。。。我买了东西就是想问问到哪了单号忘了怎么办”这种现实中用户会问的表达。这类用例的目的不是验证“标准答案”而是暴露模型的边界。第三层链路完整性测试。智能体不只是模型还有工具调用、知识库检索、上下文传递。你要测试工具被正确触发了吗参数传对了吗工具返回异常时智能体能兜住吗如果你在测一个有RAG检索增强生成的应用还要关注检索命中率、上下文长度、引用可溯源。第四层性能与稳定性测试。大模型接口普遍慢动辄几秒并发能力也有限。你需要关注响应时间、并发吞吐、超时重试、降级策略。这一层很像传统性能测试但多了“Token消耗”这个成本指标。评测集Eval Dataset是AI测试开发的弹药库。我建议你按下面的结构维护评测集这个结构是我实际项目中仍在使用的[ { id: case_001, category: intent_recognition, input: 我要查一下订单状态, expected: {intent: check_order}, difficulty: easy }, { id: case_002, category: robustness, input: 那个东西啥时候发货啊单号我找不到了, expected: {intent: check_order, note: 允许不返回order_id}, difficulty: hard } ]每条用例包含唯一ID、类别、输入、期望结果和难度标记。难度标记在后续做回归分析时非常有用你可以随时知道“是难题变好了还是简单题退步了”。接着用pytest把它们串起来。我写一个最小可运行的测试脚本# test_agent_basic.py import json import pytest from agent_demo import simple_agent def load_cases(patheval_dataset.json): with open(path, r, encodingutf-8) as f: return json.load(f) def parse_response(raw: str): 尝试从模型输出中解析JSON意图 try: return json.loads(raw) except json.JSONDecodeError: return None pytest.mark.parametrize(case, load_cases(), idslambda c: c[id]) def test_agent_basic(case): result simple_agent(case[input]) raw result[raw_response] # 1. 必须有响应 assert raw is not None and len(raw) 0, 空响应 # 2. 链路时长硬限制避免接口卡死 assert result[latency_ms] is None or result[latency_ms] 5000, 响应超时 # 3. 根据类别做结构化断言 if case[category] intent_recognition: parsed parse_response(raw) assert parsed is not None, f预期是JSON实际是: {raw} assert parsed.get(intent) case[expected][intent] else: # 鲁棒性用例只要求非空且不过长具体质量走人工抽检或模型评分 assert len(raw) 100, f回答过长后续可能触发截断: {raw} assert 订单状态 not in raw or 查不到 in raw, 疑似拒绝回答这个测试脚本里我特意没有把所有断言都做成“硬断言”因为AI应用的很多回答语义上正确、表面上不一定能写死。所以我的原则是对能结构化的输出做严格断言对开放性的回答做弱断言然后配合人工抽检和模型评分来补足覆盖。实际测试中断言体系设计得合理不合理直接决定后续维护成本高低。跑一遍之后你可能会看到有些用例失败有些通过。你还会发现一个现象同一段代码同一个用例多跑几次结果可能不完全一样。这就是概率系统的常态所以我在工程里通常做“多次抽样取稳定率”而不是“一次定生死”。关键用例跑三遍三遍都通过才算稳定通过这个习惯建议你从一开始就养成。3.3 智能体特有的测试点工具调用与RAG链路验证如果只测“模型问答”那还停留在应用层测试。真正的智能体复杂度在于它和外部工具、知识库之间的交互这部分是传统测试完全没覆盖的场景。以Function Calling工具调用为例你要重点验证四件事触发条件对不对该调工具的时候有没有调不该调的时候有没有乱调比如用户只是问“你们的退货政策是什么”结果Agent去调了一个下单接口那就是严重事故。参数传递对不对工具调用时需要提取实体和填充参数比如”帮我查一下昨天买的那个红色外套到哪了“Agent需要正确解析出用户标识、商品信息、查询时间任何一个字段提取错后续工具执行都会出错。工具异常兜底工具接口超时或返回错误时Agent是能给用户一个合理的解释还是直接崩掉或胡说工具结果使用是否合理工具返回了一堆结构化数据Agent是否基于这些数据回答还是无视工具结果自己编RAG知识库类应用还要额外测三件事检索命中给定一个知识库范围内的问题能不能检索到正确文档段。引用可溯源回答里的关键信息是否真的来自检索到的文档而不是模型自己编的。上下文截断检索到的内容太多、超出上下文窗口时系统是平滑截断还是直接把后文丢了导致回答信息缺失。这部分测试很难完全自动化我的经验是“自动化跑框架 人工抽核心链路”。自动化主要负责收集原始数据比如把每次工具调用的请求参数、返回结果、Agent决策过程全部记录下来人工用这些trace来做判断。没有trace记录工具的AI项目测试起来就是瞎子摸象。4. 常见问题与避坑实录转型期最容易踩的几个坑4.1 典型问题与排查思路速查做AI测试开发和传统测试有很大不同传统测试的Bug是确定性的AI测试的很多问题则模糊不清排查起来容易走弯路。我把实际中高频遇到的几个问题整理成速查表问题现象排查思路定位方向同一个用例今天过明天挂检查模型版本是否变化、服务是否切换环境一致性用例失败但人工看觉得没问题断言设计过严只适配了单一表达断言合理性提示词一改几十条用例全崩缺少回归基线用例和提示词耦合过深变更管理与回归集回答质量差但说不清差在哪没建评测集评价标准完全靠主观感觉评测体系建设工具调用参数提取老出错实体识别提示词不够明确缺少Few-shot示例Prompt优化模型接了个无关问题也能胡答System Prompt约束不够边界控制如果你遇到第一个问题我建议先别慌着改测试脚本而是先把环境锁死模型用固定版本、固定参数、固定部署节点。AI测试的环境一致性比传统测试更敏感模型端的任何变动都会体现在测试结果里。如果你遇到第二个问题大概率是你的断言写得“太像传统测试”了。比如要求答案必须包含某个关键词但用户其实换了个说法语义完全正确这就造成了误报。我的做法是宁可漏报也不要误报。误报太多会让团队对自动化结果失去信任AI测试用例里的断言只有两种情况适合写死——结构化输出和明确的禁止性行为其他情况一律交给人工抽检或模型打分。4.2 几条掏心窝的实操心得第一先攒“黄金评测集”再谈自动化。很多团队一上来就折腾花哨的自动化和报表却连100条高质量用例都没有这是本末倒置。如果你只能做一件事就把你业务里最典型的50-100个问题整理成评测集然后定期跑一遍看看整体分数趋势。这个习惯持续三个月你对产品稳定性的掌控力会超越绝大多数测试团队。第二用例制度宁精勿多。我见过有人一口气写了2000条AI测试用例但大量用例是重复的都在问“你好”“在吗”这类无意义输入。AI测试的用例质量比拼数量重要得多。我建议你把精力集中在头部场景用户问得最多的30个问题、最容易出错的20个边界问题、以及10个对抗性攻击样本。50条用好了比500条水用例有价值得多。第三把“模型能力问题”和“测试没做好”分开。这是AI测试开发在团队协作中非常重要的一环。传统测试里Bug归开发AI测试里模型答错了可能是模型能力问题、Prompt问题、知识库数据问题甚至测试数据本身就有问题。如果你不区分清楚很容易背锅。我一直在用的方法是把问题按“模型层、提示词层、工具链路层、数据层”四个维度标记错了就记录到对应层级的标签下这样责任归属清晰改进方向也明确。第四别急着追求“全自动”。AI测试的终点不是全自动而是“自动化收集结果 人做关键判断”。你花一个月训练一个自动评分模型可能还不如让产品和开发每周抽20条Bad Case一起看效果更直接。自动化应该用在脏活累活上比如批量回归、数据收集、结果汇总、异常告警核心判断留给人来做。写在最后转型这件事今天就能动起来我在带团队时反复说一句话AI测试开发不是一个神秘的岗位它是“测试思维 AI认知 工程能力”的组合体缺一不可。你不需要先去读个机器学习学位再转岗那太慢了而且没必要。聪明人做法是把现有测试能力作为杠杆在AI领域里找到一个支点然后快速补齐应用层知识在实战中迭代。如果你今天看完这篇文章只记住一个行动那我建议你把你自己最熟悉的业务里用户最常问的10个问题整理出来试着设计成JSON格式的评测集然后随便找一个大模型API跑一遍看看系统会怎么答。这不需要任何审批、任何预算你下班后花两个小时就能完成。做完这一步你就不再是一个“对AI测试一无所知的测试”而是一个“已经跑通一个最小AI测试闭环的人”。AI应用的浪潮不会等任何人但也不会辜负那些提前整理了第一份评测集的测试人。