AI agent自动化测试

用一个案例看懂 AI Agent 自动化测试

一句话理解

传统自动化测试是：人提前写好固定步骤，脚本按照步骤执行。

AI Agent 自动化测试是：人给出测试目标，Agent 根据执行过程中的实际状态，动态决定下一步调用哪个测试工具。

原有的 Playwright、接口测试、数据库校验和断言并没有被替代。它们被封装成工具，由 Agent 统一调度。

测试目标
  ↓
AI Agent 观察状态、决定下一步
  ↓
调用 Playwright、接口、数据库等工具
  ↓
代码断言验证结果
  ↓
生成测试报告和执行记录

案例：自动完成电商下单测试

测试目标：

使用测试账号登录电商网站，搜索“蓝牙耳机”，选择一个有库存的商品加入购物车并提交订单，最后验证订单状态和金额是否正确。

测试约束：

只能操作测试环境；
可以提交订单，但不能支付；
商品库存、活动弹窗和页面状态可能变化；
最终结果必须通过接口和数据库验证。

这个场景适合使用 Agent，因为执行路径不是完全固定的。例如，第一个商品可能无库存，活动弹窗可能遮挡按钮，提交订单也可能失败。Agent需要根据现场状态调整操作。

Agent 可以使用哪些工具

Agent 负责选择工具，工具负责真正执行操作。

工具	作用
Playwright	打开页面、点击、输入、读取页面状态和截图
接口工具	创建测试账号、清理购物车、查询商品和订单
数据库工具	查询订单和库存数据
日志工具	根据 Trace ID 查询服务日志
断言工具	精确比较订单状态、金额等结果
报告工具	保存步骤、截图、证据和最终结论

完整执行流程

1. 接收测试任务

测试人员向 Agent 提供目标、环境、限制条件和通过标准。

{
  "goal": "完成蓝牙耳机下单并验证订单",
  "environment": "test",
  "allow_payment": false,
  "success_criteria": [
    "成功创建订单",
    "订单状态为待支付",
    "订单金额与页面金额一致"
  ]
}

Agent 从中识别：要完成什么、不能做什么、最终验证什么，以及需要调用哪些工具。

2. 准备测试数据

Agent 调用接口工具：

create_test_user()
clear_user_cart()
query_product("蓝牙耳机")

这些工具负责创建测试账号、清空历史购物车并确认测试商品存在。Agent只负责发起调用并检查前置条件是否满足。

3. 观察当前页面

Agent 调用 Playwright 打开网站并读取页面状态：

open_page(test_url)
get_page_state()

工具返回当前 URL、页面文本、可操作元素和截图。Agent据此判断当前是否已经登录、下一步应该操作哪个元素。

4. 制定初始计划

Agent 根据测试目标和当前页面生成计划：

登录账号
→ 搜索商品
→ 选择有库存商品
→ 加入购物车
→ 提交订单
→ 验证订单

这个计划不是固定脚本。每执行一步，Agent都会重新观察页面，再决定下一步。

5. 循环执行：观察、判断、操作

Agent进入最核心的执行循环：

观察当前状态
→ 判断下一步动作
→ 调用测试工具
→ 获取执行结果
→ 再次观察

例如，Agent准备点击“加入购物车”，但发现按钮被活动弹窗遮挡。它不会继续盲目点击，而是调整执行步骤：

关闭活动弹窗
→ 重新读取页面状态
→ 点击“加入购物车”

如果第一个商品已经无库存，Agent可以返回商品列表，选择另一个满足条件的商品。这种根据现场状态调整路径的能力，是 Agent 相比固定自动化脚本的主要价值。

6. 提交订单并执行确定性验证

订单创建后，Agent获取订单号和页面金额，然后调用订单接口、数据库工具和断言工具：

query_order(order_id)
query_order_from_database(order_id)

assert_equal(api_status, "WAIT_PAY")
assert_equal(database_status, "WAIT_PAY")
assert_equal(api_amount, page_amount)
assert_equal(database_amount, page_amount)

