用 Claude Code 搭建端到端测试套件，把 Bug 挡在用户之前

编码智能体写代码很快，但它也会犯错：漏掉某条信息，或者写出绕来绕去、带出意外副作用的实现。这类问题靠单元测试不一定抓得住，因为单元测试验证的是你写的那段代码，而不是用户真正看到的产品。端到端测试正好补上这一层——它不关心你跑了什么代码、构建了什么产物，只把应用本身跑起来，像用户一样点进去、看结果。用 Claude Code 这类编码智能体来搭建和维护端到端测试，可以把「用户先发现 Bug」变成「你在发布前发现 Bug」。这篇教程讲的就是这套做法：给智能体浏览器权限，用提示词描述用户旅程，再把测试挂到 CI/CD 和定时任务上。

准备工作

开始之前，先把下面几件事确认清楚。端到端测试跑的是真实应用，任何一项缺失都会让测试结果失真。

1. 一个可访问的运行环境

测试要打开的是真实页面，所以你需要一个智能体能访问到的应用地址：本地开发服务器、预发布环境或生产环境都可以，但要明确每个测试针对哪一个。如果测试要跑在 CI/CD 里，环境必须能从流水线所在机器访问到。

2. 给智能体浏览器访问能力

Claude Code 本身是命令行里的编码智能体，它需要额外的浏览器工具才能真正「点」页面。素材中采用的做法是接入 Playwright MCP，让智能体通过它操作浏览器：打开页面、识别元素、点击按钮、读取下一页内容。配置好之后，智能体就能自己完成「看到界面 → 决定点哪里 → 观察结果」这一整条链路。

这一步是整套方案的地基。没有浏览器访问能力，智能体只能读代码、猜行为，那就退化成了普通的静态检查，抓不到真实交互中的问题。

3. 明确要测试的用户角色

端到端测试的价值很大一部分来自「用不同身份走同一条路」。在动手写提示词之前，先列出你的应用里有哪些角色，例如普通用户与管理员。每个角色能看到什么、能做什么，要提前写清楚，因为这会直接变成测试的断言条件。

4. 决定测试在哪里运行

端到端测试通常有两种运行方式，建议两种都准备：

• 合并前运行：作为 CI/CD 流水线的一环，在代码合入开发分支或生产分支之前跑一遍。
• 周期性运行：在开发或生产环境上按固定间隔（例如每小时）重复跑，用来捕捉代码之外的变化，比如环境变量被改动。

如果这两种运行方式此前都没搭过，第一次需要先建好承载它们的「外壳」。这个外壳要放在一台稳定、不容易挂掉的机器上，可选方案包括云端单独的一台机器、GitHub Actions 的 runner，或者手边一台常开的 Mac mini 之类。具体用哪种，可以让 Claude Code 根据你的技术栈来判断，比如用系统自带的任务调度、平台提供的 Cron 任务，或者其他方式。

5. 账号与凭据

测试需要以不同角色登录，所以要准备好各角色的测试账号，并确认凭据能安全地注入到运行环境里（本地环境变量、CI 的密钥管理都行）。这部分的具体配置方式取决于你的平台，价格、配额与可用功能请以官网当前信息为准。

操作步骤

第一步：理解端到端测试与旧做法的差别

传统端到端测试需要人工逐页走查：进入每个页面，找到要点击的按钮的 ID，把它写进测试脚本，再记录下点击后应该出现什么结果。搭建成本高，维护成本更高——页面改版、逻辑调整，测试脚本就得跟着改，这份维护负担会一直背到测试废弃为止。

智能体驱动的端到端测试换了一种形态：一个测试本质上就是「一个有浏览器权限的智能体 + 一份它该做什么的计划」。你告诉它「走到 A 页面，执行 B 操作，应该出现 C 结果」，它自己去页面上找路。只要按钮还在页面上，页面设计怎么改都不需要你更新测试。它也更通用，能发现过去那种范围狭窄的脚本发现不了的问题；而且新增一个测试的成本很低，测试覆盖面可以铺得比以前大得多。

第二步：给智能体接入浏览器工具

在 Claude Code 中配置 Playwright MCP，让智能体获得操作浏览器的能力。配置完成后，先做一次最小验证：让智能体打开你的应用首页，描述它看到了什么。如果它能准确说出页面上的标题、按钮和导航项，说明浏览器通道已经打通，可以进入下一步。

这一步不要跳过验证。很多后续「测试写好了但跑不出结果」的问题，根源都在浏览器工具没接好，智能体其实是在凭空想象页面内容。

第三步：用提示词描述一条用户旅程

