1. 测试人转型AI测试开发到底在转什么这两年跟不少做测试的朋友聊天话题绕来绕去最后都会落到同一个焦虑上传统功能测试的岗位需求在肉眼可见地收缩招聘JD里开始频繁出现熟悉大模型有AI测试经验优先了解Agent这类字眼。有人觉得这是炒作有人已经开始动手了。我的判断很直接——这不是一波短期风口而是测试这个工种的能力模型正在被重写。先把话说清楚AI测试开发不是让你去训练大模型也不是让你转行做算法工程师。它的核心是两件事。第一件用AI能力去增强你原本的测试工作比如用大模型帮你读需求、生成用例、生成UI自动化脚本、做缺陷归因。第二件测试AI系统本身比如大模型的输出质量怎么评估、Agent的行为怎么验证、多模态应用的边界怎么测。前者是AI赋能测试后者是测试AI两条路都缺人但入门门槛和技能栈不一样。我见过太多测试同学卡在第一步知道要学但不知道从哪下手。买了几门课看了几篇讲Prompt的文章装了个本地大模型跑了两天然后就没有然后了。问题出在哪出在没有一个能落地的项目把零散的知识串起来。你学Prompt工程学LangChain学Playwright单独看都会但让你做一个读取测试用例自动生成UI自动化脚本的Agent就懵了。而这恰恰是现在企业最需要的能力。这篇内容我想干的事就是把测试人转型AI测试开发这件事拆开揉碎从能力地图、核心技术点、一个完整的Agent实战项目、到学习路径和避坑经验全部讲透。不管你是刚入行一两年的功能测试还是做了五六年想突破瓶颈的测试开发都能从中找到自己能立刻上手的那一块。关键词里提到的人工智能、AI测试开发、测试开发、大模型、Agent我会一个一个落到具体的技术细节和操作上不讲空话。2. 转型前必须想清楚的能力地图2.1 传统测试开发和AI测试开发的技能差异很多人以为转型就是多学一个AI其实不是加法是能力重心的迁移。我整理了一张对照表你可以对着看看自己现在站在哪个位置。能力维度传统测试开发AI测试开发核心产出自动化脚本、测试框架、CI集成AI增强的测试工具链、AI系统评测方案主要工具Selenium、Appium、Pytest、JenkinsLangChain、Playwright、大模型API、向量库编程重心面向对象、设计模式、框架封装Prompt编排、Agent流程设计、数据处理测试对象确定性系统输入A必得B概率性系统同样输入输出可能不同验证方式断言相等/包含语义相似度、评分模型、人工抽检典型难点元素定位、环境稳定性输出不确定性、幻觉、评测标准设计看这张表你会发现传统测试开发的底子不但不浪费反而是优势。你懂测试用例设计、懂边界值、懂等价类这些在给AI系统设计评测集的时候直接就能用。你懂Pytest、懂断言、懂CI这些在搭建AI测试流水线的时候也是现成的。真正要补的是概率性系统的思维方式以及大模型和Agent这套工具链。2.2 三类转型路径选错方向白费半年我观察下来测试人转AI测试开发大概有三条路难度和天花板都不一样。第一条AI增强测试工具方向。就是用大模型和Agent去提升测试效率。典型场景根据需求文档自动生成测试用例、根据用例自动生成UI自动化脚本、失败用例自动归因、测试报告自动总结。这条路对算法要求最低对工程能力要求中等最适合大多数测试开发同学切入。你不需要懂反向传播但你要懂怎么调API、怎么设计Prompt、怎么把Agent串进现有流程。第二条AI系统质量保障方向。就是专门测大模型应用、测Agent、测多模态系统。你要设计评测集、定义评测指标准确率、召回、幻觉率、拒答率、搭建自动化评测流水线。这条路需要对大模型的特性有比较深的理解知道它为什么会幻觉、什么情况下会不稳定。天花板高但目前岗位相对少多集中在有大模型业务的公司。第三条算法方向。微调模型、训练评测模型。这条路对数学和算法要求最高坦白说从测试转过去的人比例很低投入产出比要慎重评估。除非你本身有比较强的算法背景否则我不建议把主要精力放这。我的建议是主攻第一条了解第二条第三条看兴趣。第一条路能让你在半年内就有可展示的项目面试的时候拿得出手而且和现有工作能结合边做边学。2.3 别被大模型三个字吓住你需要的只是会用这里必须破除一个误解。很多测试同学一听大模型就觉得是算法工程师的领域自己碰不了。实际上应用层开发和模型层开发是两回事。你不需要知道Transformer的注意力机制怎么算你只需要知道怎么调用API、怎么控制输出格式、怎么处理它不听话的情况。打个比方你用数据库的时候需要懂B树的实现吗不需要。你只需要会写SQL、会看执行计划、会优化索引。大模型也一样应用层的人只需要会用把模型当成一个能力很强但不太稳定的组件来对待。这个心态转变过来你会发现门槛一下子低了很多。具体到技能应用层你需要掌握的是Prompt的基本写法角色、任务、约束、示例、结构化输出让它返回JSON、函数调用Function Calling、以及用LangChain这类框架把多个步骤串起来。这些内容一个有编程基础的测试开发认真投入两三个月就能上手做项目。3. 大模型与Agent测试人真正要掌握的技术点3.1 大模型在测试场景里的四种用法大模型不是万能的它在测试场景里有明确的适用边界。我把它归纳成四种用法从简单到复杂。第一种文本生成。最典型的就是根据需求生成测试用例。你把需求描述丢给它让它按给定格式输出用例。这个用法门槛最低但要注意生成的用例质量参差不齐必须有人工审核环节不能直接入库。第二种文本理解与转换。比如把自然语言的测试步骤转换成结构化的操作指令或者把一段报错日志翻译成人能看懂的缺陷描述。这个用法的价值在于翻译把非结构化变成结构化。第三种代码生成。这是测试人最关心的——根据测试用例生成UI自动化脚本。比如给它一条登录页面输入用户名密码点击登录验证跳转到首页的用例让它输出Playwright的Python代码。这个用法对Prompt的要求比较高需要给它足够的上下文页面元素定位方式、框架版本、代码规范。第四种作为Agent的决策核心。这是最复杂的大模型不再只是生成内容而是决定下一步做什么。比如一个测试Agent它要自己判断当前页面加载完了吗该点哪个元素断言失败了要不要重试这些决策都由大模型来做。四种用法难度递增价值也递增。转型初期建议从第一种和第三种切入因为它们最容易出成果也最容易和现有工作结合。3.2 Agent到底是什么和普通脚本的本质区别关键词里反复出现Agent很多人对这个词的理解是模糊的。我用一句话说清楚普通脚本是你告诉它每一步怎么做Agent是你告诉它目标它自己决定怎么做。举个具体例子。传统UI自动化你得写清楚打开浏览器、访问URL、等待元素、点击、输入、再点击、断言。每一步都是你写死的。而一个测试Agent你给它的是验证登录功能是否正常这个目标它自己去规划先打开页面看看有没有登录入口有就点进去输入测试数据提交检查结果。中间遇到弹窗它会自己判断要不要关掉。这个区别的本质在于决策权的转移。传统脚本的决策权在你手里Agent的决策权在模型手里。这就带来一个新问题模型会决策错。所以Agent开发的核心工作其实是设计好它的能力边界和纠错机制让它在该自主的时候自主该受约束的时候受约束。一个Agent通常由四部分组成规划Planning、记忆Memory、工具Tools、执行Action。规划是拆解任务记忆是保存上下文工具是它能调用的外部能力比如打开浏览器、读文件、查数据库执行是真正动手。LangChain这类框架帮你把这四部分搭起来但怎么设计得好用还是靠人。3.3 LangChain在测试Agent里的角色定位LangChain经常被吐槽抽象太重版本变化快但它在快速搭建原型阶段确实省事。对于测试人来说它的价值主要在三个地方。第一统一了模型调用接口。你写一套代码换个模型只改配置不用重写逻辑。这在测试不同模型效果的时候特别有用。第二提供了工具调用的标准封装。你想让Agent能读文件、能执行代码、能调APILangChain有现成的Tool抽象你只要按格式包一下就行。第三提供了链式编排能力。一个复杂任务拆成多个步骤每个步骤一个Chain串起来跑。比如读用例→生成脚本→校验语法→保存文件就是一条链。但我也要提醒LangChain不是必须的。如果你的Agent逻辑很简单直接用模型的原生API加几十行代码可能更清爽。我见过不少人为了用框架而用框架结果调试的时候被框架的黑盒行为坑得很惨。选型的原则是先用最朴素的方案跑通遇到重复劳动再考虑上框架。3.4 Playwright为什么成了UI自动化的新宠关键词里出现了使用playw指的应该是Playwright。这几年它在UI自动化领域的势头确实很猛我自己的项目也基本从Selenium迁过来了。原因有几个。自动等待机制。Selenium最让人头疼的就是元素还没加载出来就去点报一堆NoSuchElement。Playwright内置了智能等待大部分情况下你不用手写sleep和显式等待它会自动等到元素可交互。这一条就省了大量调试时间。多浏览器统一API。Chromium、Firefox、WebKit一套代码通吃而且启动快。强大的选择器。它支持文本选择器、角色选择器比如get_by_role(button, name登录)这种写法比XPath可读性好太多也更稳定。对AI生成友好。这一点很关键。大模型生成Playwright代码的准确率普遍比生成Selenium代码高因为Playwright的API更语义化、更一致。你让模型生成page.get_by_label(用户名).fill(test)它不容易出错让它生成Selenium那一堆find_element(By.XPATH, ...)定位策略就容易写歪。所以做用例生成UI脚本这个AgentPlaywright是比Selenium更合适的输出目标。这不是跟风是实测下来的准确率差异。4. 一个能写进简历的实战项目用例自动生成UI脚本Agent4.1 项目目标与技术选型这个项目的目标很明确输入一条自然语言写的测试用例输出一段可运行的Playwright Python脚本。听起来简单但要做好中间有不少坑。技术选型我建议这样模型层用支持函数调用的大模型API。国内国外的都行选一个你稳定能调通的。如果预算有限用免费额度或者本地部署的小模型也能跑通流程只是生成质量会打折扣。编排层初期直接用原生API加Python跑通后再考虑LangChain。输出层Playwright Pytest生成的是标准的测试函数。辅助层一个页面元素信息的采集工具把目标页面的可交互元素抓下来作为上下文喂给模型。为什么要把页面元素信息喂给模型因为模型不知道你的页面长什么样。你不给它元素信息它只能瞎猜定位方式生成的脚本大概率跑不起来。这是这个项目最容易被忽略、也最关键的一步。4.2 第一步把测试用例结构化自然语言的用例模型直接读也能读但结构化之后效果稳定得多。我一般把用例整理成这样的JSON{ case_id: LOGIN_001, title: 正常登录, precondition: 已打开登录页面, steps: [ {action: 输入, target: 用户名输入框, value: testuser}, {action: 输入, target: 密码输入框, value: Passw0rd}, {action: 点击, target: 登录按钮} ], expected: 页面跳转到首页显示欢迎信息 }为什么要这么拆因为步骤里的action、target、value是模型生成代码的直接依据。你给它结构化的输入它输出的代码结构也更规整。这一步可以用另一个模型调用来完成——把原始用例文本丢给模型让它输出这个JSON格式。这就是一个典型的链先结构化再生成代码。4.3 第二步采集页面元素作为上下文这一步是整个项目的技术核心。你需要写一个小工具用Playwright打开目标页面把所有可交互元素的信息抓出来。抓什么我一般抓这几项元素的角色rolebutton、textbox、link等可访问名称accessible name通常是按钮上的文字、输入框的label元素类型tag可能的定位属性id、name、placeholder、data-testid抓完之后整理成一个列表作为上下文塞进Prompt。这样模型在生成get_by_role(button, name登录)的时候是有依据的不是猜的。from playwright.sync_api import sync_playwright def collect_elements(url): elements [] with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url) page.wait_for_load_state(networkidle) # 抓取所有可交互元素 handles page.query_selector_all( button, input, a, select, textarea, [role] ) for h in handles: info { tag: h.evaluate(el el.tagName.toLowerCase()), role: h.get_attribute(role), text: (h.inner_text() or ).strip()[:30], id: h.get_attribute(id), name: h.get_attribute(name), placeholder: h.get_attribute(placeholder), testid: h.get_attribute(data-testid), } elements.append(info) browser.close() return elements这段代码不复杂但它是整个Agent看得见页面的眼睛。没有它模型就是闭着眼睛写代码。4.4 第三步设计生成脚本的PromptPrompt设计是这个项目的灵魂。我踩过的坑是一开始写得太随意模型生成的代码风格五花八门有的用XPath有的用CSS有的还自己造API。后来我把Prompt固定成几个部分效果稳定多了。角色设定你是一个资深的Playwright自动化测试工程师。任务描述根据给定的测试用例和页面元素信息生成一个Pytest测试函数。硬性约束这部分最重要只使用Playwright的同步API优先使用get_by_role、get_by_label、get_by_placeholder等语义化定位禁止使用time.sleep用Playwright的自动等待断言使用expect不要用裸assert函数名格式为test_加用例ID小写输出格式只输出Python代码不要任何解释文字不要Markdown代码块标记。示例给一个输入输出的完整例子。把这几块拼起来模型生成的代码质量会有一个明显的跃升。示例Few-shot这一块千万别省它比你说十句约束都管用。4.5 第四步生成结果的校验与自动修复模型生成的代码第一次跑不通是常态。所以这个Agent必须有一个校验和修复环节否则它只是个玩具。校验分两层。第一层是语法校验用ast.parse或者直接python -m py_compile检查语法语法都不对的直接打回重生成。第二层是运行校验真正跑一遍看能不能通过。跑不通怎么办把报错信息收集起来连同原始代码一起再丢给模型让它修复。这就是一个典型的自我修复循环def generate_with_retry(case, elements, max_retry3): code generate_code(case, elements) for i in range(max_retry): ok, error run_and_check(code) if ok: return code code fix_code(code, error) return code # 返回最后一次结果标记为需人工介入这里有个经验重试次数不要太多2到3次足够。超过3次还修不好说明要么用例本身有问题要么页面元素信息不全继续重试只是浪费token。这时候应该把这条用例标记出来转人工处理。4.6 实测效果与准确率数据我在一个中等复杂度的后台管理系统上跑过这个Agent测试集是50条登录、查询、增删改类的用例。第一版生成的结果语法通过率大概85%一次运行通过率大概55%。加上自动修复循环最多3次之后最终通过率能到78%左右。剩下22%需要人工介入主要是复杂交互拖拽、文件上传、iframe嵌套和动态元素。这个数据说明什么说明它不能完全替代人但能干掉大部分重复劳动。原来写50条脚本可能要一整天现在生成加修复加人工处理半天能搞定而且生成的代码风格统一维护起来也省心。对于企业来说这个效率提升是实打实的。我还要强调一点准确率高度依赖页面元素信息的质量。如果页面用了大量动态生成的class、没有语义化的role和label那模型也巧妇难为无米之炊。这时候要么推动前端加testid要么在采集环节做更多处理。测试左移从推动可测性开始这句话在AI测试时代依然成立。5. 学习路径从观望到能上手需要多久5.1 分阶段的学习节奏我给一个相对务实的节奏假设你每天能投入1到2小时。第1到2周打基础。把Python的异步、装饰器、类型注解过一遍如果还不熟。同时把Playwright官方文档的入门部分跑一遍能写出基本的页面操作脚本。这个阶段不要碰大模型先把自动化底子夯实。第3到4周大模型应用入门。学会调用大模型API理解Prompt的基本结构能写出稳定的结构化输出。这个阶段的产出是一个能根据需求文本生成测试用例的小工具。第5到8周Agent项目实战。就是上面那个用例生成UI脚本的项目。从最简单的单步生成开始逐步加上元素采集、校验、修复。这个阶段会遇到大量调试是成长最快的时候。第9到12周工程化与扩展。把项目接入CI加上报告处理并发考虑怎么和现有的测试平台集成。同时开始了解AI系统评测的知识为第二条路径做准备。三个月能做出一个拿得出手的项目面试的时候能讲清楚技术选型和踩坑过程。这个投入产出比我觉得是划算的。5.2 每个阶段该产出什么学习最怕的就是学了很多但说不出做了什么。所以每个阶段都要有可展示的产出。阶段产出物能证明什么基础期一个完整的Playwright测试脚本集自动化基本功入门期需求转用例的小工具大模型应用能力实战期用例转UI脚本的Agent综合工程能力工程期接入CI的完整流水线落地能力面试的时候你把实战期那个Agent拿出来讲清楚为什么这么设计、遇到什么问题、怎么解决的比你说一百句我学过LangChain都有用。项目是最好的简历。5.3 免费资源和付费课程怎么选资源这块我给点实在的建议。官方文档永远是最好的老师Playwright和LangChain的文档质量都很高遇到问题先查文档。大模型的能力边界和Prompt技巧看各家模型的官方指南比看二手文章靠谱。付费课程的价值在于帮你省时间、给你一个结构。如果你自律性强、能自己啃文档完全可以自学。如果你容易半途而废、需要有人带着走那选一个有完整项目实战、有老师答疑的课程是值得的。但选课的时候要擦亮眼睛看它有没有真实项目看它讲不讲踩坑看它是不是只讲概念不讲代码。只讲大模型原理Agent概念这种课的对转型帮助有限。我个人的经验是课程负责给你地图走路还得靠自己。再好的课你不敲代码、不做项目也变不成自己的能力。6. 转型路上最容易踩的几个坑6.1 只学概念不动手学完还是不会这是最普遍的问题。看了很多讲Agent架构、讲Prompt技巧的文章笔记记了一堆但从来没完整跑通过一个项目。结果就是面试的时候能说出名词一问细节就露馅。破解方法很简单从最小的项目开始动手。不要一上来就搞复杂的多Agent协作先做一个调用API生成一段文本的脚本跑通。再加一个功能再跑通。每一步都要有能运行的东西哪怕很简陋。跑通十个简单脚本比看懂十篇架构文章有用得多。6.2 盲目追新框架基础反而荒废AI领域新框架层出不穷今天LangChain明天又出个什么。有人就跟着追每个都学一点每个都不精。更糟的是追框架的过程中把Python基础、测试设计这些根本的东西荒废了。我的态度是框架是工具基础是内功。LangChain会过时但你对测试用例设计的理解、对自动化稳定性的把控、对代码质量的要求这些不会过时。选一个主流框架深入用透比浅尝辄止地追新强。而且很多框架的核心思想是相通的你把一个用明白了换另一个上手很快。6.3 忽视测试思维把AI测试做成调API有些同学转型之后满脑子都是怎么调模型、怎么优化Prompt反而把测试人最核心的东西丢了——测试思维。什么是测试思维就是知道一个系统可能在哪里出问题知道怎么设计用例去覆盖这些风险点。测AI系统尤其需要这个。大模型的输出是不确定的你怎么设计评测集才能覆盖它的能力边界怎么区分是模型能力问题还是Prompt问题怎么定义通过这些问题靠调API是解决不了的得靠测试思维。AI测试开发测试是根AI是叶。根扎得深叶才茂盛。6.4 期望速成两周没成果就放弃最后一个坑也是最要命的期望速成。有人觉得AI这么火学两周就能拿高薪。现实是转型是一个以月为单位的过程中间会有大量调试失败、看不懂报错、怀疑自己的时刻。我的建议是把目标拆小给自己正反馈。不要盯着成为AI测试专家这个大目标而是盯着这周跑通一个生成用例的脚本下周让Agent能生成一段能跑的代码。每完成一个小目标就离终点近一步。这个过程里坚持比聪明重要。7. 关于要不要现在入场这件事回到标题里那句话——这一次别再观望。我理解观望的心态毕竟前几年各种风口让不少人交了学费。但AI测试开发这个方向和那些纯概念的风口不太一样它有实实在在的落地场景和岗位需求。判断一个方向值不值得投入我一般看三点有没有真实的企业需求、有没有可复用的技能沉淀、有没有持续演进的生态。AI测试开发这三点都占。企业确实在招这样的人你学的Prompt工程、Agent开发、Playwright这些技能换个项目照样能用而且整个生态还在快速迭代不会学完就废。当然我不是说所有人都必须转。如果你现在的工作很稳定、你也享受当下的状态那没必要焦虑。但如果你已经感受到了岗位需求的变化或者想给自己多一条路那现在动手比再观望半年要强。技术这件事永远是先动手的人吃到红利。我自己的体会是转型过程中最难的不是技术本身而是迈出第一步和坚持下去。技术可以学项目可以做但如果你一直停在了解的层面那再多的信息也变不成能力。找一个能跑通的小项目今天就动手比什么都强。
测试人转型AI测试开发：从大模型到Agent实战，3个月拿得出手的项目
1. 测试人转型AI测试开发到底在转什么这两年跟不少做测试的朋友聊天话题绕来绕去最后都会落到同一个焦虑上传统功能测试的岗位需求在肉眼可见地收缩招聘JD里开始频繁出现熟悉大模型有AI测试经验优先了解Agent这类字眼。有人觉得这是炒作有人已经开始动手了。我的判断很直接——这不是一波短期风口而是测试这个工种的能力模型正在被重写。先把话说清楚AI测试开发不是让你去训练大模型也不是让你转行做算法工程师。它的核心是两件事。第一件用AI能力去增强你原本的测试工作比如用大模型帮你读需求、生成用例、生成UI自动化脚本、做缺陷归因。第二件测试AI系统本身比如大模型的输出质量怎么评估、Agent的行为怎么验证、多模态应用的边界怎么测。前者是AI赋能测试后者是测试AI两条路都缺人但入门门槛和技能栈不一样。我见过太多测试同学卡在第一步知道要学但不知道从哪下手。买了几门课看了几篇讲Prompt的文章装了个本地大模型跑了两天然后就没有然后了。问题出在哪出在没有一个能落地的项目把零散的知识串起来。你学Prompt工程学LangChain学Playwright单独看都会但让你做一个读取测试用例自动生成UI自动化脚本的Agent就懵了。而这恰恰是现在企业最需要的能力。这篇内容我想干的事就是把测试人转型AI测试开发这件事拆开揉碎从能力地图、核心技术点、一个完整的Agent实战项目、到学习路径和避坑经验全部讲透。不管你是刚入行一两年的功能测试还是做了五六年想突破瓶颈的测试开发都能从中找到自己能立刻上手的那一块。关键词里提到的人工智能、AI测试开发、测试开发、大模型、Agent我会一个一个落到具体的技术细节和操作上不讲空话。2. 转型前必须想清楚的能力地图2.1 传统测试开发和AI测试开发的技能差异很多人以为转型就是多学一个AI其实不是加法是能力重心的迁移。我整理了一张对照表你可以对着看看自己现在站在哪个位置。能力维度传统测试开发AI测试开发核心产出自动化脚本、测试框架、CI集成AI增强的测试工具链、AI系统评测方案主要工具Selenium、Appium、Pytest、JenkinsLangChain、Playwright、大模型API、向量库编程重心面向对象、设计模式、框架封装Prompt编排、Agent流程设计、数据处理测试对象确定性系统输入A必得B概率性系统同样输入输出可能不同验证方式断言相等/包含语义相似度、评分模型、人工抽检典型难点元素定位、环境稳定性输出不确定性、幻觉、评测标准设计看这张表你会发现传统测试开发的底子不但不浪费反而是优势。你懂测试用例设计、懂边界值、懂等价类这些在给AI系统设计评测集的时候直接就能用。你懂Pytest、懂断言、懂CI这些在搭建AI测试流水线的时候也是现成的。真正要补的是概率性系统的思维方式以及大模型和Agent这套工具链。2.2 三类转型路径选错方向白费半年我观察下来测试人转AI测试开发大概有三条路难度和天花板都不一样。第一条AI增强测试工具方向。就是用大模型和Agent去提升测试效率。典型场景根据需求文档自动生成测试用例、根据用例自动生成UI自动化脚本、失败用例自动归因、测试报告自动总结。这条路对算法要求最低对工程能力要求中等最适合大多数测试开发同学切入。你不需要懂反向传播但你要懂怎么调API、怎么设计Prompt、怎么把Agent串进现有流程。第二条AI系统质量保障方向。就是专门测大模型应用、测Agent、测多模态系统。你要设计评测集、定义评测指标准确率、召回、幻觉率、拒答率、搭建自动化评测流水线。这条路需要对大模型的特性有比较深的理解知道它为什么会幻觉、什么情况下会不稳定。天花板高但目前岗位相对少多集中在有大模型业务的公司。第三条算法方向。微调模型、训练评测模型。这条路对数学和算法要求最高坦白说从测试转过去的人比例很低投入产出比要慎重评估。除非你本身有比较强的算法背景否则我不建议把主要精力放这。我的建议是主攻第一条了解第二条第三条看兴趣。第一条路能让你在半年内就有可展示的项目面试的时候拿得出手而且和现有工作能结合边做边学。2.3 别被大模型三个字吓住你需要的只是会用这里必须破除一个误解。很多测试同学一听大模型就觉得是算法工程师的领域自己碰不了。实际上应用层开发和模型层开发是两回事。你不需要知道Transformer的注意力机制怎么算你只需要知道怎么调用API、怎么控制输出格式、怎么处理它不听话的情况。打个比方你用数据库的时候需要懂B树的实现吗不需要。你只需要会写SQL、会看执行计划、会优化索引。大模型也一样应用层的人只需要会用把模型当成一个能力很强但不太稳定的组件来对待。这个心态转变过来你会发现门槛一下子低了很多。具体到技能应用层你需要掌握的是Prompt的基本写法角色、任务、约束、示例、结构化输出让它返回JSON、函数调用Function Calling、以及用LangChain这类框架把多个步骤串起来。这些内容一个有编程基础的测试开发认真投入两三个月就能上手做项目。3. 大模型与Agent测试人真正要掌握的技术点3.1 大模型在测试场景里的四种用法大模型不是万能的它在测试场景里有明确的适用边界。我把它归纳成四种用法从简单到复杂。第一种文本生成。最典型的就是根据需求生成测试用例。你把需求描述丢给它让它按给定格式输出用例。这个用法门槛最低但要注意生成的用例质量参差不齐必须有人工审核环节不能直接入库。第二种文本理解与转换。比如把自然语言的测试步骤转换成结构化的操作指令或者把一段报错日志翻译成人能看懂的缺陷描述。这个用法的价值在于翻译把非结构化变成结构化。第三种代码生成。这是测试人最关心的——根据测试用例生成UI自动化脚本。比如给它一条登录页面输入用户名密码点击登录验证跳转到首页的用例让它输出Playwright的Python代码。这个用法对Prompt的要求比较高需要给它足够的上下文页面元素定位方式、框架版本、代码规范。第四种作为Agent的决策核心。这是最复杂的大模型不再只是生成内容而是决定下一步做什么。比如一个测试Agent它要自己判断当前页面加载完了吗该点哪个元素断言失败了要不要重试这些决策都由大模型来做。四种用法难度递增价值也递增。转型初期建议从第一种和第三种切入因为它们最容易出成果也最容易和现有工作结合。3.2 Agent到底是什么和普通脚本的本质区别关键词里反复出现Agent很多人对这个词的理解是模糊的。我用一句话说清楚普通脚本是你告诉它每一步怎么做Agent是你告诉它目标它自己决定怎么做。举个具体例子。传统UI自动化你得写清楚打开浏览器、访问URL、等待元素、点击、输入、再点击、断言。每一步都是你写死的。而一个测试Agent你给它的是验证登录功能是否正常这个目标它自己去规划先打开页面看看有没有登录入口有就点进去输入测试数据提交检查结果。中间遇到弹窗它会自己判断要不要关掉。这个区别的本质在于决策权的转移。传统脚本的决策权在你手里Agent的决策权在模型手里。这就带来一个新问题模型会决策错。所以Agent开发的核心工作其实是设计好它的能力边界和纠错机制让它在该自主的时候自主该受约束的时候受约束。一个Agent通常由四部分组成规划Planning、记忆Memory、工具Tools、执行Action。规划是拆解任务记忆是保存上下文工具是它能调用的外部能力比如打开浏览器、读文件、查数据库执行是真正动手。LangChain这类框架帮你把这四部分搭起来但怎么设计得好用还是靠人。3.3 LangChain在测试Agent里的角色定位LangChain经常被吐槽抽象太重版本变化快但它在快速搭建原型阶段确实省事。对于测试人来说它的价值主要在三个地方。第一统一了模型调用接口。你写一套代码换个模型只改配置不用重写逻辑。这在测试不同模型效果的时候特别有用。第二提供了工具调用的标准封装。你想让Agent能读文件、能执行代码、能调APILangChain有现成的Tool抽象你只要按格式包一下就行。第三提供了链式编排能力。一个复杂任务拆成多个步骤每个步骤一个Chain串起来跑。比如读用例→生成脚本→校验语法→保存文件就是一条链。但我也要提醒LangChain不是必须的。如果你的Agent逻辑很简单直接用模型的原生API加几十行代码可能更清爽。我见过不少人为了用框架而用框架结果调试的时候被框架的黑盒行为坑得很惨。选型的原则是先用最朴素的方案跑通遇到重复劳动再考虑上框架。3.4 Playwright为什么成了UI自动化的新宠关键词里出现了使用playw指的应该是Playwright。这几年它在UI自动化领域的势头确实很猛我自己的项目也基本从Selenium迁过来了。原因有几个。自动等待机制。Selenium最让人头疼的就是元素还没加载出来就去点报一堆NoSuchElement。Playwright内置了智能等待大部分情况下你不用手写sleep和显式等待它会自动等到元素可交互。这一条就省了大量调试时间。多浏览器统一API。Chromium、Firefox、WebKit一套代码通吃而且启动快。强大的选择器。它支持文本选择器、角色选择器比如get_by_role(button, name登录)这种写法比XPath可读性好太多也更稳定。对AI生成友好。这一点很关键。大模型生成Playwright代码的准确率普遍比生成Selenium代码高因为Playwright的API更语义化、更一致。你让模型生成page.get_by_label(用户名).fill(test)它不容易出错让它生成Selenium那一堆find_element(By.XPATH, ...)定位策略就容易写歪。所以做用例生成UI脚本这个AgentPlaywright是比Selenium更合适的输出目标。这不是跟风是实测下来的准确率差异。4. 一个能写进简历的实战项目用例自动生成UI脚本Agent4.1 项目目标与技术选型这个项目的目标很明确输入一条自然语言写的测试用例输出一段可运行的Playwright Python脚本。听起来简单但要做好中间有不少坑。技术选型我建议这样模型层用支持函数调用的大模型API。国内国外的都行选一个你稳定能调通的。如果预算有限用免费额度或者本地部署的小模型也能跑通流程只是生成质量会打折扣。编排层初期直接用原生API加Python跑通后再考虑LangChain。输出层Playwright Pytest生成的是标准的测试函数。辅助层一个页面元素信息的采集工具把目标页面的可交互元素抓下来作为上下文喂给模型。为什么要把页面元素信息喂给模型因为模型不知道你的页面长什么样。你不给它元素信息它只能瞎猜定位方式生成的脚本大概率跑不起来。这是这个项目最容易被忽略、也最关键的一步。4.2 第一步把测试用例结构化自然语言的用例模型直接读也能读但结构化之后效果稳定得多。我一般把用例整理成这样的JSON{ case_id: LOGIN_001, title: 正常登录, precondition: 已打开登录页面, steps: [ {action: 输入, target: 用户名输入框, value: testuser}, {action: 输入, target: 密码输入框, value: Passw0rd}, {action: 点击, target: 登录按钮} ], expected: 页面跳转到首页显示欢迎信息 }为什么要这么拆因为步骤里的action、target、value是模型生成代码的直接依据。你给它结构化的输入它输出的代码结构也更规整。这一步可以用另一个模型调用来完成——把原始用例文本丢给模型让它输出这个JSON格式。这就是一个典型的链先结构化再生成代码。4.3 第二步采集页面元素作为上下文这一步是整个项目的技术核心。你需要写一个小工具用Playwright打开目标页面把所有可交互元素的信息抓出来。抓什么我一般抓这几项元素的角色rolebutton、textbox、link等可访问名称accessible name通常是按钮上的文字、输入框的label元素类型tag可能的定位属性id、name、placeholder、data-testid抓完之后整理成一个列表作为上下文塞进Prompt。这样模型在生成get_by_role(button, name登录)的时候是有依据的不是猜的。from playwright.sync_api import sync_playwright def collect_elements(url): elements [] with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url) page.wait_for_load_state(networkidle) # 抓取所有可交互元素 handles page.query_selector_all( button, input, a, select, textarea, [role] ) for h in handles: info { tag: h.evaluate(el el.tagName.toLowerCase()), role: h.get_attribute(role), text: (h.inner_text() or ).strip()[:30], id: h.get_attribute(id), name: h.get_attribute(name), placeholder: h.get_attribute(placeholder), testid: h.get_attribute(data-testid), } elements.append(info) browser.close() return elements这段代码不复杂但它是整个Agent看得见页面的眼睛。没有它模型就是闭着眼睛写代码。4.4 第三步设计生成脚本的PromptPrompt设计是这个项目的灵魂。我踩过的坑是一开始写得太随意模型生成的代码风格五花八门有的用XPath有的用CSS有的还自己造API。后来我把Prompt固定成几个部分效果稳定多了。角色设定你是一个资深的Playwright自动化测试工程师。任务描述根据给定的测试用例和页面元素信息生成一个Pytest测试函数。硬性约束这部分最重要只使用Playwright的同步API优先使用get_by_role、get_by_label、get_by_placeholder等语义化定位禁止使用time.sleep用Playwright的自动等待断言使用expect不要用裸assert函数名格式为test_加用例ID小写输出格式只输出Python代码不要任何解释文字不要Markdown代码块标记。示例给一个输入输出的完整例子。把这几块拼起来模型生成的代码质量会有一个明显的跃升。示例Few-shot这一块千万别省它比你说十句约束都管用。4.5 第四步生成结果的校验与自动修复模型生成的代码第一次跑不通是常态。所以这个Agent必须有一个校验和修复环节否则它只是个玩具。校验分两层。第一层是语法校验用ast.parse或者直接python -m py_compile检查语法语法都不对的直接打回重生成。第二层是运行校验真正跑一遍看能不能通过。跑不通怎么办把报错信息收集起来连同原始代码一起再丢给模型让它修复。这就是一个典型的自我修复循环def generate_with_retry(case, elements, max_retry3): code generate_code(case, elements) for i in range(max_retry): ok, error run_and_check(code) if ok: return code code fix_code(code, error) return code # 返回最后一次结果标记为需人工介入这里有个经验重试次数不要太多2到3次足够。超过3次还修不好说明要么用例本身有问题要么页面元素信息不全继续重试只是浪费token。这时候应该把这条用例标记出来转人工处理。4.6 实测效果与准确率数据我在一个中等复杂度的后台管理系统上跑过这个Agent测试集是50条登录、查询、增删改类的用例。第一版生成的结果语法通过率大概85%一次运行通过率大概55%。加上自动修复循环最多3次之后最终通过率能到78%左右。剩下22%需要人工介入主要是复杂交互拖拽、文件上传、iframe嵌套和动态元素。这个数据说明什么说明它不能完全替代人但能干掉大部分重复劳动。原来写50条脚本可能要一整天现在生成加修复加人工处理半天能搞定而且生成的代码风格统一维护起来也省心。对于企业来说这个效率提升是实打实的。我还要强调一点准确率高度依赖页面元素信息的质量。如果页面用了大量动态生成的class、没有语义化的role和label那模型也巧妇难为无米之炊。这时候要么推动前端加testid要么在采集环节做更多处理。测试左移从推动可测性开始这句话在AI测试时代依然成立。5. 学习路径从观望到能上手需要多久5.1 分阶段的学习节奏我给一个相对务实的节奏假设你每天能投入1到2小时。第1到2周打基础。把Python的异步、装饰器、类型注解过一遍如果还不熟。同时把Playwright官方文档的入门部分跑一遍能写出基本的页面操作脚本。这个阶段不要碰大模型先把自动化底子夯实。第3到4周大模型应用入门。学会调用大模型API理解Prompt的基本结构能写出稳定的结构化输出。这个阶段的产出是一个能根据需求文本生成测试用例的小工具。第5到8周Agent项目实战。就是上面那个用例生成UI脚本的项目。从最简单的单步生成开始逐步加上元素采集、校验、修复。这个阶段会遇到大量调试是成长最快的时候。第9到12周工程化与扩展。把项目接入CI加上报告处理并发考虑怎么和现有的测试平台集成。同时开始了解AI系统评测的知识为第二条路径做准备。三个月能做出一个拿得出手的项目面试的时候能讲清楚技术选型和踩坑过程。这个投入产出比我觉得是划算的。5.2 每个阶段该产出什么学习最怕的就是学了很多但说不出做了什么。所以每个阶段都要有可展示的产出。阶段产出物能证明什么基础期一个完整的Playwright测试脚本集自动化基本功入门期需求转用例的小工具大模型应用能力实战期用例转UI脚本的Agent综合工程能力工程期接入CI的完整流水线落地能力面试的时候你把实战期那个Agent拿出来讲清楚为什么这么设计、遇到什么问题、怎么解决的比你说一百句我学过LangChain都有用。项目是最好的简历。5.3 免费资源和付费课程怎么选资源这块我给点实在的建议。官方文档永远是最好的老师Playwright和LangChain的文档质量都很高遇到问题先查文档。大模型的能力边界和Prompt技巧看各家模型的官方指南比看二手文章靠谱。付费课程的价值在于帮你省时间、给你一个结构。如果你自律性强、能自己啃文档完全可以自学。如果你容易半途而废、需要有人带着走那选一个有完整项目实战、有老师答疑的课程是值得的。但选课的时候要擦亮眼睛看它有没有真实项目看它讲不讲踩坑看它是不是只讲概念不讲代码。只讲大模型原理Agent概念这种课的对转型帮助有限。我个人的经验是课程负责给你地图走路还得靠自己。再好的课你不敲代码、不做项目也变不成自己的能力。6. 转型路上最容易踩的几个坑6.1 只学概念不动手学完还是不会这是最普遍的问题。看了很多讲Agent架构、讲Prompt技巧的文章笔记记了一堆但从来没完整跑通过一个项目。结果就是面试的时候能说出名词一问细节就露馅。破解方法很简单从最小的项目开始动手。不要一上来就搞复杂的多Agent协作先做一个调用API生成一段文本的脚本跑通。再加一个功能再跑通。每一步都要有能运行的东西哪怕很简陋。跑通十个简单脚本比看懂十篇架构文章有用得多。6.2 盲目追新框架基础反而荒废AI领域新框架层出不穷今天LangChain明天又出个什么。有人就跟着追每个都学一点每个都不精。更糟的是追框架的过程中把Python基础、测试设计这些根本的东西荒废了。我的态度是框架是工具基础是内功。LangChain会过时但你对测试用例设计的理解、对自动化稳定性的把控、对代码质量的要求这些不会过时。选一个主流框架深入用透比浅尝辄止地追新强。而且很多框架的核心思想是相通的你把一个用明白了换另一个上手很快。6.3 忽视测试思维把AI测试做成调API有些同学转型之后满脑子都是怎么调模型、怎么优化Prompt反而把测试人最核心的东西丢了——测试思维。什么是测试思维就是知道一个系统可能在哪里出问题知道怎么设计用例去覆盖这些风险点。测AI系统尤其需要这个。大模型的输出是不确定的你怎么设计评测集才能覆盖它的能力边界怎么区分是模型能力问题还是Prompt问题怎么定义通过这些问题靠调API是解决不了的得靠测试思维。AI测试开发测试是根AI是叶。根扎得深叶才茂盛。6.4 期望速成两周没成果就放弃最后一个坑也是最要命的期望速成。有人觉得AI这么火学两周就能拿高薪。现实是转型是一个以月为单位的过程中间会有大量调试失败、看不懂报错、怀疑自己的时刻。我的建议是把目标拆小给自己正反馈。不要盯着成为AI测试专家这个大目标而是盯着这周跑通一个生成用例的脚本下周让Agent能生成一段能跑的代码。每完成一个小目标就离终点近一步。这个过程里坚持比聪明重要。7. 关于要不要现在入场这件事回到标题里那句话——这一次别再观望。我理解观望的心态毕竟前几年各种风口让不少人交了学费。但AI测试开发这个方向和那些纯概念的风口不太一样它有实实在在的落地场景和岗位需求。判断一个方向值不值得投入我一般看三点有没有真实的企业需求、有没有可复用的技能沉淀、有没有持续演进的生态。AI测试开发这三点都占。企业确实在招这样的人你学的Prompt工程、Agent开发、Playwright这些技能换个项目照样能用而且整个生态还在快速迭代不会学完就废。当然我不是说所有人都必须转。如果你现在的工作很稳定、你也享受当下的状态那没必要焦虑。但如果你已经感受到了岗位需求的变化或者想给自己多一条路那现在动手比再观望半年要强。技术这件事永远是先动手的人吃到红利。我自己的体会是转型过程中最难的不是技术本身而是迈出第一步和坚持下去。技术可以学项目可以做但如果你一直停在了解的层面那再多的信息也变不成能力。找一个能跑通的小项目今天就动手比什么都强。
