2026/9/7 3:01:18
FEATURED · 精选文章 
AI 测试是 2026 年测试工程师绕不开的进阶方向但它不是靠背几个面试题就能掌握的单一技能里面至少有三条完全不同的路线测试 AI 产品、用 AI 辅助测试、搭建 AI 测试智能体和平台。我最近在给团队排测试能力进阶方案时被问得最多的一个问题就是普通功能测试或自动化测试工程师到底该先学什么优先级怎么排。这篇文章把我实际用下来比较顺的路线整理出来按可落地的顺序拆开适合正在做功能测试、自动化测试或者刚入行想直接切 AI 方向的人参考。先说一个基本判断2026 年做测试Python 和 pytest 基本是入场券大模型接口调用能力是加速器而真正拉开差距的是“能不能把 AI 工具稳定地接进测试流程”。下面从方向拆解、能力分层、实操代码、测试智能体、AI 产品质量验证、学习规划、踩坑记录七个部分展开。1. 先把“AI测试”拆成三条路线再谈入行很多人一听到 AI 测试第一反应是“让 AI 帮我写用例、跑自动化”。这只是其中一条路线。实际在岗位分工和项目协作里AI 测试通常指下面三种工作难度、技能树和职业路径差别不小。1.1 路线一测试 AI 产品这类工作的对象是 AI 应用本身比如大模型对话机器人、RAG 问答系统、搜索排序、图像生成、语音识别这类产品。你要验证的不只是“接口通不通”还包括回答准不准、有没有幻觉、多轮对话稳定性、敏感内容是否拦截、延迟是否能接受。这条路线适合对数据敏感、喜欢抠细节的人。核心技能是 Python 数据处理、评测集建设、质量指标设计、回归策略。难点在于“正确”的边界很模糊一个回答可能既不完全对也不完全错需要定义清楚评价标准。1.2 路线二用 AI 辅助测试也就是让大模型帮你生成测试用例、把自然语言描述变成自动化脚本、分析日志定位问题、给失败用例写初步判断。这条路线门槛最低见效最快几乎所有测试工程师都可以先从这里开始。实操时要注意AI 生成的用例脚本本质上只是“初稿”。它能帮你节省写代码的时间但不能帮你确认系统该有的行为。真正可靠的流程是“AI 生成人工核对再交给 pytest 执行”。我见太多人把生成完的脚本直接扔进流水线结果用例跑得飞快但根本没断言到关键逻辑等于假通过。1.3 路线三搭建 AI 测试智能体与平台更高一层是开发一个测试 Agent给它一句“对订单模块做一轮冒烟测试”它能自动拆解步骤、调用接口或 UI 自动化工具、执行校验、收集日志、生成报告跑完还能把失败结果回传到缺陷系统。这条路需要的不只是测试知识还要懂 Agent 的任务编排、工具调用、超时重试、并发控制、日志设计。它更像测试开发架构师做的事但也是 2026 年测试团队里最缺的能力。方向核心工作必备能力入门周期测试 AI 产品评测、数据集、回归、质量分析Python、指标设计、数据分析3-6 个月用 AI 辅助测试用例生成、脚本生成、日志分析pytest、prompt、API 调用1-3 个月AI 测试智能体任务拆解、工具编排、平台化Agent 框架、函数调用、工程化6-12 个月三条路线不是互斥的。比较合理的成长顺序是先会用 AI 辅助自己干活再去做 AI 产品测试最后有能力了再往智能体和平台方向走。2. 能力进阶路线四个层级从手工测试到智能化测试我一般把测试工程师在 AI 时代的能力进阶拆成四个层级。每一层都有明确的交付物和判断标准不满足上一层的条件直接跳到下一层往往会卡住。2.1 第一层编程、接口与自动化测试基础底层能力仍然是 Python、HTTP 协议、接口测试、UI 自动化基础。移动端要看 AppiumWeb 端要看 Selenium 或 Playwright框架层面首选 pytest。为什么这一层绕不开因为 AI 生成的测试脚本、评测脚本最后都要落到代码里执行。你自己看不懂脚本、不会改断言、不会处理依赖和路径AI 帮你生成的代码一旦报错你就只能干瞪眼。我在团队里常说AI 写代码的能力越强越考验你不会代码时能不能发现问题。交付物能用 pytest 写完 10 条接口用例能跑通并接入命令行执行。2.2 第二层AI 应用开发认知不需要你会训练模型但要懂大模型 API 的基本调用方式、prompt 怎么写、上下文长度限制、函数调用Function Calling是什么、RAG 大概怎么工作、并发和限流是怎么回事。原因很简单你要测试一个 AI 系统就得先知道它的基本结构。RAG 系统测试要拆检索和生成两段Chat 应用测试要关注多轮记忆Agent 应用测试要关注工具调用链路。这些没概念测试用例设计就无从谈起。交付物能独立调用一个大模型接口把一段业务描述转成结构化的测试用例清单。2.3 第三层AI 测试专项能力这一层开始和普通测试拉开差距。要做的是建设评测集和 Golden Case基准用例覆盖正常、边界、对抗、异常输入设计质量指标比如准确率、召回率、幻觉率、响应延迟、稳定性建立回归基线模型版本每次更新都在同一套数据集上对比结果设计灰度发布策略线上只放一部分流量观察指标后再全量。交付物给一个 AI 功能输出完整的评测报告包括数据集说明、指标变化、回归结论。2.4 第四层平台化、Agent 化与规模化到这一层重点是复用。把单次评测变成平台能力数据集版本管理、任务队列、结果看板、失败自动重跑、CI/CD 集成、多项目共用。交付物一个内部使用的 AI 测试小平台至少有两个项目在跑并且新人能直接上手操作。这四层不建议跳跃。前两层根基不牢后两层做出来的东西经不起业务推敲出了问题连排查入口都找不到。3. 最快见效的一步用 pytest 接上大模型接口生成并执行测试用例下面这套流程我建议每个人都亲手做一遍它是最小可运行的 AI 辅助测试闭环写一条手动用例、调大模型生成用例、跑 pytest、人工检查断言。3.1 环境准备先准备好 Python 环境建议 3.10 以上。安装两个依赖就够了其他用到再加。pip install pytest requests如果你要调大模型接口还要确认供应商的 SDK 或直接用 requests 调 HTTP 接口。不同供应商的请求格式不同这里以通用 OpenAI 兼容格式为例实际使用以你的服务端文档为准。注意接口地址、模型名称、密钥都要以你实际拿到的服务信息为准不要照抄网上的任意示例。3.2 先手写一条用例确认被测服务的行为不要一上来就生成用例。先手动发一个请求确认服务的返回结构。这一步决定了后面生成的用例断言对不对。import requests def test_query_service(): resp requests.post( http://127.0.0.1:8000/query, json{query: 上海今天天气怎么样}, timeout10, ) assert resp.status_code 200 data resp.json() assert data.get(code) 0 assert len(data.get(data, {}).get(answer, )) 0跑通之后记下返回的字段名、类型、错误码含义。AI 生成的代码大多会假设一个返回结构如果你的服务字段名不同它生成的断言就全是错的。3.3 用大模型生成测试用例下面这一段是把业务描述交给大模型让它返回 pytest 代码。注意把密钥放在环境变量里不要硬编码到仓库。import os import requests def generate_cases(business_desc: str) - str: prompt ( 你是一名资深测试工程师请根据下面的业务描述生成 pytest 用例代码。\n f业务描述{business_desc}\n 要求\n 1. 使用 requests 调用被测服务服务地址为 http://127.0.0.1:8000\n 2. 断言状态码和关键返回字段\n 3. 至少包含一个正常用例和一个异常用例\n 4. 只输出 Python 代码不要额外解释 ) resp requests.post( https://api.example.com/v1/chat/completions, json{ model: your-model, messages: [{role: user, content: prompt}], }, headers{Authorization: fBearer {os.environ[LLM_API_KEY]}}, timeout60, ) return resp.json()[choices][0][message][content]把生成的代码保存成test_generated.py放在 pytest 能识别的位置然后执行pytest test_generated.py -v3.4 校验生成结果先看能不能跑再看对不对这里有一个关键步骤很多新手会跳过。AI 生成的用例“能通过”不等于“有效”。我一般会做两个检查第一个检查故意改错一个字段名比如把code改成code_wrong看用例会不会失败。如果仍然通过说明断言根本没生效这条用例是废的。第二个检查把被测服务的返回内容改掉或者临时模拟一个错误码确认用例能敏锐地发现异常。只有这两种情况都能被捕捉到的用例才值得保留进回归集。AI 生成用例的最大风险不是报错而是“假通过”。4. 进阶实操搭一个最小可用的 AI 测试 Agent用例生成跑通之后可以再往前走一步把“拆解任务、执行调用、结果校验、输出报告”串成一个最小的 AI 测试 Agent。这里不需要一上来就上重型框架先把流程打通。4.1 Agent 需要哪几部分一个测试 Agent 至少包含四个环节规划器接收自然语言任务拆成步骤列表执行器按步骤调用工具比如发 HTTP 请求、跑 pytest、查数据库、操作 Appium校验器检查执行结果是否符合预期决定重试还是终止报告器把过程日志和最终结论整理成结构化报告。工具层可以用一个字典注册模型通过函数调用function calling选择要执行的工具。简单实现类似这样TOOLS { http_request: call_http, run_pytest: run_pytest_command, query_database: query_database, }如果模型不支持函数调用也可以让模型每次返回一段 JSON里面只包括tool和args两个字段。解析后再执行把结果回传给模型让它决定下一步。4.2 执行链路要控制的三个参数第一个是超时。每个工具调用都必须有独立超时HTTP 请求、数据库查询、UI 操作都不能共用一个超时。否则一个卡住的步骤会拖死整个任务。第二个是最大步骤数。Agent 可能陷入反复尝试的死循环规划器觉得自己在执行实际上什么都没推进。给任务设置上限比如最多 20 步超过就停止并把中间日志输出。第三个是并发数。能跑通单条任务之后再考虑批量。不建议一上来就开 10 个并发任务因为被测服务很可能扛不住或者大模型接口触发限流。我一般从 1 个任务开始稳定后再提到 3 到 5 个观察资源占用和服务延迟再往上加。4.3 失败重试不能盲目执行重试只适用于幂等操作比如查询接口。对于创建订单、发送短信、修改数据这类有状态的操作用例盲目重试会制造大量脏数据还会掩盖真实缺陷。更稳妥的做法是第一次失败后保留日志不重试由人工判断如果确认是网络抖动或服务临时不可用再手动触发重跑。Agent 里可以设计一个“可重试”标记只有打上这个标记的步骤才允许自动重试。4.4 报告和人工复核报告至少要包含任务输入、每一步调用的工具和参数、执行耗时、断言结果、失败时的响应内容、重试记录。输出成 JSON 方便程序解析同时生成一份 Markdown 给人工阅读。无论 Agent 多智能测试结论在进入正式流程前最好还是由人工扫一眼报告。Agent 负责把数据整理得足够完整和规范人负责判断哪些问题是真正需要提缺陷的。5. 测试 AI 产品时真正要盯住的质量维度如果你负责的是一个 AI 产品不是拿 AI 来辅助测试那关注点就要换一下。功能测试那套“输入-输出”校验只是底线更核心的是下面这些维度。5.1 功能正确性之外先看这五个指标第一内容准确率。回答里的关键事实是否与可信来源一致这个需要人工抽检或引入参考答案比对。第二幻觉率。模型是否输出了没有依据的信息。对 RAG 系统来说凡是答案里引用了检索内容却编造了原文没有的细节都算幻觉。第三稳定性。同样的问题连续问 5 次回答结构是否一致关键结论是否会漂移。模型本身有随机性但业务上不能允许核心结论反复横跳。第四延迟。包含首字延迟和总耗时还要看 p95 和 p99不能只看平均值。一个模型平均 1 秒但高峰期 8 秒体验上是不可用的。第五内容安全与合规。生成内容是否符合产品的内容安全规范是否会出现不适合展示的信息。这类验证要做自动检查加人工抽检的组合不能只靠一句“让模型注意点”。5.2 Golden Case、评测集和回归基线做 AI 产品测试一定要有“评测集”意识。整理一批有代表性的问题集每个问题记录期望行为。可以把评测集分成几类标准场景大多数用户会问的常规内容边界场景超长输入、空输入、同义词、错别字、多轮突然换主题对抗场景诱导型问题、模糊问题、多条件矛盾问题。评测集要有版本。模型升级、prompt 调整、检索库更新都要在同一套评测集上跑一轮回归。没有基线你根本说不清某次效果变好是因为模型强了还是因为测试问题问得太简单。5.3 灰度发布与 A/B 对比AI 模型上线不太适合“全量直接替换”。比较稳妥的做法是做灰度新版本先放 5% 的流量观察线上真实评测数据和用户反馈确认指标没有变差再逐步放量。灰度期间要同时记录新旧版本的同一批线上请求做对比分析。如果新版本准确性提升了但延迟明显变高要评估是否值得。线上评测不能只看平均值还要拆维度看不同问题类型、不同用户群体、不同时段。5.4 多场景产品的共性测试思路车载测试、智能硬件、芯片测试这些方向也会有越来越多 AI 模块介入比如感知算法、语音交互、决策规划。它们的共性是测试环境很难完全真实通常要依赖仿真、台架、录制的数据集回放。做这类测试时除了关注算法指标更要关注环境条件对结果的影响光照、噪声、温度、网络波动、资源限制。同样的模型在实验室跑得很好到实际环境性能下降往往是环境差异导致的。这类问题的排查重点不是模型本身而是数据采集一致性和运行环境等价性。6. 三个月到一年的落地学习规划前面讲了很多方向这里给一个按时间推进的学习计划。它的原则是每段时间都有明确交付物而不是单纯“学完某门课”。6.1 第一个月把基础补到“能写能跑”内容Python 基础列表、字典、函数、文件读写、异常处理、requests 库、pytest 基础、HTTP 接口基本概念、本地接口调试。交付物写一个脚本从 JSON 或 Excel 文件里读取接口请求批量执行并输出通过失败统计。跑稳这一个小工具比刷一百道面试题有用。6.2 第二到三个月自动化测试和 AI 工具练手内容Web 和移动端自动化基础Appium 或 Playwright 二选一大模型 API 调用prompt 基本技巧函数调用。交付物把第 3 节的“AI 生成用例并执行”流程做成一个小工具能从 Excel 读取多条业务需求批量生成用例文件跑完输出汇总报告。6.3 半年节点做一个完整的 AI 测试项目内容选一个真实对象比如公司内部的问答机器人、搜索服务或 RAG 知识库。为它建设评测集设计指标跑回归最后产出一份评测报告。交付物评测集文档 回归脚本 报告。这阶段最好能推动业务一次真实的产品迭代让评测结论真正影响产品决策。6.4 一年节点往平台化和团队复用走内容把半年的成果工程化。评测集版本管理、任务队列、失败重试、结果看板、CI 集成、权限控制。如果团队有 Java 栈需求可以看 Spring AI但对测试场景Python 生态更直接。交付物一个至少两个项目在用的内部 AI 测试平台。到这一步你在这个方向的竞争力就比多数人强了。时间学习重点交付物常见误区第 1 个月Python、pytest、接口基础批量接口检查脚本只刷理论不动手第 2-3 个月AI API、prompt、自动化工具AI 生成用例小工具用例只生成不校验半年评测集、指标、回归AI 产品评测报告报告写给自己看不推进决策一年Agent、平台、CI 集成内部测试平台功能堆砌没有团队真正使用7. AI 测试最容易翻车的几个地方和我的排查顺序最后把实战里高频踩坑的点集中说一遍。这些问题单独看都很小但组合起来会严重影响你落地。7.1 AI 生成的用例看着完整实际跑不起来最常见的三种情况第一代码里调用了不存在的对象或方法第二断言用的字段名和实际返回值不一致第三生成的是 mock 数据而不是真实请求。排查顺序先看代码是否报语法错误再看依赖是否安装然后看被测服务地址和端口是否正确最后逐条核对断言字段。跑用例时加-v参数每一条的执行结果都要看不要只看最后的总数。7.2 大模型输出不稳定断言不能写得太死测试 AI 产品时最忌讳断言“回答必须等于某个字符串”。大模型几乎不可能每次输出完全一致。合理的做法是断言结构、关键字段、长度范围或者用语义相似度打分阈值根据实际数据调整。如果你的场景确实要求稳定输出比如接口需要固定 JSON 格式那应该优先通过 prompt 约定格式并在代码里增加格式校验和错误重试而不是靠反复跑碰运气。7.3 限流、超时、费用和并发问题批量测试 AI 功能时最常见的问题是限流和费用失控。解决方案分三层设置单次请求超时避免慢请求堆积设置并发上限和每日调用上限尤其是真实模型接口对重复请求做缓存同一问题同一模型版本只测一次结果落盘复用。费用控制方面尽量用小模型做粗筛只有粗筛不通过的样本再交给大模型细评。这样可以显著降低成本。7.4 环境问题本地连接、权限和依赖版本很多报错看起来是代码问题实际是环境问题。比如本地服务提示 127.0.0.1 拒绝连接先确认服务真的启动了再确认服务监听的端口然后确认是不是把localhost解析到了 IPv6 的::1导致连不上只监听 IPv4 的服务。排查顺序固定下来服务是否启动、地址端口是否正确、防火墙和代理是否干扰、依赖版本是否匹配、运行用户是否有权限、日志在哪看。按这套顺序走80% 的环境类问题都能定位。7.5 安全测试要在合规环境里做2026 年测试分工里安全测试的热度一直不低。学安全测试没问题但一定要在授权、合规的本地环境里练习。比如自己搭一个漏洞靶场学习常见漏洞原理和防御思路。不要对未授权的系统做扫描和探测这不只是技术问题更是职业底线。安全测试的学习路径应该是先学网络基础和 HTTP 协议再学常见漏洞原理然后在靶场里做重复性练习最后配合修复方案做验证。它和 AI 的结合点在于可以用 AI 辅助生成测试流量、帮助分析响应特征、辅助编写检测规则但核心仍然是人要理解漏洞原理和业务逻辑。回到开头那句话AI 测试不是一个花哨标签而是一条可以拆成多个层级的真实能力路线。我个人更建议先把“单条任务跑稳”这件事做扎实手写一条用例、接一次大模型、生成一批脚本、人工核对断言。这样走完一圈你对 AI 测试的感知会比看十篇教程都强。真正值钱的地方不在于你调用了多少模型接口而在于你能不能把输入、执行、校验、报告和回归基线整理成一套别人也能复用的流程。踩过几次坑之后就会发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。
AI测试进阶路线：从pytest到测试智能体的实战指南
AI 测试是 2026 年测试工程师绕不开的进阶方向但它不是靠背几个面试题就能掌握的单一技能里面至少有三条完全不同的路线测试 AI 产品、用 AI 辅助测试、搭建 AI 测试智能体和平台。我最近在给团队排测试能力进阶方案时被问得最多的一个问题就是普通功能测试或自动化测试工程师到底该先学什么优先级怎么排。这篇文章把我实际用下来比较顺的路线整理出来按可落地的顺序拆开适合正在做功能测试、自动化测试或者刚入行想直接切 AI 方向的人参考。先说一个基本判断2026 年做测试Python 和 pytest 基本是入场券大模型接口调用能力是加速器而真正拉开差距的是“能不能把 AI 工具稳定地接进测试流程”。下面从方向拆解、能力分层、实操代码、测试智能体、AI 产品质量验证、学习规划、踩坑记录七个部分展开。1. 先把“AI测试”拆成三条路线再谈入行很多人一听到 AI 测试第一反应是“让 AI 帮我写用例、跑自动化”。这只是其中一条路线。实际在岗位分工和项目协作里AI 测试通常指下面三种工作难度、技能树和职业路径差别不小。1.1 路线一测试 AI 产品这类工作的对象是 AI 应用本身比如大模型对话机器人、RAG 问答系统、搜索排序、图像生成、语音识别这类产品。你要验证的不只是“接口通不通”还包括回答准不准、有没有幻觉、多轮对话稳定性、敏感内容是否拦截、延迟是否能接受。这条路线适合对数据敏感、喜欢抠细节的人。核心技能是 Python 数据处理、评测集建设、质量指标设计、回归策略。难点在于“正确”的边界很模糊一个回答可能既不完全对也不完全错需要定义清楚评价标准。1.2 路线二用 AI 辅助测试也就是让大模型帮你生成测试用例、把自然语言描述变成自动化脚本、分析日志定位问题、给失败用例写初步判断。这条路线门槛最低见效最快几乎所有测试工程师都可以先从这里开始。实操时要注意AI 生成的用例脚本本质上只是“初稿”。它能帮你节省写代码的时间但不能帮你确认系统该有的行为。真正可靠的流程是“AI 生成人工核对再交给 pytest 执行”。我见太多人把生成完的脚本直接扔进流水线结果用例跑得飞快但根本没断言到关键逻辑等于假通过。1.3 路线三搭建 AI 测试智能体与平台更高一层是开发一个测试 Agent给它一句“对订单模块做一轮冒烟测试”它能自动拆解步骤、调用接口或 UI 自动化工具、执行校验、收集日志、生成报告跑完还能把失败结果回传到缺陷系统。这条路需要的不只是测试知识还要懂 Agent 的任务编排、工具调用、超时重试、并发控制、日志设计。它更像测试开发架构师做的事但也是 2026 年测试团队里最缺的能力。方向核心工作必备能力入门周期测试 AI 产品评测、数据集、回归、质量分析Python、指标设计、数据分析3-6 个月用 AI 辅助测试用例生成、脚本生成、日志分析pytest、prompt、API 调用1-3 个月AI 测试智能体任务拆解、工具编排、平台化Agent 框架、函数调用、工程化6-12 个月三条路线不是互斥的。比较合理的成长顺序是先会用 AI 辅助自己干活再去做 AI 产品测试最后有能力了再往智能体和平台方向走。2. 能力进阶路线四个层级从手工测试到智能化测试我一般把测试工程师在 AI 时代的能力进阶拆成四个层级。每一层都有明确的交付物和判断标准不满足上一层的条件直接跳到下一层往往会卡住。2.1 第一层编程、接口与自动化测试基础底层能力仍然是 Python、HTTP 协议、接口测试、UI 自动化基础。移动端要看 AppiumWeb 端要看 Selenium 或 Playwright框架层面首选 pytest。为什么这一层绕不开因为 AI 生成的测试脚本、评测脚本最后都要落到代码里执行。你自己看不懂脚本、不会改断言、不会处理依赖和路径AI 帮你生成的代码一旦报错你就只能干瞪眼。我在团队里常说AI 写代码的能力越强越考验你不会代码时能不能发现问题。交付物能用 pytest 写完 10 条接口用例能跑通并接入命令行执行。2.2 第二层AI 应用开发认知不需要你会训练模型但要懂大模型 API 的基本调用方式、prompt 怎么写、上下文长度限制、函数调用Function Calling是什么、RAG 大概怎么工作、并发和限流是怎么回事。原因很简单你要测试一个 AI 系统就得先知道它的基本结构。RAG 系统测试要拆检索和生成两段Chat 应用测试要关注多轮记忆Agent 应用测试要关注工具调用链路。这些没概念测试用例设计就无从谈起。交付物能独立调用一个大模型接口把一段业务描述转成结构化的测试用例清单。2.3 第三层AI 测试专项能力这一层开始和普通测试拉开差距。要做的是建设评测集和 Golden Case基准用例覆盖正常、边界、对抗、异常输入设计质量指标比如准确率、召回率、幻觉率、响应延迟、稳定性建立回归基线模型版本每次更新都在同一套数据集上对比结果设计灰度发布策略线上只放一部分流量观察指标后再全量。交付物给一个 AI 功能输出完整的评测报告包括数据集说明、指标变化、回归结论。2.4 第四层平台化、Agent 化与规模化到这一层重点是复用。把单次评测变成平台能力数据集版本管理、任务队列、结果看板、失败自动重跑、CI/CD 集成、多项目共用。交付物一个内部使用的 AI 测试小平台至少有两个项目在跑并且新人能直接上手操作。这四层不建议跳跃。前两层根基不牢后两层做出来的东西经不起业务推敲出了问题连排查入口都找不到。3. 最快见效的一步用 pytest 接上大模型接口生成并执行测试用例下面这套流程我建议每个人都亲手做一遍它是最小可运行的 AI 辅助测试闭环写一条手动用例、调大模型生成用例、跑 pytest、人工检查断言。3.1 环境准备先准备好 Python 环境建议 3.10 以上。安装两个依赖就够了其他用到再加。pip install pytest requests如果你要调大模型接口还要确认供应商的 SDK 或直接用 requests 调 HTTP 接口。不同供应商的请求格式不同这里以通用 OpenAI 兼容格式为例实际使用以你的服务端文档为准。注意接口地址、模型名称、密钥都要以你实际拿到的服务信息为准不要照抄网上的任意示例。3.2 先手写一条用例确认被测服务的行为不要一上来就生成用例。先手动发一个请求确认服务的返回结构。这一步决定了后面生成的用例断言对不对。import requests def test_query_service(): resp requests.post( http://127.0.0.1:8000/query, json{query: 上海今天天气怎么样}, timeout10, ) assert resp.status_code 200 data resp.json() assert data.get(code) 0 assert len(data.get(data, {}).get(answer, )) 0跑通之后记下返回的字段名、类型、错误码含义。AI 生成的代码大多会假设一个返回结构如果你的服务字段名不同它生成的断言就全是错的。3.3 用大模型生成测试用例下面这一段是把业务描述交给大模型让它返回 pytest 代码。注意把密钥放在环境变量里不要硬编码到仓库。import os import requests def generate_cases(business_desc: str) - str: prompt ( 你是一名资深测试工程师请根据下面的业务描述生成 pytest 用例代码。\n f业务描述{business_desc}\n 要求\n 1. 使用 requests 调用被测服务服务地址为 http://127.0.0.1:8000\n 2. 断言状态码和关键返回字段\n 3. 至少包含一个正常用例和一个异常用例\n 4. 只输出 Python 代码不要额外解释 ) resp requests.post( https://api.example.com/v1/chat/completions, json{ model: your-model, messages: [{role: user, content: prompt}], }, headers{Authorization: fBearer {os.environ[LLM_API_KEY]}}, timeout60, ) return resp.json()[choices][0][message][content]把生成的代码保存成test_generated.py放在 pytest 能识别的位置然后执行pytest test_generated.py -v3.4 校验生成结果先看能不能跑再看对不对这里有一个关键步骤很多新手会跳过。AI 生成的用例“能通过”不等于“有效”。我一般会做两个检查第一个检查故意改错一个字段名比如把code改成code_wrong看用例会不会失败。如果仍然通过说明断言根本没生效这条用例是废的。第二个检查把被测服务的返回内容改掉或者临时模拟一个错误码确认用例能敏锐地发现异常。只有这两种情况都能被捕捉到的用例才值得保留进回归集。AI 生成用例的最大风险不是报错而是“假通过”。4. 进阶实操搭一个最小可用的 AI 测试 Agent用例生成跑通之后可以再往前走一步把“拆解任务、执行调用、结果校验、输出报告”串成一个最小的 AI 测试 Agent。这里不需要一上来就上重型框架先把流程打通。4.1 Agent 需要哪几部分一个测试 Agent 至少包含四个环节规划器接收自然语言任务拆成步骤列表执行器按步骤调用工具比如发 HTTP 请求、跑 pytest、查数据库、操作 Appium校验器检查执行结果是否符合预期决定重试还是终止报告器把过程日志和最终结论整理成结构化报告。工具层可以用一个字典注册模型通过函数调用function calling选择要执行的工具。简单实现类似这样TOOLS { http_request: call_http, run_pytest: run_pytest_command, query_database: query_database, }如果模型不支持函数调用也可以让模型每次返回一段 JSON里面只包括tool和args两个字段。解析后再执行把结果回传给模型让它决定下一步。4.2 执行链路要控制的三个参数第一个是超时。每个工具调用都必须有独立超时HTTP 请求、数据库查询、UI 操作都不能共用一个超时。否则一个卡住的步骤会拖死整个任务。第二个是最大步骤数。Agent 可能陷入反复尝试的死循环规划器觉得自己在执行实际上什么都没推进。给任务设置上限比如最多 20 步超过就停止并把中间日志输出。第三个是并发数。能跑通单条任务之后再考虑批量。不建议一上来就开 10 个并发任务因为被测服务很可能扛不住或者大模型接口触发限流。我一般从 1 个任务开始稳定后再提到 3 到 5 个观察资源占用和服务延迟再往上加。4.3 失败重试不能盲目执行重试只适用于幂等操作比如查询接口。对于创建订单、发送短信、修改数据这类有状态的操作用例盲目重试会制造大量脏数据还会掩盖真实缺陷。更稳妥的做法是第一次失败后保留日志不重试由人工判断如果确认是网络抖动或服务临时不可用再手动触发重跑。Agent 里可以设计一个“可重试”标记只有打上这个标记的步骤才允许自动重试。4.4 报告和人工复核报告至少要包含任务输入、每一步调用的工具和参数、执行耗时、断言结果、失败时的响应内容、重试记录。输出成 JSON 方便程序解析同时生成一份 Markdown 给人工阅读。无论 Agent 多智能测试结论在进入正式流程前最好还是由人工扫一眼报告。Agent 负责把数据整理得足够完整和规范人负责判断哪些问题是真正需要提缺陷的。5. 测试 AI 产品时真正要盯住的质量维度如果你负责的是一个 AI 产品不是拿 AI 来辅助测试那关注点就要换一下。功能测试那套“输入-输出”校验只是底线更核心的是下面这些维度。5.1 功能正确性之外先看这五个指标第一内容准确率。回答里的关键事实是否与可信来源一致这个需要人工抽检或引入参考答案比对。第二幻觉率。模型是否输出了没有依据的信息。对 RAG 系统来说凡是答案里引用了检索内容却编造了原文没有的细节都算幻觉。第三稳定性。同样的问题连续问 5 次回答结构是否一致关键结论是否会漂移。模型本身有随机性但业务上不能允许核心结论反复横跳。第四延迟。包含首字延迟和总耗时还要看 p95 和 p99不能只看平均值。一个模型平均 1 秒但高峰期 8 秒体验上是不可用的。第五内容安全与合规。生成内容是否符合产品的内容安全规范是否会出现不适合展示的信息。这类验证要做自动检查加人工抽检的组合不能只靠一句“让模型注意点”。5.2 Golden Case、评测集和回归基线做 AI 产品测试一定要有“评测集”意识。整理一批有代表性的问题集每个问题记录期望行为。可以把评测集分成几类标准场景大多数用户会问的常规内容边界场景超长输入、空输入、同义词、错别字、多轮突然换主题对抗场景诱导型问题、模糊问题、多条件矛盾问题。评测集要有版本。模型升级、prompt 调整、检索库更新都要在同一套评测集上跑一轮回归。没有基线你根本说不清某次效果变好是因为模型强了还是因为测试问题问得太简单。5.3 灰度发布与 A/B 对比AI 模型上线不太适合“全量直接替换”。比较稳妥的做法是做灰度新版本先放 5% 的流量观察线上真实评测数据和用户反馈确认指标没有变差再逐步放量。灰度期间要同时记录新旧版本的同一批线上请求做对比分析。如果新版本准确性提升了但延迟明显变高要评估是否值得。线上评测不能只看平均值还要拆维度看不同问题类型、不同用户群体、不同时段。5.4 多场景产品的共性测试思路车载测试、智能硬件、芯片测试这些方向也会有越来越多 AI 模块介入比如感知算法、语音交互、决策规划。它们的共性是测试环境很难完全真实通常要依赖仿真、台架、录制的数据集回放。做这类测试时除了关注算法指标更要关注环境条件对结果的影响光照、噪声、温度、网络波动、资源限制。同样的模型在实验室跑得很好到实际环境性能下降往往是环境差异导致的。这类问题的排查重点不是模型本身而是数据采集一致性和运行环境等价性。6. 三个月到一年的落地学习规划前面讲了很多方向这里给一个按时间推进的学习计划。它的原则是每段时间都有明确交付物而不是单纯“学完某门课”。6.1 第一个月把基础补到“能写能跑”内容Python 基础列表、字典、函数、文件读写、异常处理、requests 库、pytest 基础、HTTP 接口基本概念、本地接口调试。交付物写一个脚本从 JSON 或 Excel 文件里读取接口请求批量执行并输出通过失败统计。跑稳这一个小工具比刷一百道面试题有用。6.2 第二到三个月自动化测试和 AI 工具练手内容Web 和移动端自动化基础Appium 或 Playwright 二选一大模型 API 调用prompt 基本技巧函数调用。交付物把第 3 节的“AI 生成用例并执行”流程做成一个小工具能从 Excel 读取多条业务需求批量生成用例文件跑完输出汇总报告。6.3 半年节点做一个完整的 AI 测试项目内容选一个真实对象比如公司内部的问答机器人、搜索服务或 RAG 知识库。为它建设评测集设计指标跑回归最后产出一份评测报告。交付物评测集文档 回归脚本 报告。这阶段最好能推动业务一次真实的产品迭代让评测结论真正影响产品决策。6.4 一年节点往平台化和团队复用走内容把半年的成果工程化。评测集版本管理、任务队列、失败重试、结果看板、CI 集成、权限控制。如果团队有 Java 栈需求可以看 Spring AI但对测试场景Python 生态更直接。交付物一个至少两个项目在用的内部 AI 测试平台。到这一步你在这个方向的竞争力就比多数人强了。时间学习重点交付物常见误区第 1 个月Python、pytest、接口基础批量接口检查脚本只刷理论不动手第 2-3 个月AI API、prompt、自动化工具AI 生成用例小工具用例只生成不校验半年评测集、指标、回归AI 产品评测报告报告写给自己看不推进决策一年Agent、平台、CI 集成内部测试平台功能堆砌没有团队真正使用7. AI 测试最容易翻车的几个地方和我的排查顺序最后把实战里高频踩坑的点集中说一遍。这些问题单独看都很小但组合起来会严重影响你落地。7.1 AI 生成的用例看着完整实际跑不起来最常见的三种情况第一代码里调用了不存在的对象或方法第二断言用的字段名和实际返回值不一致第三生成的是 mock 数据而不是真实请求。排查顺序先看代码是否报语法错误再看依赖是否安装然后看被测服务地址和端口是否正确最后逐条核对断言字段。跑用例时加-v参数每一条的执行结果都要看不要只看最后的总数。7.2 大模型输出不稳定断言不能写得太死测试 AI 产品时最忌讳断言“回答必须等于某个字符串”。大模型几乎不可能每次输出完全一致。合理的做法是断言结构、关键字段、长度范围或者用语义相似度打分阈值根据实际数据调整。如果你的场景确实要求稳定输出比如接口需要固定 JSON 格式那应该优先通过 prompt 约定格式并在代码里增加格式校验和错误重试而不是靠反复跑碰运气。7.3 限流、超时、费用和并发问题批量测试 AI 功能时最常见的问题是限流和费用失控。解决方案分三层设置单次请求超时避免慢请求堆积设置并发上限和每日调用上限尤其是真实模型接口对重复请求做缓存同一问题同一模型版本只测一次结果落盘复用。费用控制方面尽量用小模型做粗筛只有粗筛不通过的样本再交给大模型细评。这样可以显著降低成本。7.4 环境问题本地连接、权限和依赖版本很多报错看起来是代码问题实际是环境问题。比如本地服务提示 127.0.0.1 拒绝连接先确认服务真的启动了再确认服务监听的端口然后确认是不是把localhost解析到了 IPv6 的::1导致连不上只监听 IPv4 的服务。排查顺序固定下来服务是否启动、地址端口是否正确、防火墙和代理是否干扰、依赖版本是否匹配、运行用户是否有权限、日志在哪看。按这套顺序走80% 的环境类问题都能定位。7.5 安全测试要在合规环境里做2026 年测试分工里安全测试的热度一直不低。学安全测试没问题但一定要在授权、合规的本地环境里练习。比如自己搭一个漏洞靶场学习常见漏洞原理和防御思路。不要对未授权的系统做扫描和探测这不只是技术问题更是职业底线。安全测试的学习路径应该是先学网络基础和 HTTP 协议再学常见漏洞原理然后在靶场里做重复性练习最后配合修复方案做验证。它和 AI 的结合点在于可以用 AI 辅助生成测试流量、帮助分析响应特征、辅助编写检测规则但核心仍然是人要理解漏洞原理和业务逻辑。回到开头那句话AI 测试不是一个花哨标签而是一条可以拆成多个层级的真实能力路线。我个人更建议先把“单条任务跑稳”这件事做扎实手写一条用例、接一次大模型、生成一批脚本、人工核对断言。这样走完一圈你对 AI 测试的感知会比看十篇教程都强。真正值钱的地方不在于你调用了多少模型接口而在于你能不能把输入、执行、校验、报告和回归基线整理成一套别人也能复用的流程。踩过几次坑之后就会发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。 
