★ FEATURED ARTICLE 凌晨一点发版当天的自动化报告终于跑完了红了一大片。群里第一条消息不是问哪条用例挂了而是那句我听见无数遍的话“这自动化现在是在帮倒忙吧。”说真的这句话比报告里一百个失败用例都扎心。移动端自动化测试做了这么些年从“解放人力”到“越做越痛”几乎是一条绕不开的路线。用例越写越多维护量越来越大失败还得人肉去看到最后自动化团队不是在跑测而是在给脚本打工。问题到底出在哪大模型又凭什么能破这个局这篇文章不聊虚的我结合自己这些年在一线跑自动化、排查失败用例、带测试小团队的实际经验把痛点的根因拆开把大模型能介入的几个真实切入点捋清楚也给一套不用推翻现有体系就能落地的渐进式路径。我不会说大模型是银弹但它确实有几个环节能把人从泥潭里捞出来。只要找对了位置哪怕先用在一个高频失败模块上收益都会非常直接。1. 从“写脚本”到“养脚本”移动端自动化测试越来越痛的真实原因1.1 工作量不守恒定律写用例只占两成维护占八成先泼一盆冷水自动化测试最大的成本从来不是“写”而是“养”。我见过很多团队对自动化的预期是“写一遍跑很久”。实际情况是一个移动端用例的生命周期里初次编写可能只占20%的时间剩下80%都消耗在后续的维护上。App每发一个版本按钮文案变了页面布局重构了某个弹窗提前冒出来遮挡了点击坐标又或者后端接口字段调整导致断言数据对不上都是家常便饭。更别提国内安卓生态下各厂商的ROM会私自改控件的资源ID同一套脚本在不同机型上表现完全不一样。我拿自己负责过的一条登录链路做过统计两周时间内用例本身没有新增任何业务逻辑但因为版本改动登录按钮的ID换了两次、第三方登录模块的弹窗样式调了一次、新加了一个隐私协议勾选控件。结果这条用例在两周里改了五版。你说这是写的活吗不是这是纯纯的“养脚本”。这就是为什么很多团队自动化用例数涨得飞快、人效却越跑越低。用例数量一多每个版本跑完红掉的事项成百上千而每条失败原因都有细微差别维护动作也就成了一个个需要人肉判断的孤案。时间久了自动化团队不是在“测试”而是在“考古现场做修复”。1.2 假阳性与假阴性自动化信任度是怎么崩塌的自动化测试真正致命的不是“失败多”而是“失败了你不敢信通过了也不敢信”。先说假阳性。一条用例因为网络抖动、某个弹窗晚出现了0.5秒而失败业务功能本身完全正常。这种情况出现一次两次大家还愿意点进去看出现十次八次整个团队就会形成肌肉记忆红灯不用看大概率又是环境问题、或者脚本太脆。等到真正的缺陷出现自动化报告的红灯被习惯性忽略风险就是这样漏掉的。再说假阴性。用例通过但业务其实已经有问题了。最常见的场景是断言写得过于粗糙比如只验证“页面能打开”就结束了至于页面上金额是否显示正确、状态是否流转到预期阶段完全没覆盖。脚本高兴地报绿用户已经在线上遇到了数据错乱。这种假阴性是最可怕的因为它没有噪音是完全的静默失效等到线上出问题测试这边还拿着“全部通过”的报告解释不了为什么没有拦住。痛的不是自动化本身而是维护成本和信任度同时失控。一旦陷入这个循环团队对自动化的态度会从“神器”变成“包袱”而项目管理者通常会错误地归咎于人不够多、不够努力最后加大投入去堆更多人维护脚本结果是越陷越深。1.3 碎片化机型、系统、分辨率带来的指数级负担移动端自动化还绕不开一个web端不太会遇到的噩梦碎片化。不同机型的屏幕分辨率、系统版本、厂商定制ROM、全面屏手势、权限弹窗样式甚至刘海屏的传感器区域都会影响元素定位和点击坐标。同一个元素在一台手机上用id就能定位到在另一台上可能被外包了一层壳同一段操作在iOS上是直接点到了安卓上得先处理一个系统授权弹窗同一个页面在平板上的布局和手机完全不同selector写法自然也跟着变。如果团队手里维护着几十上百台真机设备池那这些差异就会被指数级放大。我见过最极端的例子是一条用例在同一批设备上跑通过率60%失败原因有五种完全不同的表现。有人会说“那不就每一种原因修一下”但真实情况是每周都在修同样的五种原因因为每次新版本会引入新的变种旧问题修完新问题又长出来。这时候自动化测试团队真正做的已经不是测试工作而是一场永无止境的“适配战争”。而这个战争的根源不全是设备和系统太杂更核心的是定位方式和校验方式太脆弱——这个问题不解决加再多人力也只是在打地鼠。2. 根因在更上游脚本关心“怎么做”业务关心“做什么”2.1 两层映射之间的断裂才是所有痛的共同源头如果我们把所有痛点往根上挖会挖到同一个地方传统自动化脚本表达的是“怎么做”但测试真正想验证的是“做什么”。我给你打个比方。你让一个不认识路的人去买酱油你给他两条路线。一条是“往前走两个红绿灯第二个路口左转看到XXX银行招牌后右手边第二家店。”另一条是“找到最近的一家便利店买一瓶黄豆酱油找零钱记得数一下。”第一条路只要路上的红绿灯坏了、招牌换了、店铺改了位置他就彻底迷路。第二条路他可以根据当下的情况实时调整路线只要目标是“买到酱油”他总能走到。传统移动端自动化脚本几乎全是“第一个红绿灯左转”这种写法。它把一个业务动作拆解成坐标、控件ID、层级路径、相对位置这些信息本质上全是不稳定的“路牌”。而测试人员真正关心的“用户能不能登录成功”“支付成功后状态是否正确”被淹没在了定位细节里。大模型真正的价值不是把脚本写得更好而是第一次有能力把“做什么”和“怎么做”连接起来。它懂自然语言也见过海量的UI结构和代码样本所以它可以承担“意图翻译”的职责让自动化从面向控件转向面向业务语义。2.2 三种映射关系从元素级到视觉级再到意图级为了把这个问题说清楚我习惯把移动端UI自动化里的映射关系分成三层。第一层是元素级映射。通过控件ID、XPath、资源名称、文本内容去定位某个具体控件再执行点击、输入、断言。这也是目前绝大多数测试框架的核心模式。优点是指向准确缺点是极度依赖UI的实现细节。一个ID改了一条用例就废了。第二层是视觉级映射。通过截图像素、图像匹配、OCR识别去找到“屏幕上哪个位置有’登录’两个字”“哪个区域是一个红色按钮”。这类定位能力User对UI实现细节的依赖会弱一些不要求你暴露资源ID设计稿改了字体颜色它也不受影响。但同时新问题也来了视觉匹配对屏幕分辨率、主题模式适配很敏感计算成本也更高。第三层是意图级映射。一句话描述业务目的比如“用户从首页进入个人信息页找到设置项完成退出登录”机器需要自己拆解成步骤再根据页面上可见的元素去逐步执行。这一层最接近测试人员真正想表达的东西也最难实现因为它要求系统具备语义理解能力。过去第三层只是学术界和技术大会上的Demo大模型成熟之后它才第一次有了工程落地的可能性。2.3 为什么移动端比Web端更脆弱有人会问web端的自动化不也是操作DOM和XPath吗怎么没见痛成这样三个原因。第一个原因移动端页面结构更容易变。H5页面每次发版都可能改版原生页面受版本灰度影响同一个线上App里不同用户看到的版本可能都不一样。Web端起码你测的域名是固定的、版本是明确的。第二个原因移动端的UI层级更复杂。不少App是原生页面里嵌着WebViewWebView里又有自己的DOM或者整个页面是动态化框架渲染出来的底层只有一个画布传统selenium式的元素树在它面前直接失效。你甚至可能拿不到稳定的控件ID只能靠坐标硬点。第三个原因移动端的系统交互干扰太多。键盘弹起遮挡、权限弹窗、iOS的剪切板授权、安卓的悬浮窗权限、深色模式切换这些Web端几乎不用考虑的问题在移动端每一个都能轻易打断一条脚本。所以移动端自动化对“意图级”能力的需求比Web端急迫得多。谁先想办法让脚本理解“我到底要干嘛”谁就先从小黑屋里走出来。3. 大模型破局第一层从“写出用例”到“描述业务意图”3.1 自然语言生成脚本不是替代人而是帮你打草稿大模型进测试领域我听到最激进的说法是“以后不用写用例了直接告诉它你要测什么”。我做了一段时间实验后更愿意把它定义成“高级草稿工具”——它不可能直接交付一个上线级的脚本但它能把从自然语言到脚本之间的那部分体力活干掉。实际操作上我建议这样拆你提供业务场景描述、涉及的关键页面、数据准备条件、期望的断言结果大模型基于这些信息生成一份完整的测试步骤草稿包含每一步预期落到哪个页面、操作哪个控件、校验什么状态。然后由测试人员评审这份草稿修正业务理解错误再落到测试工程里。举个例子。对模型输入“新用户首次启动App同意隐私协议跳过广告用手机号验证码登录进入首页后点击理财Tab确认页面加载出推荐产品列表至少能刷新出三条数据。”以往这个过程测试人员要把这串中文手动翻译成几十行代码。现在大模型几秒内能给你一份初稿。翻译得对不对那是另一码事但你省下的时间是真的而且大模型写代码的平均水平至少能顶上一个入门级的测试开发。3.2 Think-Then-Act的Agent模式让脚本在页面执行中动态调整比生成一次脚本更大的进阶是让大模型参与测试过程的实时决策。也就是现在大家常说的Agent模式。传统的自动化脚本是“写死剧本”从第一步到第N步路径提前规划好中间任何一步走歪脚本就挂了。Agent模式的思路完全不同。你只给它一个任务目标它先观察当前页面理解这个页面上的元素大概是什么、哪些操作在当前上下文里是有意义的然后选择一步动作执行之后继续观察新页面再决定下一步。这种模式下哪怕某个按钮从页面的左上角挪到了底部或者原本叫“立即登录”的按钮改成了“一键登录”只要模型能从页面的视觉结构和文字语义上判断出“这就是那个完成登录的按钮”动作就能继续执行下去。我实测过这类思路之后最大的感受是它把脚本的“耐力”提高了很多。过去一条用例可能因为任何一个无伤大雅的UI调整就死掉现在它可以比较聪明地顺着当前页面的实际情况往下走。当然代价也有每一步决策都涉及模型推理耗时比传统执行高不少所以更合适跑核心链路不适合全量铺开。3.3 提示词里必须塞进的“测试上下文”想让大模型生成的步骤靠谱光说“测登录”三个字是远远不够的。我踩过几次坑之后总结出至少要给三类上下文。第一类是产品背景。这个模块是做什么的目标用户是谁关键路径是什么。第二类是UI约定。当前页面上有哪些通用控件规格、哪些原生命中周期弹窗必须处理、按钮的命名规律是什么。第三类是测试约束。哪些数据不能串环境、哪些环境账号有特殊权限、哪些操作需要等待特定回调才算成功。把这些信息整理成一份团队内部的测试上下文规范文档写进提示词模板里大模型给出的结果质量会肉眼可见地提升。说白了大模型像是一个极其聪明但对业务一无所知的新同事你入职培训给得越细他上手越快。直接扔一句“帮我测一下下单流程”他只能靠猜猜出来的东西你敢直接用吗4. 大模型破局第二层选择器自愈把最耗时的修脚本环节降下来4.1 从“死地址”到“语义地址”如果说意图理解是长期主义的解法那选择器自愈就是今天就能见效的速效救心丸。几乎所有移动端自动化团队都被同一件事折磨过页面元素ID变了脚本找不到元素直接失败。传统的修法是什么呢人打开失败截图去新页面里找新ID改代码提交重新跑。一个用例可能花十分钟一条条改下来发版周期里两天就没了。大模型在这里可以提供一个“语义地址”机制。不再只依赖死板的“idlogin_btn”这种写法而是给元素增加一层语义描述这是一个“登录页主操作区里的主按钮”功能语义是“提交登录表单”。当旧ID失效时系统会用大模型去匹配页面新结构里哪个元素承担了相同的语义找到后自动替换选择器并继续执行。这个过程听起来玄核心逻辑不复杂用自然语言表达元素的“功能身份”让大模型基于页面截图、控件树、文本信息综合判断。ID会变文案会变但“提交登录”这个东西在业务层面的身份短时间内不会随便变。4.2 一个可以落地的自愈闭环我建议真想做的团队可以从下面这个闭环开始不要一上来就整大模型测试全流程。第一步当脚本中的元素定位失败时先记录失败现场。包括当前页面的截图、控件树、之前的操作路径、失败控件的历史描述。第二步触发自愈引擎把失败现场喂给模型。用三个信号去查询候选元素历史控件的语义描述、失败时截图里的视觉对应区域、当前控件树里文本/类型/位置都接近的节点。第三步模型输出若干个候选定位方式按置信度排序。系统尝试用推荐度最高的方式去执行同一个点击或输入动作如果后续页面顺利走到预期节点就判定自愈成功。第四步把成功的替换写回脚本仓库同时标记为“待人工确认”。测试人员看到记录后可一键确认或回滚。这个闭环跑起来以后我见过最直观的变化是一个注册登录模块的用例因为验证码按钮的文案从“获取验证码”改成“发送验证码”过去要人工改脚本现在自愈引擎直接匹配到变化后的按钮用例一路跑到底只在最后推了一条“选择器已更新待确认”的消息给维护者。4.3 自愈的“度”和误修正问题自愈不是越多越好这里面有两个坑必须提前说。第一个坑是重试风暴。如果定位失败后自愈引擎还在不断尝试同时失败用例又很多整个执行层的资源会被拖垮。合理的做法是限定每条用例最多触发一到两次自愈且每次自愈之间的等待时间要递增不能无限重试。与其让一百条用例慢吞吞地各自挣扎不如快速失败把问题汇总交给大模型批量分析。第二个坑是误修正。这是最难把握的某一次用例失败可能不是选择器失效而是产品真的出了缺陷。如果自愈引擎自作主张把控件换了一个匹配项用例继续往下跑并且通过了那么这个真实缺陷就被悄悄掩盖了。所以我的原则是自愈只允许处理“定位不到”这一类失败一旦后续断言步骤失败立即停止不允许再自愈。同时所有自愈动作都要有审计记录确保任何一次替换行为都可以被回溯。信任重建很难保住自动化报告的可信度比让用例跑绿更优先。5. 大模型破局第三层失败归因与报告解读把人工排查时间砍掉一半5.1 失败原因分类很多失败根本不需要修脚本自动化报告一红第一反应都是“脚本又挂了”。但我大量统计后的结论是真正需要改脚本的失败通常只占一半左右。另外一半五花八门测试环境数据被污染、依赖的后端服务灰度异常、某个第三方SDK弹了新的广告、真机上的系统CPU占用过高导致页面加载超时。传统工具很难区分这些原因因为失败的报告只有一句“element not found”或者一张截图。排查的人要自己开日志、连数据库、看服务状态几个来回下来半小时没了。这里大模型有一个很擅长的优势把一个多模态的失败现场综合起来做判断。它同时看截图、看控件树、看服务端返回的日志片段、看用例执行的时间点信息然后按照预置的类型模板输出一个结论环境问题、数据问题、UI变更、真实缺陷、还是脚本自身逻辑错误。我建议每一条失败报告都产出一个结论标签和置信度。置信度高的时候直接通知对应负责人置信度低的时候系统给出“建议人工介入”的提示并说明模型为什么犹豫。5.2 从日志堆到人话报告解读的体验升级有过排查经验的人都知道移动端自动化的失败信息非常不友好。日志里可能有几十行堆栈、一串base64截图、若干个嵌套异常人要在信息海里捞针。大模型可以把这些原始材料浓缩成人能直接看懂的话。比如不再输出“timed out waiting for element with id xxx”而是输出“登录页点击操作超时原因是按钮’立即登录’在当前页面中不存在。当前页面顶部出现了未预期的活动弹窗疑似与本次运营活动有关。建议检查弹窗开关或为用例增加关闭弹窗步骤。”这种报告哪怕不够完美也已经把排查者的工作从“到处找线索”变成了“验证线索”。我自己的经验是投入大模型做归因之后团队处理失败用例的平均时长从半小时左右降到了十分钟以内而且新人也能快速上手——因为报告本身就是一条“带人话解释”的排查指南。5.3 让模型学会结合“已知变更”来判断缺陷归因想要更准还缺一个关键输入发布或配置的变更信息。同样是“登录按钮找不到”如果当天版本刚改过登录模块这是UI变更的概率很高如果最近一周都没动过登录相关代码但线上做了一次UI统一换肤那也可能和皮肤切换有关如果登录模块没动、UI也没动但是接口服务报了5xx那更可能是后端问题。所以我在设计归因提示词时会把当次被测版本涉及的需求列表、变更范围、配置开关状态都提供进去。模型看到完整的变更上下文判断的准确率会比只看失败现场高不少。这也是为什么我不建议拿一个通用大模型直接裸跑归因。它对你的系统一无所知你喂给它的上下文越完整它的结论才越有价值。6. 落地路径不要改造整个体系先做止血型试点6.1 选最痛的链路先做而不是从平台层面重构提到大模型落地测试很多人第一反应是想做一个覆盖所有流程的智能测试中台。我劝你打住。这种大而全的工程改造周期长、利益方多、见效慢大概率还没跑完就被砍了。更务实的路径是找到当前维护成本最高、失败率最不可控、人工排查最耗时的一条业务链路比如登录注册、支付、或者某一个核心交易流程先把试点做起来。在我实践过的方案里我选了一条用例数量不多但每次上线都让人紧张的核心链路。它的特点是操作步骤多、涉及弹窗多、断言复杂跑一遍要十分钟失败率每个月都在涨维护的人已经麻木了。这个场景就是最合适的试验田。链路足够痛团队才有动力配合你试错同时范围又足够窄就算折腾出问题也影响不到全局。试点目标也定得很收敛把这条链路的用例维护时间缩短一半把失败场景的误判率降低到可接受的范围。达不到说明方案要调整达到了再去谈复制到更多模块。6.2 分级调用不是所有页面都值得让大模型看一遍真正把方案推到执行层时要面对一个非常现实的问题成本。每一次大模型调用都在烧钱尤其是视觉大模型处理一张截图、分析一段视频流的成本比普通文本接口高出不少。如果全量用例、每个失败都丢给大模型分析成本会直接把收益吃掉。我见过不少团队在这上面翻车做大模型测试平台时觉得能力好炫上线后因为账单太贵灰度中就被叫停了。正确的思路是分级调用。第一级用传统规则和低成本的模糊匹配去解决最常见、最机械的问题比如文本完全匹配、正则匹配、控件树近邻查找这能覆盖一半以上场景。第二级用中等成本的开源或私有化小模型做语义匹配和简单归因比如判断两个文本是否表达同一个意思、描述页面发生了什么变化。第三级才轮到需要复杂推理的视觉大模型处理那些前两级解决不了的情况比如页面整体改版后的结构再识别。每一级都要设置明确的输出置信度阈值低置信度的才逐级上报。这个策略实际跑起来单条用例的智能化增量成本可以压到很低的水平收益才真正大于支出。6.3 度量指标别只看通过率要看维护人日做技术的人往往喜欢盯着通过率看但我想说单纯看通过率很容易误判。比如通过率从85%提到95%如果靠砍掉脆弱用例实现的那是自欺欺人如果靠修好了一堆不稳定因素实现的那是真进步。同样自动化用例数量从一万条降到两千条看起来是退步但可能维护成本降了八成核心覆盖覆盖率反而更高了。我推荐度量三个指标每次发版后的自动化修复耗时也就是从报告出炉到用例重新恢复稳定的总工时每月人工介入排查失败用例的工时以及自愈系统的误修改率也就是被自动改掉的选择器里最终被发现改错的占比。这三个指标直接对应这篇文章开头提到的痛点。当“修脚本”的时间降下来“排查失败”的时间降下来自动化团队才有余力去做真正有价值的事比如探索新场景、分析覆盖率缺口、把测试往前推移。技术先进不先进最终要看人力的账本。7. 边界与风险大模型是在帮你判断不是在替你决策7.1 确定性输出与幻觉问题测试这行最怕“编得像真的”大模型有一个让所有测试人员都睡不着觉的问题那就是幻觉。它可能在归因报告里非常笃定地写“元素自愈成功已定位到相同语义的新控件。”但实际上那个控件匹配错了用例能继续跑纯粹是因为页面碰巧有个不相关的可点击区域。轻则用例误报重则掩盖了真实的缺陷。所以凡是模型参与定位、归因、报告结论的环节都要人为加一道确定性护栏。我习惯在两条核心链路上守死。一是模型生成的代码和选择器必须经过一次回放验证才能合入不能让生成结果直接替代线上脚本。二是归因结论只作为“建议”不可以自动创建真实缺陷单、也不可以自动关闭缺陷单。人可以参考模型给出的结论快速做决定但决定权必须留给人。有个词我很喜欢人在回路。大模型价值在于把可能的情况压缩到很小的范围让人不再从零开始排查但最终拍板的永远应该是能对质量结果负责的人。7.2 数据安全与成本页面截图和业务数据不能随便出网移动端自动化涉及的大量截图、控件树、日志里常会带上真实的用户数据、业务配置、内部接口信息。把这类内容送到外部大模型接口光是安全合规这一关就过不去。这个问题的常规解法是分级部署。可以先评估数据敏感程度脱敏后的页面结构信息、控件文本、日志摘要走一些相对安全的接口问题不大一旦涉及用户手机号、订单金额、内部配置字段就必须在私有化环境里跑模型或者先做字段级脱敏再送出去。成本方面除了接口调用费还要算上基础设施、模型部署、算力资源的账。所以我建议先从文本型任务开始再做视觉型任务。文本型的意图解析、归因分析用量可控、效果明显视觉型任务等技术路径成熟、成本下降后再逐步引入更划算。7.3 测试人员的角色会变成什么大模型进入自动化测试之后很多测试开发心里会打鼓是不是我们就要被替代了我自己的观察是被替代的不会是测试工程师而是测试工程师手上那些一眼就能看穿规律的体力活。过去一个测试开发每天花三个小时修脚本、查日志、跟开发对线环境问题这些活确实会被大模型消化掉。但剩下来、也更重要的工作是把业务需求翻译成测试意图、判断模型输出的可行性、完善断言覆盖深度、对可疑缺陷做最终确认。换句话说这个角色的能力模型会从“写脚本的”慢慢变成“懂业务、懂系统、会指挥自动化体系的质检者”。门槛不是低了而是高了。愿意学新工具、愿意理解模型边界的人接下来几年会是最抢手的一批。守着一个旧工具链不放那才会真的焦虑。我在整个落地过程中最大的体会是别急着让大模型一步到位接管整个自动化测试体系那既危险也不现实。把它拆成一个个小决策点——翻译一下意图、修一下选择器、把失败原因归结出来——每个点单独看都不花哨合起来就是一条真实的减负路径。先从最让你头疼的那条链路开始跑通一次指标改善这件事就成了。
阅读完成 · 觉得有帮助？
