这两年我经常在技术社区看到一种提问干了五六年功能测试每天点来点去越干越恐慌想转型“AI测试开发”但网上课程这么多到底学什么才能不掉坑我部门这几年陆续有几个测试同事转型成功我也亲手带过几条AI测试链路。今天不卖课也不画饼就把“AI测试开发”这个方向拆开揉碎讲讲它到底是什么、测试人怎么一步步转型、以及我自己验证过的一条实操路线用LangChain做一个能读取测试用例、自动生成UI自动化脚本的Agent。看完你至少能分清哪些是真需求哪些是培训机构包装出来的概念。1. AI测试开发不是“测试加个AI插件”而是新工种1.1 传统测试开发和AI测试开发的本质差异传统测试开发的核心工作是写自动化框架、搭CI流水线、维护接口测试脚本、做性能工具选型。它解决的是“人手动执行太慢”的问题本质是把重复劳动代码化。AI测试开发多了一层把“人怎么设计用例、怎么分析失败、怎么评估风险”这件事拆成可以用大模型 数据 工具链自动完成的任务。它解决的不仅是“跑得慢”还有“想得慢、写不快、查不准”。举个例子传统写UI自动化你先得梳理测试步骤给元素定位再写Playwright或Selenium脚本。一个中等复杂度的页面写脚本加上调稳定性少说半天。AI测试开发干的活是把“需求描述 → 测试用例 → 可执行脚本”的过程自动化。你可以用大模型直接读一版需求产出用例草稿再让Agent补全脚本框架自己只需要做审核和调优。说白了传统测试开发把“点鼠标的手工测试”变成“写代码的自动化测试”AI测试开发把“写代码的自动化测试”变成“写提示词和搭工作流的测试智能体”。层级不同产出也不同。1.2 为什么这个方向会火起来我经历过几个阶段的测试工具演进最早的录制回放然后是关键字驱动再到Page Object模型到现在Playwright这类“响应式”框架。每次演进都是为了让人少写点样板代码。LLM的文本理解、代码生成能力正好撞上了测试行业的痛点用例文档一堆和代码是脱节的自动化脚本维护成本高因为页面一改就挂失败定位难截图几百张没人看。这些痛点天然适合用大模型做信息提取、脚本生成、根因分析。更关键的是AI测试开发是一个“杠杆效应”极强的岗位。一个人能维护的自动化用例数量是有限的但一个Agent可以同时服务多个项目的用例生成和脚本维护把你从几千条脚本的泥潭里拉出来。这也是为什么很多测试团队在预算有限的情况下愿意培养一个懂AI的测试开发而不是招一堆手工测试。1.3 你是否适合转这个方向我见过最快的转型者一个功能测试干了三年Python只会写if和for但逻辑思维强肯钻。TA用了大概四个月就把LangChain的Agent链路跑通了。我也见过写了几年自动化脚本的资深工程师反而被“以前怎么学测试”的思维框住迟迟进不了状态。给你一张自检表对照一下能力维度加分项减分项建议投入编程基础能用Python写自动化脚本只会跑现成框架每天2到3小时测试思维知道用例设计方法、测试分层只会按需求点执行持续保持数据分析会看日志、能拆解用例的共性几乎不碰数据需要系统补好奇心愿意研究新框架、自己动手验证等现成解决方案最关键软素质工具敏感度用过Playwright、Docker、Git只在Windows上点点点边学边补核心判断标准不是你会不会写代码而是你能不能忍受“踩坑、查文档、改提示词、再跑一遍”这种循环。AI测试开发这个方向没有成熟教材大量时间都花在跟模型对话、看报错、调整上下文上面。2. AI能在测试链路里干的活比你想的多得多2.1 需求解析与测试用例脑暴这是我认为落地最稳、见效最快的环节。以前需求评审完测试要自己对着PRD写用例容易漏边界场景。现在的做法是把需求文档丢给大模型让它从功能、边界、异常、性能、安全几个维度生成候选用例你再筛选、补全。我常用的提示词结构是“你是资深测试架构师。基于以下PRD输出功能测试用例要求每个用例包含前置条件、步骤、预期结果并标出优先级。”注意不是问一句就能出来高质量用例。你需要拆两步走第一步先让模型产出用户场景列表第二步再基于用户场景生成用例。一次性让模型输出几十条用例时它会把简单功能复杂化反而加大你的审核负担。2.2 从测试用例生成自动化脚本这是目前AI测试开发最吸引人的场景。它本质上是一个“文本到代码”的转换问题输入一份写好的测试用例输出一套用Playwright或Selenium写好的自动化脚本。但这里有个天坑模型没见过你的页面结构它生成的元素定位符基本是瞎猜。我早期的实验里大模型生成脚本的定位符准确率大概只有一半剩下全靠猜。要解决这个问题不能只靠提示词你得给模型提供页面信息——DOM快照、接口文档、数据特征让它有依据地写selector。后面的第四章我会详细写这个链路的工程实现这里先记住一条结论用例转脚本的上限不取决于模型聪明不聪明取决于你喂给它的页面上下文够不够。2.3 失败用例分析与缺陷定位自动化跑挂了以前你要翻日志、看截图、对照页面源码挨个排查是环境问题、数据问题还是真缺陷。大模型在处理这种“多模态信息”上有天然优势你给它一段报错堆栈、几张页面截图、近期的代码提交记录它能快速给出嫌疑点。我们团队实际跑过一种方案用例失败后自动把日志、截图、当时的前端API请求信息拼成一个上下文调大模型多模态接口让它输出“失败分类 可能原因 建议排查顺序”。效果最突出的是网络超时和断言杂音这一类问题模型几乎秒杀人工排查漏报率也不高。2.4 测试报告的“人话翻译”这个场景经常被低估。测试经理需要的不是一个40页的测试报告附件而是“本次版本质量行不行、风险在哪、该不该发版”。用Agent把测试执行结果、缺陷趋势、覆盖率数据拉出来生成一段执行摘要再附上原始数据链接这一套完全可以自动跑。我见过一个团队把每周测试报告从两小时压缩到十五分钟关键就是让大模型读测试管理平台的接口数据按固定模板生成周报只留一个人审核。3. 转型AI测试开发的技能地图3.1 编程基础不是刷题是写自动化框架很多测试转AI开发的第一反应是去刷LeetCode方向错了。你要的不是算法工程师而是能把想法落地成代码的脚本工程师。重点练这几个Python的异常处理、文件读写、装饰器、类与继承playwright的基本APIrequests库处理接口pytest的fixture和断言机制。练到啥程度算合格给你个标准能用Python写一个简单的Page Object框架传给新人能用加一个页面对象不用改框架代码。我不推荐一上来就啃Selenium源码或者研究Spring那是给Java后端看的。测试开发的核心是用脚本解决测试问题不是做中间件。3.2 把大模型当开发工具而不是聊天玩具这一步最卡人。很多人用完ChatGPT或者DeepSeek觉得“也就那样”原因是用它聊天而不是写工具。你要学会的是提示词工程里的三个基础能力任务拆分把“帮我把登录功能测试自动化”拆成“提取用例步骤 — 生成定位符候选 — 生成脚本结构 — 补断言”这样的小任务每个小任务对应一条独立提示词链。上下文管理不把整个代码库丢给模型而是只贴当前页面相关的代码片段、DOM子集或者接口样例。塞太多无关内容模型输出质量反而下降。校验闭环模型生成的代码必须有一个自动化校验环节比如让它跑静态检查、让测试框架试跑一次。不校验就把代码合进仓库早晚出事故。我建议你从改造自己的日常工作开始拿一份旧测试报告用大模型生成摘要拿一个历史bug让模型写缺陷分析拿一个旧页面录制脚本看它能不能重构出Playwright版本。3.3 掌握Agent核心架构这是AI测试开发的硬通货如果只学一样东西我推荐研究下Agent。AI测试开发绝大多数高级场景背后都是Agent在跑它自己决定调用哪个工具、什么时候停止、失败之后怎么重试。我对Agent的理解可以简化成三件套工具集合比如“读取测试用例”“读取页面结构”“执行上一步生成出来的脚本”“查询测试库状态”这些函数让Agent能调用外部系统。上下文组装把用户问题、测试用例、页面结构、历史失败记录拼成一段让大模型理解当前状态的文本。控制循环让模型决策下一步要调哪个工具执行后把结果贴回上下文再继续决策直到满足退出条件。LangChain在这里的优势在于它已经把“模型选工具、执行工具、更新上下文”这套循环封装好了你不用自己写调度代码。最新的LangChain版本里create_agent那一套API已经比较成熟支持结构化输出和工具调用校验。用熟了之后你会对这个职业方向有全新的感知。3.4 选型模型、框架、基础设施怎么配我做AI测试开发实验时前期先按“够用、便宜、稳定”三个指标选型。模型层面优先选能稳定输出函数调用结果的因为Agent场景对JSON结构化要求很高这是大模型最容易翻车的地方。框架层面LangChain在测试行业生态最成熟文档齐全社区案例多。如果你习惯更轻量直接写原生Python requests调用模型接口也完全可行甚至隐私性更好。但考虑到团队协作和维护我建议团队里至少有一个人熟悉LangChain的Agent体系。基础设施上最容易被忽略的是缓存。大模型API不便宜测试场景里同样的用例会跑很多遍。一定要在中间加一层缓存把“参数相同、结果相同”的调用命中缓存成本能降一半以上。我团队跑了一个月之后缓存命中率到40%账单数字好看了很多。4. 实操用LangChain做一个“用例转自动化脚本Agent”4.1 整体设计思路为了让你对AI测试开发有立体感受我把第四章做成一个可直接伪代码复现的案例。假设你有这样一份Markdown格式的测试用例## 用例登录功能 前置条件系统已部署数据库正常 步骤 1. 打开首页 2. 输入有效用户名 3. 输入有效密码 4. 点击登录按钮 预期结果跳转到首页右上角显示用户昵称目标让Agent读取这份用例调用工具生成对应的Pytest Playwright脚本文件。整体架构分三层读取层Agent先调用“load_testcase”工具读取Markdown用例并解析成结构化json。生成层Agent结合用例里的步骤调用“generate_playwright_code”工具让大模型输出脚本代码。校验层Agent调用“validate_code”工具用Python编译器做语法检查再用pytest试跑。如果失败把报错贴回给Agent让它修正后重试。关键设计点来了不要试图让Agent一步到位生成完整脚本而是强制它走“读用例 → 写代码 → 校验 → 修正”的循环。这样每次生成的代码都经过一次实际试跑的反馈质量比“一次性生成”高很多。4.2 搭建基础代码框架我用的是Python 3.10 LangChain Playwright。先安装依赖pip install langchain langchain-openai playwright pytest pytest-playwright playwright install chromium核心代码逻辑可以这样组织from langchain_openai import ChatOpenAI from langchain.agents import create_openai_functions_agent, AgentExecutor from langchain.tools import StructuredTool from langchain.prompts import ChatPromptTemplate # 这里接入你实际可用的模型服务本地部署或云API都可以 llm ChatOpenAI( modelyour-model, temperature0, max_retries1 )我强烈建议temperature设成0原因很简单测试脚本代码最怕“创造性发挥”你必须让它输出确定性内容。接下来定义三个工具函数def load_testcase(file_path: str) - dict: with open(file_path, r, encodingutf-8) as f: content f.read() # 用正则或简单解析把Markdown转成结构化json # return {title: ..., steps: [...], expected: ...} def generate_playwright_code(testcase: dict) - str: # 调用模型生成代码的prompt模板 # 返回脚本字符串 def validate_code(code: str) - str: import subprocess, tempfile # 写入临时py文件先做语法编译再用pytest运行 # 返回运行结果或报错信息然后把这些函数包装成StructuredTooltools [ StructuredTool.from_function(funcload_testcase), StructuredTool.from_function(funcgenerate_playwright_code), StructuredTool.from_function(funcvalidate_code), ]提示词模板的核心是这样prompt ChatPromptTemplate.from_messages([ (system, 你是测试开发工程师负责把Markdown测试用例转成可运行的Playwright测试脚本。你必须先读取用例再生成代码调用校验工具查错最后给出脚本文件。), (human, {input}), (placeholder, {agent_scratchpad}), ])最后组装Agentagent create_openai_functions_agent(llm, tools, prompt) executor AgentExecutor( agentagent, toolstools, verboseTrue, max_iterations8, early_stopping_methodforce )看到max_iterations没有这是我在坑里爬出来的经验不加这个上限Agent遇到复杂用例时会陷入“生成代码—报错—再生成—再报错”的死循环。给它一个硬上限既能防止死循环也能预防账单爆炸。4.3 从用例内容到真正可跑的脚本给Agent输入一句“请把test_login.md里的登录用例转换成Playwright脚本先读文件再生成代码。”Agent的内部动作大致是调用load_testcase拿到结构化用例调用generate_playwright_code把步骤描述灌进提示词生成一段带selector的代码调用validate_code试跑如果validate返回的报错是“定位不到元素”Agent会尝试修正selector再跑一次你会发现这里的Agent其实就是在模拟你平时的工作流先读需求再写代码跑不通就看报错改代码。它把“写脚本”这个事变成了“决策 调用函数”。第一批跑的时候不要期望太高定位符的准确率可能不到60%。但只要你给每个页面提供一份可见元素清单比如用Playwright自带的accessibility snapshot抓一下页面结构把这份快照作为上下文塞给Agent准确率能往上抬一截。4.4 让Agent更可控的三个改进第一增加“人工确认节点”。在validate_code通过后不要直接把代码写进仓库。在Agent里加一条规则要求“给出代码摘要说明生成思路由人确认后才落盘”。这是最容易让团队接受AI测试开发的方式因为大家不信任“黑盒生成的脚本直接上CI”但会信任“AI负责写代码人负责审核”。第二把“失败样本”回灌给Agent。每次脚本跑失败把为什么失败、人是如何修好的记录下来存成一个json文件。下回Agent生成相似用例时把这个记录作为few-shot示例塞进提示词。这个做法是让Agent从“会用工具”进化到“懂业务”的关键。第三把用例文件做分片。如果用例文件很大不要整篇丢给模型。按“模块名”或者“功能编号”切片让Agent每次只处理一小段。这样上下文更聚焦生成结果更准token成本也更低。5. 常见问题与避坑记录5.1 AI幻觉在测试脚本里尤其危险大模型生成的代码如果语法错误一跑就报错反而不可怕。最怕的是它生成了“看起来对、跑起来全绿、但实际上啥也没验证”的脚本。比如说断言写成assert page.title() 首页但页面标题在数据初始化时并没有刷新测试通过了实际功能早就坏了。我总结出的对策有三条要求Agent在生成脚本时必须输出“验证点清单”列清楚每条断言在验证什么。人工审核脚本时优先看断言而不是看定位符。在CI里加入“变异测试”或“诱导失败”的check故意改断言语义看测试能不能炸出来。5.2 不要一上来就全自动先做“人审机跑”我见过很多团队引入AI测试开发失败败因都是“太激进”。刚搭好Agent就想着接入全回归结果AI生成的脚本跑崩了一个核心流程还把锅甩到模型头上。建议的切入路径是先用AI生成新模块的测试脚本人工review后上CI跑一个月稳定了再扩大到存量用例的转换最后再考虑Agent自动修复脚本。5.3 成本控制是技术活大模型API的计费方式决定了Agent跑一次不是免费的。特别是Agent每调一个工具都要发一轮模型请求。同样的任务简单提示词可能只要0.01元Agent循环下来可能就是0.5元。日积月累这是一笔不小的开支。控制成本我常用这几个手段缓存重复请求先让低成本的模型做粗分类只有疑难内容才调用高级模型限定Agent轮次不给它无限试错。给你一个参考数字我们跑一个100条用例的回归生成任务优化前成本约15元加了缓存和分片后降到4元左右质量反而更稳定。5.4 安全与隐私别留死角测试环境里经常有脱敏不彻底的账号、手机号、身份证号。把这些数据塞给外部大模型就等于把客户隐私送出门。我在实际项目里明确禁止把含真实数据的测试用例直接传给云端模型API。合规的做法是能本地部署就用本地部署的模型必须用云端API时先做数据脱敏把用户名、手机号、邮箱替换成符合规则的假数据脚本生成完毕后再做数据映射。问题现象根因解决方案Agent无限循环没设max_iterations加迭代上限失败直接终止生成的selector不稳定模型瞎猜页面结构注入DOM快照让Agent有依据断言假绿模型写的断言流于形式审核时优先看断言加诱导失败检查成本飙升一次任务反复调用大模型加缓存分片限制重试次数外部API误传敏感数据数据脱敏流程缺失本地部署或先脱敏再传写在最后我个人的体会是AI测试开发这个方向最大的价值不是让你用大模型写几个测试脚本而是逼着你重新思考“测试工作里哪些环节真正需要人”。当你把用例解析、脚本生成、失败初筛都交付给Agent之后你的时间会释放出来去盯那些模型搞不定的事业务风险判断、模糊需求的澄清、测试策略设计。最后一个建议别急着报班。先用两周时间把LangChain官方文档里的Agent教程过一遍再用第五章的案例思路做一个最小闭环。能跑通再决定要不要系统投入跑不通你也知道自己缺的是哪块。这条路适合有耐心、愿意和不确定性共处的人恰好这也是好测试该有的特质。
AI测试开发实战：用LangChain构建自动化脚本生成Agent
这两年我经常在技术社区看到一种提问干了五六年功能测试每天点来点去越干越恐慌想转型“AI测试开发”但网上课程这么多到底学什么才能不掉坑我部门这几年陆续有几个测试同事转型成功我也亲手带过几条AI测试链路。今天不卖课也不画饼就把“AI测试开发”这个方向拆开揉碎讲讲它到底是什么、测试人怎么一步步转型、以及我自己验证过的一条实操路线用LangChain做一个能读取测试用例、自动生成UI自动化脚本的Agent。看完你至少能分清哪些是真需求哪些是培训机构包装出来的概念。1. AI测试开发不是“测试加个AI插件”而是新工种1.1 传统测试开发和AI测试开发的本质差异传统测试开发的核心工作是写自动化框架、搭CI流水线、维护接口测试脚本、做性能工具选型。它解决的是“人手动执行太慢”的问题本质是把重复劳动代码化。AI测试开发多了一层把“人怎么设计用例、怎么分析失败、怎么评估风险”这件事拆成可以用大模型 数据 工具链自动完成的任务。它解决的不仅是“跑得慢”还有“想得慢、写不快、查不准”。举个例子传统写UI自动化你先得梳理测试步骤给元素定位再写Playwright或Selenium脚本。一个中等复杂度的页面写脚本加上调稳定性少说半天。AI测试开发干的活是把“需求描述 → 测试用例 → 可执行脚本”的过程自动化。你可以用大模型直接读一版需求产出用例草稿再让Agent补全脚本框架自己只需要做审核和调优。说白了传统测试开发把“点鼠标的手工测试”变成“写代码的自动化测试”AI测试开发把“写代码的自动化测试”变成“写提示词和搭工作流的测试智能体”。层级不同产出也不同。1.2 为什么这个方向会火起来我经历过几个阶段的测试工具演进最早的录制回放然后是关键字驱动再到Page Object模型到现在Playwright这类“响应式”框架。每次演进都是为了让人少写点样板代码。LLM的文本理解、代码生成能力正好撞上了测试行业的痛点用例文档一堆和代码是脱节的自动化脚本维护成本高因为页面一改就挂失败定位难截图几百张没人看。这些痛点天然适合用大模型做信息提取、脚本生成、根因分析。更关键的是AI测试开发是一个“杠杆效应”极强的岗位。一个人能维护的自动化用例数量是有限的但一个Agent可以同时服务多个项目的用例生成和脚本维护把你从几千条脚本的泥潭里拉出来。这也是为什么很多测试团队在预算有限的情况下愿意培养一个懂AI的测试开发而不是招一堆手工测试。1.3 你是否适合转这个方向我见过最快的转型者一个功能测试干了三年Python只会写if和for但逻辑思维强肯钻。TA用了大概四个月就把LangChain的Agent链路跑通了。我也见过写了几年自动化脚本的资深工程师反而被“以前怎么学测试”的思维框住迟迟进不了状态。给你一张自检表对照一下能力维度加分项减分项建议投入编程基础能用Python写自动化脚本只会跑现成框架每天2到3小时测试思维知道用例设计方法、测试分层只会按需求点执行持续保持数据分析会看日志、能拆解用例的共性几乎不碰数据需要系统补好奇心愿意研究新框架、自己动手验证等现成解决方案最关键软素质工具敏感度用过Playwright、Docker、Git只在Windows上点点点边学边补核心判断标准不是你会不会写代码而是你能不能忍受“踩坑、查文档、改提示词、再跑一遍”这种循环。AI测试开发这个方向没有成熟教材大量时间都花在跟模型对话、看报错、调整上下文上面。2. AI能在测试链路里干的活比你想的多得多2.1 需求解析与测试用例脑暴这是我认为落地最稳、见效最快的环节。以前需求评审完测试要自己对着PRD写用例容易漏边界场景。现在的做法是把需求文档丢给大模型让它从功能、边界、异常、性能、安全几个维度生成候选用例你再筛选、补全。我常用的提示词结构是“你是资深测试架构师。基于以下PRD输出功能测试用例要求每个用例包含前置条件、步骤、预期结果并标出优先级。”注意不是问一句就能出来高质量用例。你需要拆两步走第一步先让模型产出用户场景列表第二步再基于用户场景生成用例。一次性让模型输出几十条用例时它会把简单功能复杂化反而加大你的审核负担。2.2 从测试用例生成自动化脚本这是目前AI测试开发最吸引人的场景。它本质上是一个“文本到代码”的转换问题输入一份写好的测试用例输出一套用Playwright或Selenium写好的自动化脚本。但这里有个天坑模型没见过你的页面结构它生成的元素定位符基本是瞎猜。我早期的实验里大模型生成脚本的定位符准确率大概只有一半剩下全靠猜。要解决这个问题不能只靠提示词你得给模型提供页面信息——DOM快照、接口文档、数据特征让它有依据地写selector。后面的第四章我会详细写这个链路的工程实现这里先记住一条结论用例转脚本的上限不取决于模型聪明不聪明取决于你喂给它的页面上下文够不够。2.3 失败用例分析与缺陷定位自动化跑挂了以前你要翻日志、看截图、对照页面源码挨个排查是环境问题、数据问题还是真缺陷。大模型在处理这种“多模态信息”上有天然优势你给它一段报错堆栈、几张页面截图、近期的代码提交记录它能快速给出嫌疑点。我们团队实际跑过一种方案用例失败后自动把日志、截图、当时的前端API请求信息拼成一个上下文调大模型多模态接口让它输出“失败分类 可能原因 建议排查顺序”。效果最突出的是网络超时和断言杂音这一类问题模型几乎秒杀人工排查漏报率也不高。2.4 测试报告的“人话翻译”这个场景经常被低估。测试经理需要的不是一个40页的测试报告附件而是“本次版本质量行不行、风险在哪、该不该发版”。用Agent把测试执行结果、缺陷趋势、覆盖率数据拉出来生成一段执行摘要再附上原始数据链接这一套完全可以自动跑。我见过一个团队把每周测试报告从两小时压缩到十五分钟关键就是让大模型读测试管理平台的接口数据按固定模板生成周报只留一个人审核。3. 转型AI测试开发的技能地图3.1 编程基础不是刷题是写自动化框架很多测试转AI开发的第一反应是去刷LeetCode方向错了。你要的不是算法工程师而是能把想法落地成代码的脚本工程师。重点练这几个Python的异常处理、文件读写、装饰器、类与继承playwright的基本APIrequests库处理接口pytest的fixture和断言机制。练到啥程度算合格给你个标准能用Python写一个简单的Page Object框架传给新人能用加一个页面对象不用改框架代码。我不推荐一上来就啃Selenium源码或者研究Spring那是给Java后端看的。测试开发的核心是用脚本解决测试问题不是做中间件。3.2 把大模型当开发工具而不是聊天玩具这一步最卡人。很多人用完ChatGPT或者DeepSeek觉得“也就那样”原因是用它聊天而不是写工具。你要学会的是提示词工程里的三个基础能力任务拆分把“帮我把登录功能测试自动化”拆成“提取用例步骤 — 生成定位符候选 — 生成脚本结构 — 补断言”这样的小任务每个小任务对应一条独立提示词链。上下文管理不把整个代码库丢给模型而是只贴当前页面相关的代码片段、DOM子集或者接口样例。塞太多无关内容模型输出质量反而下降。校验闭环模型生成的代码必须有一个自动化校验环节比如让它跑静态检查、让测试框架试跑一次。不校验就把代码合进仓库早晚出事故。我建议你从改造自己的日常工作开始拿一份旧测试报告用大模型生成摘要拿一个历史bug让模型写缺陷分析拿一个旧页面录制脚本看它能不能重构出Playwright版本。3.3 掌握Agent核心架构这是AI测试开发的硬通货如果只学一样东西我推荐研究下Agent。AI测试开发绝大多数高级场景背后都是Agent在跑它自己决定调用哪个工具、什么时候停止、失败之后怎么重试。我对Agent的理解可以简化成三件套工具集合比如“读取测试用例”“读取页面结构”“执行上一步生成出来的脚本”“查询测试库状态”这些函数让Agent能调用外部系统。上下文组装把用户问题、测试用例、页面结构、历史失败记录拼成一段让大模型理解当前状态的文本。控制循环让模型决策下一步要调哪个工具执行后把结果贴回上下文再继续决策直到满足退出条件。LangChain在这里的优势在于它已经把“模型选工具、执行工具、更新上下文”这套循环封装好了你不用自己写调度代码。最新的LangChain版本里create_agent那一套API已经比较成熟支持结构化输出和工具调用校验。用熟了之后你会对这个职业方向有全新的感知。3.4 选型模型、框架、基础设施怎么配我做AI测试开发实验时前期先按“够用、便宜、稳定”三个指标选型。模型层面优先选能稳定输出函数调用结果的因为Agent场景对JSON结构化要求很高这是大模型最容易翻车的地方。框架层面LangChain在测试行业生态最成熟文档齐全社区案例多。如果你习惯更轻量直接写原生Python requests调用模型接口也完全可行甚至隐私性更好。但考虑到团队协作和维护我建议团队里至少有一个人熟悉LangChain的Agent体系。基础设施上最容易被忽略的是缓存。大模型API不便宜测试场景里同样的用例会跑很多遍。一定要在中间加一层缓存把“参数相同、结果相同”的调用命中缓存成本能降一半以上。我团队跑了一个月之后缓存命中率到40%账单数字好看了很多。4. 实操用LangChain做一个“用例转自动化脚本Agent”4.1 整体设计思路为了让你对AI测试开发有立体感受我把第四章做成一个可直接伪代码复现的案例。假设你有这样一份Markdown格式的测试用例## 用例登录功能 前置条件系统已部署数据库正常 步骤 1. 打开首页 2. 输入有效用户名 3. 输入有效密码 4. 点击登录按钮 预期结果跳转到首页右上角显示用户昵称目标让Agent读取这份用例调用工具生成对应的Pytest Playwright脚本文件。整体架构分三层读取层Agent先调用“load_testcase”工具读取Markdown用例并解析成结构化json。生成层Agent结合用例里的步骤调用“generate_playwright_code”工具让大模型输出脚本代码。校验层Agent调用“validate_code”工具用Python编译器做语法检查再用pytest试跑。如果失败把报错贴回给Agent让它修正后重试。关键设计点来了不要试图让Agent一步到位生成完整脚本而是强制它走“读用例 → 写代码 → 校验 → 修正”的循环。这样每次生成的代码都经过一次实际试跑的反馈质量比“一次性生成”高很多。4.2 搭建基础代码框架我用的是Python 3.10 LangChain Playwright。先安装依赖pip install langchain langchain-openai playwright pytest pytest-playwright playwright install chromium核心代码逻辑可以这样组织from langchain_openai import ChatOpenAI from langchain.agents import create_openai_functions_agent, AgentExecutor from langchain.tools import StructuredTool from langchain.prompts import ChatPromptTemplate # 这里接入你实际可用的模型服务本地部署或云API都可以 llm ChatOpenAI( modelyour-model, temperature0, max_retries1 )我强烈建议temperature设成0原因很简单测试脚本代码最怕“创造性发挥”你必须让它输出确定性内容。接下来定义三个工具函数def load_testcase(file_path: str) - dict: with open(file_path, r, encodingutf-8) as f: content f.read() # 用正则或简单解析把Markdown转成结构化json # return {title: ..., steps: [...], expected: ...} def generate_playwright_code(testcase: dict) - str: # 调用模型生成代码的prompt模板 # 返回脚本字符串 def validate_code(code: str) - str: import subprocess, tempfile # 写入临时py文件先做语法编译再用pytest运行 # 返回运行结果或报错信息然后把这些函数包装成StructuredTooltools [ StructuredTool.from_function(funcload_testcase), StructuredTool.from_function(funcgenerate_playwright_code), StructuredTool.from_function(funcvalidate_code), ]提示词模板的核心是这样prompt ChatPromptTemplate.from_messages([ (system, 你是测试开发工程师负责把Markdown测试用例转成可运行的Playwright测试脚本。你必须先读取用例再生成代码调用校验工具查错最后给出脚本文件。), (human, {input}), (placeholder, {agent_scratchpad}), ])最后组装Agentagent create_openai_functions_agent(llm, tools, prompt) executor AgentExecutor( agentagent, toolstools, verboseTrue, max_iterations8, early_stopping_methodforce )看到max_iterations没有这是我在坑里爬出来的经验不加这个上限Agent遇到复杂用例时会陷入“生成代码—报错—再生成—再报错”的死循环。给它一个硬上限既能防止死循环也能预防账单爆炸。4.3 从用例内容到真正可跑的脚本给Agent输入一句“请把test_login.md里的登录用例转换成Playwright脚本先读文件再生成代码。”Agent的内部动作大致是调用load_testcase拿到结构化用例调用generate_playwright_code把步骤描述灌进提示词生成一段带selector的代码调用validate_code试跑如果validate返回的报错是“定位不到元素”Agent会尝试修正selector再跑一次你会发现这里的Agent其实就是在模拟你平时的工作流先读需求再写代码跑不通就看报错改代码。它把“写脚本”这个事变成了“决策 调用函数”。第一批跑的时候不要期望太高定位符的准确率可能不到60%。但只要你给每个页面提供一份可见元素清单比如用Playwright自带的accessibility snapshot抓一下页面结构把这份快照作为上下文塞给Agent准确率能往上抬一截。4.4 让Agent更可控的三个改进第一增加“人工确认节点”。在validate_code通过后不要直接把代码写进仓库。在Agent里加一条规则要求“给出代码摘要说明生成思路由人确认后才落盘”。这是最容易让团队接受AI测试开发的方式因为大家不信任“黑盒生成的脚本直接上CI”但会信任“AI负责写代码人负责审核”。第二把“失败样本”回灌给Agent。每次脚本跑失败把为什么失败、人是如何修好的记录下来存成一个json文件。下回Agent生成相似用例时把这个记录作为few-shot示例塞进提示词。这个做法是让Agent从“会用工具”进化到“懂业务”的关键。第三把用例文件做分片。如果用例文件很大不要整篇丢给模型。按“模块名”或者“功能编号”切片让Agent每次只处理一小段。这样上下文更聚焦生成结果更准token成本也更低。5. 常见问题与避坑记录5.1 AI幻觉在测试脚本里尤其危险大模型生成的代码如果语法错误一跑就报错反而不可怕。最怕的是它生成了“看起来对、跑起来全绿、但实际上啥也没验证”的脚本。比如说断言写成assert page.title() 首页但页面标题在数据初始化时并没有刷新测试通过了实际功能早就坏了。我总结出的对策有三条要求Agent在生成脚本时必须输出“验证点清单”列清楚每条断言在验证什么。人工审核脚本时优先看断言而不是看定位符。在CI里加入“变异测试”或“诱导失败”的check故意改断言语义看测试能不能炸出来。5.2 不要一上来就全自动先做“人审机跑”我见过很多团队引入AI测试开发失败败因都是“太激进”。刚搭好Agent就想着接入全回归结果AI生成的脚本跑崩了一个核心流程还把锅甩到模型头上。建议的切入路径是先用AI生成新模块的测试脚本人工review后上CI跑一个月稳定了再扩大到存量用例的转换最后再考虑Agent自动修复脚本。5.3 成本控制是技术活大模型API的计费方式决定了Agent跑一次不是免费的。特别是Agent每调一个工具都要发一轮模型请求。同样的任务简单提示词可能只要0.01元Agent循环下来可能就是0.5元。日积月累这是一笔不小的开支。控制成本我常用这几个手段缓存重复请求先让低成本的模型做粗分类只有疑难内容才调用高级模型限定Agent轮次不给它无限试错。给你一个参考数字我们跑一个100条用例的回归生成任务优化前成本约15元加了缓存和分片后降到4元左右质量反而更稳定。5.4 安全与隐私别留死角测试环境里经常有脱敏不彻底的账号、手机号、身份证号。把这些数据塞给外部大模型就等于把客户隐私送出门。我在实际项目里明确禁止把含真实数据的测试用例直接传给云端模型API。合规的做法是能本地部署就用本地部署的模型必须用云端API时先做数据脱敏把用户名、手机号、邮箱替换成符合规则的假数据脚本生成完毕后再做数据映射。问题现象根因解决方案Agent无限循环没设max_iterations加迭代上限失败直接终止生成的selector不稳定模型瞎猜页面结构注入DOM快照让Agent有依据断言假绿模型写的断言流于形式审核时优先看断言加诱导失败检查成本飙升一次任务反复调用大模型加缓存分片限制重试次数外部API误传敏感数据数据脱敏流程缺失本地部署或先脱敏再传写在最后我个人的体会是AI测试开发这个方向最大的价值不是让你用大模型写几个测试脚本而是逼着你重新思考“测试工作里哪些环节真正需要人”。当你把用例解析、脚本生成、失败初筛都交付给Agent之后你的时间会释放出来去盯那些模型搞不定的事业务风险判断、模糊需求的澄清、测试策略设计。最后一个建议别急着报班。先用两周时间把LangChain官方文档里的Agent教程过一遍再用第五章的案例思路做一个最小闭环。能跑通再决定要不要系统投入跑不通你也知道自己缺的是哪块。这条路适合有耐心、愿意和不确定性共处的人恰好这也是好测试该有的特质。
