一个每个测试工程师都遇到过的场景
产品经理改了个按钮的位置，UI 上肉眼几乎看不出差异。第二天，CI 里有 40 个测试用例同时挂红。
排查半小时后发现：不是产品逻辑坏了，是测试脚本里写死的 CSS selector #submit-btn-v2 找不到元素了——按钮的 DOM 结构变了，id 也换了。业务代码完全正确，测试脚本先"死"了。
这是自动化测试里最常见、最消耗人力，但技术含量最低的一类故障。也是这个系列想讨论的起点：LLM 到底能不能把这类问题，以及测试领域里另外几个老问题，从"靠人力硬扛"变成"有工程化的解法"。
传统自动化测试的三个老问题
在讨论 LLM 能做什么之前，先把问题本身说清楚。这三个问题不是新问题，业界讨论了十几年，但一直没有便宜、通用的解法。
问题一：脆弱定位（Fragile Locators）
自动化测试脚本要"找到"页面上的元素才能操作它——点击按钮、填写表单、读取文本。找元素的方式无非几种：CSS selector、XPath、元素 ID、坐标。
这几种方式共享一个致命假设：UI 结构在测试脚本写完之后不会变。 现实是 UI 一直在变——改版、A/B 测试、换了个前端框架重构组件树。脚本对 UI 结构的依赖越具体，就越脆弱。
selector 精确度 鲁棒性 维护成本
────────────────────────────────────────────
#submit-btn-v2 极低 UI 稍微变动就失效
.btn.primary 低 class 名重构就失效
//div[3]/button[1] 极低 DOM 层级调整就失效
坐标 (320, 480) 极低 分辨率/布局变化就失效业界给这个问题起了个名字："selector 地狱"。测试团队规模越大，维护 selector 的工时占比越高——不是在写新测试，是在修旧测试的定位逻辑。
问题二：Oracle 问题（怎么判断结果对不对）
"Oracle" 在测试里指的是判断输出正确与否的标准。传统单元测试的 oracle 很明确：assert result == 42。但很多测试场景的 oracle 本身就模糊：
页面截图跟上一版本有像素差异，是 bug 还是正常的字体渲染抖动？
返回的 JSON 多了一个字段，是 API 变更还是测试环境脏数据？
用户流程走完了，但页面"看起来不太对"——不对在哪，说不清楚传统方案是把 oracle 显式化：像素级 diff（阈值多少算变化）、schema 校验（哪些字段必须存在）、断言链（每一步显式检查状态）。这些方案的共同问题是：oracle 定义得越死板，越容易产生大量误报（把无意义的变化标记为失败）；定义得越宽松，越容易漏报（真的 bug 被放过）。
问题三：维护成本（脚本比业务代码更快过时）
这是前两个问题的结果，但值得单独拎出来，因为它是团队最终放弃自动化测试的直接原因。
一个真实的现象：功能迭代速度越快的团队，自动化测试的实际覆盖率往往越低——不是因为不想写，是写完就过时，过时了没人有时间去修，最后干脆被跳过或标记为 skip。测试代码库的熵增速度超过了团队维护它的能力。
这三个问题互相加剧：定位脆弱 → 测试频繁挂红 → 维护成本上升 → 团队没时间维护 → 干脆减少测试覆盖 → oracle 问题更难被发现（因为覆盖率本身在下降）。
为什么是现在：测试恰好是"有明确对错标准"的场景
过去两年 LLM Agent 在很多场景的落地都卡在同一个地方：怎么知道 Agent 做对了。 写代码、做决策、生成内容，这些场景的"对错"往往是连续的、主观的，需要额外搭建评测体系才能判断（这正是 eval-series 在讨论的问题）。
测试恰好是个例外。测试任务本身自带明确的成功信号：
单元测试通过 / 不通过 —— 布尔值，没有中间态
UI 元素找到了 / 没找到 —— 布尔值
断言成立 / 不成立 —— 布尔值
覆盖率提升了多少百分点 —— 可量化的数字这意味着 LLM 在测试场景里的输出质量，可以用测试本身的执行结果来验证，不需要额外一层"评测 LLM 输出是否合理"的元问题。这是测试相比其他 LLM 落地场景的结构性优势——也是为什么过去两年这个方向出现了大量真正跑通的开源项目，而不只是概念验证。
当然，"明确对错"只是针对测试执行结果本身。测试脚本要不要生成、定位要不要自愈、失败原因是真 bug 还是环境问题——这些判断仍然是模糊的，LLM 介入的空间正是在这些判断上，不是在"测试通过与否"这个最终结果上。
LLM 能接上的三个位置
回到开篇的三个老问题，LLM 分别能接入的位置是：
脆弱定位 → 语义定位（"找到提交按钮"而不是"找到 #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 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页