LLM 自动化测试系列（01）：为什么测试是 LLM 落地的新战场

一个每个测试工程师都遇到过的场景

产品经理改了个按钮的位置，UI 上肉眼几乎看不出差异。第二天，CI 里有 40 个测试用例同时挂红。

排查半小时后发现：不是产品逻辑坏了，是测试脚本里写死的 CSS selector #submit-btn-v2 找不到元素了------按钮的 DOM 结构变了，id 也换了。业务代码完全正确，测试脚本先"死"了。

这是自动化测试里最常见、最消耗人力，但技术含量最低的一类故障。也是这个系列想讨论的起点：LLM 到底能不能把这类问题，以及测试领域里另外几个老问题，从"靠人力硬扛"变成"有工程化的解法"。

传统自动化测试的三个老问题

在讨论 LLM 能做什么之前，先把问题本身说清楚。这三个问题不是新问题，业界讨论了十几年，但一直没有便宜、通用的解法。

问题一：脆弱定位（Fragile Locators）

自动化测试脚本要"找到"页面上的元素才能操作它------点击按钮、填写表单、读取文本。找元素的方式无非几种：CSS selector、XPath、元素 ID、坐标。

这几种方式共享一个致命假设：UI 结构在测试脚本写完之后不会变。 现实是 UI 一直在变------改版、A/B 测试、换了个前端框架重构组件树。脚本对 UI 结构的依赖越具体，就越脆弱。

css 复制代码

selector 精确度      鲁棒性        维护成本
────────────────────────────────────────────
#submit-btn-v2      极低          UI 稍微变动就失效
.btn.primary         低            class 名重构就失效
//div[3]/button[1]   极低          DOM 层级调整就失效
坐标 (320, 480)       极低          分辨率/布局变化就失效

业界给这个问题起了个名字："selector 地狱"。测试团队规模越大，维护 selector 的工时占比越高------不是在写新测试，是在修旧测试的定位逻辑。

问题二：Oracle 问题（怎么判断结果对不对）

"Oracle" 在测试里指的是判断输出正确与否的标准。传统单元测试的 oracle 很明确：assert result == 42。但很多测试场景的 oracle 本身就模糊：

javascript 复制代码

页面截图跟上一版本有像素差异，是 bug 还是正常的字体渲染抖动？
返回的 JSON 多了一个字段，是 API 变更还是测试环境脏数据？
用户流程走完了，但页面"看起来不太对"------不对在哪，说不清楚

传统方案是把 oracle 显式化：像素级 diff（阈值多少算变化）、schema 校验（哪些字段必须存在）、断言链（每一步显式检查状态）。这些方案的共同问题是：oracle 定义得越死板，越容易产生大量误报（把无意义的变化标记为失败）；定义得越宽松，越容易漏报（真的 bug 被放过）。

问题三：维护成本（脚本比业务代码更快过时）

这是前两个问题的结果，但值得单独拎出来，因为它是团队最终放弃自动化测试的直接原因。

一个真实的现象：功能迭代速度越快的团队，自动化测试的实际覆盖率往往越低------不是因为不想写，是写完就过时，过时了没人有时间去修，最后干脆被跳过或标记为 skip。测试代码库的熵增速度超过了团队维护它的能力。

这三个问题互相加剧：定位脆弱 → 测试频繁挂红 → 维护成本上升 → 团队没时间维护 → 干脆减少测试覆盖 → oracle 问题更难被发现（因为覆盖率本身在下降）。

为什么是现在：测试恰好是"有明确对错标准"的场景

过去两年 LLM Agent 在很多场景的落地都卡在同一个地方：怎么知道 Agent 做对了。 写代码、做决策、生成内容，这些场景的"对错"往往是连续的、主观的，需要额外搭建评测体系才能判断（这正是 eval-series 在讨论的问题）。

测试恰好是个例外。测试任务本身自带明确的成功信号：

复制代码

单元测试通过 / 不通过        ------ 布尔值，没有中间态
UI 元素找到了 / 没找到        ------ 布尔值
断言成立 / 不成立            ------ 布尔值
覆盖率提升了多少百分点        ------ 可量化的数字

这意味着 LLM 在测试场景里的输出质量，可以用测试本身的执行结果来验证，不需要额外一层"评测 LLM 输出是否合理"的元问题。这是测试相比其他 LLM 落地场景的结构性优势------也是为什么过去两年这个方向出现了大量真正跑通的开源项目，而不只是概念验证。

当然，"明确对错"只是针对测试执行结果本身。测试脚本要不要生成、定位要不要自愈、失败原因是真 bug 还是环境问题------这些判断仍然是模糊的，LLM 介入的空间正是在这些判断上，不是在"测试通过与否"这个最终结果上。

LLM 能接上的三个位置

回到开篇的三个老问题，LLM 分别能接入的位置是：

arduino 复制代码

脆弱定位  → 语义定位（"找到提交按钮"而不是"找到 #submit-btn-v2"）
          → 自愈定位（UI 变了，用语义重新找到元素，而不是脚本直接挂掉）

Oracle 问题 → 语义判断（"这个视觉变化对用户来说是不是真的 bug"）
            → 而不是纯像素/纯结构比对

维护成本  → 自动生成测试用例（覆盖率驱动）
          → 自动分类失败原因（真 bug / 环境问题 / 测试本身有问题）

这三条线索对应系列后续要拆解的方向：单元测试生成（03）、Web/移动端 UI 自动化（04-09）、自愈定位（10）、API 测试（11）、视觉回归（12）、失败分类（13）。

下一篇（02）会先把这些方案背后共享的技术底座讲清楚------视觉定位、DOM 语义化理解、纯坐标点击式 Computer Use，这三条路线各自的原理和取舍，是后面每一篇案例拆解都会用到的词汇表。

这个系列不打算做什么

在开篇先说清楚系列的边界，避免读者带错预期：

不做"AI 测试趋势"综述：每篇选一个技术点，配一个可考证的开源项目案例，不写"据说""未来可能"这类无法验证的表述
不重复讲 LLM 输出质量评测 ：那是 eval-series 的范畴，这个系列讲的是"用 LLM 做测试"，不是"评测 LLM 输出"
不回避局限性：每个技术方案介绍完，都会讲它在什么场景下不成立，或者代价是什么

总结

脆弱定位、oracle 问题、维护成本是自动化测试的三个老问题，且会互相加剧
测试任务自带明确的成功信号（通过/不通过），这是 LLM 在这个领域落地相比其他场景的结构性优势
LLM 能接入的位置是语义定位/自愈、语义 oracle 判断、自动生成与分类，而不是替代"测试通过与否"这个最终判定本身

欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，欢迎访问我的个人主页