当团队开始用 AI 编码代理持续交付 UI 改动时，五年前常见的软件测试基础需要重新审视。本文主张把测试编写的基本单位从 DOM 选择器转向用户意图。
自愈不应只是付费附加项，而应成为测试体系的默认能力。验证也不宜等到几天后的独立 QA 周期，而应尽量在 AI 编码代理的工作会话中完成。
测试套件的价值，不应由写了多少行 Playwright 决定，而取决于它能否以接近交付速度的节奏给出反馈。如果你的测试仍是录一遍点击路径、下次重构后看它失效、再反复修选择器，这篇文章提供了一份可逐步采用的升级清单。
测试基础为何重构
变化的原因并不是 QA 发明了新的理论，而是软件交付链路的其他环节变了。Claude Code、Cursor、OpenAI Codex 等 AI 编码代理缩短了实现功能的时间，测试反馈若仍停留在独立且滞后的周期，就更容易与交付节奏脱节。
在高频交付的团队中，Pull Request 数量增加，UI 改动也更持续。2020 年代常见的做法是编写 Playwright，在合并时运行，并在选择器漂移后修复。面对新的交付吞吐量，这套做法的维护压力会持续上升。
本文给出一套面向 2026 年的替代思路：五项能够落地的测试基础、每一项的具体含义，以及示例产品 Shiplight 中对应的能力，帮助你在阅读后的一周内开始试用。如果你想先了解更大的类别框架，而不只是这些基础原则，可以先看 AI 测试是什么。
2026 年的五项基础
基于意图编写测试。测试描述用户要做什么，而不是要点击哪个选择器。对应能力：YAML Test Format。
默认具备自愈能力。测试能够在 UI 重构后继续运行，不要求人工逐条修改。对应能力：Shiplight 的 AI Fixer。
代理原生验证。AI 编码代理在编写代码的同一会话里，将测试作为工具调用。对应能力：Shiplight MCP Server。
在 PR 阶段设置CI 门禁，而不是依赖夜间批处理。每个 Pull Request 都在真实浏览器中验证，并阻止会破坏用户流程的合并。对应能力：Shiplight Cloud runners 与 CI 集成。
测试归属代码仓库。测试以可评审的代码工件存在于 git，而不是锁在供应商的界面中。对应能力：与源代码一起提交的 YAML Test Format。
下文会解释这些变化背后的原因，以及如何在不重写既有测试栈的前提下逐步完成升级。
测试基础的代际迁移
| 维度 | 2020 年的软件测试基础 | 2026 年的软件测试基础 |
|---|---|---|
| 编写方式 | Playwright、Cypress、Selenium 代码，绑定 CSS 或 XPath | 自然语言意图，例如点击结算，绑定用户动作 |
| 能否经受 UI 变化 | 不能，每次重构都可能破坏选择器绑定 | 可以，意图会在当前 DOM 中重新解析，采用 intent-cache-heal 模式 |
| 编写者 | 以人工输入速度工作的工程师 | 在同一会话中以代理速度工作的 AI 编码代理 |
| 验证运行时机 | 夜间或合并时 | 每个 Pull Request，在真实浏览器中、评审前运行 |
| 维护成本 | QA 时间中可能有 40%~60% 用于维护选择器 | 可显著降低，自动修复处理 UI 漂移，人工审核补丁 |
| 归属 | 独立测试周期中的 QA 团队 | 交付改动的产品工程师 |
| 失败信号 | 带堆栈跟踪的失败 CI，且往往不稳定 | 失败回放视频、DOM 快照，以及按步骤给出的可操作差异 |
| 覆盖形态 | 取决于有人来得及写多少 | 代理在构建期间生成的测试，加上持续保留的回归覆盖 |
如果你的团队在多数维度上仍处于左列，问题未必是没有使用某个新工具，而是测试方式可能没有适配当前交付节奏。两种方式可以并存，你可以渐进式引入新做法，而不必一次重写。下面每一项基础都可以独立落地。
基础一：意图优先
2026 年软件测试最重要的变化，是测试如何被写出来。旧默认做法是把步骤绑定到 CSS 选择器或 XPath，这使得每个测试都像为重构埋下的触发器。改一个类名、替换组件库、对按钮文案做 A/B 测试，都可能在一夜之间积累大量无意义的失败。
本文建议采用相反的做法：测试步骤使用自然语言描述用户意图，运行器在执行时把意图解析到 DOM 元素。
- intent：将第一个商品加入购物车
- intent：前往结算
- VERIFY：订单确认页显示订单号
对比下面的写法：
await page.locator('button.btn-primary[data-testid="add-to-cart"]').click();
await page.locator('a[href="/checkout"]').click();
await expect(page.locator('h1#order-confirmation')).toContainText(/Order #\d+/);
Playwright 写法很精确，但也很脆弱。YAML 写法更容易跨越重构，并且让非技术角色也能在 PR 中读懂测试。更深入的原因可以参考意图优先的 E2E 测试指南。
Shiplight 示例能力。若选择 Shiplight，文中对应的能力是 YAML Test Format：测试以纯 YAML 文件与源代码一起提交，可在代码评审中查看、比较差异、搜索并纳入版本控制。是否存在供应商锁定风险，仍应以目标产品的导出、迁移和版本控制能力为准。
基础二：默认自愈
2020 年，自愈测试通常被视为高级功能。对于由 AI 编码代理持续带来 UI 改动的团队，它更适合作为测试体系的基础能力；否则，需要人工维护选择器的测试套件会持续成为瓶颈。
实际落地时，默认自愈至少要覆盖下面几种情况：
- 某一步写着点击提交按钮，提交按钮从 button 元素变成 a 元素。下一次执行时，运行器仍可依据文本、角色和位置找到它，测试继续通过
- 两个测试步骤之间多出一个弹窗，例如 Cookie 提示。运行器应等待页面稳定，并在合理范围内处理该弹窗，而不是直接超时
- 当某一步确实无法可靠解析时，运行器应给出测试补丁建议，而不是只报红。由人工像审核普通 PR 一样审核差异
最后一点尤其重要。许多所谓自愈工具会静默修改测试，这会破坏可审计性。将修复作为 PR 中可审核的补丁，才能同时保留审计线索。关于这个边界，可以继续阅读如何修复不稳定的 E2E 测试，以及自愈和人工维护的对比。
Shiplight 示例能力。若选择 Shiplight，文中对应的能力是 AI Fixer：它根据当前 DOM 解析意图；无法高置信地解析某一步时，生成可审核的差异补丁。这样既保留 git 中的审计记录，也减少人工维护选择器的工作。实际效果应以团队自身的失败率、修复率和人工审核成本验证。
基础三：代理原生验证
这是 2020 年没有出现过的基础，因为当时还没有能够自主编写生产代码的 AI 编码代理。如今，代理原生的自动化 QA 才能把验证闭环放回 AI 编码团队的实际工作方式中，而不是把受选择器约束的旧测试套件硬套到新的交付节奏上。
它解决的失败模式很直接：编码代理生成了一个功能，既有测试套件全部通过，因为代理没有触及测试；PR 合并后，三天后才有用户反馈新流程不可用。代理从未在真实浏览器中验证自己刚刚交付的结果，它只运行了已经存在的测试。
本文建议的基础做法是：编码代理在提交 PR 前，于生成代码的同一会话中调用测试工具。
代理为刚刚实现的功能生成一条基于意图的测试，在真实浏览器中运行，看到实际渲染结果后，才标记 PR 可以进入评审。关于这一模式，可以参考面向 AI 编码代理的测试层。
要做到这一点，测试工具至少需要两项能力：
- 可由代理调用的编程接口，而不只是供人工点击的界面。对应 Shiplight MCP Server
- 兼容 MCP 的接口，使 Claude Code、带 MCP 的 Cursor 或自定义编排器都能调用，而不需要单独开发胶水层。对应 Shiplight MCP Server 与 MCP for testing
简而言之：测试工具如果不把自己暴露给代理，代理交付的代码可能从未被它验证过。
基础四：PR 质量门禁
2020 年的常见做法是夜间运行完整测试套件，在合并时运行较小的冒烟检查。本文建议把受影响流程的真实浏览器测试前置到 Pull Request 评审前，并在失败时阻止合并。
当 AI 生成的代码占据更多 PR 时，明天再发现构建已坏的反馈时延，与快速完成一次改动的交付时延严重不匹配。质量门禁也应以接近交付速度的节奏工作。
一个实用的 2026 年 CI 门禁至少检查以下问题：
- 受影响流程的意图测试是否在真实浏览器中通过
- 对新增功能，代理是否生成了测试，并且该测试是否已经成功运行
- 已被隔离或标记为不稳定的测试，是否已经稳定到可以解除隔离
- 测试改动本身是否通过代码评审，因为 YAML 测试同样是可评审的代码工件
一套面向 AI PR 的质量门禁，会把这些问题落实为可判定的合并条件。输出不该只是堆栈跟踪，而应是评审者能够信任的合并或不合并信号。
Shiplight 示例能力。若选择 Shiplight，文中对应的能力是 Cloud runners 与 CI 集成，可对接 GitHub Actions、GitLab CI 和 CircleCI。它应提供回放视频、DOM 快照以及按步骤呈现的失败差异，而不是只输出堆栈跟踪文本；具体接入能力应以实际产品文档和试运行结果为准。
基础五：测试与代码同库
有一项常被忽略的基础，通常只有在团队想迁移平台时才会意识到它的重要性：测试定义究竟存在哪里。2020 年 SaaS 测试工具盛行时，测试常被放在供应商界面、拖拽式构建器、专有脚本格式和其云端截图中。离开供应商，往往意味着从头重写。
本文建议的基础做法是：测试以纯文本存在于代码仓库，在 PR 中评审，并由同一批交付功能的工程师负责。这样可以带来几项直接收益：
- 测试差异和功能改动出现在同一个 PR 中，由同一个评审者审阅
- 新工程师可以像阅读源代码一样阅读测试
- 测试历史就是 git log，拥有同样的作者归属和回退路径
- 平台迁移更像修改解析器，而不是重写整套测试
这也是选择 YAML 测试格式的原因：它是文本，便于比较差异，也便于迁移。
仍待厘清的问题
单元测试还要写吗？要。单元测试验证单元。这里讨论的 2026 年基础针对端到端层，因为 AI 生成的 UI 变化更容易在这里暴露，也更容易带来 Playwright 维护成本。单元测试、集成测试和 E2E 测试仍是三个互补层次。
人工探索性测试过时了吗？没有，只是频率可能降低。人工探索性测试擅长发现脚本没有想到的意外用户路径，这类缺陷仍然存在。代理式测试生成器正在缩小这部分差距，例如 agentic QA benchmark 所讨论的方向；但在高风险发布中，仍然值得保留人工查看实际构建结果的环节。
还需要独立 QA 团队吗？取决于规模。2026 年更常见的默认做法是，交付改动的工程师负责该改动的测试。在企业规模下，一个专注于测试策略、隔离测试评审和探索性测试的小型 QA 职能仍有价值。可以进一步阅读从人工 QA 瓶颈到代理优先团队。
API 和契约测试怎么办？它们仍然属于同一分层模型：API 测试与单元测试一起放在代码仓库中，在每个 PR 上快速运行。本文的新基础主要讨论 UI 层，因为这里是 AI 编码代理带来最多速度、也最容易带来意外的区域。
收录于 FunTester 原创专题：AI ，测试有点东西
相关阅读：看懂 AI 测试工具的四种类型 · 意图驱动测试，重塑测试范式 · 负 10 倍工程师的质量护栏 · 微服务 E2E 测试为何失败 · MCP：引领 AI 测试新时代