使用说明
剧作家MCP测试代理–实用指南
此存储库演示了如何使用 剧作家测试代理 随着 MCP（模型上下文协议） 简化测试工作流程，减少重复性工作。
我们的目标不是取代测试人员，而是让人工智能处理繁琐的探索、测试计划起草、骨架生成和修复明显的问题，而人类则专注于真正需要判断的事情：决定测试什么、自动化什么以及什么是重要的。
这是实验性的
测试代理通过提示工作，并且不是确定性的。质量取决于及时的清晰度、范围定义和提供的上下文。代理人会提供帮助，但不能保证完美。
期待一个提示来提供完美的自动化将导致失望。
什么是剧作家测试代理？
剧作家测试代理结合了：
- 大型语言模型（LLM）
- Playwright的浏览器自动化
- 用于受控执行的MCP工具
交互是通过聊天界面中的对话提示进行的。
代理模式
| 模式 | 目的 |
|---|---|
| 规划师 | 在Markdown中探索应用程序并生成测试计划 |
| 发电机 | 将测试场景转换为Playwright测试 |
| 治愈者 | 调查并修复失败的测试 |
| 通用 | 处理运行测试和执行命令 |
了解更多： 剧作家测试代理文档
先决条件
- Node.js（LTS版本）
- 剧作家
- VS代码内部人员（建议用于MCP支持，常规VS代码也适用）
- 通过MCP（GPT-4、Claude等）获得法学硕士学位
安装和设置
# Install dependencies
npm install
npx playwright install
# Initialize Playwright Agents
npx playwright init-agents --loop=vscode
什么 init-agents 做：
- 安装剧作家测试代理
- 配置MCP与VS代码的集成
- 设置具有代理模式的聊天界面
在VS Code Insiders中打开项目以访问聊天界面。
关键：范围问题
什么行不通
- 一次探索整个应用程序
- 一次完成所有事情的自动化
- 处理没有上下文的复杂流
结果：覆盖率差距30-50%，理解浅，假设不正确，断言薄弱。
什么效果更好
逐个模块的方法。
一次专注于一个模块或功能可以显著提高结果。通过适当的范围界定，覆盖率可以从50-70%跃升至80-90%。
将代理人视为需要明确方向和界限的初级团队成员。
工作流程
步骤1：创建测试计划（计划模式）
示例提示：
Navigate to the login module.
Explore all visible elements and user flows.
Create a detailed test plan covering positive, negative, and edge case scenarios.
输出：
- Markdown测试计划，包括场景、步骤和预期结果
- 典型覆盖率：50-70%
重要提示： 审查计划。添加缺失的场景。对业务逻辑的正确假设。
步骤2：生成测试（生成器模式）
将测试计划置于上下文中，并切换到生成器模式。
示例提示：
Generate Playwright tests for the "Product Search" scenarios
from the attached test plan.
Use proper locators and include assertions.
输出：
- 带有测试结构、定位器和基本断言的Playwright测试文件
对于页面对象模型： 附加一个现有的页面对象文件，并明确请求：“遵循附件中显示的页面对象模型结构。”
步骤3：运行测试
通过总代理模式：
Run the generated tests in Chromium headed mode
通过终端：
npx playwright test --project=chromium --headed
有些测试会通过，有些会失败。这是正常的，也是意料之中的。
步骤4：修复失败的测试（治疗师模式）
示例提示：
The search-with-no-results.spec.ts test failed.
Investigate and fix the issue.
治疗师可以修复：
- 严格违反模式
- 模糊的定位器
- 选择器索引问题
- 轻微的时间问题
治疗师无法修复：
- 错误的业务逻辑
- 有缺陷的测试策略
- 应用程序错误
这是一个需要后续问题和背景的迭代对话。
用于深度导航的种子文件
当测试需要浏览许多页面才能到达目标区域时，请创建一个种子文件来自动进行初始导航。
用途：
- 编写一个可导航到目标区域的剧作家测试
- 在提示Planner时附加种子文件
- 指定：“使用附加的种子文件导航到[目标区域]，然后为[模块]创建测试计划”
人的责任
仍然需要：
- 验证测试计划
- 决定自动化什么
- 提供业务背景
- 审查生成的代码
- 定义测试策略
代理人处理什么：
- 乏味的探索
- 生成测试骨架
- 查找定位器
- 创建基本结构
- 解决明显的技术问题
这是授权，不是退位。
改善结果
提供上下文
附上相关文件：
- 业务需求（用于理解有效输入、错误消息）
- 现有页面对象（遵循框架模式）
- API文档
- 种子文件
写清楚提示
而不是：“测试搜索功能”
使用：“为产品搜索创建测试，包括：完全匹配、部分搜索、无结果、特殊字符和区分大小写。验证结果是否正确显示。”
迭代
这是一个对话：
- 从基本提示开始
- 评审输出
- 请求更正
- 提供更多上下文
- 要求具体更改
这表明了什么
演示如何：
- 加快测试计划
- 自动化探索性导航
- Bootstrap自动化更快
- 在帮助下修复明显的故障
不：
- 更换测试工程师
- 提供零工作量自动化
- 作为开箱即用的生产框架工作
- 做出测试决策
关键要点
剧作家测试代理减少了繁忙的工作，而不是批判性思维。
用作助手：非常有价值。 用作决策者：令人失望。
