当前位置：首页 > news >正文

Playwright三大Agent实战：从测试生成到自愈的自动化测试新范式

news 2026/7/3 17:23:01

1. 项目概述：从“写测试”到“管测试”的范式转移

如果你和我一样，在软件测试领域摸爬滚打了几年，一定对“测试代码维护”这件事又爱又恨。爱的是，一套健壮的自动化测试是产品质量的“金钟罩”；恨的是，随着产品迭代，测试用例的编写、调试、修复，尤其是应对UI变更导致的定位器（Locator）失效，简直是个无底洞，消耗着团队大量的时间和耐心。我们常常自嘲，不是在写业务代码，而是在“伺候”测试代码。

最近，Playwright团队放出的“三大Agent”组合拳，让我看到了彻底改变这一现状的曙光。这不仅仅是又一个自动化工具，而是一套完整的、面向未来的“测试自治”系统。它把测试工程师从重复、琐碎的“码农”工作中解放出来，让我们能更专注于测试策略设计、质量分析和风险把控。简单来说，Planner（规划者）、Generator（生成者）、Healer（治愈者）这三个Agent，分别对应了测试生命周期的“谋”、“产”、“养”三个核心环节，联手实现从需求到可执行、可自愈的测试用例的全自动流水线。

这背后的核心思想是“Agentic Loop”（智能体循环）。不再是手动编写每一行page.click()或expect()，而是通过自然语言或结构化文档驱动智能体协作。你提供一个种子测试（Seed Test）来设定初始环境，然后告诉Planner你的测试意图，它就会像一位经验丰富的测试分析师一样，去探索你的应用，并产出一份详尽的Markdown测试计划。接着，Generator这位“代码工匠”会将这份人类可读的计划，精准地翻译成可执行的Playwright测试脚本。最后，当应用迭代导致测试失败时，Healer会主动介入，诊断问题并尝试自动修复定位器或等待逻辑，让测试套件保持“健康”。

对于测试负责人而言，这意味着更快的测试覆盖速度、更低的维护成本和更高的测试可靠性。对于开发者而言，这意味着能更早、更频繁地获得质量反馈。接下来，我将结合实战，带你深入这套系统的每一个环节，看看如何将它落地到你的项目中，真正实现“测试全自动”。

2. 三大Agent核心原理与协作机制拆解

在深入实操之前，我们必须先理解这三大Agent各自的分工和它们如何像一支训练有素的团队一样协同工作。这决定了我们后续如何有效地使用和配置它们。

2.1 Planner：应用探索与测试策略的“大脑”

Planner Agent的核心任务是理解和规划。它不是一个简单的爬虫，而是一个具备应用理解能力的探索引擎。

工作原理：

环境初始化：它首先会运行你提供的seed.spec.ts文件。这个种子测试至关重要，它定义了测试的起点，例如如何登录系统、跳转到哪个起始页面、使用哪些测试夹具（Fixtures）。Planner通过执行它来获取一个有效的、已认证的page对象上下文。
探索与学习：在种子测试提供的页面上，Planner会开始探索。它模拟用户交互，如点击可见的按钮、链接，填写表单，并观察应用的响应。在此过程中，它会学习应用的UI结构、可交互元素以及业务流程。
计划生成：基于你的自然语言指令（如“为购物车结算流程生成测试计划”）和探索所得，Planner会结构化地输出一份Markdown文档。这份文档详细描述了测试场景、步骤、预期结果，甚至包括测试数据建议。

关键设计考量：

种子测试的质量决定上层建筑：如果种子测试本身不稳定或无法正确初始化环境，Planner的探索将失败或产生错误的计划。因此，种子测试应尽可能简单、稳定，只做最必要的初始化。
Prompt工程的价值：给Planner的指令越清晰，产出的计划越精准。例如，“测试用户从商品详情页加入购物车并完成支付”比“测试购物车”要好得多。你还可以附上产品需求文档（PRD）作为上下文，帮助它更好地理解业务逻辑。

2.2 Generator：从蓝图到代码的“工匠”

Generator Agent是一个代码生成器，但它不是基于模板的简单替换，而是具备实时验证能力的代码生成器。

工作原理：

