8.0
热点
AI SCORE
编程提效2026-08-14 21:44
RAG+Playwright MCP构建零代码AI测试自动化Agent
dev.to · AI#RAG#MCP#测试自动化
Editor brief · 编辑速览
用RAG注入项目知识、MCP提供浏览器工具、LLM做推理规划，实现自然语言描述测试需求、AI完成底层自动化的完整架构。
AI 驱动的测试自动化正在超越简单地生成 Playwright 或 Selenium 脚本。
下一代演进是构建一个 AI 测试自动化智能体，它能够理解应用需求、创建测试场景、与浏览器交互、执行测试、分析失败原因，并辅助维护自动化工作，而无需测试人员手动编写每一行代码。
实现这一目标的实用架构结合了以下技术：
LLM / AI 智能体用于推理和规划
RAG 用于项目特定的 QA 知识
Playwright MCP 用于浏览器交互
向量数据库用于可搜索的项目知识
测试执行与反馈用于持续改进
最终形成的工作流程是：测试人员可以用自然语言描述需要测试的内容，而 AI 则负责处理大量底层自动化工作。
核心思想很简单：
RAG 赋予 AI 知识。MCP 赋予 AI 工具。Playwright 赋予它浏览器自动化能力。
让我们看看这些组件是如何协同工作的。
无代码 AI 测试自动化智能体的高级架构如下：
flowchart TD
U["QA 工程师<br/>自然语言请求"]
K["QA 知识库<br/><br/>PRD / SRS<br/>用户故事<br/>测试用例<br/>API 文档<br/>现有自动化<br/>缺陷历史<br/>业务规则"]
R["RAG 管道<br/><br/>分块<br/>嵌入<br/>向量数据库<br/>语义检索"]
A["AI QA 智能体<br/><br/>推理与规划<br/>场景生成<br/>测试数据<br/>断言<br/>失败分析"]
M["MCP 工具层<br/><br/>Playwright MCP<br/>API MCP<br/>Jira MCP<br/>Git MCP<br/>数据库 MCP"]
P["Playwright<br/>浏览器自动化"]
APP["待测应用"]
E["执行结果<br/><br/>通过 / 失败<br/>截图<br/>日志<br/>网络数据<br/>证据"]
U --> A
K --> R
R --> A
A --> M
M --> P
P --> APP
APP --> E
E --> A
E --> R
这里有几个重要的层次。
这包含了 AI 理解应用及其业务规则所需的一切：
AI 智能体使用检索到的信息来：
理解需求
生成测试场景
选择适当的操作
决定下一步做什么
MCP 将 AI 智能体连接到外部工具，例如：
实际的应用测试产生：
这些结果随后可以反馈到 AI 工作流程中。
RAG 是 Retrieval-Augmented Generation（检索增强生成）的缩写。
没有 RAG，AI 模型主要依赖其提示词和通用训练知识。
对于严肃的测试自动化来说，这是不够的。
AI 可能知道如何编写 Playwright 代码，但不会自动知道：
应用如何运作
适用哪些业务规则
哪些测试用例已存在
哪些 API 可用
应使用哪些测试账户
之前发现了哪些缺陷
哪些工作流是高风险的
团队遵循哪些自动化模式
RAG 通过赋予 AI 访问组织 QA 知识的能力来解决这个问题。
QA 知识库可能包含：
QA 知识库
│
├── 需求
│ ├── PRD
│ ├── SRS
│ └── 用户故事
│
├── 测试
│ ├── 测试用例
│ ├── 回归套件
│ └── 自动化
│
├── 应用
│ ├── API 文档
│ ├── UI 规范
│ └── 架构
│
├── 缺陷
│ ├── 未关闭 Bug
│ ├── 已关闭 Bug
│ └── 根因分析
│
├── 业务
│ ├── 业务规则
│ ├── 角色
│ └── 工作流
│
└── 测试数据
├── 测试账户
├── 测试产品
└── 测试场景
现在考虑一个简单的请求：
"为结账创建自动化。"
通用 AI 可能会生成一个基本的结账测试。
而 RAG 驱动的 AI 智能体可以先检索：
结账需求
现有结账测试用例
支持的支付方式
之前的结账缺陷
然后根据实际应用创建测试计划，而不是做假设。
这就是通用 AI 生成自动化与项目感知 AI 自动化之间的区别。
模型上下文协议（Model Context Protocol，MCP）提供了一种标准化的方式，让 AI 应用与外部工具交互。
对于浏览器自动化，Playwright MCP 可以将浏览器能力暴露给 AI 智能体。
AI 智能体不需要在事情发生之前生成完整的 Playwright 脚本，而是可以通过可用工具与浏览器交互。
从概念上讲，工作流程如下：
AI QA 智能体
│
├── 导航
│
├── 检查页面
│
├── 查找元素
│
├── 点击
│
├── 输入
│
├── 检查更新后的状态
│
└── 验证结果
这改变了传统的自动化模型。
需求
↓
人工编写自动化代码
↓
Playwright
↓
浏览器
自然语言需求
↓
AI QA 智能体
↓
Playwright MCP
↓
Playwright
↓
浏览器
测试人员描述期望的行为，而 AI 智能体决定如何与应用交互。
RAG 和 MCP 不是竞争技术。
它们解决不同的问题。
一个有用的记忆方式是：
RAG 回答："AI 知道什么？"
MCP 回答："AI 能做什么？"
flowchart LR
R["RAG<br/><br/>需求<br/>测试用例<br/>测试数据<br/>历史缺陷"]
A["AI QA 智能体<br/><br/>推理 + 规划"]
M["Playwright MCP<br/><br/>浏览器工具"]
B["应用<br/><br/>浏览器"]
R --> A
A --> M
M --> B
想象测试一个登录页面。
有效用户：
qa-user@example.com
预期行为：
成功认证后重定向用户到仪表盘。
历史问题：
登录偶尔返回 HTTP 500。
MCP 允许 AI 实际执行：
打开登录页面
↓
检查页面
↓
输入用户名
↓
输入密码
↓
点击登录
↓
检查结果
↓
验证仪表盘
RAG 提供上下文。
MCP 提供操作。
AI 智能体将它们连接起来。
测试人员不应该需要编写 Playwright 代码。
相反，界面可以提供一个简单的输入框：
你想测试什么？
"验证现有用户可以使用有效凭证登录，并被重定向到仪表盘。"
AI 智能体可以：
检索相关需求。
检索现有登录测试。
识别适当的测试数据。
生成测试计划。
检查应用。
执行浏览器工作流。
测试人员看到的是测试工作流，而不是管理实现细节。
无代码界面可以可视化显示生成的工作流：
登录测试
┌─────────────┐
│ 打开登录页 │
└──────┬──────┘
↓
┌─────────────┐
│ 输入邮箱 │
└──────┬──────┘
↓
┌──────────────┐
│ 输入密码 │
└──────┬───────┘
↓
┌─────────────┐
│ 点击登录 │
└──────┬──────┘
↓
┌──────────────────┐
│ 验证仪表盘 │
└──────────────────┘
底层浏览器自动化可以保持隐藏，除非测试人员想要检查它。
让我们走一遍完整示例。
使用有效凭证测试登录功能，
并验证用户到达仪表盘。
AI 智能体首先理解请求。
RAG 管道搜索知识库。
登录需求
↓
认证测试用例
↓
现有 Playwright 测试
↓
有效测试账户
↓
历史登录缺陷
智能体现在拥有了项目特定的上下文。
这很重要，因为 AI 不是从空白提示词开始的。
它知道应用的预期行为。
AI 创建一个结构化的测试场景：
测试场景：
有效用户登录
前置条件：
存在一个有效的用户账户。
步骤：
1. 打开登录页面。
2. 输入用户的邮箱。
3. 输入用户的密码。
4. 点击登录。
5. 验证仪表盘是否显示。
预期结果：
用户成功认证并重定向到仪表盘。
此时，测试人员仍未编写自动化代码。
AI 将计划映射到浏览器操作。
导航
↓
检查页面
↓
查找邮箱字段
↓
输入邮箱
↓
查找密码字段
↓
输入密码
↓
查找登录按钮
↓
点击登录
↓
检查更新后的页面
↓
验证仪表盘
重要的区别在于，智能体可以在执行期间检查应用状态。
它不必盲目依赖生成测试时所做的假设。
浏览器执行工作流。
AI 智能体可以对可用的执行信息进行推理，例如：
URL
页面状态
元素信息
操作结果
截图
网络信息
测试断言
操作：
点击登录
结果：
登录请求已提交。
观察到的：
仪表盘已加载。
断言：
仪表盘标题可见。
状态：
通过
结果可以以人类可读的测试报告形式呈现给测试人员。
现在想象登录测试失败了。
传统自动化框架可能只是简单报告：
AI 驱动的系统可以分析证据并提供更多上下文。
Test: Login
Status: FAILED
Failure:
Dashboard was not displayed.
Observed:
HTTP 500 returned from /api/login.
Assessment:
The failure is more likely to be an
application/API issue than a locator
or synchronization issue.
Recommendation:
Create a defect for the authentication API.
关键在于，AI 不仅仅是在执行测试。
它还在对结果进行推理。
一个成熟的 AI 测试系统不应在测试结束时停止。
测试结果可以成为未来测试的额外知识。
flowchart TD
T["Test Execution"]
R["Test Results"]
P["Passed Test"]
F["Failed Test"]
A["AI Root Cause Analysis"]
D["Defect / Fix Information"]
K["QA Knowledge Base"]
T --> R
R --> P
R --> F
F --> A
A --> D
P --> K
D --> K
K --> T
Requirement
↓
Test Scenario
↓
Execution
↓
Failure
↓
Root Cause
↓
Defect
↓
Fix
↓
Regression Test
随着时间的推移，系统可以建立对应用程序更丰富的理解。
未来的测试生成可以利用来自先前失败和修复的信息。
这正是 RAG 变得特别有价值的地方。
一个实际实现可以使用以下组件：
具体技术栈可以有所不同。
架构比个体技术选择更重要。
关键是要保持职责分离：
Knowledge
↓
RAG
Reasoning
↓
AI Agent
Actions
↓
MCP
Browser Automation
↓
Playwright
Execution
↓
Test Environment
Results
↓
AI Analysis
一个常见的错误是把 RAG 当作倾倒所有应用程序信息的垃圾场。
相反，要围绕 QA 团队实际工作方式来组织知识库。
Knowledge Base
│
├── Requirements
│ ├── PRD
│ ├── SRS
│ └── User Stories
│
├── Testing
│ ├── Test Cases
│ ├── Regression
│ └── Automation
│
├── Defects
│ ├── Open Bugs
│ ├── Closed Bugs
│ └── Root Causes
│
├── Application
│ ├── API Docs
│ ├── UI Specs
│ └── Architecture
│
└── Business
├── Rules
├── Roles
└── Workflows
元数据也很重要。
{
"project": "Payment Portal",
"module": "Checkout",
"document_type": "test_case",
"version": "2.4",
"environment": "staging"
}
这使检索变得更加有针对性。
系统可以基于以下条件进行过滤，而不是在每次请求时搜索每个文档：
更好的检索通常意味着为 AI 提供更好的上下文。
避免创建一个包含所有可能操作的巨大 MCP 服务器。
更好的架构是使用专门的工具集成：
flowchart TD
A["AI QA Agent"]
P["Playwright MCP<br/>Browser Automation"]
API["API MCP<br/>API Testing"]
J["Jira MCP<br/>Defect Management"]
G["Git MCP<br/>Automation Repository"]
D["Database MCP<br/>Test Data"]
A --> P
A --> API
A --> J
A --> G
A --> D
AI QA Agent
│
├── Browser Actions
│
├── API Actions
│
├── Test Data
│
├── Defect Management
│
└── Automation Repository
这使系统更容易维护，并让你更好地控制权限。
它还允许团队逐步添加能力。
你可能从以下开始：
AI Agent
↓
Playwright MCP
API MCP
Jira MCP
Git MCP
Database MCP
随着平台的成熟。
AI 测试自动化智能体可以与真实应用程序和外部系统交互。
这意味着它不应自动获得无限权限。
一个有用的权限模型可能如下：
Read-only
↓
Browser Testing
↓
Create Test
↓
Create Defect
↓
Modify Automation
↓
Production Actions
高风险操作应需要明确批准。
AI:
"I found a likely defect.
Would you like me to create a Jira ticket?"
[ Create Defect ] [ Cancel ]
生产级实现应考虑：
工具级权限
环境限制
破坏性操作需要人工批准
目标是给予 AI 足够的访问权限以使其有用，而不是给予它对所有内容的无限制访问。
AI 生成自动化最大的挑战之一是不正确的假设。
例如，AI 可能假设登录按钮使用：
#login-button
而实际应用程序使用：
button[data-testid="login"]
RAG 可以提供应用程序上下文，但智能体在行动前还应检查实时应用程序。
一个更可靠的工作流程是：
flowchart LR
R["Requirement"]
K["Retrieve Knowledge"]
P["Create Plan"]
I["Inspect Application"]
V["Validate Assumptions"]
E["Execute"]
A["Verify Result"]
R --> K
K --> P
P --> I
I --> V
V --> E
E --> A
原则很简单：
不要让 AI 完全依赖它所知道的。让它在行动前观察应用程序。
这种检索上下文和实时应用程序检查的结合可以使自动化工作流程变得更加稳健。
无代码用户体验和无工程平台之间有一个重要的区别。
测试人员可能不需要写代码。
但平台背后仍然需要工程。
需要有人构建和维护：
权限管理
目标是复杂性从测试人员转移到平台。
Tester
↓
Write code
↓
Maintain locators
↓
Debug failures
↓
Update tests
体验变成：
Tester
↓
Describe what to test
↓
AI QA Agent
↓
Plan + Execute + Analyze
↓
Review Result
这就是无代码 AI 测试的真正承诺。
AI 驱动的测试演进可以这样看待：
AI Code Generator
↓
AI Test Generator
↓
AI Test Executor
↓
AI Test Analyzer
↓
AI Test Maintainer
↓
AI QA Agent
最后阶段更加雄心勃勃。
想象给一个 AI 智能体这样的指令：
"验证新的结账版本。"
不仅仅是生成几个脚本，智能体可以：
阅读发布需求。
识别受影响的模块。
检索历史缺陷。
生成基于风险的场景。
执行浏览器测试。
生成 QA 报告。
建议发布就绪性。
这比简单生成 50 个 Playwright 脚本要有价值得多。
执行质量工程任务的 AI。
整个概念可以总结为：
RAG 给予 AI 记忆，MCP 给予 AI 手，Playwright 给予它浏览器自动化，LLM 提供推理能力。
这就是无代码 AI 测试自动化智能体的基础。
AI 不一定取代自动化工程师。
相反，它可以改变他们时间的分配方式。
与其每天大部分时间编写重复的浏览器操作，QA 工程师可以更多地专注于：
业务关键场景
自动化治理
审查 AI 生成的测试
人类仍然决定什么重要。
AI 可以越来越多地帮助确定如何测试它。
测试自动化的未来不太可能仅仅是生成更多代码。
更大的机会是创建理解需求、应用程序行为、测试历史和业务上下文的系统，同时具有与真实测试工具交互的能力。
RAG 提供知识层。
MCP 提供工具访问层。
Playwright 提供浏览器自动化。
LLM 提供推理和决策。
它们一起可以转变传统自动化工作流程：
Requirement
↓
Manual Coding
↓
Execution
↓
Reporting
Natural Language
↓
RAG
↓
AI Planning
↓
MCP
↓
Playwright
↓
Execution
↓
AI Analysis
↓
Continuous Learning
目标不是消灭自动化工程师。
目标是让 QA 工程师减少编写重复自动化的时间，更多地花在决定：
对这个产品来说，质量意味着什么？
这就是 RAG + MCP + AI + 测试自动化可以将 QA 从脚本生成转向智能体质量工程的地方。