AI 测试岗最近讨论度确实很高。不少测试同学刷到招聘信息后第一反应是“薪资不错、方向新但要求是不是太高了”于是网上就出现了“先混进去再说”的说法。这类调侃背后其实隐藏着岗位信息不对称的焦虑。本文我会从 AI 测试岗位的真实工作内容、技能要求、常见误区出发再带你手写一个 AI 辅助测试的小 demo把“AI 测试到底要会什么”这件事讲透给准备转岗或刚入行的测试人一份能落地的参考。1. AI 测试岗位的真相不是“会 AI”是“懂业务会测试能用 AI”1.1 为什么有人会说“先混进去再说”“先混进去再说”这句话我在技术社群和面试交流帖里见过很多次。说这话的人通常是把 AI 测试岗理解为“门槛很高、要求很新但自己现有经验也能沾点边”的岗位。他们觉得只要简历包装一下面试时把大模型、智能体、自动化测试这些词都套上先进公司再慢慢学总比一直待在舒适区强。这种想法不是完全没有道理因为 AI 测试岗位确实还在快速演化中不同公司对它的定义差异非常大。但“混进去”并不等于“真的能胜任”。我在招聘和团队协作中看到的情况是AI 测试岗最大的门槛往往不是算法知识而是测试基本功是否扎实、动手能力是否过硬、遇到不确定的问题能不能自己找到答案。如果你只是把“AI”当噱头却没有提前准备任何可落地的技能就算顺利进入面试也很容易被几个追问打回原形。比如面试官问你“你打算怎么用大模型生成接口测试用例”你如果只能回答“用 ChatGPT 问一下”这显然是撑不住的。所以我的建议是心态上可以轻松一些但准备上一定要务实。1.2 AI 测试岗的几种真实形态同样是“AI 测试岗”不同公司的职责差别很大。看到岗位名称时先别急着被“AI”两个字吓到也不要觉得只要是 AI 测试岗就一定要求你会训练模型。目前市面上比较常见的形态可以分成四类。岗位形态测试对象核心任务偏重能力AI 产品测试对话机器人、智能客服、内容审核、推荐系统等 AI 功能验证 AI 功能行为是否符合预期处理边界输入、badcase、回归测试传统测试设计 AI 行为理解AI 辅助测试普通业务系统或接口用大模型生成测试用例、测试数据、智能断言提升测试效率自动化测试 提示词工程 工具开发算法评测模型效果、数据标注、评测集设计对模型输出质量进行评估分析准确率、召回率、badcase 分布数据分析、统计知识、评测经验测试开发 AI测试平台、CI/CD 流程、测试工具链把大模型能力接入现有测试平台建设 AI 测试基础设施工程能力 架构设计 AI 应用开发从岗位数量来看第二种“AI 辅助测试”是很多传统测试转岗最容易切入的方向也是本文重点演示的方向。它不需要你重新学一遍高等数学更像是把大模型当成一个“能力增强组件”嵌入到你已有的自动化测试流程中。1.3 认清岗位现实哪些能力是硬门槛很多招聘 JD 看起来要求又多又高比如“熟悉 Transformer”“有大模型微调经验”“掌握分布式训练”但实际面试时未必真的会问这么深。这是因为 AI 测试岗的职责边界还不稳定技术负责人自己也在摸索JD 往往是“按理想画像”写的不是“按每天实际工作”写的。但你也不要因此掉以轻心。从我接触到的真实情况看以下能力是 AI 测试岗比较硬的敲门砖扎实的测试基础用例设计、边界值、等价类、异常场景、回归策略这些不会被替代。至少一门编程语言Python 是目前 AI 相关岗位的主流选择如果你只会手工点点点转岗难度会很大。接口自动化能力能够独立搭建接口测试框架熟悉 pytest、requests 这类工具。对 AI 产品有基本认知能说清楚大模型为什么会有“幻觉”为什么输出不稳定什么是上下文长度什么是提示词工程。快速学习能力AI 工具迭代太快岗位内容很可能半年一变固守一种工具反而容易被淘汰。所以“先混进去再说”这个策略的最大问题是它把“岗位信息差”当成了“能力豁免”。实际上一个能长期待下去的 AI 测试工程师绝不是靠混而是靠不断更新技能树。2. 转岗前的技能盘点从传统测试到 AI 测试需要补什么2.1 传统测试基本功不能丢很多想转 AI 测试的人容易把注意力全部放在“AI”上却忽略了测试基本功。实际上AI 测试岗面试时面试官依然会考察你对测试理论的理解。比如“给你一个登录功能你怎么设计测试用例”“接口返回结果不稳定时你怎么判断测试通过”这些问题本质上还是传统测试问题。我建议转岗前先做一次自我盘点接口测试知道 GET、POST、PUT、DELETE 的区别能使用 Postman、curl、requests 发起请求能看懂状态码。自动化测试能用 pytest 编写测试用例会在测试前置、后置中处理数据准备和清理。用例设计熟悉等价类划分、边界值分析、因果图、场景法等最基础的用例设计方法。缺陷管理了解缺陷生命周期能清晰描述复现步骤、预期结果、实际结果。数据库与 Linux能写简单的 SQL 查询会看日志会使用 grep、tail 等命令定位问题。这些内容不要求你达到专家级别但如果其中任意一项是完全空白的状态我建议先补基础再考虑 AI 方向。原因很简单AI 测试是“测试”和“AI”的交集而不是“只看 AI、不看测试”。2.2 AI 知识到底要学多深对于绝大多数 AI 测试岗来说你不一定要会训练模型也不一定要懂反向传播。你需要的是“会用模型、能评估模型、能发现模型的问题”。下面这份知识清单是按重要程度排序的大模型 API 调用掌握通过 HTTP 请求访问大模型接口的基本方式理解请求参数里的 model、messages、temperature 等含义。提示词工程会设计 system、user 提示词让模型生成结构化的测试用例、测试数据或断言结果。输出稳定性理解大模型输出不是确定的同一个提示词多次调用结果可能不同因此测试用例和断言要做容错设计。常见应用模式了解 RAG检索增强生成、Agent智能体、Function Call函数调用的基本概念知道它们在大模型产品中扮演什么角色。AI 产品评测指标如果是做 AI 产品测试还会接触准确率、召回率、F1、幻觉率、badcase 分析等概念。不建议一开始就去啃模型训练、微调、量化这些偏算法工程师方向的内容。除非你面试的是算法评测岗否则这些知识在前期投入产出比很低。2.3 环境准备一套最小可用的测试开发环境工欲善其事必先利其器。下面是一套比较轻量的本地测试开发环境适合我们后面写 demo 使用。版本不要照抄硬背需要根据你实际的操作系统和 Python 版本调整。建议工具清单操作系统Windows / macOS / Linux 均可。Python3.9 或更高版本主要用于编写测试脚本和调用大模型 API。代码编辑器VS Code或者你熟悉的 PyCharm 都可以。虚拟环境使用 venv 管理 Python 依赖避免污染系统环境。依赖库requests、pytest以及后面 demo 中会用到的 fastapi、uvicorn。先创建一个项目目录并创建虚拟环境mkdir ai-test-demo cd ai-test-demo python -m venv venv激活虚拟环境Windowsvenv\Scripts\activatemacOS / Linuxsource venv/bin/activate然后在项目根目录新建requirements.txt内容如下fastapi uvicorn pytest requests安装依赖pip install -r requirements.txt这里没有锁定具体版本号因为不同 Python 版本对依赖版本有兼容要求。如果你在实际安装时遇到版本冲突可以根据报错信息为指定依赖加上版本号例如pytest7.0。3. 用 AI 辅助测试三个可以落地的方向3.1 AI 辅助生成测试用例传统接口测试用例的编写过程往往是测试人员阅读接口文档然后人肉思考各种入参组合、边界条件、异常场景。这个过程费时费力而且容易遗漏边界情况。大模型辅助生成测试用例的核心思路是把接口描述、字段约束、业务规则写成一段结构化提示词让模型输出 JSON 格式的测试用例列表再由测试人员审核后转成可执行的自动化脚本。这样做的好处是生成速度快几分钟就能得到一批用例草稿。覆盖思路不受个人经验限制模型可以从训练数据中借鉴很多常见边界条件。生成结果格式统一可以直接程序化解析。但要注意大模型生成的用例不能直接执行。因为模型不了解你的真实业务数据也可能会编造字段。所以必须经过人工审核。下面是一个提示词示例你是一名资深测试工程师请根据下面的接口描述生成 pytest 风格的测试用例。 要求 1. 只输出 JSON 数组。 2. 每个用例包含字段case_name、method、url、headers、body、expected_code、expected_keyword。 3. 至少包含正常场景、参数缺失、参数类型错误、超长字符、未授权五类场景。 接口描述 POST /api/login 参数username字符串必填password字符串必填 正确账号admin / 123456通过这种结构化的提示词模型输出的结果更容易被程序解析也更容易接入自动化流程。3.2 智能断言让大模型判断结果是否符合预期在传统接口测试中断言通常是“判断状态码是否为 200”“判断返回 JSON 中某个字段是否等于预期值”。这种断言简单可靠但遇到一些语义化、非结构化的返回内容时就会很吃力。例如一个智能客服接口的返回内容是“您好您咨询的退款问题我们会在 1-3 个工作日内为您处理。”如果你要断言这句回复语义是否正确传统写法很难覆盖因为你无法穷举所有合法表达。这时候可以借助大模型做智能断言。思路是把“接口返回内容”和“预期规则”一起发给大模型让模型返回 PASS 或 FAIL并附上判断理由。import requests def smart_assert(response_text: str, rule: str, api_key: str, base_url: str, model: str) - str: url f{base_url}/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { model: model, messages: [ { role: system, content: 你是一个智能断言器只输出 JSON格式为 {\result\: \PASS\ 或 \FAIL\, \reason\: \判断理由\} }, { role: user, content: f接口返回内容{response_text}\n预期规则{rule} } ], temperature: 0 } resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content]使用智能断言时有两点需要特别注意。第一不是所有场景都适合用大模型断言凡是能用代码写死的精确断言一定要先写死。第二大模型只是“辅助判断”最终是否上线需要测试人员人工确认规则是否被正确理解。3.3 基于历史缺陷的回归用例挖掘很多团队积累了大量的历史缺陷记录但缺陷库里的用例没有系统性地转化为自动化回归用例。借助 AI可以从历史缺陷描述中提取关键词、复现路径、影响范围再结合当前接口参数推荐需要补充的回归用例。这里不一定要引入复杂算法先用简单的方案也能有明显效果。比如先对历史缺陷文本做关键词切分再与接口字段做匹配找出高频风险点。等数据积累到一定程度再接大模型做更智能的聚合和推荐。一个简化示例思路risk_fields [username, password, token] def extract_risk_points(defect_list): risk_counter {} for defect in defect_list: text defect.get(description, ) for field in risk_fields: if field in text: risk_counter[field] risk_counter.get(field, 0) 1 return sorted(risk_counter.items(), keylambda x: x[1], reverseTrue)这个例子虽然简单但它体现了一个思路AI 测试不是必须一步到位你可以先用规则、统计、脚本把过程跑通再逐步引入大模型提升智能化程度。4. 完整实战为登录接口编写 AI 辅助测试 demo4.1 项目结构下面我们用一个完整的 demo 串联前面提到的知识点。项目结构如下ai-test-demo/ ├── app.py # 被测登录接口 ├── requirements.txt # 依赖 ├── ai_test_utils.py # AI 辅助测试工具 └── test_login.py # pytest 测试用例4.2 编写被测接口我们先使用 FastAPI 写一个简单的登录接口方便本地测试验证。这个接口不是生产环境接口仅用于学习演示。文件路径app.pyfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class LoginRequest(BaseModel): username: str password: str app.post(/api/login) def login(req: LoginRequest): if req.username admin and req.password 123456: return { code: 0, message: success, token: fake-token-123 } raise HTTPException(status_code401, detailusername or password error)启动接口服务uvicorn app:app --reload --port 8000启动后可以先用 curl 验证接口是否正常curl -X POST http://127.0.0.1:8000/api/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}预期返回{code:0,message:success,token:fake-token-123}4.3 封装 AI 辅助测试工具接下来封装一个通用函数用于调用大模型接口。这里以常见的 OpenAI 兼容格式为例接口地址、模型名、API Key 都通过环境变量或参数传入不写死某个厂商。文件路径ai_test_utils.pyimport json import os import requests def chat_with_model(prompt: str, api_key: str, base_url: str, model: str) - str: url f{base_url}/chat/completions headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { model: model, messages: [ { role: system, content: 你是一名资深测试工程师只输出符合要求的JSON不要输出多余解释。 }, { role: user, content: prompt } ], temperature: 0, } resp requests.post(url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() return data[choices][0][message][content] def generate_test_cases(api_desc: str, api_key: str, base_url: str, model: str) - list: prompt f请根据下面的接口描述生成测试用例只输出JSON数组。 数组元素包含字段case_name、method、url、headers、body、expected_code、expected_keyword。 至少覆盖正常场景、参数缺失、参数类型错误、超长字符、未授权等场景。 接口描述 {api_desc} text chat_with_model(prompt, api_key, base_url, model) text text.strip() if text.startswith(json): text text.removeprefix(json).removesuffix().strip() elif text.startswith(): text text.removeprefix().removesuffix().strip() return json.loads(text)需要说明的是不同大模型服务商的接口格式可能略有差异。比如有的服务商需要额外传api-version有的需要把模型名换成部署名。这里的示例只用于演示核心思路实际接入时要参考你所用服务的官方文档。4.4 编写 pytest 测试用例文件路径test_login.pyimport os import pytest import requests BASE_URL http://127.0.0.1:8000 def test_login_success(): resp requests.post(f{BASE_URL}/api/login, json{ username: admin, password: 123456 }) assert resp.status_code 200 json_data resp.json() assert json_data[code] 0 assert json_data[token] def test_login_wrong_password(): resp requests.post(f{BASE_URL}/api/login, json{ username: admin, password: wrong }) assert resp.status_code 401 pytest.mark.skipif( not os.getenv(AI_API_KEY), reason未配置 AI_API_KEY跳过 AI 扩展用例 ) def test_ai_generate_cases_with_model(): from ai_test_utils import generate_test_cases api_desc POST /api/login参数 username、password正确账号 admin/123456 cases generate_test_cases( api_desc, api_keyos.getenv(AI_API_KEY), base_urlos.getenv(AI_BASE_URL, https://api.example.com), modelos.getenv(AI_MODEL, demo-model) ) assert isinstance(cases, list) assert len(cases) 0 for case in cases: assert case.get(case_name) assert case.get(method) assert case.get(url) assert case.get(expected_code)默认情况下前两个用例会直接执行第三个依赖外部大模型的用例因为没有配置环境变量AI_API_KEY会被 pytest 跳过。这个设计很实用因为 AI 能力是可选增强不应该成为本地基础测试的阻塞项。4.5 运行与验证先启动被测接口新开一个终端进入项目目录执行uvicorn app:app --reload --port 8000再打开另一个终端确保虚拟环境已激活然后执行pytest -v如果你没有配置大模型 API Key预期输出大致如下collected 3 items test_login.py::test_login_success PASSED test_login.py::test_login_wrong_password PASSED test_login.py::test_ai_generate_cases_with_model SKIPPED如果你在环境变量中配置了AI_API_KEY、AI_BASE_URL、AI_MODEL第三个用例会尝试调用大模型生成测试用例。这时候要特别关注模型返回的 JSON 格式是否正确以及生成的用例是否真的符合接口定义。5. 常见问题与排查思路在实际开发和转岗练习中大家经常会遇到一些重复性问题。这里整理一份排查清单可以帮你快速定位。问题现象常见原因解决思路运行 pytest 报ModuleNotFoundError依赖未安装或虚拟环境未激活执行pip install -r requirements.txt确认终端里已激活 venv接口请求一直超时被测服务未启动或端口不对先访问http://127.0.0.1:8000/docs看服务是否存在再检查端口大模型接口返回 401API Key 错误、服务商不支持该模型检查环境变量确认账号权限阅读服务商错误码文档模型返回的不是合法 JSON提示词约束不够或模型不稳定把 temperature 设为 0在提示词中强调“只输出JSON”增加解析异常兜底AI 生成用例不符合接口实际接口描述信息不足补充请求头、鉴权方式、字段类型、业务规则等详细描述测试用例执行成功后没有真正验证业务只断言了状态码增加对返回体关键字段、token 是否存在、错误提示文案的断言AI 调用费用突然升高用例生成没有限制次数对 AI 调用加缓存、限流并把确定性用例先写成普通 pytest 用例除了技术问题还有一个很典型的认知误区以为 AI 测试只需要会“问 ChatGPT”。真实项目中AI 只承担一部分辅助决策工作测试架构、数据准备、结果分析、缺陷定位这些环节依然需要工程师自己完成。6. 最佳实践与工程建议6.1 遵循“确定性优先”原则AI 测试最容易踩的坑是“什么都想用大模型”。实际上能用代码写死的断言一定不要交给模型。比如状态码、JSON 结构、关键字段值、数据库落库结果这些都应该使用普通断言。大模型适合处理的场景是语义判断、相似度判断、非结构化内容提取、用例思路扩展。把这些场景和非确定性场景分开整个测试框架的稳定性会高很多。6.2 对模型输出做结构和内容双重校验大模型返回内容即使看起来是 JSON也可能出现字段缺失、类型错误、编造字段等情况。在程序里解析完 JSON 后还要做结构校验否则后续取字段时会出现KeyError。建议在代码里增加一个简单的结构校验函数def validate_case_schema(case: dict) - bool: required_fields [ case_name, method, url, headers, body, expected_code, expected_keyword, ] return all(field in case for field in required_fields)如果校验不通过可以选择让模型重新生成或者记录到失败列表由人工处理。这样既充分利用 AI 的生成能力又不让不稳定输出直接冲击测试流程。6.3 保护敏感数据与权限边界在测试环境中使用大模型最需要留意的是数据安全问题。不要把生产环境真实手机号、身份证号、银行卡号、用户密码等敏感数据发送给外部大模型服务。即使是你信任的服务商也要遵循最小化原则尽量使用脱敏后的虚拟测试数据。同时在团队协作中给 AI 工具的 API Key 要使用独立账号开通最小权限不要使用拥有云平台管理权限的密钥。密钥应存放在环境变量、密钥管理服务或 CI 系统的 Secret 配置中不要硬编码到代码仓库。6.4 控制成本和调用频率大模型 API 是按调用量计费的。为了让 AI 辅助测试可持续运行建议在框架中增加以下机制对相同请求做缓存同一个提示词和接口描述不要重复调用。设置单次运行的调用次数上限比如最多生成 50 条测试用例。按接口维度做用例生成不要每个测试用例单独调用一次模型。在本地开发环境中关闭 AI 增强只在指定的 CI 任务中启用。6.5 保留人工审核闭环AI 生成的测试用例、智能断言结果都应该有一个“人审”环节。最简单的做法是AI 生成的内容先写入文件由测试人员在代码评审中确认再合并进自动化用例集。不要直接让 AI 生成的用例自动上线执行。这不仅是保证质量也是明确责任边界的做法。测试结论最终要由人来负责AI 只是辅助工具。6.6 建立可回归的基线如果你的测试对象本身就是 AI 产品比如对话机器人、内容生成服务那么输出不稳定会一直存在。这时候不能只靠单次测试结果下结论而要建立基线用同一组评测问题集每隔一个版本跑一次记录通过率、输出质量、badcase 数量观察变化趋势。基线数据积累得越久你对模型版本升级带来的影响就越有把握。7. 总结与转岗建议回到文章开头那个问题AI 测试岗是不是“先混进去再说”我的看法是这个岗位确实存在很大的信息差不同公司对它的预期完全不同所以网上各种说法都有。但“混”不能解决问题提前把技能练扎实才是更稳妥的路线。尤其是 Python、pytest、接口自动化、大模型 API 调用、提示词工程这几项无论岗位名称怎么变都是比较通用的底层能力。如果你正准备转岗建议按照下面的节奏规划学习路径第 1-2 周补齐 Python 基础重点掌握 requests、pytest、JSON 处理。第 3-4 周独立完成一个接口自动化测试小项目至少覆盖登录、增删改查、异常参数场景。第 5-6 周学习大模型 API 调用和提示词工程理解 temperature、system、user、JSON 输出约束等概念。第 7-8 周把 AI 辅助用例生成、智能断言整合到之前的接口测试项目里形成一个小而完整的 demo。之后根据目标岗位方向补充 AI 产品评测、智能体测试、RAG 测试或测试平台开发经验。实际面试时比起背诵概念面试官更想看到你能现场讲清楚一个 AI 测试 demo 的设计思路能说出 AI 输出的不稳定性怎么处理能意识到敏感数据不能传给外部模型。这些细节都比“我了解大模型”这句话更有说服力。如果你现在还在犹豫要不要转岗与其焦虑岗位会不会消失不如先花两周时间把上面的 demo 自己跑一遍。动手做了之后你会更清楚自己缺什么也会更容易判断 AI 测试岗适不适合你。