凌晨一点，某团队的工作群里炸了锅。一套覆盖核心业务链路的移动端回归用例，在版本迭代改版首页和支付页之后，一夜之间挂了八百多条，满屏的失败截图和报错堆栈，负责维护的同事一边改定位器一边在群里发了一句：这套自动化到底是帮我们省时间的，还是让我们加班的？
这个问题，做移动端自动化测试的人几乎都遇到过。脚本越写越多，维护越来越痛；用例越跑越频繁，失败噪音越来越大。与其说这是工具选型问题，不如说是测试生产方式本身的结构性问题。而大模型的出现，让很多人第一次看到了从根本上重构这套生产方式的可能性——不是给旧房子打个补丁，而是换一套承重结构。
这篇文章我会从痛点根因、大模型的范式转换、具体落地场景、我在一个模拟项目里的实测踩坑，以及一条不推倒重来的渐进式路线这几个维度展开。不吹概念，只讲我实际验证过的东西。
1. 写的速度赶不上改的速度：移动端自动化维护困局的真实画像
1.1 一次改版让几百条用例一夜之间全红
先说那个团队的具体情况。他们维护的App是一款电商类应用，自动化用例大概九百多条，覆盖注册登录、首页浏览、商品搜索、加购下单、支付、订单查询这些核心链路。框架用的是跨平台方案，元素定位基本靠 resource-id、content-desc、xpath 混着来。
那次版本迭代做的事，在开发眼里是很常规的重构：首页信息流改版、支付页按钮位置调整、部分页面启用了动态渲染容器。但在测试这边，代价是毁灭性的——改版第二天跑批，820条用例失败，失败原因清一色是元素找不到或超时。
你算一笔账就知道这个痛有多实际。假设一条用例平均需要30分钟去修——定位器改一改、等待逻辑加一加、回归验证跑一遍——820条就是400多人时。一个测试团队五个人，不吃不喝也要干两周。关键是，这类修复工作在下一个版本里大概率会再次出现，于是修用例成了无限循环。
为什么会出现这种情况？因为移动端UI的变更频率远远高于传统Web页面，而传统的自动化脚本把"界面结构"硬编码进了脚本逻辑里。界面结构一变化，脚本就变成了废纸。这不是执行效率问题，而是维护模型的缺陷：你把稳定性押在了最不稳定的东西上。
1.2 碎片化矩阵把"跑通"变成了体力活
如果说改版是"急性病"，那么碎片化就是"慢性病"。
移动端自动化测试面对的不是一个浏览器，而是一个近乎无限分裂的矩阵：不同厂商的Android手机、不同的定制ROM、不同的系统版本、不同的屏幕分辨率、不同的WebView内核。同一个元素，在一台设备上叫com.xxx.bt_add_to_cart，在另一台设备上可能因为厂商改写了资源ID而变成com.xxx.btn_add_cart_v2。
iOS看起来好一些，但也不省心。系统版本升级带来的权限弹窗变化、深色模式与浅色模式下视觉元素的差异、灵动岛和底部横条对布局的挤压，都会让测试用例的行为发生微妙改变。你在一台iOS 16的模拟器上跑得好好的用例，到了iOS 18的真机上就可能卡在某个弹窗上。
模拟器和真机的差异更是老生常谈。很多团队为了追求速度和稳定，大量使用模拟器执行用例，结果到了版本发布前做真机冒烟，一批原来在模拟器上正常的用例纷纷翻车。有人会说是"环境问题"，但从成本角度看，这个"环境问题"每年都会吃掉大量的排障工时。
碎片化的本质是：移动端测试的"环境变量"比Web端多一个数量级，而传统自动化对每一种环境变化都要显式适配。环境越多，适配越多，维护成本就越不可控。
1.3 反馈循环越来越慢，自动化逐渐失去核心价值
自动化测试的核心价值是快速反馈：开发提测之后，几分钟内能拿到一个相对可信的回归结果，从而决定是继续开发还是修完再提。然而在真实项目里，这个反馈循环是逐步劣化的。
一个典型的过程是这样的：用例刚开始只有二三十条，执行十分钟内出结果，大家都很满意；随后用例增长到两百条、五百条，执行时间变成四十分钟、一小时；再后来并发设备不够，排队等资源，测试结果出来已经是提测两小时之后。如果碰上失败用例一片红，还要花一两个小时去分析这到底是产品Bug、用例写得烂还是环境不稳定。
当反馈周期从几分钟拉长到半天，开发团队对自动化的信任就会快速流失。他们会觉得"等测试结果还不如我手动点两下"，于是自动化用例被慢慢边缘化，最后成为一项只有测试团队自己在维护的仪式性工作。
这里有个反直觉的点：用例越多，测试套件整体的置信度反而可能越低。因为失败噪音太大，团队会下意识忽略红色结果，甚至为了"好看"把有问题的用例直接标记成skip。所以痛点不光是"维护累"，更是整个测试策略的失效。
2. 选择器断裂、断言失真、噪音过载：藏在日常维护里的三个结构性病因
2.1 元素定位：从控件 ID 到 xpath 的脆弱链条
如果让我给移动端自动化的痛点排个序，元素定位绝对排第一。
表面上，元素定位是一个简单的"找控件"问题，但实际它是一条脆弱链条。findElement(By.id("pay_btn"))这种写法，在UI稳定的阶段确实干净可靠，可一旦开发把控件类型改了、外包了一层容器、把布局从XML改成动态渲染，这条定位链就断了。改用 xpath 看起来更灵活，比如//android.widget.TextView[@text='立即支付']，但xpath对页面层级变化极其敏感，开发加一层嵌套，xpath就失效。更麻烦的是，xpath定位往往严重依赖解析出来的控件树结构，而不同系统版本下控件树的组织方式可能完全不同。
有人会说，那用 image 识别总行了吧？用OCR或截图对比确实能绕过结构依赖，但OCR对精度和性能的负面影响，以及截图对比在动态内容区域的高误报率，都让它很难成为主方案。而且这种方案本质上还是在跟"UI到底长什么样"死磕，并没有解决测试意图的建模问题。
我见过的相对成熟的传统方案是"多重定位器+动态等待"策略：先按ID找，找不到按文本找，再找不到用坐标偏移找，每一层都包上显式等待。这个策略能把一次失败率从80%降到40%，但代价是脚本复杂度大幅上升，日志里全是重试记录，排查一个"真失败"反而更困难。
2.2 断言：太细则碎，太粗没用
断言设计是另一个让人头疼的平衡问题。
遇到过度的断言非常多。测得严格一点，于是断言里塞进了商品列表的完整排序、每个价格的精确文案、页面截图精细比对。这种用例的一大特点就是极易碎，哪怕产品经理只是想调整一下按钮的颜色或在按钮上多加了几个字，用例都能挂掉，而且这种挂掉并不会给产品带来任何新的保障信息。
另一种极端是断言形同虚设。比如进入支付页面之后只判断了一个"页面元素存在"，或者接口返回了200就算通过。这种方式用例是稳定了，但支付流程是否真的走通了、金额是否正确、订单状态是否变更为"已支付"，这些真正和业务价值挂钩的点全部没有覆盖。跑完一片绿，但是线上事故该出还是出。
这个问题的根源在于：传统自动化工具要求我们把"验证逻辑"精确地写成代码，而多数写用例的人，实际上是用代码去表达一种业务意图。一旦意图到代码的翻译过程出现变形，断言就会偏向某一个极端。太细的，被实现细节绑架；太粗的，丢失了业务本质。
2.3 失败信息过载：排查时间的隐形黑洞
第三个结构性问题，是失败信息的分析成本。
一次大范围失败，团队得到的往往是一堆截图、堆栈、日志和控制台输出。这些信息混杂在一起，没有人能一眼分辨出：这是产品真正出了Bug，还是脚本本身定位不到元素？是后端服务抖动导致的超时，还是这台设备的环境有问题？
我见过一种很典型的心酸操作：测试同学把几十个失败的截图一张张打开，根据肉眼判断来分类，然后在群里挨个扇区@开发。这个动作持续了两年，没有人觉得哪里不对，直到有人做了个简单的统计——每次大范围失败时，真正的产品缺陷占比不到15%，剩下85%都是脚本、环境、数据问题。换句话说，团队每天花大量时间处理的，其实是自己维护不当制造出来的噪音。
更进一步，失败之后的重跑策略也常常是粗暴的。有些团队选择全量重跑，通过"重跑后变绿"来掩盖问题；有些团队直接开会点名。但真正的问题没有被定位，下一次改版，同样的噪音还会再来一遍。
这三大结构性问题——元素定位脆弱、断言逻辑变形、失败信息噪音大——互相叠加，就构成了"越做越痛"的完整闭环：脚本因为定位问题天天崩，崩了以后需要人肉分析大量失败报告，分析出的结论又没法反哺脚本的设计，于是下个版本继续崩。
3. 大模型为什么能破这个局：从"指令执行者"到"意图理解者"的范式切换
3.1 传统自动化是在"背诵课文"，而移动端界面随时在改版
我一直觉得，传统自动化脚本和"背诵课文"很像。脚本的执行逻辑是确定性的：给定一个固定的输入，按照固定的步骤操作控件，最后比对固定的结果。只要环境不变，脚本一定稳定执行；可一旦环境变了——UI结构调整、文案修改、网络抖动——脚本就没有任何应变能力。
而大模型的能力边界在于，它可以通过语义理解去处理"没见过的情况"。你告诉它"用户想在商品详情页把商品加入购物车"，它不一定需要知道页面级的控件树长什么样，它可以借助视觉信息、文本上下文和知识推理，去找到"加入购物车"这个意图在当前界面下的实际表达形式。这就像你不再让一个人死记硬背一张地图，而是告诉他目的地和交通工具的使用原则，他到了现场自己会看路牌。
这个转换的关键词是：从"结构绑定"到"意图绑定"。结构会变，但业务意图相对稳定。无论开发怎么改UI，"用户要能完成加购"这件事是不变的。
3.2 大模型真正改变的是"测试意图"的建模方式
传统自动化里，测试意图散落在每一行代码里：定位器描述了"我要操作哪个控件"，步骤序号描述了"什么样的操作顺序"，断言描述了"什么样的结果可接受"。
散落的问题在于，一旦任何一个环节发生变化，意图就会失真。定位器失效了，脚本根本走不到断言那一步；断言写歪了，整个用例的验证价值就归零；步骤顺序变了，脚本完全不知道该如何自适应。
大模型提供了一种新的可能性：把测试意图独立建模，然后让机器去动态生成具体的执行方案。
比如你定义一个"测试意图对象"，它包含：业务目标（验证用户能完成登录）、前置条件（账号已注册）、关键操作链（打开App、输入账号、输入密码、点击登录）、验证目标（进入首页且展示用户名）。这些信息都是相对稳定的业务描述。至于密码框的定位器怎么写、登录按钮的xpath是什么、等待多久合适，这些可以全部交给一个"执行器"去实时判断。在页面结构稳定的时候，执行器直接用上次的定位器；在结构变化时，执行器基于当前界面信息重新推导。
这个架构的价值在于：当UI改版时，你不需要重写"业务目标"和"操作链"，只需要让执行器重新生成一版执行细节。脚本的"保质期"通过这个方式被大幅拉长。
3.3 为什么是现在：多模态、代码推理与私有化部署刚好就位
大模型能谈落地，不只是因为概念火，而是几条能力线刚好在最近两年同时成熟。
第一条是多模态能力。大模型不再只能读文本，还能直接"看"界面截图，识别按钮的位置和含义。这个能力对移动端UI理解至关重要，因为很多元素在控件树里信息不完整，但是从视觉上很容易判断它是登录按钮还是底导栏的Tab。
第二条是代码推理能力。现在的大模型不仅能补全代码，还能理解一段脚本的执行上下文，知道这个脚本在哪个页面、在等待什么条件、下一步可能跳到哪里。这个能力让"根据错误日志自动修复脚本"成了现实。
第三条是私有化部署的可行性。测试脚本、测试数据往往涉及核心业务信息，不能直接丢到公网服务上。最近一年里，开源模型的能力提升加上多种私有化推理方案的成熟，让"企业内部部署一个测试专用的大模型服务"从奢侈变成了可选。
这三条线叠加，使得"用大模型重构移动端自动化测试"不是PPT里的概念，而是一个可以在现有测试框架基础上渐进式引入的工程方案。
4. 大模型在移动端自动化测试的四个落地场景
4.1 用例生成：从业务描述到可执行步骤
第一个落地场景，是用例生成。这里的核心不是"让AI替人写代码"，而是让测试人员把精力从编码细节转移到业务描述和评审上。
具体做法是，先定义一套结构化的用例描述模板，包含前置条件、数据准备、操作步骤、预期结果、优先级这些字段。测试人员只需要用自然语言或者模板填空的形式描述"我想验证一个已登录用户能够正常提交退货申请"，大模型根据这个描述，结合代码库里的页面对象模型、已有脚本范例和操作习惯，生成一组具体的测试步骤。
我只测试经验里，生成出来的步骤并不总是完美的，但基本都是"可用的草稿"——比从零开始写得快很多，而且大模型会模仿团队已有的脚本风格，不会生成一套四不像。真正有经验的测试工程师要做的是审核、删减和补充边界场景，而不是对着空白文件发呆。
4.2 元素语义定位与自愈机制
第二个场景，是元素定位。这是大模型对移动端自动化最立竿见影的改造点。
传统定位依赖ID、xpath这种结构信号。大模型定位可以加入三层语义信号：第一层是控件的结构属性，第二层是控件附近的文本和功能描述，第三层是截图里的视觉位置。三者的权重可以动态调节，页面结构正常时主要用结构信号，结构变化后可以回退到文本和视觉信号。
这里我实际验证过的一个方案流程是这样的：用例运行时先尝试传统定位器，如果失败，就自动把当前页面的控件树、截图和错误信息打包发给大模型，让模型分析"用户意图要找的元素最可能是哪一个"，然后返回新的定位路径。如果是选择器写法变了，就原地修复定位器并重新执行；如果是页面大改版，则上报"需要人来看一下"。
这个机制在业界通常被称作"自愈"，但它不是简单的重试，而是带着语义理解的重新定位。
4.3 智能断言：让验证逻辑跟着业务意图走
第三个场景是断言生成。不是完全替代断言，而是帮助测试人员识别"哪些验证点真正重要"。
假设操作链走到"提交订单"这一步，大模型可以根据业务常识推断：订单号已生成、订单状态为待支付、支付按钮可用、金额与商品结算价一致，这些是重要断言；而按钮的具体背景色、页面文案的措辞，这些是非关键断言。传统做法里，这些判断全靠测试人员的个人经验，写出来的断言质量参差不齐。大模型相当于一个"副驾驶"，它会先给出一组建议断言，并标注每个断言的动机和风险等级，由人来选择保留哪些。
我把它理解为：AI把"该不该验证"这件事做出了可讨论的草案，人做最后决策。对话式的交互方式，比起在代码里逐行写断言，效率高得多，而且能让新人少走弯路。
4.4 失败分析与缺陷分类：把排查时间降下来
第四个场景，是失败后的分析。
当一轮回归跑完，大模型可以把所有失败用例的报错信息、截图、日志、堆栈汇总起来，自动做分类，并生成一份人类可读的"失败摘要"：哪些失败极可能是产品缺陷，哪些是脚本定位器失效，哪些是环境类问题，哪些疑似数据污染。分类完之后，还可以给出每个类别的代表性的证据截图，方便直接转给开发。
这个功能解决的不是"怎么不挂"，而是"挂了之后，能多快知道挂了到底是因为什么"。实际体验下来，过去需要一个人花一上午去整理的失败分析，现在大模型辅助下，十分钟可以出一份初步结论，人只需要做验证和补充。别小看这个环节，它直接决定了自动化团队有没有余力做更有价值的事情。
5. 我在一个模拟项目里的实测：效果数据、踩坑记录与方法校准
5.1 模拟项目搭建方式：传统框架加LLM增强层
为了验证上面的思路，我做了一个模拟项目X：一个虚构的电商App，后端用本地mock，前端是标准的Android原生页面，把传统自动化框架跑通以后，再挂上一层LLM增强服务。LLM服务是私有化部署的，数据不出内网。
整体架构很简单，在传统自动化框架之上增加了一个"意图执行器"模块。执行器手里有两类能力：一类是调用既有测试框架的确定性操作，比如点击坐标、等待元素、输入文本；另一类是调用LLM做语义决策，比如定位器失效时的重新识别、断言候选生成、失败原因分类。执行器内部维护一个"用例意图对象"，把界面操作和业务验证分离。
5.2 提示词与输出解析的关键设计
这里有一个很关键的工程细节：提示词设计决定了LLM输出的可用性。
我不建议让大模型自由发挥输出自然语言，而是强制约定一套结构化的JSON格式。系统提示词里给出明确的角色定义、输入信息、输出schema、few-shot示例，以及一个强制规则：只输出JSON，不要解释，不要客套。输出侧再加一层schema校验，不合法就自动要求模型重新生成，最多重试三次。
举个例子，元素定位请求的返回结构大体是这样：
{ "strategy": "semantic_match", "element": { "by": "text|id|xpath|visual", "expression": "加入购物车", "confidence": 0.92, "fallback_hint": "当前控件树中未找到完全匹配，建议检查权限弹窗是否遮挡" } }这个结构的好处是，自动化框架拿到结果后可以直接执行，不需要再解析自然语言，稳定性和可调试性都强很多。所有的LLM调用都走同一个网关，有超时、重试和监控，不会因为模型服务的一次抖动导致整套用例全崩。
5.3 实测对比：修用例时间缩短了多少
在模拟项目里，我选了三条最容易崩的场景做了几组对比实验：一条是首页到商品详情，一条是购物车到结账页，还有一条是订单列表翻页和筛选。每一条都人为改了几处UI结构，比如改了按钮的resource-id、调整了页面的容器层级、改了某个文案。
对比的结果，我可以给你一个相对粗略但方向明确的表：
| 对比项 | 传统手工修复 | LLM辅助修复 |
|---|---|---|
| 平均定位器修复时长 | 15分钟/处 | 3分钟/处 |
| 全流程人工介入次数 | 每处至少1次 | 每3-4处介入1次 |
| 一次改版后用例恢复时间 | 2-3天 | 4-6小时 |
| 新用例从描述到可执行草稿 | 1-2小时/条 | 15-20分钟/条 |
这个数据不严谨，但方向非常清楚。大模型不是把修复时间变成零，而是把"人肉定位"变成了"人审结果"，把以小时为单位的活变成了以分钟为单位。
5.4 三个典型的坑以及对应的校准方法
坑一：幻觉选择器。大模型在描述不存在的元素时，会一本正经地编一个看起来合理的定位路径。我遇到过模型在控件树里没有"我的订单"入口的情况下，自信地生成了一个xpath。对策是：在提示词里注入真实的控件树摘要和页面截图信息，让模型基于事实来源回答，而不是凭空推理。同时，任何LLM生成的定位器在执行前都要过一次本地校验，校验不过就不允许执行。
坑二：长会话后半段质量下降。让大模型在一个长上下文里连续处理几十个步骤，后半段错误率会显著上升。对策是任务切片，每轮会话只做单一决策，比如一次只定位一个元素或只分析一条失败日志。宁可多调用几次，也不要尝试一次做完所有事。
坑三：生成用例的"正确但无用"。大模型生成的步骤很可能在语法上完全正确，但缺少对特定业务逻辑的理解，比如没有考虑到该账号的优惠券状态、没有处理中途插出的广告弹窗。对策是把LLM定位为"候选生成器"，绝不能让它绕过人工评审直接进测试套件。我现在的流程是：生成之后，测试负责人做一轮场景走查，把业务约束写回用例描述模板里，作为后续生成的few-shot参考。
6. 不推倒重来：一条渐进式的LLM辅助测试落地路线
6.1 从低风险、可量化的场景开始试点
别一开始就想着把整套测试平台重构了。我更建议找一类低风险、可量化的场景先试点，例如核心链路的冒烟测试或回归测试。这个场景的用例量不大，业务价值明确，失败了也不至于引发大范围事故，非常适合验证LLM辅助的效果。
关键要提前定好评估指标。不要只看自动化通过率，那个指标在维护好的用例里本来就很高。要看的是：一条新用例从需求到可执行脚本的产出时间、一次UI改版后的用例恢复时间、每轮回归的失败噪音数量、一次失败从发生到分诊完成的时间。这四个指标能真实反映"维护负担"和"反馈效率"的变化。
6.2 建立测试意图中间层，别让LLM直接生成脆弱的脚本
很多人在引入LLM时容易犯一个错误：让LLM直接生成原本的脚本代码。这其实是换了一种方式继续制造脆弱的脚本。
我的建议是建立一个中间表示层，你可以叫它"测试意图语言"或"轻量DSL"。它不绑定具体的控件定位器，而是描述业务步骤与断言目标。例如：
step: 添加商品到购物车 target: 商品详情页的加购按钮 action: click assert: - 购物车角标数字从0变为1 - 出现加购成功提示这样的一层描述，既能让LLM理解测试目标，又能让传统框架把它翻译成具体的执行指令。好处有两层：LLM的输出更稳定，因为它不直接生成易碎的xpath；同时当界面改版时，你只需要更新"target"的解析逻辑，而不需要动业务描述。
6.3 人在回路的闭环：生成、审核、沉淀、复盘
落地路线能不能跑起来，关键看有没有形成"人在回路"的闭环。
我的流程是这样的：大模型先生成一个候选的用例意图，测试负责人审核并修改，确认后加入用例库。一旦这个用例在后续执行中失败，会自动触发定位器修复或失败归因，修复的结果又会被记录为一个新的示例，回流到提示词的few-shot池里。这样模型会越来越熟悉这个项目的页面结构和业务习惯，而不是每次都从零开始猜。
每隔一个月，我会拿一批真实的产品缺陷去做一次复盘，问一个问题：这套自动化用例能不能在缺陷上线之前把它拦下来？如果拦不住，是什么环节出了问题——是断言缺失，还是操作步骤没覆盖到，还是数据准备不对？这个复盘的正反馈，比任何指标都有说服力。
6.4 团队技能要求与角色分工
最后是团队层面的调整。引入LLM辅助之后，测试团队的核心技能不是会写提示词，而是会写"好的测试意图"和"会评审模型输出"。
具体分工上，我倾向于这样的安排：一部分有自动化经验的成员改造框架、维护意图中间层和提示词体系，他们是"工具链的建设者"；另外一部分业务测试成员专注于需求分析、用例评审和人工走查，他们是"质量判断者"。前者不用一天到晚贴界面细节，后者不用硬啃代码。
从成本角度说，这个转型对团队是友好的，因为它不要求所有测试人员都成为大模型专家。只要三四个人能掌握LLM调用的工程化方法，整个团队的产出效率就能上一个台阶。
7. 大模型的边界与底线：幻觉、成本和数据安全
7.1 幻觉是正确性风险，不是体验小瑕疵
网上很多人聊大模型都聚焦在"惊喜感"，但在测试这个对正确性要求极高的领域，幻觉是致命的。一个模型生成了一条断言，说"当订单金额为0时不应该生成订单"，但业务实际是允许0元订单的，这条断言一旦进入套件，就会造成线上误判。
所以我的底线是：任何LLM生成的内容，在直接作用于生产测试之前，必须有显式的护栏。这个护栏可以是schema校验、本地解析验证、最小人工审核，也可以是"双重引擎"——让LLM和一组确定性规则同时给出结果，不一致时以规则为准。没有护栏，再强的模型也不敢直接信。
7.2 token成本与执行频率的工程权衡
LLM调用不是免费的，尤其是在私有化部署之后，算力成本需要精打细算。
做一个粗略的测算：假设每次回归执行500条用例，每条用例平均失败率是5%，失败时有25条需要走LLM修复和归因分析。每条失败用例大概产生3次LLM调用，每次调用消耗的输入输出token合计约4000到6000个。那么一轮回归的LLM调用量大约是75次，token消耗在30万到45万之间。如果每天跑10轮回归，一个月下来就是一个不小的数字。
所以工程上有一个明确的取舍原则：高频路径用确定性脚本，低频创建和维护场景用LLM。用例一旦稳定通过，就不需要每轮都调大模型；只在高频回归之外，做定期的智能巡检和失败归因时再让LLM介入。这样既能降低成本，也能让基础设施更稳定。
7.3 数据安全：私有化部署是不可绕过的前提
做移动端自动化测试，脚本里通常包含业务账号、密码、订单数据、内部接口地址，甚至权限控制的细节。这些东西一旦在公网链路里过一遍第三方模型，性质就完全变了，合规上一定是不允许的。
所以不管怎么引入，私有化部署都是硬前提。现在不少方案都支持在内网用开源模型搭建推理服务，效果虽不及最顶尖的公网大模型，但对于元素定位、失败归因、用例生成这些任务，能力已经足够。从这个角度说，拿"模型不够聪明"当借口不落地，其实是站不住脚的。
最后再分享一个个人体会。我在整套实践里最深的感受是：大模型没有把测试这个职业变简单，但它确实把"一个资深专家才能做好的事"变成了"一个普通工程师经过训练也能做到80分的活"。这已经是很大的进步了。
如果你要开始试，我建议从一件小事入手——挑一个你最常因为UI改版而反复修的用例场景，把它的失败日志交给一个私有化部署的模型，看看它能不能帮你定位到准确的元素和修复建议。把这条路走通，再谈放大也不迟。
