今年AI和测试开发的讨论比过去五年的总和还要多。你打开任何一个技术社区都能看到AI会消灭测试岗和AI离不开测试人两种观点来回拉扯。我在测试行业干了十几年带过功能测试团队也做过测试开发基建看到大量测试同行卡在同一个问题上工具会用一点脚本能写一点但一提到AI就不知道从哪入手更不知道怎么把AI变成每天干活时真正用得上、能解决实际问题的能力。这篇内容我想直接围绕测试人转型AI测试开发来讲。先讲清楚行业环境为什么在这个时间点出现了真正的机会窗口再拆解AI测试开发需要用到的核心技术栈然后给出一个完整的实战案例——基于LangChain开发一个能读取测试用例、自动生成UI自动化脚本的Agent最后聊一聊从测试到AI测试开发的转型路线和学习规划。如果你是一名正在观望的测试人这篇内容就是写给你的。你不需要有很深的技术功底但需要愿意花点时间把思路理清楚。1. 测试人真正的机会窗口为什么是现在1.1 传统测试方法正在失效的三个场景先说一个我在项目里反复遇到的场景。以前做Web端UI自动化测试一个测试用例从编写到稳定运行大概需要经历写脚本-跑用例-修脚本-定时执行-维护脚本这么一套流程。最难的不是写脚本本身而是维护。前端稍微改个按钮位置选择器就失效加个登录态校验整个链路就要重新调。我曾经带过一个自动化测试项目光维护成本就占了整个团队60%的工作量。这也是很多测试团队说自动化测试是个笑话的原因——稳定不下来。到了AI时代这个问题不仅没有消失反而变得更复杂了。因为现在的软件系统已经不只是人机交互的页面还有大量由大模型驱动的AI原生应用。这类应用有几个让传统测试方法直接失效的特征第一输出不确定性。以前你测一个登录框输入正确账号密码点击登录系统返回用户名这是确定的。但现在测一个智能客服同一个问题在10次请求里可能长出9种不同的回答。你怎么断言怎么校验通过/失败第二测试用例的边界变模糊。以前一条用例有明确的预期结果现在AI应用的预期结果往往是是否符合业务目标这种模糊判断。比如你让AI助手生成一段营销文案它的用词、语气、结构每次都不一样但可能每次都符合需求。传统断言根本没法落到这种场景上。第三回归成本指数级上涨。前端迭代快、版本多加上AI Agent会自己调用工具、自己规划步骤一条核心业务链路的回归光靠人肉执行和传统脚本已经跑不动了。这些场景叠加在一起就产生了一个真实的供需缺口市场上缺的已经不是会写脚本的执行者而是能设计AI测试策略、能开发AI测试工具链、能让测试效率成倍提升的AI测试开发工程师。1.2 AI不是来替代测试的是来替代不懂AI的测试的很多测试同行一听到AI自动生成代码就焦虑觉得岗位要没了。但我在实际项目里的感受正好相反。大模型现在确实能写代码能自动补全用例能把一条自然语言描述的步骤变成脚本片段。但AI生成的脚本谁来校验用例与真实业务状态的偏差谁来发现失败之后谁来决定是改代码还是改需求自动生成的测试结论谁来做最终的业务判断这些任务懂业务、懂测试设计、能理解系统边界的人最合适。AI把你从重复劳动里解放出来剩下的高价值工作恰恰落到了会使用AI的测试人手里。这里我想澄清一个误区。很多人觉得AI测试开发很远好像必须得会训练模型、会调参、会分布式系统。其实完全不是。AI测试开发的核心是把大模型当作一个强大的能力组件去解决测试领域的具体问题。你懂测试用例设计懂业务逻辑懂缺陷规律你再学会怎么调用大模型、怎么用LangChain把流程编排起来、怎么用Playwright把脚本跑起来这四样拼在一起就已经松一个非常能打的AI测试开发工程师了。本质上它不是让你转行做算法而是让你在原有的测试功底上叠加一层AI工程能力。1.3 这个班想解决的问题和适合的人群我们的人工智能测试开发班要解决的就是上面说的这个转化问题——把具备测试思维的人锻造成能用AI工具链解决实际测试问题的开发型人才。课程设计的核心假设是测试人最大的资产不是写代码能力而是质量思维和业务理解力。我们要做的不是把你变成又一个Python工程师而是把你变成懂质量、懂业务、会AI工程化的测试开发工程师。这个班适合这几类人功能测试做了三五年想往测试开发方向转但一直没找到清晰路径的人。会写部分自动化脚本但感觉遇到了瓶颈想借助AI提升测试效率和工具链能力的人。对LangChain、Agent、Playwright这些技术有零散了解但没有系统实践过、不知道怎么落地到测试场景的人。如果你符合其中任何一类建议认真往下看。接下来我会先讲技术栈的选择逻辑再带你走一遍完整实战。2. AI测试开发的核心技术栈LLM、LangChain与Playwright怎么配合2.1 LLM测试过程中的翻译官和决策脑在AI测试开发这个体系里大语言模型扮演的角色不是写代码神器这么简单。我习惯把它理解成两个角色翻译官和决策脑。翻译官好理解。测试人员写测试用例时说过最多的一句话是点击登录按钮输入用户名admin密码123456点击提交验证跳转到首页。这种描述要变成一个自动化脚本传统做法是测试开发工程师手动把它翻译成代码。而LLM能直接把这个翻译过程自动化。决策脑就比较有意思了。比如页面加载超时传统脚本只会报timeout然后等着人来处理。但如果你把页面快照、错误信息和环境状态喂给LLM它可以通过推理判断出——可能是环境网络慢还是可能是元素被新弹窗遮挡了还是可能是接口响应变慢导致前端卡顿。这种判断能力以前完全依赖人肉排障现在可以模型化。选择LLM技术上需要注意几个点。一个是上下文窗口长度要能容得下完整的页面结构或报错信息一个是输出稳定性建议固定temperature让结果尽量一致再就是生成格式必须让模型输出结构化内容JSON或代码否则后面脚本没法直接解析。2.2 LangChain把不靠谱的LLM变成靠谱的组件链直接裸调LLM接口做测试工具会遇到几个很现实的问题。比如你想让模型根据测试用例生成Playwright脚本第一次调用可能生成得很粗糙漏了等待时间选择器用得也不稳定。你只能复制报错信息再去问一遍然后再把第二版脚本拿回来继续试。这种一来一回的效率太低而且人肉参与太多就不叫AI测试开发了。LangChain解决的就是这个编排问题。你可以把整个流程拆成多个环节每个环节由不同的Prompt和不同的模型调用组成再用Chain把它们串联起来。更关键的是Agent机制它允许LLM在运行时自己决定调用哪些工具、按什么顺序执行。比如一个测试脚本生成Agent它可以先读取用例文件再检查页面源码再生成代码再执行代码看到报错后自动修正再重试。此外LangChain还提供了Memory机制可以在多轮交互中记住之前的决策和失败原因。对于测试场景来说这是刚需——因为同一个用例在回归中反复失败后Agent如果能记住上次失败的原因和修复策略下一次运行会精准得多。2.3 Playwright比Selenium更懂现代网页的自动化引擎UI自动化测试的落地最终还是得靠一个靠谱的浏览器自动化框架。过去很多团队用Selenium但它启动慢、依赖重、对现代前端框架React/Vue的支持也有不少别扭的地方。我在近两年项目里明显感觉Playwright的体验是碾压级的。先说自动等待。Selenium时代写脚本到处都是time.sleep等元素出现、等页面跳转、等渲染完成写得好坏全看经验。Playwright内置了自动等待机制元素可交互、页面加载完成之前它会自己等脚本干净很多。再说选择器。Playwright支持text选择器、CSS选择器、XPath、还有自动生成的唯一选择器。实测下来它对动态组件和Shadow DOM的处理比Selenium稳定太多。即使前端改版很多时候只需要改一条选择器其他都还能跑。还有分栏执行和Trace Viewer。跑并行用例、录视频、看每一步的操作记录和DOM快照调试排错效率高出一大截。对于AI生成脚本的场景来说这个可观测性特别重要——AI生成脚本跑出问题你得能清楚看到它到底卡在哪一步因为排查AI的错误和排查人写的错误思路上是两回事。2.4 三者组合后的完整链路把这个技术栈拼成一个完整的AI测试链路大概是这样的自然语言测试用例 → 结构化解析 → LLM生成脚本片段 → LangChain编排多个模型调用与工具调用 → Playwright执行UI自动化 → 执行结果反馈 → 失败后由LLM分析原因并自动修复。这条链路和传统的人写脚本-人维护有本质区别。人和AI的分工变成了人负责定义用例意图和边界条件AI负责把意图变成脚本、执行、排障、自愈。这个模式一旦跑通原来一周的回归工作量可能压缩到几个小时。3. 硬核实战开发一个从测试用例到UI自动化脚本的Agent3.1 需求边界和整体设计思路下面用我实际做过的项目来演示。任务目标很明确让Agent读取一份Excel格式的测试用例表自动分析用例步骤生成对应的Playwright UI自动化脚本并执行到稳定通过。在做这个Agent之前我先划了下边界不然容易把项目做成一个大而无当的半成品用例格式约定为Excel表格包含用例编号、测试名称、前置条件、操作步骤、预期结果、测试数据这几列。生成的脚本统一使用Python PlaywrightSync API目标是相关浏览器跑通。执行失败后要能自动分析原因并尝试修复而不是直接抛给人工。整体设计采用分步流水线的思路先解析用例为结构化JSON数据然后把用例数据和页面上下文一起交给LLM生成脚本骨架再由本地验证执行最后走一个失败自愈的闭环。3.2 第一步把Excel里的测试用例解析成结构化数据这一步不需要AI参与就是很朴素的工程处理。用openpyxl读取Excel表格把每一行用例转成JSON对象。为什么先转JSON因为后续不管是用LangChain也好直接调LLM也好都需要一个干净、稳定的输入格式。把人写的自然语言步骤和程序要执行的字段解耦开。看代码from openpyxl import load_workbook import json def parse_test_cases_from_excel(file_path, sheet_nameSheet1): wb load_workbook(file_path) ws wb[sheet_name] headers [cell.value for cell in ws[1]] cases [] for row in ws.iter_rows(min_row2, values_onlyTrue): row_dict dict(zip(headers, row)) case { case_id: row_dict.get(用例编号), case_name: row_dict.get(测试名称), precondition: row_dict.get(前置条件) or , steps: row_dict.get(操作步骤) or , expected: row_dict.get(预期结果) or , test_data: row_dict.get(测试数据) or } cases.append(case) return cases cases parse_test_cases_from_excel(test_cases.xlsx) print(json.dumps(cases[:1], ensure_asciiFalse, indent2))跑出来的数据大概长这样{ case_id: TC001, case_name: 用户登录成功, precondition: 用户已注册, steps: 1.打开登录页;2.输入用户名test01;3.输入密码123456;4.点击登录按钮;5.验证跳转到首页, expected: 登录成功页面跳转到首页且右上角显示用户名, test_data: test01/123456 }这一步已经把一条测试用例变成了机器可读的数据结构。接下来这些结构化的用例描述就可以扔给LLM去生成脚本了。3.3 第二步给LLM喂上下文而不是裸指令很多人在用LLM生成脚本时容易犯一个错误直接把用例文本甩给模型说一句帮我把这个用例转成Playwright脚本得到的代码质量很差。原因是模型不知道页面长什么样不知道按钮在哪里不知道登录框用什么选择器全靠瞎猜生成的自然不处于可用状态。正确做法是把页面结构上下文和用例步骤一起喂给模型。页面结构可以通过Playwright快速抓取from playwright.sync_api import sync_playwright def capture_page_snapshot(url): with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url) # 抓取主要交互元素供LLM作为选择器候选 elements page.eval_on_selector_all( button, input, a[href], select, textarea, els els.map(el ({ tag: el.tagName, type: el.type || el.getAttribute(type), text: el.innerText?.trim()?.slice(0, 30) || , name: el.getAttribute(name), id: el.id, placeholder: el.getAttribute(placeholder) })) ) browser.close() return elements拿到这些元素信息后构造Prompt时把用例和页面元素信息一起给出同时明确要求模型输出可执行的Playwright脚本片段以及定义选择器的理由。实际验证下来先给上下文再生成脚本可用率能提升50个百分点以上基本从需要大量人工修改变成只需要做少量微调。这里我不展开完整代码但Prompt模板的核心结构是这样的角色设定你是一名资深测试开发工程师精通Python和Playwright。页面信息以下是当前页面可用的交互元素JSON。用例信息以下是需要实现自动化的一条用例JSON。输出要求输出完整的Python脚本只包含代码不额外解释优先使用text选择器其次使用id和name。整个Prompt模板用LangChain的ChatPromptTemplate管理好处是可复用、可版本化、可批量替换策略。3.4 第三步让Agent学会自愈——失败用例的自动修复Agent跑起来之后肯定会有用例第一步失败。传统脚本失败就是失败要等人来排查。我做的第二步是把失败信息回流给LLM形成自愈闭环。具体流程是Playwright执行脚本后如果出现异常捕获异常信息、失败步骤的截图路径、页面当前的关键元素快照然后把这三样东西一起交给LLM让它分析失败原因并给出修复后的脚本。自愈逻辑的Prompt设计是另一个关键点。对比简单Prompt脚本执行失败请修复。这样的输出基本不能直接用。我实际验证过的做法是给出结构化错误上下文error_info { error_type: TimeoutError, error_message: 等待定位按钮超时, failed_step: 步骤4: 点击登录按钮, page_snapshot: [...], # 当前页面的可交互元素 original_script: login_test.py, }然后让LLM判断三类情况一是选择器失效需要改用页面快照中的其他定位方式二是等待时间不足需要增加显式等待三是前置条件不满足属于用例数据问题需要跳过该脚本并标记为环境问题。实测中这个自愈闭环能解决掉约七成左右的环境性失败和定位器变动失败剩下三成是业务逻辑或数据问题才需要人工介入。这个比例已经很能说明问题了——过去人肉排查不划算的低级错误Agent现在能自动处理测试工程成本自然就下来了。3.5 实测效果与翻车记录把整条链路跑在一个真实的电商登录和下单项目上时我用60条用例做了一次验证。结果分成三档首次运行直接通过的约占45%有一次自愈修复后通过的约占31%经过自愈仍然失败需要人工处理的约占24%。人工处理的案件主要集中在两类一是测试数据条件不满足比如测试账号被锁定二是业务逻辑本身有特殊caseLLM生成的通用脚本覆盖不进去。翻车记录也踩了几个值得分享。第一次跑的时候LLM生成的脚本喜欢用很长的CSS嵌套选择器一看就是浏览器里DevTools复制的在代码库里基本一改版就碎。后来我在Prompt里明确限制不要使用多层级CSS选择器优先使用text定位后这个问题改善了很多。第二个失败点是LLM总会生成截图保存到固定路径的代码导致多worker并发执行时互相覆盖。后来我在脚本生成Prompt里加入并发安全要求并在运行时用时间戳动态生成截图路径这个问题才解掉。这些坑传统的自动化测试教程不会告诉你只有亲手做完一整个项目才会意识到Prompt细节和执行环境的耦合有多深。4. 从测试人到AI测试开发的转型路线学习路径与实战规划4.1 四个阶段的学习任务拆解转型不是靠报一个班就能完成的它需要你按顺序、按节奏地完成几个阶段。我在课程里把完整学习路径分成了四段阶段一AI与大模型应用基础。重点是Prompt工程原理、上下文窗口机制、API调用方法、温度等参数的意义。目标是能用代码调通一个LLM接口不再只是和网页版聊天。阶段二LangChain核心框架。掌握Chain、Agent、Tool、Memory四大件。能自己组装一个多步骤的AI工作流。这个阶段学完你已经具备了解决AI测试开发项目80%问题的基础。阶段三测试自动化工程能力。以Playwright为核心掌握分栏跑、Trace Viewer排障、元素定位策略、数据驱动、CI接入。目标是不依赖别人自己能把脚本跑到稳定通过。阶段四AI测试开发综合实战。直接把前面三个阶段的技能合在一起。做成我们上面讲的用例读取Agent、脚本生成Agent、自愈Agent最后交付一个有完整业务场景的项目。这四阶段不是独立的每个阶段的项目都是下一个阶段的输入。比如阶段一学完你得会用LangChain做一个测试报告总结Agent把Jenkins里的测试报告自动转成给产品经理看的自然语言总结。这就是阶段四大项目的最小雏形。测试人学AI最大的障碍往往不是技术难度而是不知道学到什么程度算够。上面四阶的划分就解决这个问题——每一步都有清晰产出和验收标准。你不需要成为一个算法工程师你只需要成为一个能把LLM当工具用出花来的测试工程专家。4.2 项目集怎么设计简历上的AI测试开发项目从哪来很多测试人简历上的项目写的都是参与XX系统的测试工作编写自动化脚本300条这类描述在今天的招聘市场上已经基本没有竞争力了。原因很简单会写脚本的人太多了但会用AI重新定义测试流程的人很少。我建议在简历上呈现2-3个具备AI含量的测试开发项目。不用多但一定得能讲透。我列几个真实的候选题目供参考项目一测试用例自动生成Agent。输入业务需求文档自动生成覆盖正常流程、异常分支、边界条件的测试用例集。这个考验的是用例设计思维 LLM结构化输出能力。项目二UI自动化脚本生成与自愈Agent。就是我们上面落地的那套读取用例、生成Playwright脚本、失败自愈。这个项目能同时展示你的自动化工程功底和AI工程化能力。项目三智能缺陷分析助手。把Bug系统中的历史缺陷数据和大模型结合自动归纳缺陷分布规律预测新版本的高风险模块。这个偏数据分析但测试人做有天然的行业优势——你懂缺陷的生成机制。这三类项目分别覆盖了用例生成脚本执行缺陷分析三个核心测试环节比单做一个AI聊天机器人的Demo更有说服力。因为面试官能一眼看出你是把AI当鲶鱼用进测试流程里的不是为AI而AI。4.3 测试人的先天优势与面试表达要点最后聊一个比较有趣的观察。带了几期学员之后我发现真正转型成功的测试人都不是代码基础最好的而是对质量目标理解最深的。代码练一练大家都能到差不多的水平但一个系统的核心风险点在哪里什么缺陷会造成用户流失什么异常在真实环境里概率最高这种东西就是纯测试人靠大量业务和线上问题积累出来的直觉。这种直觉在AI测试开发场景里特别值钱因为LLM再强也不会自动知道某些业务细节的优先级。面试时通过项目展示你的质量判断非常关键。比如你在自我介绍之后可以这样讲项目链路我做了一个测试脚本生成Agent。传统的UI自动化维护成本太高所以我用LangChain把自然语言用例解析成结构化数据让LLM基于真实的页面上下文生成Playwright脚本再加了一层失败自愈机制。跑通后脚本维护成本大约降了六成回归频率从两周一次提升到每天一次。这段话里你展示的不是我会用LangChain和Playwright这种工具层面的信息而是我能看到自动化测试的核心痛点并且用AI工程手段系统性地解决它。这种项目思维正是AI测试开发工程师和普通自动化测试人员之间的分水岭。写在最后一个过来人的转型建议我见过太多测试人把转型拖成了观望。今天看一个教程明天收藏一个帖子三个月过去了还是在原地。转型AI测试开发这件事最需要的是在一段集中的、有反馈的时间里把上面讲的几个阶段走完一遍。你不需要一开始就非常精通LangChain或Playwright但你需要有一个真实的上手项目跟着完整的链路从头走一次。我的经验是把读取用例-生成脚本-执行-自愈这条链路跑通一次你对AI测试开发的理解就会发生质变——它不再是新闻里的概念而是你手上每天都能用的能力。这个班就是要帮你把这条路走完少走冤枉路少踩没必要的坑。那些第一批跑起来的人已经把AI写进日常工作流在团队里变成不可替代的角色。这一次轮到你了。 
长河君 · 2026/9/28 20:18:44 · 阅读 1.2k 测试人转型AI测试开发：核心技术栈与Agent实战全解析
今年AI和测试开发的讨论比过去五年的总和还要多。你打开任何一个技术社区都能看到AI会消灭测试岗和AI离不开测试人两种观点来回拉扯。我在测试行业干了十几年带过功能测试团队也做过测试开发基建看到大量测试同行卡在同一个问题上工具会用一点脚本能写一点但一提到AI就不知道从哪入手更不知道怎么把AI变成每天干活时真正用得上、能解决实际问题的能力。这篇内容我想直接围绕测试人转型AI测试开发来讲。先讲清楚行业环境为什么在这个时间点出现了真正的机会窗口再拆解AI测试开发需要用到的核心技术栈然后给出一个完整的实战案例——基于LangChain开发一个能读取测试用例、自动生成UI自动化脚本的Agent最后聊一聊从测试到AI测试开发的转型路线和学习规划。如果你是一名正在观望的测试人这篇内容就是写给你的。你不需要有很深的技术功底但需要愿意花点时间把思路理清楚。1. 测试人真正的机会窗口为什么是现在1.1 传统测试方法正在失效的三个场景先说一个我在项目里反复遇到的场景。以前做Web端UI自动化测试一个测试用例从编写到稳定运行大概需要经历写脚本-跑用例-修脚本-定时执行-维护脚本这么一套流程。最难的不是写脚本本身而是维护。前端稍微改个按钮位置选择器就失效加个登录态校验整个链路就要重新调。我曾经带过一个自动化测试项目光维护成本就占了整个团队60%的工作量。这也是很多测试团队说自动化测试是个笑话的原因——稳定不下来。到了AI时代这个问题不仅没有消失反而变得更复杂了。因为现在的软件系统已经不只是人机交互的页面还有大量由大模型驱动的AI原生应用。这类应用有几个让传统测试方法直接失效的特征第一输出不确定性。以前你测一个登录框输入正确账号密码点击登录系统返回用户名这是确定的。但现在测一个智能客服同一个问题在10次请求里可能长出9种不同的回答。你怎么断言怎么校验通过/失败第二测试用例的边界变模糊。以前一条用例有明确的预期结果现在AI应用的预期结果往往是是否符合业务目标这种模糊判断。比如你让AI助手生成一段营销文案它的用词、语气、结构每次都不一样但可能每次都符合需求。传统断言根本没法落到这种场景上。第三回归成本指数级上涨。前端迭代快、版本多加上AI Agent会自己调用工具、自己规划步骤一条核心业务链路的回归光靠人肉执行和传统脚本已经跑不动了。这些场景叠加在一起就产生了一个真实的供需缺口市场上缺的已经不是会写脚本的执行者而是能设计AI测试策略、能开发AI测试工具链、能让测试效率成倍提升的AI测试开发工程师。1.2 AI不是来替代测试的是来替代不懂AI的测试的很多测试同行一听到AI自动生成代码就焦虑觉得岗位要没了。但我在实际项目里的感受正好相反。大模型现在确实能写代码能自动补全用例能把一条自然语言描述的步骤变成脚本片段。但AI生成的脚本谁来校验用例与真实业务状态的偏差谁来发现失败之后谁来决定是改代码还是改需求自动生成的测试结论谁来做最终的业务判断这些任务懂业务、懂测试设计、能理解系统边界的人最合适。AI把你从重复劳动里解放出来剩下的高价值工作恰恰落到了会使用AI的测试人手里。这里我想澄清一个误区。很多人觉得AI测试开发很远好像必须得会训练模型、会调参、会分布式系统。其实完全不是。AI测试开发的核心是把大模型当作一个强大的能力组件去解决测试领域的具体问题。你懂测试用例设计懂业务逻辑懂缺陷规律你再学会怎么调用大模型、怎么用LangChain把流程编排起来、怎么用Playwright把脚本跑起来这四样拼在一起就已经松一个非常能打的AI测试开发工程师了。本质上它不是让你转行做算法而是让你在原有的测试功底上叠加一层AI工程能力。1.3 这个班想解决的问题和适合的人群我们的人工智能测试开发班要解决的就是上面说的这个转化问题——把具备测试思维的人锻造成能用AI工具链解决实际测试问题的开发型人才。课程设计的核心假设是测试人最大的资产不是写代码能力而是质量思维和业务理解力。我们要做的不是把你变成又一个Python工程师而是把你变成懂质量、懂业务、会AI工程化的测试开发工程师。这个班适合这几类人功能测试做了三五年想往测试开发方向转但一直没找到清晰路径的人。会写部分自动化脚本但感觉遇到了瓶颈想借助AI提升测试效率和工具链能力的人。对LangChain、Agent、Playwright这些技术有零散了解但没有系统实践过、不知道怎么落地到测试场景的人。如果你符合其中任何一类建议认真往下看。接下来我会先讲技术栈的选择逻辑再带你走一遍完整实战。2. AI测试开发的核心技术栈LLM、LangChain与Playwright怎么配合2.1 LLM测试过程中的翻译官和决策脑在AI测试开发这个体系里大语言模型扮演的角色不是写代码神器这么简单。我习惯把它理解成两个角色翻译官和决策脑。翻译官好理解。测试人员写测试用例时说过最多的一句话是点击登录按钮输入用户名admin密码123456点击提交验证跳转到首页。这种描述要变成一个自动化脚本传统做法是测试开发工程师手动把它翻译成代码。而LLM能直接把这个翻译过程自动化。决策脑就比较有意思了。比如页面加载超时传统脚本只会报timeout然后等着人来处理。但如果你把页面快照、错误信息和环境状态喂给LLM它可以通过推理判断出——可能是环境网络慢还是可能是元素被新弹窗遮挡了还是可能是接口响应变慢导致前端卡顿。这种判断能力以前完全依赖人肉排障现在可以模型化。选择LLM技术上需要注意几个点。一个是上下文窗口长度要能容得下完整的页面结构或报错信息一个是输出稳定性建议固定temperature让结果尽量一致再就是生成格式必须让模型输出结构化内容JSON或代码否则后面脚本没法直接解析。2.2 LangChain把不靠谱的LLM变成靠谱的组件链直接裸调LLM接口做测试工具会遇到几个很现实的问题。比如你想让模型根据测试用例生成Playwright脚本第一次调用可能生成得很粗糙漏了等待时间选择器用得也不稳定。你只能复制报错信息再去问一遍然后再把第二版脚本拿回来继续试。这种一来一回的效率太低而且人肉参与太多就不叫AI测试开发了。LangChain解决的就是这个编排问题。你可以把整个流程拆成多个环节每个环节由不同的Prompt和不同的模型调用组成再用Chain把它们串联起来。更关键的是Agent机制它允许LLM在运行时自己决定调用哪些工具、按什么顺序执行。比如一个测试脚本生成Agent它可以先读取用例文件再检查页面源码再生成代码再执行代码看到报错后自动修正再重试。此外LangChain还提供了Memory机制可以在多轮交互中记住之前的决策和失败原因。对于测试场景来说这是刚需——因为同一个用例在回归中反复失败后Agent如果能记住上次失败的原因和修复策略下一次运行会精准得多。2.3 Playwright比Selenium更懂现代网页的自动化引擎UI自动化测试的落地最终还是得靠一个靠谱的浏览器自动化框架。过去很多团队用Selenium但它启动慢、依赖重、对现代前端框架React/Vue的支持也有不少别扭的地方。我在近两年项目里明显感觉Playwright的体验是碾压级的。先说自动等待。Selenium时代写脚本到处都是time.sleep等元素出现、等页面跳转、等渲染完成写得好坏全看经验。Playwright内置了自动等待机制元素可交互、页面加载完成之前它会自己等脚本干净很多。再说选择器。Playwright支持text选择器、CSS选择器、XPath、还有自动生成的唯一选择器。实测下来它对动态组件和Shadow DOM的处理比Selenium稳定太多。即使前端改版很多时候只需要改一条选择器其他都还能跑。还有分栏执行和Trace Viewer。跑并行用例、录视频、看每一步的操作记录和DOM快照调试排错效率高出一大截。对于AI生成脚本的场景来说这个可观测性特别重要——AI生成脚本跑出问题你得能清楚看到它到底卡在哪一步因为排查AI的错误和排查人写的错误思路上是两回事。2.4 三者组合后的完整链路把这个技术栈拼成一个完整的AI测试链路大概是这样的自然语言测试用例 → 结构化解析 → LLM生成脚本片段 → LangChain编排多个模型调用与工具调用 → Playwright执行UI自动化 → 执行结果反馈 → 失败后由LLM分析原因并自动修复。这条链路和传统的人写脚本-人维护有本质区别。人和AI的分工变成了人负责定义用例意图和边界条件AI负责把意图变成脚本、执行、排障、自愈。这个模式一旦跑通原来一周的回归工作量可能压缩到几个小时。3. 硬核实战开发一个从测试用例到UI自动化脚本的Agent3.1 需求边界和整体设计思路下面用我实际做过的项目来演示。任务目标很明确让Agent读取一份Excel格式的测试用例表自动分析用例步骤生成对应的Playwright UI自动化脚本并执行到稳定通过。在做这个Agent之前我先划了下边界不然容易把项目做成一个大而无当的半成品用例格式约定为Excel表格包含用例编号、测试名称、前置条件、操作步骤、预期结果、测试数据这几列。生成的脚本统一使用Python PlaywrightSync API目标是相关浏览器跑通。执行失败后要能自动分析原因并尝试修复而不是直接抛给人工。整体设计采用分步流水线的思路先解析用例为结构化JSON数据然后把用例数据和页面上下文一起交给LLM生成脚本骨架再由本地验证执行最后走一个失败自愈的闭环。3.2 第一步把Excel里的测试用例解析成结构化数据这一步不需要AI参与就是很朴素的工程处理。用openpyxl读取Excel表格把每一行用例转成JSON对象。为什么先转JSON因为后续不管是用LangChain也好直接调LLM也好都需要一个干净、稳定的输入格式。把人写的自然语言步骤和程序要执行的字段解耦开。看代码from openpyxl import load_workbook import json def parse_test_cases_from_excel(file_path, sheet_nameSheet1): wb load_workbook(file_path) ws wb[sheet_name] headers [cell.value for cell in ws[1]] cases [] for row in ws.iter_rows(min_row2, values_onlyTrue): row_dict dict(zip(headers, row)) case { case_id: row_dict.get(用例编号), case_name: row_dict.get(测试名称), precondition: row_dict.get(前置条件) or , steps: row_dict.get(操作步骤) or , expected: row_dict.get(预期结果) or , test_data: row_dict.get(测试数据) or } cases.append(case) return cases cases parse_test_cases_from_excel(test_cases.xlsx) print(json.dumps(cases[:1], ensure_asciiFalse, indent2))跑出来的数据大概长这样{ case_id: TC001, case_name: 用户登录成功, precondition: 用户已注册, steps: 1.打开登录页;2.输入用户名test01;3.输入密码123456;4.点击登录按钮;5.验证跳转到首页, expected: 登录成功页面跳转到首页且右上角显示用户名, test_data: test01/123456 }这一步已经把一条测试用例变成了机器可读的数据结构。接下来这些结构化的用例描述就可以扔给LLM去生成脚本了。3.3 第二步给LLM喂上下文而不是裸指令很多人在用LLM生成脚本时容易犯一个错误直接把用例文本甩给模型说一句帮我把这个用例转成Playwright脚本得到的代码质量很差。原因是模型不知道页面长什么样不知道按钮在哪里不知道登录框用什么选择器全靠瞎猜生成的自然不处于可用状态。正确做法是把页面结构上下文和用例步骤一起喂给模型。页面结构可以通过Playwright快速抓取from playwright.sync_api import sync_playwright def capture_page_snapshot(url): with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(url) # 抓取主要交互元素供LLM作为选择器候选 elements page.eval_on_selector_all( button, input, a[href], select, textarea, els els.map(el ({ tag: el.tagName, type: el.type || el.getAttribute(type), text: el.innerText?.trim()?.slice(0, 30) || , name: el.getAttribute(name), id: el.id, placeholder: el.getAttribute(placeholder) })) ) browser.close() return elements拿到这些元素信息后构造Prompt时把用例和页面元素信息一起给出同时明确要求模型输出可执行的Playwright脚本片段以及定义选择器的理由。实际验证下来先给上下文再生成脚本可用率能提升50个百分点以上基本从需要大量人工修改变成只需要做少量微调。这里我不展开完整代码但Prompt模板的核心结构是这样的角色设定你是一名资深测试开发工程师精通Python和Playwright。页面信息以下是当前页面可用的交互元素JSON。用例信息以下是需要实现自动化的一条用例JSON。输出要求输出完整的Python脚本只包含代码不额外解释优先使用text选择器其次使用id和name。整个Prompt模板用LangChain的ChatPromptTemplate管理好处是可复用、可版本化、可批量替换策略。3.4 第三步让Agent学会自愈——失败用例的自动修复Agent跑起来之后肯定会有用例第一步失败。传统脚本失败就是失败要等人来排查。我做的第二步是把失败信息回流给LLM形成自愈闭环。具体流程是Playwright执行脚本后如果出现异常捕获异常信息、失败步骤的截图路径、页面当前的关键元素快照然后把这三样东西一起交给LLM让它分析失败原因并给出修复后的脚本。自愈逻辑的Prompt设计是另一个关键点。对比简单Prompt脚本执行失败请修复。这样的输出基本不能直接用。我实际验证过的做法是给出结构化错误上下文error_info { error_type: TimeoutError, error_message: 等待定位按钮超时, failed_step: 步骤4: 点击登录按钮, page_snapshot: [...], # 当前页面的可交互元素 original_script: login_test.py, }然后让LLM判断三类情况一是选择器失效需要改用页面快照中的其他定位方式二是等待时间不足需要增加显式等待三是前置条件不满足属于用例数据问题需要跳过该脚本并标记为环境问题。实测中这个自愈闭环能解决掉约七成左右的环境性失败和定位器变动失败剩下三成是业务逻辑或数据问题才需要人工介入。这个比例已经很能说明问题了——过去人肉排查不划算的低级错误Agent现在能自动处理测试工程成本自然就下来了。3.5 实测效果与翻车记录把整条链路跑在一个真实的电商登录和下单项目上时我用60条用例做了一次验证。结果分成三档首次运行直接通过的约占45%有一次自愈修复后通过的约占31%经过自愈仍然失败需要人工处理的约占24%。人工处理的案件主要集中在两类一是测试数据条件不满足比如测试账号被锁定二是业务逻辑本身有特殊caseLLM生成的通用脚本覆盖不进去。翻车记录也踩了几个值得分享。第一次跑的时候LLM生成的脚本喜欢用很长的CSS嵌套选择器一看就是浏览器里DevTools复制的在代码库里基本一改版就碎。后来我在Prompt里明确限制不要使用多层级CSS选择器优先使用text定位后这个问题改善了很多。第二个失败点是LLM总会生成截图保存到固定路径的代码导致多worker并发执行时互相覆盖。后来我在脚本生成Prompt里加入并发安全要求并在运行时用时间戳动态生成截图路径这个问题才解掉。这些坑传统的自动化测试教程不会告诉你只有亲手做完一整个项目才会意识到Prompt细节和执行环境的耦合有多深。4. 从测试人到AI测试开发的转型路线学习路径与实战规划4.1 四个阶段的学习任务拆解转型不是靠报一个班就能完成的它需要你按顺序、按节奏地完成几个阶段。我在课程里把完整学习路径分成了四段阶段一AI与大模型应用基础。重点是Prompt工程原理、上下文窗口机制、API调用方法、温度等参数的意义。目标是能用代码调通一个LLM接口不再只是和网页版聊天。阶段二LangChain核心框架。掌握Chain、Agent、Tool、Memory四大件。能自己组装一个多步骤的AI工作流。这个阶段学完你已经具备了解决AI测试开发项目80%问题的基础。阶段三测试自动化工程能力。以Playwright为核心掌握分栏跑、Trace Viewer排障、元素定位策略、数据驱动、CI接入。目标是不依赖别人自己能把脚本跑到稳定通过。阶段四AI测试开发综合实战。直接把前面三个阶段的技能合在一起。做成我们上面讲的用例读取Agent、脚本生成Agent、自愈Agent最后交付一个有完整业务场景的项目。这四阶段不是独立的每个阶段的项目都是下一个阶段的输入。比如阶段一学完你得会用LangChain做一个测试报告总结Agent把Jenkins里的测试报告自动转成给产品经理看的自然语言总结。这就是阶段四大项目的最小雏形。测试人学AI最大的障碍往往不是技术难度而是不知道学到什么程度算够。上面四阶的划分就解决这个问题——每一步都有清晰产出和验收标准。你不需要成为一个算法工程师你只需要成为一个能把LLM当工具用出花来的测试工程专家。4.2 项目集怎么设计简历上的AI测试开发项目从哪来很多测试人简历上的项目写的都是参与XX系统的测试工作编写自动化脚本300条这类描述在今天的招聘市场上已经基本没有竞争力了。原因很简单会写脚本的人太多了但会用AI重新定义测试流程的人很少。我建议在简历上呈现2-3个具备AI含量的测试开发项目。不用多但一定得能讲透。我列几个真实的候选题目供参考项目一测试用例自动生成Agent。输入业务需求文档自动生成覆盖正常流程、异常分支、边界条件的测试用例集。这个考验的是用例设计思维 LLM结构化输出能力。项目二UI自动化脚本生成与自愈Agent。就是我们上面落地的那套读取用例、生成Playwright脚本、失败自愈。这个项目能同时展示你的自动化工程功底和AI工程化能力。项目三智能缺陷分析助手。把Bug系统中的历史缺陷数据和大模型结合自动归纳缺陷分布规律预测新版本的高风险模块。这个偏数据分析但测试人做有天然的行业优势——你懂缺陷的生成机制。这三类项目分别覆盖了用例生成脚本执行缺陷分析三个核心测试环节比单做一个AI聊天机器人的Demo更有说服力。因为面试官能一眼看出你是把AI当鲶鱼用进测试流程里的不是为AI而AI。4.3 测试人的先天优势与面试表达要点最后聊一个比较有趣的观察。带了几期学员之后我发现真正转型成功的测试人都不是代码基础最好的而是对质量目标理解最深的。代码练一练大家都能到差不多的水平但一个系统的核心风险点在哪里什么缺陷会造成用户流失什么异常在真实环境里概率最高这种东西就是纯测试人靠大量业务和线上问题积累出来的直觉。这种直觉在AI测试开发场景里特别值钱因为LLM再强也不会自动知道某些业务细节的优先级。面试时通过项目展示你的质量判断非常关键。比如你在自我介绍之后可以这样讲项目链路我做了一个测试脚本生成Agent。传统的UI自动化维护成本太高所以我用LangChain把自然语言用例解析成结构化数据让LLM基于真实的页面上下文生成Playwright脚本再加了一层失败自愈机制。跑通后脚本维护成本大约降了六成回归频率从两周一次提升到每天一次。这段话里你展示的不是我会用LangChain和Playwright这种工具层面的信息而是我能看到自动化测试的核心痛点并且用AI工程手段系统性地解决它。这种项目思维正是AI测试开发工程师和普通自动化测试人员之间的分水岭。写在最后一个过来人的转型建议我见过太多测试人把转型拖成了观望。今天看一个教程明天收藏一个帖子三个月过去了还是在原地。转型AI测试开发这件事最需要的是在一段集中的、有反馈的时间里把上面讲的几个阶段走完一遍。你不需要一开始就非常精通LangChain或Playwright但你需要有一个真实的上手项目跟着完整的链路从头走一次。我的经验是把读取用例-生成脚本-执行-自愈这条链路跑通一次你对AI测试开发的理解就会发生质变——它不再是新闻里的概念而是你手上每天都能用的能力。这个班就是要帮你把这条路走完少走冤枉路少踩没必要的坑。那些第一批跑起来的人已经把AI写进日常工作流在团队里变成不可替代的角色。这一次轮到你了。