这里的职责边界非常重要：

Agent负责决定验证哪些内容；代码断言负责最终判断测试是否通过。

订单状态、金额等确定性结果，不应该只让大模型判断。

7. 失败时自动收集证据

如果提交订单返回 500，Agent不应该直接猜测原因，而是继续调用工具收集证据：

get_trace_id()
get_service_logs(trace_id)
query_product_inventory(product_id)
capture_screenshot()

如果日志明确显示库存不足，Agent可以输出对应结论；如果证据不充分，则标记为“需要人工确认”，而不是强行给出根因。

8. 生成报告并清理数据

Agent最终输出结构化测试报告：

{
  "case": "蓝牙耳机下单测试",
  "result": "PASS",
  "order_id": "TEST20260831001",
  "checks": {
    "order_created": "PASS",
    "order_status": "PASS",
    "order_amount": "PASS"
  },
  "evidence": [
    "order_api_response.json",
    "database_result.json",
    "checkout_page.png"
  ]
}

随后调用清理工具取消测试订单、清空购物车，避免影响后续测试。

每部分分别负责什么

部分	核心职责
测试人员	定义测试目标、约束和通过标准
AI Agent	观察状态、选择工具、调整执行路径
自动化工具	完成页面、接口、数据库和日志操作
代码断言	对确定性结果作出通过或失败判断
Trace 与报告	记录执行过程、证据和最终结论

RAG 在这里是什么角色

RAG不是 Agent 自动化测试的核心流程，它只是一个可选的知识查询工具。

例如，Agent不知道“未支付订单的正确状态是什么”，可以通过 RAG 查询需求文档和业务规则。查询到规则后，Agent再决定应该验证 WAIT_PAY 状态。

因此：

已经明确提供业务规则时，不一定需要 RAG；
需要查询需求、测试规范或历史 Bug 时，再加入 RAG；
RAG负责提供知识，不负责操作页面，也不负责控制测试流程。

总结

AI Agent 自动化测试的核心不是用大模型替代自动化测试，而是在已有自动化能力上增加一个智能控制层：

AI Agent：理解目标、观察状态、动态决策
自动化工具：执行页面、接口和数据库操作
确定性断言：判断测试是否真正通过

普通测试开发需要重点补充的能力也因此非常明确：

将现有自动化能力封装成 Agent 可以调用的工具；
设计 Agent 的观察、决策、执行和重试流程；
使用断言、Trace 和权限控制保证 Agent 可靠运行。

一句话概括：

AI Agent 自动化测试，就是让 AI 根据现场状态，动态组织和调用已有的自动化测试能力。

自动化测试工程师转向 AI Agent 测试开发：具体学习路线

下面按“普通自动化测试工程师，已有 Python、Pytest、接口测试、SQL 和 Linux 基础”估算。目标不是了解概念，而是达到：

能独立完成一个 RAG + Agent + Tools 项目，并能设计自动化测试、定位问题、应对面试。

难度采用 5 级制：

★：简单
★★★：需要实践
★★★★★：需要工程设计和多次调试

总体学习量

模块	目标层级	难度	时间
LLM 基础调用	能独立开发	★★	12～16 小时
Tools 工具封装	能设计和调试	★★★	18～24 小时
RAG	能搭建和优化	★★★☆	22～30 小时
Agent	能设计完整执行流程	★★★★	28～36 小时
AI 质量保障	能建立自动化回归	★★★★	22～30 小时
项目整合	能完整演示和面试讲解	★★★★	12～18 小时
合计	—	—	114～154 小时

每周学习 12～15 小时，大约需要 8～11 周。

一、LLM 基础调用

难度：★★
时间：12～16 小时
学习目标：能够稳定调用模型，并让模型输出程序可以处理的结果。

需要学习

1. 基本调用

API Key 和环境变量；
Python SDK；
System/User 消息；
同步与异步请求；
流式和非流式输出；
模型参数；
Token 和费用。

