AI自动化测试三大方案深度解析：代码脚本、DOM解析与视觉模型

在AI快速渗透软件测试行业的今天，同样是做自动化测试，玩法却已经发生了根本性变化。许多测试工程师面临一个共同的困惑：AI兴起后出现了大量新的自动化手段，我到底掌握了几种？工作中应该采用哪种方式？面试时又该如何区分自己与其他候选人？

本文系统梳理AI时代自动化测试的三大主流方案：代码脚本（AI编程）、DOM解析驱动、视觉模型（LVM）驱动，帮你建立对AI自动化测试的全貌认知。

行业背景：从「人用工具」到「AI用工具」

在AI出现之前，自动化测试主要依托两大方式：一是使用现成的自动化工具（如Selenium录制脚本、Postman、JMeter、Apifox、MeterSphere等）；二是通过编程语言编写自动化测试脚本。前者的痛点在于工具往往不契合具体项目，需要大量定制化扩展。

AI时代最大的变化，可以用两个字概括——效率。行业对效率的极致追求正在重塑每个岗位。一个明显的信号是：工具的使用对象正在从测试人员转向AI Agent。

观察Postman和Apifox近几年的大版本更新会发现，它们几乎全部围绕AI能力展开。在Postman里，你只要会打字就能生成脚本，不再需要人工编写。

这意味着两个关键转变：工具的使用者由人变成了AI Agent，脚本的编写者也由人变成了AI Agent。但AI本身并不天然具备这些能力，它需要一整套工具和知识的支撑——这正是理解三大方案的前提。

方案一：AI编程生成代码脚本

第一种方式对大多数人最为熟悉——编写代码脚本。区别在于，现在由AI来完成编码工作，即所谓的「AI编程」或「Vibe Coding（氛围编程）」。

用Skill让AI输出可控、可复用

这里引出了一个核心概念——Skill（技能）。Skill本质上是一套描述文件，告诉AI如何完成一件事情。它的物理形态是一个文件夹，里面包含一个 SKILL.md，将其放置到Agent工具的指定目录，Agent在执行指令时就会自动加载其中的描述信息。

一个典型使用场景是：在空项目中直接调用一个Skill，AI便会「根据Skill模板在当前目录创建一个基于 PyTest + Playwright + Allure 的Web自动化测试项目脚手架」。

为什么要用Skill而不是直接让AI生成？关键在于可控性：

• 直接让AI生成脚手架，前后两次的结果往往不一致；
• 封装为Skill后，每次生成的结果都是规范、可控的。

更重要的是学习范式的转变。过去学自动化最大的痛点是「学了就忘」——要背PyTest语法、背POM对象封装、背Allure报告配置。现在，你可以把学习成果封装成一个个Skill：

学完一个框架后，让AI把这个学习成果封装为Skill。以后要用时，直接调用「半年前封装的这个Skill帮我快速生成脚手架」，不再需要网上东拼西凑、反复修改。

这些Skill不仅是可复用的工作资产，更是面试时能够展示的具体成果。

代码脚本方案的核心优势

AI可以快速完成脚手架生成、测试用例编写、POM对象封装并成功运行、生成Allure测试报告的完整流程。该方案最大的特点是：执行速度快。当代码方案几秒钟就跑完多条用例并生成报告时，后面两种AI驱动方案可能才执行完一个操作。

方案二：Agent + Skill 的DOM解析驱动

随着实践深入，一个自然的疑问浮现：既然AI都能直接操作浏览器了，为什么还要写代码？

直接给AI下达自然语言指令：「点击我的书架 → 点击某本小说 → 检查是否进入详情页，若进入则输出测试通过」。AI自主完成了页面点击、内容识别和断言判断。这就是第二种方案——Agent + AI工具 + Skill 的自主执行测试（自然语言驱动）。

DOM模式的底层原理

这里的关键工具是 Playwright CLI。这个Skill的本质是：

一套说明文档 + Playwright官方的CLI命令行工具

Playwright CLI是微软基于Playwright框架开发的命令行工具，其工作原理如下：

1. AI调用Playwright CLI命令获取页面快照（DOM信息）；
2. Playwright将当前页面的所有元素进行编号（如首页编号15、登录按钮编号116）；
3. LLM大模型根据用户输入，匹配到目标元素编号；
4. 再调用Playwright执行对应操作。

