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的核心任务是理解和规划。它不是一个简单的爬虫，而是一个具备应用理解能力的探索引擎。

工作原理：

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

关键设计考量：

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

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

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

工作原理：

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