2. Prompt 基础

需要掌握：

明确角色；
明确任务；
提供上下文；
规定输出格式；
提供限制条件；
给出少量示例。

不需要学习大量所谓的“Prompt 技巧”。

3. 结构化输出

重点掌握：

JSON 输出；
JSON Schema；
Pydantic 模型；
字段校验；
输出格式错误时的处理；
枚举、必填字段和嵌套对象。

示例目标：

{
  "result": "PASS",
  "reason": "订单状态为 WAIT_PAY",
  "next_action": "query_database"
}

4. Function Calling

理解：

模型不直接执行函数
→ 模型返回工具名称和参数
→ 程序校验参数
→ 程序执行工具
→ 工具结果返回给模型

5. 异常处理

请求超时；
API 限流；
模型返回空结果；
JSON 解析失败；
上下文过长；
重试和退避；
Token 费用控制。

学到什么程度

完成一个程序：

输入测试目标
→ 模型判断应该调用哪个工具
→ 返回符合 Schema 的参数
→ 程序校验并执行
→ 输出结构化结果

验收标准：

能稳定输出 JSON；
能调用至少 3 个工具；
参数错误时不会直接执行；
API 失败时有重试和明确错误；
能记录模型、Token、耗时和结果。

二、Tools 工具封装

难度：★★★
时间：18～24 小时
学习目标：把现有自动化测试能力转换成 Agent 可以安全调用的工具。

需要学习

1. 工具设计

每个工具只完成一个明确动作：

search_product(keyword)
query_inventory(product_id)
add_to_cart(product_id, quantity)
create_order(user_id)
query_order(order_id)

不要设计成：

execute_test(command)
run_any_sql(sql)
run_shell(command)

后者权限太大，也不容易测试。

2. 参数 Schema

掌握：

参数类型；
必填字段；
默认值；
枚举；
长度和范围限制；
业务合法性校验。

3. 统一返回格式

建议所有工具统一返回：

{
  "success": true,
  "data": {},
  "error_code": null,
  "message": "执行成功",
  "trace_id": "xxx"
}

4. 工具可靠性

重点掌握：

超时；
重试；
幂等性；
错误码；
权限；
日志；
Mock；
清理测试数据。

尤其要理解幂等性：

创建订单接口超时，不能直接再次创建，应该先查询订单是否已经生成。

5. 自动化能力封装

至少封装：

Playwright 页面工具；
HTTP 接口工具；
数据库查询工具；
日志查询工具；
断言工具；
截图和报告工具。

学到什么程度

完成 6～8 个可调用工具。

验收标准：

每个工具职责单一；
输入输出都有 Schema；
参数非法时拒绝执行；
重复调用不会产生重复订单等副作用；
工具可以独立进行单元测试；
能 Mock 成功、失败、超时和异常结果；
每次调用都有 Trace 记录。

三、RAG

难度：★★★☆
时间：22～30 小时
学习目标：让 Agent 能够准确查询企业文档，并返回可追溯的答案。

需要学习

1. 文档处理

掌握：

Markdown、PDF、Word 等文档读取；
去除无用内容；
按标题和段落切分；
Chunk 大小；
Chunk 重叠；
文档元数据。

元数据至少包括：

{
  "document_id": "order-rule-001",
  "title": "订单业务规则",
  "section": "未支付订单",
  "version": "2026-08",
  "permission": "test-team"
}

2. Embedding

只需理解：

Embedding 将文本转换成向量；
语义相近的文本向量距离更近；
查询和文档必须使用兼容的 Embedding 模型；
更换 Embedding 模型通常需要重新建索引。

不需要学习向量模型训练。

3. 检索

掌握：

向量检索；
BM25 关键词检索；
Top K；
相似度阈值；
混合检索；
元数据过滤。

4. Rerank

理解完整过程：

第一次检索召回 20 条
→ Reranker 重新排序
→ 选择最相关的 3～5 条
→ 发送给大模型