测试的内容来自你对业务的描述，而不是来自代码。写提示词时，把角色、可见内容、预期结果讲清楚。下面是一条可以直接改用的示例，测试对象是一个团队概览页：

我想为团队概览页搭建一个端到端测试。
需要分别以管理员用户和普通用户的身份测试这个页面。

如果以普通用户身份登录，应该只能看到自己，
以及针对个人的各项统计，例如在平台上使用的小时数、
执行的点击次数等。

如果以管理员身份登录，应该能看到团队里的所有人（包括自己），
并且这些相同的统计项要以表格形式列出。

注意这条提示词里没有出现任何元素 ID、选择器或页面结构。它描述的是「谁、看到什么、以什么形式看到」，这正是智能体能够自行落地的东西。角色差异越具体，测试能抓到的权限类 Bug 就越多。

第四步：告诉智能体测试挂在哪里运行

智能体实现测试时，需要知道这个测试应该接进哪条运行链路。如果你已经有现成的 CI/CD 测试外壳和周期性任务，直接在提示词里说明即可，例如「把它接入合并前的流水线」或「把它加进生产环境每 X 小时运行的那批任务」。智能体知道这些位置在哪里，会按既有约定接入。

如果这是第一次搭建，就明确告诉它「目前还没有运行外壳，请一并设计」。这时它会给出承载方案，你需要确认那台机器足够稳定——端到端测试跑在不稳的机器上，失败原因会混进环境噪声，很难判断到底是应用坏了还是机器坏了。

第五步：运行并阅读结果

测试跑起来之后，智能体会报告它观察到的现象。值得关注的失败类型主要有三种：

• 点击某个按钮后出现错误；
• 点击某个按钮后什么也没发生；
• 预期动作没有按描述发生，例如普通用户看到了本不该看到的团队数据。

这三种都对应真实用户会遇到的糟糕体验。拿到报告后，让 Claude Code 直接定位并修复，再重跑同一个测试确认问题消失。

第六步：按角色扩充测试套件

一条旅程跑通之后，按同样的模式铺开：每个重要页面、每条关键流程、每种用户角色各配一个测试。因为新增测试只是再写一段提示词，成本很低，所以不必像过去那样精挑细选只测最核心的几条。角色越多、路径越全，越能在发布前拦住问题。

一个完整示例

下面把前面的步骤串成一个从头到尾能跑通的最小流程。假设你的应用有一个团队概览页，存在普通用户与管理员两种角色。

第 1 步：确认环境。启动应用，记下智能体可访问的地址，准备好两种角色的测试账号。

第 2 步：接入浏览器。在 Claude Code 中配置 Playwright MCP，然后让智能体打开首页并描述所见内容，确认通道可用。

第 3 步：提出测试需求。把第三步那段提示词发给智能体，明确要求为普通用户和管理员各建一个测试智能体。

第 4 步：指定运行方式。追加一句说明，例如「这个测试要接入合并前的 CI/CD 流水线，同时加入生产环境每小时的定时任务」。如果外壳尚未存在，让它一并搭建，并确认承载机器的稳定性。

第 5 步：让智能体实现。它会创建测试定义、角色登录逻辑、断言条件，以及接入流水线与定时任务的配置。实现完成后先手动触发一次。

第 6 步：核对两种角色的结果。普通用户视角下，页面应只显示本人及其个人统计（平台使用小时数、点击次数等）；管理员视角下，应显示团队全体成员及同样的统计项，并以表格形式呈现。任何一条不符，都让智能体修复后重跑。

第 7 步：固化。确认测试在流水线中能作为合并前检查运行，并在生产环境按设定间隔重复执行。之后每次改动页面或逻辑，只要按钮还在原位置，测试无需更新。

注意事项

• 智能体会犯错，测试本身也可能写错。端到端测试的意义是让错误在用户之前暴露，而不是假设智能体一次写对。测试首次跑通后，仍要人工核对断言是否符合业务预期。
• 承载测试的机器必须稳定。周期性任务跑在不稳的环境上，会产生大量假失败，掩盖真正的应用问题。
• 周期性运行不只防代码回归。生产环境按固定间隔跑测试，能捕捉纯代码变更之外引起的问题，例如环境变量被改动。
• 页面改版不等于测试失效。只要目标按钮仍在页面上，设计调整通常不需要更新测试；但如果流程本身被删除或改名，测试计划就要同步修改。
• 不同角色要用不同智能体。把普通用户和管理员混在一个测试里，权限类问题很容易被掩盖。
• 成本与配额。端到端测试相对便宜，但按小时持续运行仍会消耗资源，具体额度、价格与可用功能请以官网当前信息为准。