在测试圈子里泡了这么多年我发现一个特别扎心的现象手工点点点的测试工程师越来越焦虑自动化测试工程师也在焦虑——前者怕被取代后者怕自己的那套“录脚本写关键字”的本事过时。最近这一年到处都在喊“AI测试开发”但你真要问AI到底怎么跟测试结合能落地的方案长什么样大多数人其实说不清楚。这篇文章我想聊聊我对这个方向的真实理解尤其是怎么利用大模型和Agent技术把测试用例自动变成可执行的UI自动化脚本。这不是PPT里的概念是一套我已经在真实项目中跑通的玩法也顺便说清楚为什么我把这个方向做成了系统性的训练营——“测试人转型AI测试开发”这一次真的别再观望了。这篇内容适合三类人长期做功能测试想往技术方向转的同学、写了两三年自动化脚本但遇到瓶颈的测试开发工程师以及团队里开始接AI测试工具选型、想建设智能测试平台的技术负责人。你会看到AI测试开发到底需要哪些技能、主流技术栈怎么组合、一个典型的Agent项目怎么拆解和实现以及我在落地过程中踩过的那些文档里绝对不会写的坑。1. 为什么是现在AI测试开发不是概念是岗位结构正在被改写先说一个我自己的判断测试行业正在经历从“自动化测试”到“智能测试”的切换而这个切换的速度比当年从手工测试切换到自动化测试要快得多。主要原因很简单——大模型让“写脚本”这个最耗人力的环节第一次出现了被机器替代的可能。1.1 测试岗位的价值重心正在转移以前一个测试团队里最有价值的人是把业务流程转化为自动化脚本的人其次是能设计复杂测试场景的人。但随着AI介入写脚本这件事正在被工具和模型蚕食。我见过不少团队同一个用例以前需要一个测试开发花半天写一条Playwright脚本现在把用例丢给一个配置好的Agent五分钟生成初稿人工再花十分钟审核修正保质保量。这意味着测试工程师的核心竞争力正在从“编码执行力”转向“流程设计力和AI驾驭力”。懂业务、懂用例设计、又懂得怎么让大模型稳定产出高质量脚本的人会成为团队里最稀缺的角色。这恰恰就是“AI测试开发”这个岗位的本质——不是让测试转行做算法工程师而是让测试工程师掌握AI工具链把AI变成自己手里的放大器。1.2 企业招聘端的变化最诚实去翻一下主流招聘平台上“测试开发”方向的新增岗位你会发现几个高频词AI、Agent、LangChain、Playwright、提示词工程、智能体。这不是个别公司蹭热点而是大规模出现的真实需求。企业投钱搞AI测试诉求非常朴素降低脚本维护成本、缩短回归测试时间、让不懂代码的测试人员也能产出自动化资产。可悲的是人才供给完全没跟上。大部分测试工程师的现状是会写Python和Selenium但完全不知道大模型怎么接入流程听说过LangChain但不知道它跟测试有什么关系用过ChatGPT写代码但停留在“问答式辅助”而不是“让它当一个能自己看用例、自己写脚本、自己跑起来验证的Agent”。这就是窗口期。任何岗位红利期都是短暂的等所有人都把这套能力学会你再去学就没有溢价了。1.3 这波技术变革对测试人反而是利好我一直觉得做测试的人转AI测试开发比开发转过来更有优势。为什么因为AI生成的东西天生需要“挑刺思维”。写代码的人习惯让代码跑通而测试的人习惯挑毛病。大模型生成的脚本满身都是毛病让你挑——元素定位不稳、断言逻辑漏洞、等待时机不对、边界条件缺失。你多年练出来的测试思维恰恰是让AI产出变得可靠的核心能力。所以别老觉得AI是来砸饭碗的。AI砸掉的只是“纯手工点点点”的饭碗同时给“懂业务懂测试懂AI工具”的人递了一把更大的铲子。2. 转型AI测试开发需要补全的能力地图很多人一上来就焦虑要不要先学几个月机器学习要不要把Transformer原理啃透我的答案非常干脆——不需要。AI测试开发不是算法岗位它本质上是“测试开发 大模型应用工程”你只需要把大模型当成一个能写代码、能理解自然语言的超级执行器然后学会指挥它、约束它、验证它的输出。真正的核心技能分四层。2.1 第一层扎实的自动化测试功底这是永远绕不开的地基。AI再强它生成的脚本还是要跑在Playwright、Selenium这种框架上。你得懂元素定位、等待策略、断言设计、Page Object模式、CI集成。否则Agent给了你一份看起来完美但一跑就挂的脚本你可能连怎么改都不知道。我在训练营里遇到过很多这样的同学Python语法熟练但完全没做过UI自动化第一次写Playwright脚本时连“页面加载完成”和“元素可见”这两个概念都分不清。这一层如果不过关后面所有AI相关的技能都是空中楼阁。2.2 第二层大模型应用开发的核心能力这里包含三个关键点。提示词工程是基本功。很多人只会写“帮我写个脚本”这种模糊指令拿到的是模糊产出。真正做AI测试开发的人会写结构化的System Prompt把角色、任务目标、输出格式、约束条件、示例全部写清楚。好的提示词能决定脚本从“看着对但用不了”变成“拿来就能改改跑”。结构化输出是命门。不要指望模型直接输出一大段脚本来解析而是让它输出JSON结构——比如把“打开登录页—输入用户名—输入密码—点击登录—断言跳转”拆成结构化步骤再让模型为每一步生成对应的代码片段。结构化输出意味着可解析、可校验、可容错这是一切稳定性的基础。Function Calling和Agent框架是进阶。Function Calling让模型具备调用外部工具的能力比如让它调一个“读取Excel测试用例”的工具、调一个“用Playwright录制页面结构”的工具。而Agent框架比如LangChain里基于ReAct模式构建的智能体则让模型能自主规划多步操作读用例、拆步骤、写脚本、跑脚本、根据报错修脚本形成闭环。2.3 第三层测试用例的数字化工序AI测试开发的一个核心前置工作是把非结构化的测试用例变成大模型能理解的结构化数据。这一步常被忽略但直接决定项目成败。我见过大量团队的测试用例还躺在Excel和Word里写满了“点击按钮检查页面跳转”这种模糊描述——模型拿到这种用例也束手无策。你需要具备用例模板规范化的能力把用例拆解成前置条件、操作步骤、预期结果三个部分操作步骤要具体到元素、动作、数据预期结果要可机器校验。这本质上还是测试设计的基本功但要求更高——因为你的用例读者不仅仅是人还有AI。2.4 第四层工程化交付和稳定运行生成一条脚本只是demo要让它变成团队每天都用的基础设施你需要解决一堆工程问题脚本生成后怎么自动安装依赖怎么跑在Docker或CI流水线里失败时如何自动收集现场信息并触发修复选用哪个模型更划算说实话这一层最考验技术深度也最筛人。很多同学卡在“demo很惊艳一落地就崩”的阶段就是因为工程化能力不足。我自己在项目里吃了不少亏之后才明白AI测试开发的核心不是让模型单点能力强而是让整个链路稳定、可控、可回溯。3. 核心案例实操基于LangChain构建“用例自动生成UI脚本”的Agent讲了一堆理论下面进入真正的硬核环节。我来拆解一个我实际做过也正在持续迭代的项目——基于LangChain开发一个能读取测试用例、自动生成UI自动化脚本的Agent。整个项目用到的技术栈是LangChain Playwright FastAPI用于服务化封装模型走的是OpenAI兼容接口。3.1 项目要解决的真实痛点当时团队的情况很典型测试用例有上千条覆盖核心业务链路但自动化覆盖率不到20%。测试开发团队天天加班写脚本业务测试同学花大量时间做重复回归两边都怨声载道。我们评估了“纯人工补脚本”和“录制回放工具”两条路前者太慢后者脚本太脆、改一版页面就废一片。最后决定走第三条路用大模型做“用例理解”和“脚本生成”再配合人工审核兜底。3.2 整体架构与工作流设计整个Agent的工作流程我画成了一条流水线第一步加载并解析测试用例文件支持Excel、Markdown、JSON提取用例编号、前置条件、操作步骤、预期结果。第二步对用例文本做语义拆解把自然语言步骤转换为结构化步骤清单比如“输入用户名”变成“在[username_input]输入[testuser01]”。第三步将结构化步骤交给大模型让它为每一步生成对应的Playwright代码片段最终拼接成可执行的完整脚本。第四步自动执行脚本捕获运行时错误、断言失败等信息。第五步把错误信息回传给模型让模型自动分析失败原因并尝试修复带重试上限防死循环。这里面最关键的设计决策是不让模型直接凭空写一大段脚本而是“先结构化、再写代码、再执行验证、再修复”。这个决策把整个项目的稳定性拉高了不止一个档次。3.3 提示词与解析层实现先看用例读取这一层。比如Excel里一条用例长这样”前置已登录系统步骤点击侧边栏的‘订单管理’输入订单号2024001点击搜索预期列表出现对应订单记录。“这串自然语言直接丢给模型它大概率会脑补一些页面细节。所以我们加了一步中间处理先用规则做粗糙分块再让模型把内容转成固定的JSON Schema。from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser from pydantic import BaseModel, Field from typing import List class TestStep(BaseModel): action: str Field(description操作类型click/input/assert/wait/open) target: str Field(description操作目标元素描述或URL) value: str Field(default, description输入值或断言内容) class TestCase(BaseModel): case_id: str Field(description用例编号) preconditions: str Field(description前置条件) steps: List[TestStep] Field(description结构化操作步骤) expected: str Field(description预期结果描述) prompt ChatPromptTemplate.from_messages([ (system, 你是资深测试工程师请将给定的自然语言测试用例转换为结构化JSON遵循schema。), (human, 用例内容{testcase_text}) ]) parser JsonOutputParser(pydantic_objectTestCase) chain prompt | chat_model | parser result chain.invoke({testcase_text: raw_case_text})这段代码的意思是通过Pydantic定义输出的数据结构告诉模型必须按这个Schema输出再用JsonOutputParser解析结果。这种做法比让模型直接吐文本靠谱得多——因为它把“模型自由发挥”的空间压缩到最小任何一步解析失败我们都能定位和补偿。3.4 脚本生成与代码执行拿到结构化步骤之后下一步是生成Playwright脚本。这里我用了一个带few-shot示例的生成器主要为了让模型学会我们的代码风格——比如优先使用get_by_role和get_by_label而不是脆弱的XPath强制使用action.wait_for()等。script_prompt ChatPromptTemplate.from_messages([ (system, 你是Playwright脚本生成专家请根据结构化步骤生成Python脚本。 规则 1. 优先使用get_by_role、get_by_label定位不要使用绝对XPath。 2. 所有可交互元素操作前必须等待元素就绪。 3. 断言统一使用expect超时设为10秒。 4. 输出纯Python代码不要解释。), (human, 结构化步骤{steps_json}) ]) python_code (script_prompt | chat_model).invoke({steps_json: result.json()})生成的脚本会落入一个自动创建的项目目录然后通过Playwright进行执行。为了可控我把执行过程包在一个子进程里超时时间设为120秒并开启trace录制。这也是一个后来验证非常有价值的决定——失败时能拿到完整的浏览器操作录像而不是只看几行冷冰冰的报错日志。3.5 自动修复循环第一次跑AI生成的脚本失败率不会低。所以我在项目里设计了一个修复环路失败后将“脚本内容 报错信息 trace分析结果”拼接成新的Prompt让模型分析原因并输出修改后的脚本然后再次执行最多重试3次。实测下来简单问题比如元素加载慢了、属性变了通常一次修复就过复杂问题比如业务流程本身变了模型很难自己处理好这时候会自动把工单转给人工处理。重点是这个环节为整个系统兜了底让人工介入的成本从“每条脚本都审”降为“只有AI修不好的才审”效率才会真的起来。3.6 项目效果与数据这个Agent在试点项目里跑了一个月累计处理了147条用例。最终表现是一次生成即通过的比例约41%通过1轮修复后通过的约32%通过2轮修复后通过的约15%剩余12%转入人工处理。整体有效率87%一条脚本的平均生成和验证时间从人工的23小时压缩到815分钟。这个数据不算惊艳但已经足够让团队把自动化覆盖率从20%拉到60%以上——而且大部分工作由AI完成测试开发工程师只需要做审核和高难度用例兜底。4. 实操中那些“不撞南墙不知道”的坑与排查技巧做这种项目真正让你掉头发的往往不是算法和框架而是那些看似不起眼的工程细节。我把自己踩过的坑整理成一份速查表每一行都是真金白银换来的。4.1 坑一模型输出的脚本“貌似正确”但一跑就崩这是最高频的问题。根本原因在于模型对页面结构的想象和实际页面差距太大。举例模型以为输入框有明确的label但页面上根本没有模型以为按钮文案是“登录”实际是“Sign In”。这时候脚本定位失败你以为是自己代码写错了其实是模型在“脑补”。排查建议在Agent的执行环境中加入一个“页面结构采集”工具——先用Playwright启动浏览器访问目标页面抓取当前页面的可交互元素清单角色、标签、名称把这份真实数据塞进Prompt里让模型基于事实写代码而不是靠猜。这一步直接把脚本一次通过率提升了将近20个百分点。4.2 坑二测试用例写得“人懂模型不懂”前面说过测试用例不规范是转型的最大障碍。很多用例里的步骤描述是“进入页面随便填点内容点击保存检查是否成功”——这种信息密度极低的描述模型只能靠瞎猜。我见过同学拿这种用例跑Agent生成的脚本五花八门。排查建议做一套用例规范化前置处理。在把用例喂给模型之前先做一个“用例质量检查”工具自动识别缺少定位信息、动作模糊、预期不可校验的用例并打回给业务测试补充。宁可前期多花点时间把用例写清楚也不要让模型在烂用例上浪费时间。4.3 坑三元素定位保存不住下周跑就挂模型生成的脚本即使当时跑通两周后页面改版照样挂。这个问题的本质是定位策略问题不是AI特有的但AI会把问题放大——它生成的XPath又长又绝对比人写的更脆。排查建议在Prompt里硬性规定三层定位策略优先data-testid或稳定业务属性其次用ARIA角色和可见文本组合最后才允许短路径XPath。然后在脚本模板里把定位器统一封装成工具函数后续页面如果改了只需要修一个映射文件而不必改几百条脚本。4.4 坑四模型陷入“乱修循环”自动修复环路有时候会走火入魔——脚本明明已经能跑了模型觉得报错信息里有某个警告非要“修一下”结果把好的改成坏的。这种问题在依赖对话上下文的场景特别常见。排查建议给修复Agent设置一个“最小修改”约束让它只有收到失败信号时才允许改动成功信号下必须原样返回。同时设置重试上限为3次超过3次自动转人工绝不无限循环。好的Agent必须是克制且可控的不是能力越强越好。4.5 坑五模型选型直接决定成本和效果试过一堆模型从便宜的本地小模型到顶配商业模型差别极大。小模型跑简单用例还行复杂业务流程一上就胡言乱语顶配模型能力强但成本也感人。我后来定了一个策略先让便宜模型做结构化和初步生成通过校验后再调用强模型做修复成本一下子降了60%。另外需要注意接口兼容性。目前市面上大多数开源模型都提供OpenAI兼容接口LangChain可以直接通过ChatOpenAI基类对接切换模型只需改环境变量。这也是为什么我强烈推荐用LangChain而不是自己造框架——它天然屏蔽了模型差异让你把精力放在测试流程本身。5. 转型落地的学习路线与行动建议技能聊完了回到最现实的问题一个普通测试工程师到底该怎么规划自己的转型路径我见过太多人学了一堆零碎知识点今天学LangChain明天学提示词后天又跑去学Docker最后什么都没沉淀下来。核心的问题在于缺少一条围绕“测试场景”组织知识的主线。5.1 不建议的学习顺序千万不要一上来就刷“大模型原理”和“Transformer论文”。这些内容对你的日常工作几乎没有任何直接影响只会让你更快放弃。也不要东一榔头西一棒槌地学AI测试开发是一套组合技能需要以场景为锚点把Python、自动化测试框架、LangChain、Agent设计串成一条线。5.2 我建议的四阶段路线第一阶段把Python功底补扎实做到能独立写面向对象脚本并熟练在项目里使用Pytest做断言和组织用例。这个阶段不需要高级特性但要敢写。第二阶段系统掌握Playwright。重点不是会几个API而是理解自动等待机制、选择器优先级、trace调试、浏览器上下文隔离。这个阶段可以用“录制回放人工重构”的方式让脚本从能跑变成能维护。第三阶段进入AI应用开发。搞懂Prompt工程、结构化输出、Function Calling用LangChain跑通“自然语言转Python脚本再执行”的最小闭环。这一阶段不需要深究框架内部原理但必须理解Agent的“规划—行动—观察”循环。第四阶段做真正意义上的Agent项目。以“读取测试用例生成UI自动化脚本”为练手题完整实现用例解析、脚本生成、执行验证、自动修复四个模块把它包装成一个小工具并坚持迭代三个版本。这个项目做完面试时你既能讲思路也能展示代码在候选人里会非常有辨识度。5.3 关于“报班学习”的一些现实建议我一直觉得自学和报班不是对立的而是分场景的。如果你的基础好、自驱力强、有大把时间试错完全可以自学但如果你在公司既承担日常回归任务又没时间从零开始踩坑那跟着一个系统性设计的训练营走是更高效的选择。这也是我做“人工智能测试开发班”的初衷——不是制造焦虑卖课而是把我在真实项目中跑通的这套方法论毫无保留地拆给你。课程的核心不是念PPT而是带着你把上面那个Agent项目从零到一完完整整做出来每行代码都过一遍每个坑都提前告诉你。5.4 最后分享一点个人体会我带过的学员里转型最快的并不是基础最好的而是那些“愿意把一个大问题拆成无数小问题逐个击破”的人。AI技术放大了这种能力差异——会拆解的人让AI替他干活越干越快不会拆解的人被AI搞出来的问题牵着鼻子走越用越累。所以我自己做项目时始终信奉一条原则AI负责跑得快人负责跑得对。先把流程设计稳再把AI接进来这个顺序永远不能反。如果你也想在这波窗口期里踩上AI测试开发的节奏我的建议很简单找一个具体的测试场景用我上面给的思路花两周时间把最小闭环跑通。跑通了你面前就是一片新大陆跑不通带着具体问题来训练营找我我陪你把坑一个个填平。