5. 答案生成

要求模型：

只能基于检索文档回答；
没有依据时明确说不知道；
返回文档标题和章节；
不允许伪造引用。

6. RAG 测试

重点测试：

正确文档是否被召回；
正确文档排在第几位；
是否召回过期文档；
是否跨权限读取文档；
模型是否根据文档回答；
答案是否伪造信息。

工具选择

快速学习只选一套：

向量库：pgvector 或 Elasticsearch；
Embedding：选择一个兼容中文的模型；
Reranker：选择一个中文 Reranker；
框架：LangChain 或 LlamaIndex 二选一。

学到什么程度

建立一个测试知识库，包含：

测试规范；
订单业务规则；
接口文档；
历史 Bug；
故障处理手册。

准备至少 30 条查询测试集。

验收标准：

能返回正确文档；
能显示引用来源；
无答案时不会编造；
能过滤过期和无权限文档；
能解释某条问题为什么没有正确召回；
能通过调整切分、Top K 或 Rerank 改善效果。

四、Agent

难度：★★★★
时间：28～36 小时
学习目标：让 Agent 根据执行状态动态调用工具，而不是按照固定脚本运行。

需要学习

1. Agent 状态

状态至少包含：

{
  "goal": "完成下单测试",
  "current_step": "query_inventory",
  "completed_steps": [],
  "tool_results": [],
  "retry_count": 0,
  "order_id": null,
  "final_result": null
}

2. 执行循环

理解核心循环：

观察当前状态
→ 判断下一步动作
→ 选择工具
→ 校验参数
→ 执行工具
→ 保存结果
→ 再次判断

3. 分支与异常恢复

必须实现：

商品无库存时更换商品；
页面弹窗遮挡时先关闭弹窗；
接口超时时查询实际状态；
数据库暂时不可用时有限重试；
工具参数错误时重新生成；
多次失败后停止任务；
证据不足时转人工确认。

4. 终止条件

Agent 必须有：

最大执行步数；
单工具最大重试次数；
总任务超时；
Token 预算；
费用预算；
成功条件；
失败条件；
人工介入条件。

5. 高风险操作

支付、删除、发布、修改权限等操作需要：

Agent 提出操作
→ 程序判断属于高风险
→ 等待人工确认
→ 确认后才执行

不能只依靠 Prompt 限制 Agent。

6. 框架

建议使用 LangGraph，因为它适合：

显式状态；
条件分支；
可控流程；
重试；
人工确认；
执行轨迹。

只学一个 Agent 框架即可。

学到什么程度

完成一个电商下单测试 Agent。

至少覆盖：

正常下单；
商品无库存；
活动弹窗；
接口 500；
创建订单超时；
数据库查询失败；
禁止支付；
最大步骤限制。

验收标准：

能动态选择工具；
能根据工具结果改变路径；
不会无限循环；
不会重复创建订单；
高风险操作不会自动执行；
每个步骤都能追踪；
失败时能输出明确原因和证据。

五、AI 质量保障

难度：★★★★
时间：22～30 小时
学习目标：能够判断 Agent 版本是否可以上线。

需要学习

1. 分层测试

需要建立四层测试：

工具单元测试
RAG 检索测试
Agent 轨迹测试
端到端业务测试

2. 评测数据集

准备 80～150 条用例：

正常业务；
边界条件；
工具失败；
多轮上下文；
历史 Bad Case；
Prompt 注入；
权限与安全；
性能和稳定性。

3. 关键指标

只保留最重要指标：

任务成功率；
工具选择准确率；
参数正确率；
异常恢复率；
重复操作率；
安全违规次数；
P95 耗时；
单任务 Token 成本。

4. 断言方式

优先顺序：

代码断言；
规则判断；
数据库和接口验证；
LLM 评分；
人工复核。

订单金额、状态、工具参数等确定性结果，不使用 LLM 评分。

5. 多次运行

大模型具有不确定性，因此关键用例需要重复执行，例如：