解析计划：读取Planner生成的Markdown规格说明（spec）。
实时验证与代码生成：这是最精妙的部分。Generator不会凭空生成代码。它会一边解析计划中的步骤，一边在真实的浏览器环境中尝试执行对应的操作。例如，当计划中说“点击登录按钮”，Generator会：
- 在当前页面上下文中，使用Playwright的智能定位器（如getByRole(‘button’, { name: ‘登录’ })）去寻找这个元素。
- 如果找到，它就将这个已验证有效的定位器写入生成的测试代码中。
- 同时，它也会根据计划中的“预期结果”，生成相应的断言（Assertions），并使用Playwright提供的断言目录（Catalog of Assertions）来选择最合适的断言方法，如toBeVisible，toHaveText等。
输出可执行测试文件：最终生成.spec.ts文件，其中的每一步操作和断言都是经过“现场验证”的，极大提高了生成代码的首次运行成功率。

关键设计考量：

生成即验证：这避免了传统录制工具或代码生成器常产生的“脆弱定位器”（如基于易变的CSS路径）问题。因为定位器是在生成时动态解析和确认的。
支持生成提示：你可以在计划中或通过Prompt给Generator一些“提示”，例如优先使用># 1. 创建一个新目录并进入 mkdir playwright-agent-demo && cd playwright-agent-demo # 2. 初始化npm项目（如果还没有package.json） npm init -y # 3. 安装Playwright及相关测试依赖 npm init playwright@latest
运行npm init playwright@latest时，命令行会交互式地询问配置。为了后续Agent工作顺畅，建议选择：
- TypeScript：提供更好的类型支持和IDE体验。
- 测试目录：默认的tests即可。
- 添加GitHub Actions工作流：可选，但对于CI/CD有帮助。
- 安装浏览器：选择“Yes”，安装Chromium, Firefox, WebKit。
安装完成后，项目结构大致如下：
```
playwright-agent-demo/ ├── node_modules/ ├── tests/ │ ├── example.spec.ts │ └── test-helper.ts ├── playwright.config.ts ├── package.json ├── package-lock.json └── .gitignore
```
3.2 初始化三大Agent定义
这是启用Agent功能的关键一步。Playwright将Agent定义为一系列指令和MCP（Model Context Protocol）工具的集合。我们需要将其初始化到项目中。
根据你使用的AI辅助编程工具，选择对应的初始化命令：
```
# 如果你主要使用 VS Code npx playwright init-agents --loop=vscode # 如果你使用 Claude Code npx playwright init-agents --loop=claude # 如果你使用 Cursor 或 Codex npx playwright init-agents --loop=codex # 对于其他兼容MCP的工具（如OpenCode） npx playwright init-agents --loop=opencode
```
重要提示：执行此命令前，请确保你使用的VS Code版本至少为1.105（2025年10月9日发布），这是Agentic体验正常工作的最低要求。旧版本可能缺少必要的API支持。
执行命令后，你会发现项目根目录下多了一个.github/文件夹（即使你不使用GitHub），里面包含了Agent的定义文件。这个文件夹的结构和内容是由Playwright官方维护的，定义了Planner, Generator, Healer各自的能力、指令和可用工具。
初始化后的项目结构演进：
```
playwright-agent-demo/ ├── .github/ # <-- 新增！Agent定义存放处 │ └── agents/ │ ├── planner/ │ ├── generator/ │ └── healer/ ├── tests/ ├── specs/ # <-- 即将由Planner生成测试计划的目录 ├── playwright.config.ts └── package.json
```
同时，playwright.config.ts中可能会被添加一些与Agent相关的配置项。
实操心得：init-agents命令应该在你每次升级Playwright版本后重新运行一次。因为Playwright团队可能会更新Agent的工具集或指令，重新初始化可以确保你获得最新的能力。这类似于更新你的“测试AI助手”的技能库。
3.3 创建种子测试（Seed Test）
种子测试是Planner探索的起点。它不是一个真正的测试用例，而是一个环境准备脚本。它的目的是将一个可交互的页面对象page置于某个确定的初始状态。
在tests/目录下，我们创建seed.spec.ts：
```
// tests/seed.spec.ts import { test, expect } from '@playwright/test'; // 使用 test.describe 不是必须的，但有助于组织 test.describe('Seed for TodoMVC', () => { // 这个测试不会被用于实际验证功能，只为Planner提供初始页面 test('navigate to TodoMVC app', async ({ page }) => { // 1. 导航到待测应用。这里使用在线TodoMVC示例，实际项目替换为你应用的URL。 await page.goto('https://demo.playwright.dev/todomvc'); // 2. 可选：进行一些通用的初始化断言，确保页面加载正确。 // 这有助于Planner理解页面的核心结构。 await expect(page.getByPlaceholder('What needs to be done?')).toBeVisible(); await expect(page.locator('body')).toContainText('todos'); // 3. 此时，页面处于一个干净的状态：一个空的待办列表。 // Planner将从这个状态开始探索。 // 注意：这里不添加任何具体的待办项，让Planner自己去发现添加功能。 }); });
```
为什么种子测试如此重要？
- 上下文提供者：它为所有后续由Agent生成的测试提供了统一的起点和页面对象。
- 认证与状态管理：对于需要登录的应用，种子测试应包含登录逻辑，确保page处于已登录的会话状态。
- 示例作用：Planner会参考种子测试的编写风格（如导入方式、fixture使用）来生成后续测试，保持代码风格一致。
4. 驱动Planner生成测试计划
现在，我们有了Agent定义和种子测试，可以开始与Planner对话了。这个过程需要在你选择的AI编程工具（如VS Code with Cursor, Claude Code）中完成，因为这些工具集成了MCP客户端，能够调用我们初始化的Agent。
4.1 与Planner交互
在你的AI工具中，你应该能找到一个与“Agent”或“Playwright”相关的面板或聊天入口。以下是一个典型的交互流程：
你的指令（Prompt）：
```
请为TodoMVC应用创建一个测试计划，覆盖其核心功能：添加新待办事项、标记待办为完成、过滤查看（所有/进行中/已完成）、以及删除待办事项。请基于种子测试 `tests/seed.spec.ts` 进行探索。
```
Planner的工作流程：
1. 读取指令：理解你需要测试“核心功能”。
2. 运行种子测试：它会先执行tests/seed.spec.ts，打开TodoMVC页面并到达初始状态。
3. 探索应用：Planner开始与页面交互。它会：
  - 尝试在输入框输入文字并按下回车，从而“发现”添加功能。
  - 点击新添加的待办项左边的复选框，发现“标记完成”功能。
  - 查看页面底部的“All”, “Active”, “Completed”链接，发现“过滤”功能。
  - 将鼠标悬停在待办项上，发现出现的“删除”按钮。
