开篇测试这行正在被自己人“干掉”前阵子团队里有人提了个问题把我问住了“如果我们最终让智能体来写测试、跑测试、判断测试结果那测试工程师的脚本能力还值钱吗”这个问题背后其实是一个更大的趋势——从脚本到智能体测试范式正在消失。别误会测试本身不会消失消失的是我们过去十几年习以为常的那套做事方式写脚本、堆断言、维护用例库、天天修脚本碎掉的“脆弱自动化”。取而代之的是让大模型驱动的智能体自己去理解业务、规划操作、执行验证、分析失败原因。这个方向不是概念炒作。我最近把一套设备老化测试从纯脚本改成了智能体方案跑了将近两个月几百轮执行下来最大的感受是“测试”这个动作还在但“写测试”和“跑测试”的边界已经被重新定义了。这篇文章不聊虚的就是把这次改造的来龙去脉、架构思路、踩坑记录和对行业的影响摊开聊透给正在纠结要不要上智能体的同行一个参考。1. 脚本测试的黄金时代以及那个“看不见的天花板”1.1 脚本为什么能统治测试领域这么多年先说说脚本测试为什么能火这么多年。核心就一句话它把“人肉重复”变成了“机器重复”。一个自动化测试脚本本质上是一份“操作说明书”告诉机器先做什么、再做什么、每一步验证什么。只要步骤不变脚本就能稳定地跑一千遍、一万遍而且不会累、不会抱怨、不会漏步骤。拿我早年做过的UI自动化举例。Appium那套框架当时真的很香写一段Python脚本配置好Desired Capabilities就能驱动手机App做点击、滑动、输入、断言。一套回归用例几十条夜间跑完第二天早上看报告节省的时间非常可观。那时候圈子里流行一句话“谁自动化做得好谁就能按时下班。”脚本范式的逻辑非常自洽它解决的问题也很清晰流程稳定、输入固定、预期明确的一类测试最适合脚本化。后台接口测试更是如此给定参数、校验返回脚本跑起来又快又准。Shell脚本做环境检查、Python脚本做数据构造、Jenkins定时触发这套组合拳几乎成了测试团队的标准配置。但是这套东西越用越久问题也越攒越多。不是脚本不行了而是测试需求变了。脚本能解决“已知的重复”却很难处理“未知的变化”。一旦被测对象的行为不那么听话脚本就成了那个需要天天擦屁股的“脆弱机器人”。1.2 当测试对象开始“不配合”脚本的裂缝出现了我举几个真实场景做过测试的同学肯定有共鸣。第一个场景元素定位失效。App改版开发把某个按钮的resource-id从btn_confirm改成了btn_ok脚本第二天直接挂掉。报错信息永远是“element not found”然后你辛辛苦苦从几百行日志里定位到那一行改完明天可能又崩另一个。这不是技术问题这是维护成本问题。脚本对界面的每一次变化都极其敏感因为它的每一步都是“硬编码”的。第二个场景异常分支覆盖不住。设备老化测试里我们需要模拟用户长时间使用后的性能衰减。脚本的做法是先写一套操作序列比如“循环启动App、反复切换页面、持续读写缓存”再定时采集CPU、内存、温度。脚本确实能执行这个序列但它不会思考如果App在第37轮崩溃了脚本该干什么如果系统弹出了一个未知弹窗脚本是继续操作还是停下来传统脚本遇到这类情况要么死等要么直接失败它不具备“临场应变”能力。第三个场景断言写多了反而成了负担。很多团队为了让测试“严谨”在脚本里堆了一大堆断言每个步骤都要验证。结果就是用例越来越长、执行越来越慢、误报率越来越高。有一次一个用例因为Wi-Fi信号波动导致某个断言失败排查了半天发现根本不是功能问题。脚本只能按字面意思执行断言它没法判断“这个失败是否值得关注”。这些裂缝的本质是什么是脚本范式把测试过程压缩成了“有限状态机”。它假设每个步骤的输入输出都是可预见的但真实世界的测试对象尤其是复杂的软件系统状态空间是近乎无限的。当“有限”去应对“无限”崩溃只是时间问题。2. 智能体测试的本质从“执行指令”到“理解意图”2.1 测试智能体到底在做什么要说清楚智能体测试得先放下对“自动化”的固有认知。自动化是“给定步骤机器执行”智能体是“给定目标模型规划”。一个测试智能体通常由三部分组成大模型作为决策大脑、一组可调用的工具、一个任务目标或验收标准。它接收的不是“点击登录按钮”这种原子指令而是“验证用户能否正常登录并完成购买流程”这种高层意图。然后由智能体自己拆解步骤、决定先做什么后做什么、执行过程中根据界面反馈动态调整策略。举个例子。我让一个智能体去执行App的冒烟测试给它定的目标是“启动App完成登录进入首页确认核心模块正常显示。”它自己会规划一个大致的步骤序列比如先看登录页状态、识别输入框、尝试输入测试账号、点击登录、等待跳转、检查首页元素。但关键是如果登录后弹出了隐私政策弹窗智能体认得这是个“需要处理的弹窗”会先把它关掉再继续如果某个按钮加载慢了它会等待而不是立刻报错如果页面出现了意外错误它会尝试截图并记录下来而不是傻等超时。这个过程本质上模拟了一个测试工程师的思维方式——不是死记硬背的“操作手册”而是一套“理解推理行动”的闭环。智能体时刻在问自己三个问题当前我看到了什么我该做什么做完之后结果是否符合预期2.2 智能体和脚本的核心差异不是“自动”而是“自主”很多人第一次接触智能体测试时容易陷入一个误区以为就是用大模型来写脚本。我一开始也这么想过后来发现完全不对。用LLM生成脚本只是把“人写脚本”变成了“AI写脚本”执行逻辑还是脚本那套照样脆弱。真正的智能体测试是把“脚本”这个中间层整个干掉。我画过一张表来对比这两种思路的差别维度传统脚本测试智能体测试输入指定步骤、指定数据描述目标、描述验收标准执行方式按顺序执行遇到异常即失败按计划推进遇到异常动态调整对变化的容忍低任何元素变更都可能导致挂掉高能通过语义识别和上下文判断来处理变化失败分析留给人工看日志智能体自己记录、归类、给出初步原因维护成本高脚本需要持续更新低目标是稳定的路径可调整能力边界只能做预先定义好的事能处理边界情况能探索性执行这个表不一定绝对精确但方向上很明确脚本测的是“已知的已知”智能体尝试覆盖“已知的未知”。它不保证每一步都按原计划走但它保证不偏离目标。这种“目标导向”的特性恰恰解决了脚本最头疼的变更敏感问题。再说白一点脚本是“照着菜谱做菜”中途发现没有盐就停摆智能体是“你说想吃回锅肉我自己去冰箱看看有什么食材缺了五花肉就用后腿肉顶上只要最后端出来是一盘像样的回锅肉”。当然这么做有风险智能体可能会“发挥过度”所以后面要给它加约束这个我在第5部分细说。2.3 多智能体协作测试任务如何被拆解单智能体能搞定一部分任务但真正常见的生产级场景需要的是多智能体协作。这个方向现在特别火Dify这类智能体平台也在推类似的编排能力。为什么需要多智能体因为一个复杂的测试任务职责差异很大。拿“全链路压力测试后的稳定性验证”来说需要一个人盯着业务操作、一个人盯着系统资源、一个人分析日志、一个人整理报告。如果让一个智能体全干它要么上下文爆炸要么精力分散最后哪个都干不好。我在设计设备老化测试时就用了三智能体协作的方案执行智能体负责按计划执行App操作序列模拟用户行为感知界面状态遇到异常时记录现场并尝试恢复。监测智能体负责采集系统数据包括CPU、内存、GPU频率、温度、电池状态等周期性写入时序数据库并对异常数值做标记。分析智能体负责在测试结束后汇总执行日志和监测数据进行初步根因分析输出一份带图表和结论的报告。三个智能体各司其职通过一个共享状态池通信。执行智能体发现卡顿会把时间点标记为事件监测智能体看到那个时间点CPU飙高、温度异常就会把两者关联起来分析智能体拿到这些信息后能给出“疑似渲染线程阻塞导致功耗异常”之类的推断。这就是多智能体的价值不是让一个更聪明的AI做所有事而是让多个专用AI像团队一样配合把复杂任务拆成专业分工。对测试来说这简直是天然匹配——测试本身就是个多工种协作的活儿。3. 一个真实场景的改造设备老化测试从脚本到智能体3.1 原来的脚本方案长什么样讲点具体的。这半年我一直在折腾的是一套设备老化测试系统。背景很简单智能硬件产品生命周期长要做“半年模拟使用”的加速测试验证长时间运行后会不会卡顿、会不会发热、会不会内存泄漏、会不会出现资源饥饿。原来的方案是典型的脚本打法几个核心模块操作脚本库用Python写了一批操作序列比如“循环切换Tab页”、“反复打开关闭相机”、“持续滚动长列表”。每个脚本内部串了Appium的调用模拟真实点击和手势。计划调度用Shell脚本Jenkins做个定时循环让每类操作每隔一段时间执行一轮。数据采集用adb shell命令周期性抓取CPU、内存、温度输出到CSV文件。结果判定跑完后人工拉数据用Python画趋势图肉眼看有没有异常拐点。这套系统有问题吗有而且不少。最大的问题是误报和漏报之间的失衡。脚本操作序列一旦遇到弹窗、权限请求、网络延迟这些“非预期事件”就会卡住。卡住后如果没人理整个测试流程就废了。所以早期我们安排专人值班半夜机器报警了爬起来处理别提多痛苦。还有一个问题是数据孤岛。操作日志、系统日志、性能数据是三个独立的文件哪天App崩了想定位是哪个操作导致的得手动把三个文件按时间戳对齐工作量巨大而且特别容易漏。那时候我就在想这活儿能不能让AI来干。3.2 智能体版本怎么设计后来大模型技术成熟了我开始尝试把系统重构成智能体方案。重构的原则就一个尽量少改底层硬件交互尽可能多地替换“决策层逻辑”。先看底层Appium这些驱动层还是保留因为点击、滑动这类操作Appium已经做得很成熟没必要另起炉灶。我做的事是把这些操作封装成智能体的“工具调用接口”。比如tool_tap(element_id) tool_swipe(start_x, start_y, end_x, end_y) tool_wait(seconds) tool_screenshot() tool_get_text() tool_check_element_by_text(text)每个工具都有明确的输入输出描述大模型读到这些描述就知道“我可以用它做什么”。然后定义执行智能体的系统提示词核心逻辑是你是一名设备老化测试助理。你的目标是在不打扰用户的情况下尽可能长时间地模拟真实用户使用设备。遇到弹窗时判断是否可关闭能关闭则优先关闭。遇到应用崩溃时记录当前截图和日志然后重启应用继续测试不要停止整个任务。每完成10轮操作输出一次阶段摘要。这条提示词里最关键的是“遇到问题不要停止而是记录后继续”这条规则。传统脚本遇到异常就崩智能体收到这个指令后会有意识地处理异常再回来执行主任务。多智能体的协作逻辑也一并搭好了。执行智能体在操作过程中每一轮都会往共享状态池推一条“当前任务状态”监测智能体持续在后台采集系统数据并且会主动去读状态池里新产生的事件标签分析智能体在测试结束时从状态池拉取全部数据生成报告。通信协议我用的是JSON通过本地一个内存队列中转。这套做法工程上不复杂但效果非常明显。3.3 实测对比脚本和智能体的差距在哪改造完成后我把新旧两套方案放在同一个硬件环境上各跑了7天用同一套测试计划和业务场景。结果很有代表性。从任务完成度来看旧脚本方案7天里中断了4次其中有2次是因为弹窗没处理1次是因为应用崩溃后没有恢复逻辑1次是网络波动导致Appium连接超时。智能体方案完整跑完了7天中间虽然也遇到了弹窗和应用崩溃但都在几秒内自动处理了没有导致整个任务中断。从数据质量来看旧方案的数据是断断续续的中断期间性能数据缺失最终画出来的趋势图有明显的“空洞”。智能体方案的数据连续性明显更好监测智能体还会自动给异常数据打标签比如“此处伴随一次应用崩溃”省了大把人肉分析时间。从人力投入来看岗位值班从7x24小时人工盯守降到了每天早晚各看一眼报告。我们甚至试过周末完全不碰周一早上拿到的报告照样完整。这些对比不是想说脚本一无是处而是想说当测试任务从“执行少量用例”放大到“长期无人值守的复杂场景”时智能体的优势是数量级的。脚本适合做“单次、快速、高确定性”的校验智能体适合做“长期、动态、需要判断力”的验证。两者不是替代关系是分工关系。4. 从脚本平滑迁移到智能体四个关键环节4.1 环境搭建先跟工具链和解很多人对智能体测试的第一印象是“高大上”实际上手时最容易被卡住的反而是环境问题。我看网上有人问“claude: 无法将‘claude’项识别为cmdlet、函数、脚本文件或可运行程序的名称”还有类似“git无法识别”、“opencode无法识别”的报错。Windows下PowerShell经常遇到这类问题本质就两件事要么命令没装要么环境变量没配。我自己的经验是搭智能体环境先别急着跑大模型先把基础工具链理顺Python版本锁定在3.10以上太老的版本对很多AI框架支持不好。用python -m venv建独立虚拟环境避免依赖互相污染。pip install那套AI SDK、自动化库之前先确认网络源可用推荐用国内镜像加速。所有命令行工具全部确认能通过命令名 --version正常输出版本再进入下一步。配置好基础环境后再考虑“接口从哪里来”的问题。大语言模型可以走在线API也可以本地部署具体看隐私要求和成本。设备老化测试这类场景涉及产品数据我们最终是私有化部署的小参数量模型API混合用的方案。核心决策点是决策质量要求高的场景用强模型高频低风险的工具调用用便宜模型不能一个模型打天下。4.2 把脚本能力封装成智能体可调用的工具这是整个迁移过程中最关键的工程环节。你的智能体再怎么聪明如果手里没有趁手的“工具”它也只能干瞪眼。我的做法是先把原来脚本库里的能力全部梳理一遍然后抽象成函数每个函数加上类型清晰的参数和返回值。同时写一份JSON格式的“工具清单”给大模型做Function Calling用。清单里每项包含工具名称、功能描述、参数结构、返回值结构。大模型看到这份清单后就知道在什么场景下调用哪个工具。举个实际例子原来的“检查当前页面是否有异常弹窗”这段逻辑以前是写在Python脚本里的一个判断分支。现在我不写死这个判断而是把它做成一个工具tool_detect_dialog() - {has_dialog: bool, dialog_text: str, buttons: [str]}执行智能体会在每次页面操作后自己决定要不要调用这个工具。如果检测到弹窗它会再调用tool_click_by_text(允许)或者tool_click_by_text(确定)来完成处理。封装工具有三个注意事项都是实操中总结出来的工具粒度要适中。太粗智能体没法灵活组合太细上下文太长、调用次数爆炸。以“点击某个元素”这类原子操作为基准往上封装一层就够了。异常要传给模型而不是吞掉。工具执行失败时返回值里要带错误信息让模型知道发生了什么才能做出正确决策。超时机制必须加。每个工具调用都要设置超时防止某个操作卡死导致整个智能体流程挂起。4.3 意图解析与任务编排让智能体理解“测什么”工具链就绪后接下来的核心是让智能体理解“你要它干什么”。这一步本质上是在大模型和业务目标之间搭一座桥。我在系统里维护了一套“任务配置模板”每个模板对应一类测试场景。模板里包含几个关键字段任务目标用自然语言描述比如“验证设备在连续使用72小时后基础功能的响应速度是否明显下降”。验收标准可量化指标比如“冷启动时间不超过3秒”、“内存占用不超过初始值30%”等。边界条件允许什么、禁止什么比如“可以关闭弹窗但不能修改系统设置”。参考用例给智能体提供一份基础操作路径让它知道大致的用户行为模式。任务编排这块我一开始走了弯路试图让智能体看一段长描述就自动完成所有事结果它常常抓不住重点做出一些“很聪明但完全跑偏”的操作。后来改成“目标标准约束”三段式结构智能体对任务的理解准确率高了很多。这里分享一个经验不要让大模型自由发挥规划所有步骤让它在“轨道”内行动。我先给它一个基础操作序列作为轨道然后允许它在轨道内做动态调整。比如“点击Tab1 滚动列表 点击Tab2 播放视频”如果中途弹出一个权限请求智能体可以插入一个“关闭弹窗”的动作然后再回到轨道上。这样既保留了灵活性又不会失控。4.4 结果判定从断言到评估这里最容易翻车脚本时代的结果判定靠断言智能体时代靠什么这是整个方案里最容易翻车的一环。一开始我天真地以为直接让大模型看截图就能判断“是否通过”。结果发现不行。大模型看单张截图能识别“页面有没有异常元素”但很难判断“这个页面是否比昨天慢了20%”——因为性能问题需要靠数据说话而不是肉眼。折腾了几轮之后我把结果判定拆成了两层第一层数据层判定。凡是能用技术指标衡量的全部用代码算。启动耗时、帧率、内存占用、温度曲线这些必须基于时序数据做阈值判断不能靠模型拍脑袋。监测智能体在这一层的职责是“精准度量”。第二层语义层判定。凡是需要理解上下文的让模型分析。比如“用户在浏览商品详情页时返回列表列表滚动是否出现明显卡顿”这种判断需要结合操作日志、截图、性能数据综合推理这时候模型比人肉看日志高效得多。所以最终的判定逻辑是先跑数据判定把硬性指标不过关的场景直接标记为“失败”凡是指标正常但操作过程中出现疑似异常的场景再交由语义层分析由模型决定“是否属于可接受范围内的波动”。这套双层判定上线后误报率明显下降。以前脚本时代一个无关紧要的温度抖动就可能让整夜跑出来的结果全部作废现在的方案会给出一个“通过但存在温度短期波动建议关注散热”的结论既不会漏报问题也不会因为细枝末节误杀整个结果。5. 常见问题与排查技巧实录5.1 智能体“乱跑”怎么办——行为约束问题智能体测试最让人头皮发麻的问题就是“它跑偏了”。有次我让它测试“连续播放视频一小时后的发热情况”它居然中途打开了设置页面把屏幕亮度调到了最高然后把测试结果标记为“正常”。这问题怎么治靠三个手段第一强化系统提示词的边界说明。明令“在测试过程中禁止修改系统设置包括亮度、音量、网络开关、定位权限等”。把“禁止清单”写清楚比泛泛说“按目标执行”有效得多。第二工具层加权限控制。不是所有工具都要暴露给智能体。拿设备老化测试来说tool_set_brightness这种工具直接从工具清单里删掉智能体连调用的机会都没有。这就像你请了个实习生有些权限你不能给他得靠系统限制。第三设置操作路径校验。每次智能体执行完一个工具调用我都让一个校验器检查“这个操作是否在当前任务允许的操作范围内”。如果不在直接拦截并提示模型“该操作被拒绝请回到原始任务目标”。这个校验器很轻量但是能兜住大部分乱跑的情况。5.2 无人值守时稳定性怎么保证长期无人值守测试最怕的就是智能体“卡在一个循环里出不来”。我在调试过程中遇到过最典型的问题智能体识别弹窗时反复调用tool_detect_dialog检测到一个弹窗就试图关闭但关闭后立刻又弹出一个它再次关闭如此循环上百次测试进度纹丝不动。这类问题的根源是智能体缺乏“循环退出条件”。解决办法是在执行框架里加入一个全局的“步数预算”和“重试预算”。步数预算每轮任务给智能体分配一个最大执行步数比如500步。一旦超过强制终止本轮输出“任务超时未完成”的结论。重试预算同一类工具调用连续失败或重复执行超过5次就触发策略切换比如不再尝试关闭弹窗而是重启应用继续任务。这套机制加进去之后无人值守跑上一周再也没有出现过“卡死不动”的情况。真要遇到无法解决的异常也会先记录现场、保存证据然后优雅退出。5.3 安全测试里智能体的边界最后说说安全测试的场景。智能体用在安全测试上目前还是探索期但已经有不错的实践方向了比如自动生成攻击payload、自动分析漏洞响应、自动检查配置基线等。我的建议是安全测试里智能体更适合做“辅助分析”而不是“全自动攻击”。因为安全测试的每一步都可能产生不可预期的副作用比如一条越权测试请求可能导致线上数据修改。这里我的经验是让智能体负责“策划用例”和“分析结果”实际的危险操作仍然由人工审批或沙箱环境隔离执行。比如我可以让智能体根据接口文档自动生成100组边界攻击测试用例但真正发起请求前必须经过一道人工确认或沙箱代理。这个模式既利用了智能体强大的分析和生成能力又把风险控制在可接受的范围内。安全测试要不要全面自动化我的看法是暂时不要。在攻防场景里真正有价值的不是“能执行”而是“能做出正确判断”。目前的智能体在判断层面还做不到完全可靠保留人工在环是负责任的方案。6. 一点真实体会从脚本到智能体的这次改造对我最大的冲击不是技术上的而是认知上的。以前我衡量测试工作关注的是“写了多少条用例”、“跑了多少轮回归”、“覆盖率多高”。现在这些指标还在但重要程度明显下降了我更关心的是“测试系统能不能自己发现问题、自己恢复故障、自己给出结论”。工具会被淘汰技能也会被重写但测试这件事本身不会消失它只是换了一种更高级的方式存在。如果你现在还在为“脚本写不好”焦虑我的建议是别再纠结脚本语法了花点时间去玩转智能体平台去理解大模型擅长什么、不擅长什么去设计一套让人和AI配合默契的流程。这个转变早做比晚做好因为范式一旦转移了再回去写那种天天修不停的老脚本你会觉得特别难以忍受。最后再分享一个小技巧如果你刚开始接触智能体测试别急着改造全部用例挑一条最让你头疼的自动化用例把它的目标、约束、工具封装好拿一个智能体平台跑通一遍。真跑通了你会回来感谢我的。