每条核心用例执行 5 次
→ 统计成功率
→ 识别偶发失败
→ 保存每次执行轨迹

6. 回归与门禁

模型、Prompt、RAG 文档或工具变更后自动执行评测。

示例门禁：

核心任务成功率不得下降
重复订单数必须为 0
非法工具调用必须为 0
安全用例必须全部通过
P95 耗时不得超过预算

学到什么程度

实现一个批量回归程序：

读取用例
→ 执行 Agent
→ 保存轨迹
→ 执行断言
→ 汇总指标
→ 对比基线版本
→ 生成测试报告

验收标准：

至少 80 条用例；
可以批量执行；
可以重复运行；
能对比两个 Agent 版本；
能输出失败用例和失败步骤；
能区分模型、RAG、工具和业务系统问题；
能给出是否允许上线的结论。

六、8～11 周安排

周数	学习内容	阶段产出
第 1 周	LLM API、Prompt、结构化输出	结构化模型调用程序
第 2 周	Function Calling、Tools	6～8 个测试工具
第 3 周	文档切分、Embedding、向量检索	基础知识库
第 4 周	混合检索、Rerank、引用、RAG 测试	可测试的 RAG 服务
第 5 周	Agent 状态和工具调用循环	基础测试 Agent
第 6 周	分支、重试、超时、终止条件	可恢复的 Agent
第 7 周	人工确认、安全和完整轨迹	可控 Agent
第 8 周	评测集、断言、批量执行	自动化评测程序
第 9 周	版本对比、指标和报告	质量门禁
第 10 周	完整项目优化和 Bad Case 分析	面试项目
第 11 周	补充薄弱点、准备项目讲解	面试答案和简历内容

最终判断是否学会

不是看课程是否看完，而是看能否独立回答并实现：

为什么这个场景需要 RAG？
为什么需要 Agent 而不是固定脚本？
工具如何设计才能避免重复订单？
RAG 没有召回正确规则如何定位？
Agent 最终成功但执行过程错误，如何发现？
模型升级后如何判断能否上线？
如何防止 Agent 执行支付等危险操作？
如何从 Trace 判断问题属于模型、RAG 还是工具？

能够结合自己的项目回答并展示代码、轨迹、用例和报告，才算达到面试和真实项目的基本要求。

posted @ 2026-08-31 15:43 不做大哥好多年阅读(3) 评论(0) 收藏举报

刷新页面返回顶部

AI agent自动化测试

用一个案例看懂 AI Agent 自动化测试

一句话理解

案例：自动完成电商下单测试

Agent 可以使用哪些工具

完整执行流程

1. 接收测试任务

2. 准备测试数据

3. 观察当前页面

4. 制定初始计划

5. 循环执行：观察、判断、操作

6. 提交订单并执行确定性验证

7. 失败时自动收集证据

8. 生成报告并清理数据

每部分分别负责什么

RAG 在这里是什么角色

总结

自动化测试工程师转向 AI Agent 测试开发：具体学习路线

总体学习量

一、LLM 基础调用

需要学习

1. 基本调用

2. Prompt 基础

3. 结构化输出

4. Function Calling

5. 异常处理

学到什么程度

二、Tools 工具封装

需要学习

1. 工具设计

2. 参数 Schema

3. 统一返回格式

4. 工具可靠性

5. 自动化能力封装

学到什么程度

三、RAG

需要学习

1. 文档处理

2. Embedding

3. 检索

4. Rerank

5. 答案生成

6. RAG 测试

工具选择

学到什么程度

四、Agent

需要学习

1. Agent 状态

2. 执行循环

3. 分支与异常恢复

4. 终止条件

5. 高风险操作

6. 框架

学到什么程度

五、AI 质量保障

需要学习

1. 分层测试

2. 评测数据集

3. 关键指标

4. 断言方式

5. 多次运行

6. 回归与门禁

学到什么程度

六、8～11 周安排

最终判断是否学会

公告