从目标倒推过程：

1. 用例未来可维护 —— 要保存在云端且有版本管理可复原版本，不能存在本地个人电脑
2. 多人协作成本要足够低 —— 支持共享与多人在线编辑，有权限控制
3. 可追溯上下文分析其他问题 —— 需求 & bug 单关联检索展示
4. 用例呈现结构清晰 —— 使用清晰简单的树状脑图，避免使用冗长的表格
5. 用例可打标可筛选 —— 工具支持自定义标签与检索

适合，大厂无论什么时候去都不会亏，有机会还是可以进去锻炼一下。大厂给的钱相对多，平台也大，在里头除了学到什么能做，还能学到什么不能做。

认同你的观点，AI 肯定要用，也得用好。问题主要是 AI 实在太好用了，人的技能也容易用进废退。

不过重新看了一下楼主的帖子，感觉我的发言是跑题了…… 楼主的疑问应该不是标题上写的这么简单

我身边有些同事（尤其是外包和经验少的实习生），非常依赖 AI 写代码，新时代的 copy-paste 抄袭让他们没法沉下心去真正掌握技术，最后自己在写什么代码也不理解，能跑出符合预期的结果就行，但凡代码有点 bug 都没法自己排查，又得找 AI。

我就问一个问题：你想不想成为上面这样的人？

力量训练，吃点好吃，玩玩变形玩具，写点小代码

很庆幸，我从初中开始到现在还对健身保持热情，尤其是当了解到力量训练和举重后，开始打开视野，让我对 “健身” 更加地感兴趣。

希望这个兴趣能跟着我，直到我老掉牙练不动了。

写用例没需求文档怎么写，研发怎么实现需求，那不应该直接去怼产品吗？还得拉上你的测试老板一起去怼

你把一些指标的计算口径告诉 ai，然后再告诉 ai 怎么算好怎么不好，分析思路是怎么样，然后把数据格式告诉 ai，ai 就能拿着数据去分析问题了。真的很强大，省了一堆事。这样玩着玩着慢慢你就会让 ai 做越来越多分析，你的想法就能不断丰富。

那就跑路吧，跑不了就先看着，再水的代码它也是代码

1. 代码阅读技能是基本，需要从代码实现角度去理解业务架构。如果连研发的基础代码都看不懂，走不远的。
2. 对测试场景的敏锐度，业务中有很多通用的场景是可以变成经验的。哪些典型场景就天然涉及数据安全、隐私合规问题，哪些典型场景高概率要考虑性能问题……
3. 基础测试方式的信手拈来。对于性能测试、安全测试等各类姿势，要有基本理解，这种理解不会随着更换测试工具而变化，它是一种本质的理解，可以让你不依赖单一测试工具去实现你的想法。

确实是水积分很好的办法

应该不少，腾讯阿里这些肯定都有的

似乎规定是 8 点就可以下班，所谓强度看怎么理解，工作会比较密集，但是不会硬性施加很大的压力。而且强度和业务有很大关系，每个业务团队情况不一样。

但总的来说，随着加入行业的人越来越多，也逐渐开始卷起来了。

不想卷技术，不想加班，又想留在比较安逸的城市，还想拿到比其他行业高一点的薪资，可以考虑做离案外包，现在很多互联网大厂的测试都在推行离案外包，就是非驻场外包测试。

因为我这是应用方，所以具体准确率数据只能给定性的判断，超过 85%（90% 应该也有）。

局限性有，但整体利大于弊：

1. 控件搜索由控件树直接定位，变成大模型搜索控件树，定位时间有增加，但常规定位时间就是秒级，再增加影响不大。
2. 原本的代码控制点击，变成让大模型通过 function call 完成点击，依然是耗时的增加。
3. 多了大模型的处理，多加了一个不稳定的因素，也增加机器成本。
4. 大模型多次调用在返回上的不稳定，好比相同问题多次问大模型，给的答案不完全一样，有时同一个控件定位多次会有小概率定位失误，具体数据应用方视角不清楚。

故整体的局限是耗时和机器成本上的增加，但是人力等到较大节约，编写成本是一方面，长期维护成本也是一方面（谁顶得住一两周就变一下的控件 id 和控件树结构）

如果是上层决策者，个人感觉不会有很大的 “意志差别”，我倾向于认为上层决策者都是信息输入充分的理性人，而国内经常做出 “牺牲质量” 的决策，正正是因为外部环境、历史案例等各种参考。
就好比很久以前李彦宏公开说是国人愿意牺牲一点点隐私来换取极大的便利，我感觉老外可能也愿意，只是少部分很极端的意识形态阻止这种事情，不断强调某种观点，最终大家习惯了就顺着意思去做。

