当前工具链不成熟的情况下，的确使用 AI 的测试投入比不用 AI 大，很多额外的工作（学习成本，文档整理，知识沉淀，生成结果审核等），测试的工作方式可能会有定的变化，有些重复类的，整理类的工作可以让 AI 主导，人为辅，但是岗位不会消失，只是工作模式变化了，测试人员要做的就是跟紧 AI 时代的脚步，不掉队，其他的不用太焦虑。

这个方案很有前瞻性，很多大厂已经这样做了，完全可以实现，只是时间问题

还是不推荐用高代码的方式，实现 UI 自动化测试，后期的维护成本高，如果不考虑 token 的消耗的话，对应测试最终要的就是场景覆盖（基于文本描述的步骤），完全依赖自然语言驱动测试，我一直在研究这个话题，我使用的是改造后的 browser use+ 大模型来实现了一套，可以完全基于自然语言驱动 UI 一步一步的执行，稳定性也还不错，最终要的资产就是每个步骤的描述，中间可能会沉淀为一个 json 文件，但是也存的是每个步骤的一些语言描述。

你要相信，AI 的出现，测试岗位和作业模式一定会改变，迟早的事情，前面可能是人用 AI 干活，人主导，AI 为辅，后期就是 AI 主导，人为辅，人只需要做最终的审核就好了，一定不远了

在大模型时代，UI 自动化测试，不能太偏重代码实现了，重代码实现，对后期的灵活性就会差（页面变动，代码也要调整，不然会报错），其实就应该轻量化，但是有不能让大模型太发散，太发散了，稳定性就会变差， 我更倾向于，思考和决策，反馈，修正等都适合用模型去干，对于底层的点击什么元素，进行什么操作，输入什么值等确定下的事情，一定要有一个可靠性的框架来驱动去干，分工合作。

这里面有几个很关键的点，我也一直在尝试能够完全自主的实现自动化测试，并且重复运行的时候稳定性要强，首先是要选择好的底层框架，能够基于大语音模型，驱动每个用户步骤去操作浏览器，不是传统的 xpath 定位等方式，底层的适应性要足够强，你用 json 承载问题不大。其次是要能够从已经实现的自动化用例（操作序列，也是 json），能够形成一定的业务场景资产，后续可以作为一个重要的用例泛化自动生成的依据，相同的操作步骤（点和线），可以合并，这样不会爆炸式的增长，后续没有办法使用，有了这些业务流程资产，后续对用例编写要求就不需要那么高，就可以生成满意的新的用例（json）,最后就是测试数据的问题，测试的关键就是数据，没有一个完整的造数流程支撑，又写核心流程，很难进入，只能测试一些皮毛，无法深入验证业务流程。个人也有一套完整的实现方案，基本可以完整的闭环以上问题。

如果是测试接口的话，这种如果希望测试的又全面，不遗漏的话，可以写一个脚本，遍历组合测试下，不要管他需求是啥，先不管他的结果是否满足要求，把结果记录下来，人工对结果进行审查，这样比较全面，可能会有一些意想不到的 bug 可以捡漏

如果是想自己成长起来，只有自己在家里学习，并且付费那种