4. 生成Markdown计划：探索完成后，Planner会在项目的specs/目录下生成一个Markdown文件，例如specs/todomvc-core-features.md。
4.2 解读生成的测试计划
打开specs/todomvc-core-features.md，你会看到一份结构清晰、内容详尽的文档：
```
# TodoMVC应用 - 核心功能测试计划 ## 应用概述 TodoMVC是一个用于管理任务列表的经典示例应用。主要界面包含一个输入框、待办列表、以及底部的状态栏和过滤器。 ## 测试场景 ### 1. 添加新待办事项 **种子:** `tests/seed.spec.ts` #### 1.1 添加单个有效待办 **步骤:** 1. 在“What needs to be done?”输入框中点击。 2. 输入文本“Buy milk”。 3. 按下Enter键。 **预期结果:** - 列表中出现一个带有未选中复选框的新待办项，文本为“Buy milk”。 - 底部计数器显示“1 item left”。 - 输入框被清空。 - “Mark all as complete”复选框和底部过滤器区域变为可见。 #### 1.2 添加多个待办事项 **步骤:** 1. 依次添加“Task 1”, “Task 2”, “Task 3”。 **预期结果:** - 列表按顺序显示三个待办项。 - 计数器更新为“3 items left”。 ### 2. 标记待办事项为完成/未完成 #### 2.1 标记单个待办为完成 **前置条件:** 列表中至少有一个未完成的待办项。 **步骤:** 1. 点击该待办项左侧的复选框。 **预期结果:** - 该待办项的文本样式变为删除线。 - 底部计数器数字减少。 - 如果所有项都完成，“Mark all as complete”复选框应被选中。 #### 2.2 通过“Mark all as complete”进行批量操作 ... (后续计划内容)
```
这份计划的价值在于：
- 人类可读：产品经理、QA、开发者都能看懂，便于评审和确认。
- 机器可执行：步骤描述精确到UI元素和操作，为Generator提供了明确的指令。
- 结构化：分场景、分用例，逻辑清晰。
注意事项：第一次运行Planner时，由于它需要探索整个应用，可能会花费几十秒到几分钟，具体取决于应用复杂度和网络速度。请耐心等待。如果超时，可以检查种子测试是否运行成功，或者尝试缩小Planner的探索范围（例如，在Prompt中指定“只探索首页”）。
5. 使用Generator将计划转化为测试代码
有了高质量的测试计划，下一步就是让Generator将其转化为可执行的TypeScript代码。这个过程同样是半自动的，通过AI工具来驱动。
5.1 触发代码生成
在AI工具中，切换或召唤Generator Agent，并将生成的Markdown计划文件提供给它。
你的指令（Prompt）：
```
请根据测试计划文件 `specs/todomvc-core-features.md` 生成Playwright测试代码。请将生成的测试文件放在 `tests/` 目录下，并保持与计划中场景和用例对应的结构。使用与种子测试相同的导入和断言风格。
```
Generator的工作流程：
1. 解析Markdown：读取并理解计划中的每一个场景和步骤。
2. 实时验证与编码：对于计划中的每一步，如“在‘What needs to be done?’输入框中点击”，Generator会：
  - 在当前浏览器上下文（由种子测试建立）中，尝试定位这个输入框。它可能会使用getByPlaceholder(‘What needs to be done?’)。
  - 如果定位成功，它就将这行代码await page.getByPlaceholder(‘What needs to be done?’).click();写入生成的.spec.ts文件。
  - 对于预期结果，如“列表中出现一个新待办项”，它会生成相应的断言代码await expect(page.getByText(‘Buy milk’)).toBeVisible();。