发展才是硬道理啊，业务不同阶段有不同特点，，质量、成本、效率 是一个三角，都应该要关注。

对于各种常规场景是够了，操作成功率是高于 90% 的，只要不是通篇代码滥用，简单场景脚本用这个可以写得很快，也省掉很多脚本控件维护成本

可以网上找找 MTSC 或者 QCon、QECon 最近一两年的 ppt，应该已经有类似的方向，我司的 UI 自动化框架团队也做了这种 ai 找控件再点击的能力，虽然有局限性但感觉已经能覆盖 80% 以上的常规自动化场景，大体来说长得像这样：

ui.action('点击页面右上方圆形蓝色的“搜索”按钮')
ui.action('点击搜索结果列表中第二条数据')

比如，https://www.53ai.com/news/OpenSourceLLM/2024121816054.html。

MTSC 大会和 QECon 这一类大会应该有相关课题的 ppt，需要自行去搜索一下

• 有没有办法进行框架级别的整合，不管是测 UI 还是接口还是 APP，都采用同一套框架，减少对于框架的维护工作量？

我先质疑一下 “采用同一套框架” 是不是真的能带来 “框架维护工作量的减少”。从开发者视角看可能维护两套东西很麻烦，但是两套变一套不代表维护工作量除以 2，就像 5 楼鸡哥说的，硬凑在一起会带来更多复杂度，可能排个 bug 的耗时变成了之前的 3 倍？换个角度，从落地视角，已实现的老脚本要怎么支持，是要求用户从老脚本全部切到新脚本吗？那这个事情必然做不成（如果不是公司实践，那个人过过技术瘾无可厚非）

• UI 测试构建元素定位信息的过程太繁琐了，也容易出错，能不能跳过？

明确可以用 ai 去解决，业界已经有实践。我个人使用下来觉得很不错，对比原先要理解 xpath、控件 id 等概念，直接用自然语言描述/操作元素显然成本更低，还能让更多人参与进来。我是支持用 ai 解决的。

• 如果某产品有多端，需要进行联合测试，比如说一个用例，在 web 上修改一个参数，在 APP 端验证是否修改成功，这样类似的需求在框架层面好像无法实现？

这个真没必要去解决。你先想想这种联合场景多不多，人工测试覆盖需要多少人天成本再考虑。其次这种跨端联合场景，如果是跨服务端到移动端还稍微好一点，而跨 web 端到移动端就更麻烦，中间需要控制的变量/不稳定因素数不胜数。可能最后做是做出来，要不稳定性像屎一样，要不测试脚本配置编写巨麻烦。

• 如何避开复杂环境搭建的过程，减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施？

问题 4 没看明白，问题大而泛，没理解希望解决什么问题。是成本问题还是效率问题？复杂环境搭建前后端可以用 docker 等成熟技术解决，移动端不了解。【减轻使用代码构建测试用例的场景，如何让更多的人投入自动化测试的实施】，是指类似低代码的思路吗？现在是有不少团队在探索通过和 ai 聊天结合线上流量抓取、代码分析生成一系列接口自动化测试用例这种事情，不知道你是不是想表达这些。

最后，一个大的自动化测试平台，重要的不仅仅是自动化技术，数据看板运营，上下游套件，排查定位方便度等都很重要，可以考虑这些维度的效率提升。

可能是我的年纪到了，阶段到了，以前觉得这段子很煞笔，现在反而觉得这精神状态肯定活得很开心
（抱歉，回复和匿名功能玩不太明白，连删了两次评论😂）

👍

老哥到金蝶了吗？

以前和在 Thoughtworks 工作的师弟聊天，他曾外派到国内某银行干了半年到一年，他说国内很多银行都还在用 ibm 小型机，整个银行系统都是从国外买回来，再招人做运维的程度。

天啊，不敢相信 2025 年了还有如此老久的技术形态 ，但是没办法，架不住别人还是一样地库库赚钱啊。

我想表达，一个业务赚不赚钱、好不好，和技术真的没有必然的关系。但的确可以通过技术提前布局来满足业务未来增量，做到类似 “技术驱动业务” 的感觉，如阿里的全链路压测就是技术支撑业务。而真正因为技术突破而塑造新业务模式，这种案例很少的，电商算一个吧，大模型肯定也算