本质上是把页面「变成了文字」。HTML本就是超文本，AI通过阅读DOM信息就能知道哪个元素在哪、如何操作。AI并非不需要元素定位，而是Playwright帮它完成了编号定位的工作。

与代码模式的本质区别

第一，无需为每个操作编写代码——点击、输入、下拉、拖动等操作已被封装成CLI命令。

第二，调用方式不同——代码是「预制」的，写完后每次运行效果固定，一旦页面元素变化就会失效；而AI驱动可以动态地根据页面变化灵活调用不同操作，需要点击就调点击，需要滑动就调滑动。

DOM模式的三大缺陷

该方案存在以下局限性：

1. 消耗Token且依赖模型能力：每个步骤都需要大模型动态判断，模型质量较差时可能导致脚本无法跑通。
2. 上下文限制：页面复杂、流程涉及多页面时，容易触发大模型的上下文瓶颈，产生遗忘和幻觉（例如在员工ID字段填入了部门ID）。
3. 执行速度慢于代码脚本。

但它的优势同样显著——成本极低。一个月薪1.5万的测试人员，平均约100元/小时；而100元的Token在测试领域能做很多事情。对于规模不大、流程不复杂的项目，或冒烟测试、线上巡检等场景，AI自然语言驱动的性价比极高。

方案三：LVM视觉模型驱动

DOM模式还有一个软肋：如果页面开发不规范导致元素无法定位，或同类元素过多（多个登录/删除按钮）导致误判，或面对游戏、图标等没有明确文字与元素的场景，就力不从心了。这时需要第三种方案——基于视觉大模型（LVM）的驱动。

视觉模型：像人一样「看」页面

LVM即大视觉模型，处理的核心是图像。与Playwright CLI获取DOM不同，视觉模型获取的是人类肉眼能看到的页面图像。

最直观的例子是：让AI「点击一个粉色封面加女孩的小说」「找一个黑暗的、有树叶加女孩的封面」——这些没有任何文字标识、纯靠视觉判断的操作，AI都能像人一样准确识别并点击。

视觉模型的核心优势

相比DOM模式，视觉模型具备以下优势：

• 拟人程度更高，更接近人类真实的视觉操作方式；
• Token消耗更少、上下文占用更少——无需加载分析整个页面的所有DOM元素，只需针对视觉目标操作；
• 适配大页面和长流程执行，有效规避了DOM模式的上下文瓶颈。

视觉方案同样可以添加自动断言、生成带截图的测试报告——核心在于明确告诉AI要做什么、要保存哪些数据，并将这些固定任务封装为Skill。

三大方案对比与选型建议

三种AI自动化测试方案各有优劣，实际工作中应结合使用：

维度	代码脚本(AI编程)	DOM解析驱动	视觉模型(LVM)驱动
执行速度	最快	较快(简单页面)	较慢
稳定性	最高	中(受模型影响)	中高
是否需编码	需要	无需	无需
Token消耗	无	较高	较低
上下文压力	无	大	小
适用场景	稳定+高速需求	小项目/冒烟测试	复杂/长流程/无明确元素

如果你希望自动化既稳定又快，目前代码脚本仍然是唯一的选择。

关键提醒：质量把关不能失控

一个值得警惕的问题：AI生成脚本并自称「测试通过率100%」，你如何评判它的质量？

开发用AI写代码，测试也用AI写代码，再用AI去测另一个AI——如果你完全不看代码逻辑，AI在验证过程中报的错你根本无法发现。到这个地步，质量也就彻底失控了。

因此，保障AI生成脚本的质量，是AI时代自动化测试人员的必修课。写代码不等于完全交给AI，你必须具备看懂、审查AI产出的能力。

结语：AI时代测试工程师的真正竞争力

AI时代，编程语言已不再是门槛，重要的是你的编程思路和看懂AI代码的能力。

对测试从业者而言，真正的竞争力不在于「我会用AI写测试用例」，而在于：

• 解决方案多样化——三种方案都能落地，别人只会一种；
• 成果可交付——把框架封装为Skill、将AI与浏览器融合、开发视觉测试工具等实实在在的产物；
• 构建AI质量工程体系——将规范、用例、脚本、性能测试等环节与AI Agent、Skill、大模型技术贯通起来。

这是一个新赛道，意味着大家站在同一起跑线。但正如自动化时代一样，它终将经历优胜劣汰——能搭建整套体系的人会持续受到认可，而仅停留在工具使用层面的岗位则面临更大压力。掌握核心方法论，才是穿越周期的底气。