3. 生成测试文件：最终，它会在tests/目录下创建类似于tests/todomvc-core-features/的子文件夹，并在其中生成多个.spec.ts文件，每个文件对应一个主要的测试场景。
5.2 分析生成的测试代码
让我们查看一个生成的文件示例：tests/todomvc-core-features/add-todo.spec.ts
```
// spec: specs/todomvc-core-features.md // seed: tests/seed.spec.ts import { test, expect } from '@playwright/test'; test.describe('Adding New Todos', () => { test('should add a single valid todo item', async ({ page }) => { // 1. Navigate to the app (already done by seed fixture or beforeEach) await page.goto('https://demo.playwright.dev/todomvc'); // 2. Click in the "What needs to be done?" input field const todoInput = page.getByPlaceholder('What needs to be done?'); await todoInput.click(); // 3. Type "Buy milk" await todoInput.fill('Buy milk'); // 4. Press Enter key await todoInput.press('Enter'); // Expected Results: // - New todo appears in the list await expect(page.getByText('Buy milk')).toBeVisible(); const todoItem = page.locator('li').filter({ hasText: 'Buy milk' }); await expect(todoItem).toBeVisible(); // - Checkbox is unchecked const todoCheckbox = todoItem.getByRole('checkbox'); await expect(todoCheckbox).toBeVisible(); await expect(todoCheckbox).not.toBeChecked(); // - Counter shows "1 item left" await expect(page.getByText('1 item left')).toBeVisible(); // - Input is cleared await expect(todoInput).toHaveValue(''); // - Footer controls become visible await expect(page.getByRole('checkbox', { name: 'Mark all as complete' })).toBeVisible(); await expect(page.getByRole('listitem').filter({ hasText: 'All' })).toBeVisible(); }); test('should add multiple todo items sequentially', async ({ page }) => { await page.goto('https://demo.playwright.dev/todomvc'); const todoInput = page.getByPlaceholder('What needs to be done?'); const tasks = ['Task 1', 'Task 2', 'Task 3']; for (const task of tasks) { await todoInput.fill(task); await todoInput.press('Enter'); await expect(page.getByText(task)).toBeVisible(); } await expect(page.getByText('3 items left')).toBeVisible(); }); });
```
生成的代码特点分析：
- 结构清晰：使用了test.describe和test进行分层，与Markdown计划的结构对应。
- 定位器稳健：优先使用了语义化的定位器，如getByPlaceholder、getByRole、getByText，这些比基于CSS路径的定位器（如page.locator(‘.new-todo’)）更不易受样式变更影响。
- 断言完备：对每一步操作的预期结果都生成了对应的expect断言，构成了一个完整的测试用例。
- 包含必要的导航：虽然种子测试可能已经导航到页面，但Generator为了测试的独立性，通常在每个测试开头也添加了page.goto。这可能会造成冗余，我们后续可以优化。
实操心得：首次生成的代码可能不是完美的。你可能会看到一些冗余的步骤（比如每个测试都重复导航），或者定位器策略不是最优。这完全正常。Generator的目标是生成“正确且可运行”的代码，而不是“最优”的代码。我们可以将其作为高质量的初稿，然后进行人工优化和重构，例如将公共的导航步骤提取到beforeEach钩子中。
6. Healer实战：让测试具备自愈能力
前面的步骤实现了测试的“从无到有”。而Healer解决的是测试在生命周期中“从坏到好”的问题。当应用UI发生变化时，它是你的第一道自动防线。
6.1 模拟一个测试失败场景
假设我们的TodoMVC应用在前端重构中，开发者将输入框的placeholder文本从“What needs to be done?”改为了“Add a new todo…”。这会导致所有使用getByPlaceholder(‘What needs to be done?’)定位器的测试失败。
我们手动运行一下之前生成的测试：
```
npx playwright test tests/todomvc-core-features/add-todo.spec.ts
```
你会看到测试失败，错误信息大致是TimeoutError: locator.getByPlaceholder(‘What needs to be done?’): Timeout waiting for locator。
6.2 触发Healer进行自动修复
在支持Healer的AI工具中，你可以将失败的测试报告或直接告知Healer哪个测试文件失败了。
你的指令（Prompt）：
```
测试文件 `tests/todomvc-core-features/add-todo.spec.ts` 中的测试用例执行失败，错误是定位器超时。请分析原因并进行修复。
```
Healer的工作流程：
1. 诊断：Healer会重新运行失败的测试，并在失败点（定位输入框）捕获当前的页面快照和DOM结构。
2. 分析：它发现旧的placeholder属性值找不到对应的元素。于是，它会在当前页面上扫描所有<input>元素，寻找可能的替代目标。它发现了新的placeholder文本“Add a new todo…”。
3. 修复：Healer会生成一个代码补丁，将定位器从page.getByPlaceholder(‘What needs to be done?’)更新为page.getByPlaceholder(‘Add a new todo…’)。
4. 验证：应用补丁后，Healer会重新运行该测试。如果通过，修复成功。
6.3 修复结果与代码变更
Healer可能会直接修改源文件，也可能会提供一个修复建议。如果是直接修改，add-todo.spec.ts中的相关行会更新：
```
// 修复前 const todoInput = page.getByPlaceholder('What needs to be done?'); // 修复后 const todoInput = page.getByPlaceholder('Add a new todo...');
```
一个更智能的Healer甚至可能建议使用更稳定的定位策略，比如如果输入框有>import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ // 1. 设置更宽松的超时时间，给Agent探索和生成留出余地 timeout: 120000, // 全局测试超时设为2分钟 expect: { timeout: 30000, // 单个断言超时设为30秒 }, // 2. 配置重试策略，与Healer配合 retries: process.env.CI ? 2 : 1, // CI环境中重试2次，本地1次。Healer可能在重试过程中介入修复。 // 3. 配置报告，方便查看Agent生成和修复的测试结果 reporter: [ ['html', { open: 'never' }], // 生成HTML报告 ['list'], // 命令行简洁输出 ['json', { outputFile: 'test-results.json' }] // 输出JSON报告，可供其他工具解析 ], // 4. 项目配置：可以为Agent生成的测试单独配置项目 projects: [ { name: 'agent-generated', testDir: './tests/todomvc-core-features', // 指定Agent生成的测试目录 use: { ...devices['Desktop Chrome'], // 可以在这里为生成的测试设置特定的视口、权限等 viewport: { width: 1280, height: 720 }, }, }, { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, ], // 5. 全局设置与清理 globalSetup: require.resolve('./global-setup'), // 可选：用于登录等全局准备 globalTeardown: require.resolve('./global-teardown'), // 可选：全局清理 });
7.2 将Agent流程集成到CI/CD流水线
自动化测试的价值在CI/CD中才能最大化。我们可以设计一个流水线，定期或按需让Agent更新测试套件。
以下是一个GitHub Actions工作流示例（.github/workflows/playwright-agents.yml）：
```
name: Playwright Agents CI on: schedule: - cron: '0 2 * * 1' # 每周一凌晨2点自动运行一次，更新测试计划 workflow_dispatch: # 支持手动触发 push: branches: [ main, develop ] paths: - 'src/**' # 当源代码变更时触发 - 'package.json' jobs: agent-update: runs-on: ubuntu-latest if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' # 仅定时或手动触发时运行Agent更新 steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - name: Install dependencies run: npm ci - name: Install Playwright Browsers run: npx playwright install --with-deps chromium - name: Initialize Playwright Agents run: npx playwright init-agents --loop=claude # 使用你对应的loop - name: Run Planner to Update Specs run: | # 这里需要一种方式在CI中驱动Planner，目前可能需要一个脚本或使用Playwright的Node API。 # 假设我们有一个脚本 `scripts/run-planner.js` node scripts/run-planner.js --instruction "根据当前main分支代码，更新所有核心功能的测试计划" - name: Run Generator to Update Tests run: | # 同样，需要一个脚本驱动Generator node scripts/run-generator.js --spec-dir ./specs - name: Run Tests with Healer run: npx playwright test --project=agent-generated continue-on-error: true # 允许测试失败，让Healer有机会修复 env: PLAYWRIGHT_ALLOW_HEALER: 'true' # 假设有一个环境变量启用Healer - name: Create Pull Request for Updates uses: peter-evans/create-pull-request@v5 if: failure() # 如果测试失败且被Healer修复，或者有新的spec生成，则创建PR with: commit-message: 'chore(tests): Auto-update test specs and fixes via Playwright Agents' title: '[Automated] Test Suite Update by Playwright Agents' body: | This PR contains updates to test specifications and/or fixes generated by Playwright Test Agents (Planner, Generator, Healer). **Changes include:** - Updated test plans in `/specs` - Updated test code in `/tests` - Automatic fixes for failing locators Please review the changes, especially any modifications to assertion logic. branch: update/playwright-agents-${{ github.run_id }}
```
关键点说明：
- 定时触发：每周自动运行Agent，探索应用是否有新功能，更新测试计划。
- 分离关注点：将“Agent更新测试”和“常规测试执行”分为两个Job或通过条件隔开，避免每次推送都触发耗时的Agent探索。
- Healer集成：在测试步骤中设置continue-on-error: true并启用Healer，允许它在CI环境中尝试修复。
- 安全审查：通过自动创建PR的方式提交Agent的更改，确保所有自动化修改都经过人工审查后才能合入。
7.3 提升Agent效能的实用技巧
1. 编写高质量的种子测试：这是所有Agent工作的基石。确保它稳定、快速，并能到达正确的应用状态。对于复杂应用，可以考虑编写多个种子测试对应不同的模块（如seed-auth.spec.ts,seed-dashboard.spec.ts）。
2. 精细化你的Prompt：给Planner的指令越具体，输出越精准。例如：
  - 不好的Prompt：“测试用户管理页面。”
  - 好的Prompt：“以管理员身份登录后，测试用户管理页面的下列功能：1. 搜索用户。2. 禁用/启用用户。3. 查看用户详情。请基于tests/seed-admin.spec.ts生成计划。”
