当团队开始用 AI 编码代理持续交付 UI 改动时，五年前常见的软件测试基础需要重新审视。本文主张把测试编写的基本单位从 DOM 选择器转向用户意图。
自愈不应只是付费附加项，而应成为测试体系的默认能力。验证也不宜等到几天后的独立 QA 周期，而应尽量在 AI 编码代理的工作会话中完成。
测试套件的价值，不应由写了多少行 Playwright 决定，而取决于它能否以接近交付速度的节奏给出反馈。如果你的测试仍是录一遍点击路径、下次重构后看它失效、再反复修选择器，这篇文章提供了一份可逐步采用的升级清单。
变化的原因并不是 QA 发明了新的理论，而是软件交付链路的其他环节变了。Claude Code、Cursor、OpenAI Codex 等 AI 编码代理缩短了实现功能的时间，测试反馈若仍停留在独立且滞后的周期，就更容易与交付节奏脱节。
在高频交付的团队中，Pull Request 数量增加，UI 改动也更持续。2020 年代常见的做法是编写 Playwright，在合并时运行，并在选择器漂移后修复。面对新的交付吞吐量，这套做法的维护压力会持续上升。
本文给出一套面向 2026 年的替代思路：五项能够落地的测试基础、每一项的具体含义，以及示例产品 Shiplight 中对应的能力，帮助你在阅读后的一周内开始试用。如果你想先了解更大的类别框架，而不只是这些基础原则，可以先看 AI 测试是什么。
基于意图编写测试。测试描述用户要做什么，而不是要点击哪个选择器。对应能力：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 元素。
对比下面的写法：
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 改动的团队，它更适合作为测试体系的基础能力；否则，需要人工维护选择器的测试套件会持续成为瓶颈。
实际落地时，默认自愈至少要覆盖下面几种情况：
最后一点尤其重要。许多所谓自愈工具会静默修改测试，这会破坏可审计性。将修复作为 PR 中可审核的补丁，才能同时保留审计线索。关于这个边界，可以继续阅读如何修复不稳定的 E2E 测试，以及自愈和人工维护的对比。
Shiplight 示例能力。若选择 Shiplight，文中对应的能力是 AI Fixer：它根据当前 DOM 解析意图；无法高置信地解析某一步时，生成可审核的差异补丁。这样既保留 git 中的审计记录，也减少人工维护选择器的工作。实际效果应以团队自身的失败率、修复率和人工审核成本验证。
这是 2020 年没有出现过的基础，因为当时还没有能够自主编写生产代码的 AI 编码代理。如今，代理原生的自动化 QA 才能把验证闭环放回 AI 编码团队的实际工作方式中，而不是把受选择器约束的旧测试套件硬套到新的交付节奏上。
它解决的失败模式很直接：编码代理生成了一个功能，既有测试套件全部通过，因为代理没有触及测试；PR 合并后，三天后才有用户反馈新流程不可用。代理从未在真实浏览器中验证自己刚刚交付的结果，它只运行了已经存在的测试。
本文建议的基础做法是：编码代理在提交 PR 前，于生成代码的同一会话中调用测试工具。
代理为刚刚实现的功能生成一条基于意图的测试，在真实浏览器中运行，看到实际渲染结果后，才标记 PR 可以进入评审。关于这一模式，可以参考面向 AI 编码代理的测试层。
要做到这一点，测试工具至少需要两项能力：
简而言之：测试工具如果不把自己暴露给代理，代理交付的代码可能从未被它验证过。
2020 年的常见做法是夜间运行完整测试套件，在合并时运行较小的冒烟检查。本文建议把受影响流程的真实浏览器测试前置到 Pull Request 评审前，并在失败时阻止合并。
当 AI 生成的代码占据更多 PR 时，明天再发现构建已坏的反馈时延，与快速完成一次改动的交付时延严重不匹配。质量门禁也应以接近交付速度的节奏工作。
一个实用的 2026 年 CI 门禁至少检查以下问题：
一套面向 AI PR 的质量门禁，会把这些问题落实为可判定的合并条件。输出不该只是堆栈跟踪，而应是评审者能够信任的合并或不合并信号。
Shiplight 示例能力。若选择 Shiplight，文中对应的能力是 Cloud runners 与 CI 集成，可对接 GitHub Actions、GitLab CI 和 CircleCI。它应提供回放视频、DOM 快照以及按步骤呈现的失败差异，而不是只输出堆栈跟踪文本；具体接入能力应以实际产品文档和试运行结果为准。
有一项常被忽略的基础，通常只有在团队想迁移平台时才会意识到它的重要性：测试定义究竟存在哪里。2020 年 SaaS 测试工具盛行时，测试常被放在供应商界面、拖拽式构建器、专有脚本格式和其云端截图中。离开供应商，往往意味着从头重写。
本文建议的基础做法是：测试以纯文本存在于代码仓库，在 PR 中评审，并由同一批交付功能的工程师负责。这样可以带来几项直接收益：
这也是选择 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 测试新时代