八年测试老兵AI测试转型实战：大模型与智能体落地路径

1. 一个八年测试老兵的真实困惑先把时间线拉回到去年年底。我在一家做企业级SaaS的公司带测试开发团队日常工作是维护一套跑了五年的接口自动化框架外加一堆UI自动化脚本。团队里六个人每天跟Jenkins流水线、Allure报告、Appium的稳定性问题打交道。按理说这套东西我闭着眼睛都能搭起来接口自动化框架从Java的TestNG换到Python的pytestUI自动化从Selenium到Appium再到后来的Playwright每一步都踩过坑也都填过坑。但去年下半年开始事情起了变化。产品那边接入了大模型能力测试用例的生成、缺陷描述的归类、甚至部分回归用例的筛选都开始往AI方向靠。我一开始是抗拒的觉得这些花里胡哨的东西不如老老实实写断言来得实在。直到有一次一个业务线的回归用例有三千多条人工筛选优先级要花两天而隔壁团队用一套基于大模型的用例推荐方案半小时就给出了排序结果准确率还比我人工挑的高。那一刻我意识到不是AI要不要用的问题是我再不补课就要被落下了。所以当看到有AI测试方向的系统课程时我报了名。不是因为我不会测试恰恰是因为我太会传统测试了才更清楚自己的短板在哪里。这篇文章就把我这段时间的学习路径、踩过的坑、以及实际落地过程中的思考完整地分享出来。适合两类人看一是跟我一样有多年传统测试开发经验、想往AI测试方向转的老兵二是刚入行不久、想直接走AI测试路线的新人。我会尽量把每个环节讲透包括为什么这么选、怎么落地、哪里容易翻车。2. 为什么传统测试开发必须补上AI这一课2.1 传统自动化测试的天花板在哪里干了八年测试开发我最深的体会是传统自动化测试解决的是确定性问题。接口返回码是不是200字段类型对不对UI元素能不能点到这些都是确定性的断言。只要需求不变、代码不变脚本跑一万遍结果都一样。这套逻辑支撑了过去十年整个测试行业的方法论。但它有三个绕不过去的天花板。第一维护成本随用例数量线性增长。我维护过最大的一个UI自动化项目两千多条用例每次前端改版至少三分之一的选择器要修光修脚本就占了大半工作量。第二无法处理非确定性场景。比如一个推荐算法返回的结果你没法用assertEquals去断言它必须等于某个值只能人工看或者写一堆模糊匹配规则效果很差。第三测试用例的设计高度依赖人的经验。一个新手和一个老手写出来的用例覆盖度可能差三倍而传统框架没有任何机制去弥补这个差距。这三个天花板恰好是大模型和智能体擅长的地方。大模型能理解自然语言描述的需求能生成多样化的测试数据能对非确定性的输出做语义层面的判断。智能体则能把多个测试步骤串起来根据中间结果动态调整下一步动作。这不是替代传统自动化而是在传统自动化够不着的地方补位。2.2 AI测试到底在测什么很多人一听AI测试第一反应是用AI来写测试脚本。这个理解太窄了。我学下来AI测试至少覆盖四个层面。第一个层面是测试资产生成。包括根据需求文档生成测试用例、根据接口定义生成测试数据、根据页面结构生成UI自动化脚本。这一层解决的是写的效率问题。第二个层面是测试执行增强。比如用视觉大模型做UI元素的智能定位不再依赖脆弱的XPath用大模型做接口返回的语义校验判断一段文本是否合理而不是相等。第三个层面是缺陷分析与归因。把失败的用例日志、堆栈信息、截图丢给大模型让它给出可能的根因排序这个在实际排查中非常省时间。第四个层面是测试策略优化。用历史执行数据训练模型预测哪些用例最可能发现缺陷从而做精准的回归筛选。这四个层面里第一层和第三层落地最快第二层需要一定的工程能力第四层对数据量有要求。我建议新手从第一层和第三层入手见效快也容易建立信心。2.3 大模型和智能体在测试中的角色分工这里要厘清一个概念大模型和智能体不是一回事。大模型是大脑负责理解和生成智能体是手脚负责规划和执行。在测试场景里大模型可以做单点的任务比如给你一段需求它生成十条用例。但如果你要它完成打开App、登录、搜索商品、加入购物车、下单、校验订单状态这一整套流程单靠大模型不行因为它没有记忆、没有工具调用能力、没法根据中间状态做决策。这时候就需要智能体框架把大模型作为推理引擎配上工具调用比如点击、输入、截图、记忆模块记住上一步做了什么、规划模块决定下一步做什么才能跑通完整流程。我实际用下来智能体在UI自动化测试里的价值最大因为UI测试本身就是一系列有状态的操作序列天然适合用智能体来编排。而接口测试和单元测试大模型直接生成断言和数据的性价比更高不一定需要上智能体。3. 我的AI测试学习路径与核心工具选型3.1 从大模型基础认知开始别急着写代码我报的课程第一周没有写任何代码全是概念课。一开始我觉得浪费时间后来发现这一步很关键。你得先搞清楚大模型的能力边界在哪里。比如它擅长什么文本理解、代码生成、语义匹配、多轮对话。它不擅长什么精确计算、实时数据获取、确定性输出。知道这些你才知道哪些测试任务可以交给它哪些必须用传统方法兜底。举个例子我试过让大模型判断两个JSON结构是否等价。它有时候会把字段顺序不同但内容相同的两个JSON判为不等价因为它是按token概率生成的不是按结构化比较。这种任务就必须用代码做不能用大模型。反过来判断一段用户评论是正面还是负面大模型比写规则准确得多。所以第一周的概念课本质是帮你建立任务分配的判断力。3.2 本地部署还是调API我的选择逻辑课程里讲了两种使用大模型的方式本地部署和调用云端API。我两种都试了。本地部署我用的是Ollama跑了一个7B参数量的模型显卡是RX6750GRE。实测下来7B模型在测试用例生成这种任务上质量勉强够用但速度慢生成十条用例要等将近一分钟。后来换成调用云端API同样的任务三秒出结果质量还更好。所以我的选择逻辑很简单学习和实验阶段用本地部署成本低、数据不出内网实际生产用云端API速度和质量的性价比更高。本地部署还有一个好处是你可以做微调比如用自己团队的测试用例数据去微调一个行业模型让它生成的用例更贴合你们的业务风格。这个我还在摸索阶段后面如果有成果再单独写。这里插一句关于模型选择的心得。市面上知名的大模型很多各有侧重。有的擅长代码生成有的擅长中文理解有的在长文本处理上更强。我的建议是不要迷信某一个模型而是根据任务类型做选择。测试用例生成和代码相关的任务选代码能力强的需求文档理解和缺陷描述归类选中文语义能力强的。课程里给了一个对比表我整理了一下我实际用过的几个方向任务类型推荐模型特点我的实际体验测试用例生成代码能力强、结构化输出稳定生成速度快但需要给清晰的格式约束缺陷日志分析长文本理解强、推理链清晰对堆栈信息的归因准确率约七成UI元素语义定位多模态能力强截图理解准确但需要配合DOM信息测试数据生成多样性好、边界值覆盖全比人工造数据快十倍以上3.3 智能体框架怎么选我踩过的坑智能体框架我试了三个方向。一个是LangChain加LangGraph的组合这个偏底层灵活度高但学习曲线陡写一个简单的测试智能体要写不少胶水代码。第二个是Dify这类低代码平台拖拖拽拽就能搭一个智能体上手快但定制能力有限复杂逻辑不好实现。第三个是直接用大模型的原生工具调用能力自己写编排逻辑这个最灵活但什么都得自己来。我最后的选择是原型验证用Dify快速看效果生产落地用LangGraph保证可控性。为什么不用纯原生因为测试流程里有很多状态管理和异常重试的逻辑自己写容易出bugLangGraph的状态图模型天然适合这种场景。举个例子一个登录流程如果验证码识别失败需要重试三次每次重试要刷新验证码这个逻辑用状态图表达很清晰用纯代码写就容易乱。这里有个坑要提醒智能体框架的版本迭代非常快我学的时候用的API过了一个月就变了。所以不要死记某个框架的具体写法要理解它的核心概念——状态、节点、边、工具调用这些概念是通用的换框架也能迁移。4. AI测试落地的四个核心实操场景4.1 用大模型批量生成测试用例的完整流程这是我落地最快、收益最明显的一个场景。传统做法是产品给需求文档测试人员一条条读一条条写用例一个中等规模的需求写用例要两天。现在我的流程是这样的第一步把需求文档做预处理。不要直接把整篇文档丢给大模型那样它抓不住重点。我的做法是按功能模块拆成小段每段控制在五百字以内并且明确告诉它这段描述的是什么功能。第二步给大模型一个清晰的输出格式约束。我用的提示词模板大概是这样的你是一个资深测试工程师请根据以下需求描述生成测试用例输出格式为表格包含用例编号、用例标题、前置条件、操作步骤、预期结果、优先级。第三步对生成的用例做人工评审和补充。大模型生成的用例覆盖度大概能到人工的七八成但边界值和异常场景容易漏需要人工补。实测下来一个中等需求原来两天的工作量现在半天就能完成而且用例的规范性比新人写的还好。但要注意大模型生成的用例不能直接入库必须经过人工评审。我遇到过它把不存在的功能点编出来的情况也遇到过它把两个功能的步骤混在一起。所以评审环节不能省。4.2 接口自动化测试的AI增强实践接口自动化是我最熟悉的领域所以我在这个方向上做的AI增强也最深入。传统接口自动化的问题是断言写得太死接口返回一个动态的token或者时间戳脚本就挂了。我的做法是用大模型做语义断言。比如一个查询用户信息的接口返回的昵称字段我不再断言它等于某个固定值而是让大模型判断这个昵称是否是一个合理的用户昵称。这样即使测试数据变了断言依然有效。另一个增强点是失败用例的智能归因。以前接口脚本挂了我要去看日志、看堆栈、看请求响应排查一个失败平均要十分钟。现在我把失败的请求、响应、堆栈信息一起丢给大模型让它给出可能的根因排序。实测下来排在第一位的根因准确率大概六成前三位能到八成五。这意味着我排查一个失败的时间从十分钟降到了三分钟。这里有个细节要注意丢给大模型的日志要做脱敏处理。接口请求里可能有用户手机号、身份证号这些敏感信息不能直接发给云端API。我的做法是在发送前用正则把敏感字段替换成占位符这个步骤必须自动化不能靠人记得。4.3 UI自动化测试的智能体编排方案UI自动化是我觉得智能体价值最大的地方。传统的Appium脚本元素定位靠ID或者XPath前端一改版就失效。我尝试用智能体来做UI测试思路是这样的给智能体一个目标比如登录后进入个人中心检查昵称是否正确显示智能体自己规划步骤自己找元素自己判断结果。具体实现上我用的是视觉大模型加DOM信息结合的方式。智能体每一步先截图把截图和当前页面的DOM结构一起发给大模型让它判断下一步该点哪里、该输入什么。这样即使元素ID变了只要视觉位置和语义没变智能体依然能找到。实测下来在一个中等复杂度的App上智能体的流程通过率能到七成左右剩下的三成主要是验证码和复杂手势操作这些还是得用传统脚本兜底。所以我的结论是智能体不是替代Appium而是补充Appium。稳定的核心流程用Appium保证确定性易变的、探索性的流程用智能体保证灵活性。两者结合整体稳定性反而比纯Appium高。4.4 缺陷分析与测试报告生成这个场景是我觉得最省时间的。以前一个版本测完写测试报告要半天整理缺陷列表、归类、统计、写结论。现在我把缺陷数据导出成结构化格式丢给大模型让它生成报告初稿包括缺陷分布、严重程度统计、主要风险点。我再在初稿基础上修改半小时就能出终稿。缺陷分析方面我让大模型对每个缺陷做自动归类比如是UI问题、逻辑问题、性能问题还是兼容性问题。归类准确率大概八成比人工快很多。而且它还能发现一些人工容易忽略的模式比如这个版本的缺陷集中在支付模块且都是并发场景这种洞察对测试策略调整很有价值。5. 实操过程中踩过的坑与排查技巧5.1 大模型输出不稳定的三种表现和对策第一个表现是格式漂移。你让它输出表格它有时候输出表格有时候输出列表有时候输出一段话。对策是在提示词里加few-shot示例给它两三个正确输出的例子格式稳定性会大幅提升。第二个表现是内容幻觉。它会编造不存在的功能点或者接口字段。对策是给它明确的约束比如只根据以下需求描述生成用例不要添加需求中没有的功能。第三个表现是重复生成。同样的输入两次输出差异很大。对策是降低temperature参数我一般设在0.3左右既能保证一定的多样性又不会太飘。5.2 智能体执行卡死的排查思路智能体跑UI测试的时候最常见的问题是卡死。表现是它一直在某个步骤循环或者停在那里不动。我的排查思路分三步第一步看日志确认它卡在哪个节点第二步看截图确认当前页面状态第三步看它的思考过程很多智能体框架会输出推理链看它为什么做了这个决策。大部分卡死是因为元素定位失败后没有正确的重试逻辑或者页面加载慢导致截图时页面还没渲染完。对策是加显式等待和最大重试次数超过次数就报错退出不要让它无限循环。5.3 成本控制的几个实用技巧用云端API是要花钱的我第一个月没注意账单出来吓了一跳。后来总结了几个控制成本的技巧。第一缓存重复请求。同样的需求文档不要重复生成用例把结果存下来。第二用小模型做粗筛大模型做精修。比如缺陷归类先用小模型跑一遍不确定的再交给大模型。第三控制输入长度。不要把整个日志文件丢进去只截取关键部分。第四设置预算告警。大部分云平台都支持设置月度预算超过就告警避免意外超支。5.4 常见问题速查表问题现象可能原因排查方法解决方案生成用例格式混乱提示词约束不够检查输出格式描述加few-shot示例智能体循环卡死元素定位失败无重试上限看推理链和截图加最大重试次数断言误判大模型语义理解偏差对比人工判断结果关键断言用代码兜底API调用超时输入过长或网络波动看请求日志截断输入加超时重试成本超预期重复请求未缓存看调用量统计加缓存层和预算告警6. 给不同阶段测试人的学习建议6.1 传统测试开发转AI测试的最短路径如果你跟我一样有多年传统测试经验我的建议是不要从零学机器学习那条路太长。你的优势是懂测试流程、懂业务场景缺的是对大模型和智能体的工程化应用能力。所以最短路径是第一周搞懂大模型的能力边界和提示词工程第二周用一个实际需求练手用例生成第三周尝试把大模型接入现有的自动化框架做增强第四周学一个智能体框架搭一个简单demo。一个月下来你就能在团队里推动AI测试的落地了。6.2 新人直接走AI测试路线的注意事项如果你是新人直接学AI测试我的建议是不要跳过传统测试基础。我见过一些新人会用大模型生成用例但连等价类划分和边界值分析都说不清楚生成的用例质量很差。传统测试理论是根基AI是工具。根基不牢工具再好也白搭。所以新人的路径应该是先花三个月把传统测试理论和自动化工具学会再花三个月学AI测试的工程化应用。这样出来的人比纯学AI的更有竞争力。6.3 团队推广AI测试的切入点如果你是想在团队里推广AI测试我的建议是从缺陷分析这个点切入。为什么因为这件事不改变现有的测试流程只是在流程末端加了一个提效环节阻力最小。而且效果立竿见影原来排查一个失败要十分钟现在三分钟团队成员自己就能感受到好处。等大家接受了再往用例生成、智能体编排这些更深的环节推。一上来就搞大变革容易遭到抵触。7. 我个人的几点真实体会学了这段时间最大的感受是AI测试不是一门新技术而是一种新的工作方式。它没有推翻传统测试的任何理论只是在传统测试够不着的地方补了位。那些说AI要取代测试工程师的要么是不懂测试要么是不懂AI。真正会发生的是会用AI的测试工程师取代不会用的。另一个体会是不要追求全自动。我见过一些团队非要搞一个全自动的AI测试平台结果投入巨大效果一般。我的做法是半自动AI负责生成和初筛人负责评审和决策。这样既享受了效率提升又保证了质量可控。测试这件事最终是要对质量负责的不能为了AI而AI。最后一个体会是关于学习心态。我干了八年测试报班的时候确实有点不好意思觉得一把年纪了还跟新人一起上课。但学下来发现班里有不少跟我一样的老兵大家的问题都很实际讨论的质量比纯新人班高很多。所以如果你也在犹豫要不要补课我的建议是别犹豫你多年的经验不是包袱而是你学AI测试最大的加速器。你知道哪些场景值得用AI哪些不值得这个判断力是新人没有的。