3. 管理生成的代码：
  - 代码风格：生成代码后，运行项目的代码格式化工具（如Prettier）保持风格统一。
  - 重构与抽象：将Generator生成的代码视为“初稿”。及时将重复的页面对象（Page Objects）或工具函数提取出来，提高可维护性。例如，将todoInput的定位器提取到一个TodoPage类中。
4. 为Healer设置边界：
  - 在playwright.config.ts中，可以通过projects配置为Healer启用或禁用某些测试。
  - 考虑使用test.info().annotations为测试添加标签，如@no-heal，然后在配置中让Healer跳过这些测试。
5. 版本控制策略：
  - 将specs/目录纳入版本控制。这些Markdown计划是宝贵的测试资产，记录了测试意图。
  - 定期审查specs/和tests/的变更，确保自动化演进符合业务逻辑。
8. 常见问题排查与效能优化实录
在实际使用中，你可能会遇到一些典型问题。以下是我在实践中总结的一些排查思路和优化技巧。
8.1 Planner探索失败或超时
问题现象：Planner长时间无响应，或最终报错“无法探索应用”。
排查步骤：
1. 检查种子测试：首先手动运行seed.spec.ts，确保它能独立成功执行，并且页面能加载到预期状态。
2. 检查网络与资源：如果种子测试需要访问外部URL或依赖内部服务，确保网络通畅，服务可用。Planner在探索时可能会触发页面上的异步加载，如果资源加载失败，可能导致探索卡住。
3. 简化探索范围：初始尝试时，在Prompt中限制探索范围。例如，“只探索首页顶部的导航栏”，成功后再逐步扩大范围。
4. 增加超时时间：在playwright.config.ts中为测试设置更长的timeout和expect.timeout，给Planner充足的探索时间。
5. 查看日志：运行Planner时，查看AI工具或Playwright的输出日志，是否有具体的错误信息。
8.2 Generator生成的定位器不稳定
问题现象：生成的测试首次运行通过，但稍后（如页面样式微调后）就失败了。
原因与解决：
- 原因：Generator在生成时，可能选择了基于文本或相对位置的定位器，这些容易变化。
- 解决：
  - 优化生成提示：在给Generator的Prompt中明确要求：“请优先使用>


查看全文


http://www.jsqmd.com/news/1116667/



相关文章：

算力中心用电告急？氢能应急电源正成为“新刚需”


IDEA：SVN路径报错解决


我已严肃深扒Claude Code的源码，证明那段针对国内用户的代码是真的。


显存碎片化治理，调整 block size 提升推理稳定性


AI时代大模型入门指南：小白程序员抓住新机遇，未来职场生存必备技能


华为运动数据格式转换终极指南：3分钟解锁多平台数据自由


前端Monorepo依赖管理优化：pnpm硬链接与按需安装实战


2026年企业级大模型API中转服务商深度横向评测：企业级架构选型的技术逻辑与实证分析


13DOF传感器与PIC18F57K42微控制器的高精度定位实现


资源编号319：高德地图 9.5.0.600006 迷你世界像素风定制主题


高斯溅射渲染库gsplat：从零开始的完整配置指南


7自由度开源机械臂：从零到一的完整搭建指南


AI教材编写新利器！低查重AI写教材工具，快速生成专业教材框架


微信小程序开发平台哪家好？从认证、审核、支付和后台运营判断


告别Steam客户端限制：Wallpaper Engine创意工坊壁纸下载终极指南


3步掌握MDUT数据库利用工具：从入门到高效实战


2026年7月上海办公室装修服务公司怎么选？办公、厂房、车间、门面装修靠谱工程服务商解析


口碑好的openclaw推荐


终极指南：用ThreeFingerDragOnWindows重新定义Windows触控板交互哲学


Triton 编译器在 ROCm 的应用，连接框架与硬件的桥梁


Tiny-Twin数字孪生平台架构与5G资源调度优化


Appium会话启动失败：系统性排查与解决方案全解析


Anthropic 大面积封号，连大 V 都忍不了开喷了。


从卖点讲解到带货短视频：必火AI数字人电商内容路径观察


安卓设备自动开机终极指南：告别手动按电源键的烦恼


为什么企微OA数据同步进入数仓总是产生断层？


本地 API 服务搭建，用 Ollama 快速发布大模型接口


机加车间排产困局：为什么计划永远赶不上变化？


蜜蜂蚂蚁智能分类系统项目实践


VisualCppRedist AIO：告别Windows软件兼容性问题的终极修复方案

1. 项目概述：从“写测试”到“管测试”的范式转移

2. 三大Agent核心原理与协作机制拆解

2.1 Planner：应用探索与测试策略的“大脑”

2.2 Generator：从蓝图到代码的“工匠”

3.2 初始化三大Agent定义

3.3 创建种子测试（Seed Test）

4. 驱动Planner生成测试计划

4.1 与Planner交互

4.2 解读生成的测试计划

5. 使用Generator将计划转化为测试代码

5.1 触发代码生成

5.2 分析生成的测试代码

6. Healer实战：让测试具备自愈能力

6.1 模拟一个测试失败场景

6.2 触发Healer进行自动修复

6.3 修复结果与代码变更

7.2 将Agent流程集成到CI/CD流水线

7.3 提升Agent效能的实用技巧

8. 常见问题排查与效能优化实录

8.1 Planner探索失败或超时

8.2 Generator生成的定位器不稳定

相关文章：