测试 Agent 评测体系详细方案

title: 测试 Agent 评测体系详细方案
date: 2026-07-08
format: xmind-outline-backup

测试 Agent 评测体系详细方案

1. 评测目标与边界

核心目标

验证 Agent 是否真正完成测试任务，而不是只生成看似合理的文本

衡量从需求理解、测试设计、执行、断言、归因到报告的端到端质量

形成模型/工具/提示词/工作流升级前后的可回归评测基线

把评测结果接入发布门禁、工具选型和测试平台治理

被测对象

测试用例生成 Agent

UI 自动化 Agent：如 Playwright Test Agents、Midscene、UI-TARS、Computer Use 类方案

接口/流程测试 Agent：从 OpenAPI、Arazzo、需求文档生成并执行测试

资损测试 Agent：识别资金风险、生成异常场景、验证业务不变量

代码测试 Agent：补单测、修失败测试、修 CI、提升覆盖率

评测平台自身：dataset、grader、runner、trace 和报告

不纳入首期范围

纯模型通用能力 benchmark

只看回答质量、不验证执行结果的静态问答评测

无法脱敏或无法沙箱隔离的真实资金操作

核心结论口径

任务是否成功：最终产物是否可执行、可验证、可复现

过程是否可信：每一步工具调用、观察、决策都有 trace

风险是否覆盖：高风险业务点是否被召回并验证

成本是否可控：执行时间、模型费用、人审成本是否可接受

2. 全链路节点展开

节点 0：评测任务入口

目标：定义要评测的 Agent、任务集、环境、模型版本和工具版本

输入：Agent 配置、模型版本、提示词版本、工具白名单、评测集版本

输出：一次 eval run 的唯一 ID、运行计划、权限范围

指标：配置完整率、版本可追溯率、任务启动成功率

难点：同一个 Agent 在不同模型/工具/提示词下结果差异很大

设计点：所有运行强制记录 model、prompt、tool、dataset、环境镜像和代码 commit

节点 1：需求/任务理解

目标：判断 Agent 是否正确理解需求、约束、风险和验收标准

输入：PRD、需求单、接口文档、页面链接、历史缺陷、用户故事

输出：需求摘要、测试目标、风险清单、待澄清问题

指标：需求点召回率、误解率、风险点召回率、澄清问题有效率

难点：需求常有歧义、隐含规则、过期文档和跨系统依赖

设计点：引入标准答案要点、业务规则 checklist、人工抽样复核和反例需求集

节点 2：测试计划生成

目标：从需求生成分层测试策略和可执行测试计划

输入：需求理解结果、系统架构、接口契约、页面结构、风险模型

输出：测试范围、测试类型、优先级、数据准备、执行顺序、退出标准

指标：测试类型覆盖率、关键路径覆盖率、冗余率、不可执行计划比例

难点：Agent 容易只列常规功能点，漏掉异常、权限、并发、幂等、资损场景

设计点：按功能、接口、UI、流程、资损、数据、性能、安全、兼容性建立覆盖模板

节点 3：测试设计与用例生成

目标：生成具体 case、断言、测试数据和执行脚本

输入：测试计划、接口 schema、页面结构、业务规则、历史 case

输出：UI case、API case、流程 case、资损 case、数据质量规则、单测代码

指标：可执行率、断言完整度、边界值覆盖率、重复用例比例、维护成本

难点：生成内容可能看似完整但不可运行，或者断言太弱只验证 200/页面存在

设计点：生成后必须进入静态校验、依赖校验、dry-run 和最小执行验证

节点 4：测试数据准备

目标：为测试生成稳定、隔离、可回滚、可复用的数据

输入：数据需求、环境、账号、权限、商品/订单/账户/优惠/库存状态

输出：测试数据包、数据创建脚本、清理脚本、数据血缘记录

指标：数据准备成功率、数据污染率、复用率、清理成功率

难点：真实业务数据依赖多、状态复杂、跨系统创建成本高

设计点：建设测试数据工厂；支持数据模板、快照、mock、影子账号和回滚策略

节点 5：环境与依赖校验

目标：确认被测系统、依赖服务、浏览器、数据库、消息队列和权限可用

输入：环境配置、服务健康检查、依赖拓扑、测试账号

输出：环境就绪报告、阻塞项、降级策略

指标：环境可用率、非业务失败占比、依赖故障定位时间

难点：大量 eval 失败不是 Agent 能力问题，而是环境、数据、权限和依赖问题

设计点：运行前 health check；失败分类区分 Agent failure 和 environment failure

节点 6：工具调用与执行

目标：评估 Agent 使用 Playwright、API client、DB、日志、CI、代码工具的能力

输入：工具白名单、测试计划、上下文、执行权限

输出：工具调用序列、执行日志、截图、网络请求、数据库查询、代码 diff

指标：工具调用正确率、非法调用率、重试次数、工具参数错误率、任务完成率

难点：Agent 可能选错工具、构造错误参数、越权操作、陷入无效循环

设计点：工具网关统一鉴权、参数 schema 校验、危险动作审批、最大步数和预算限制

节点 7：断言与结果判定

目标：判断执行结果是否满足业务、技术和体验预期

输入：执行结果、页面状态、API 响应、DB 状态、日志、消息、业务不变量

输出：pass/fail、失败证据、断言详情、置信度

指标：误判率、漏判率、断言强度、oracle 覆盖率

难点：很多真实任务没有单一标准答案，UI 和业务状态也可能异步变化

设计点：组合 oracle：规则断言 + 执行结果 + 快照对比 + LLM judge + 人审抽样

节点 8：失败归因

目标：把失败归类为需求问题、Agent 规划问题、工具问题、环境问题、产品缺陷或测试缺陷

输入：trace、日志、截图、错误堆栈、网络请求、系统指标

输出：失败类别、根因假设、复现步骤、责任域、修复建议

指标：归因准确率、人工复核一致率、平均定位时间、重复失败聚类率

难点：长链路失败常有多个原因，Agent 也可能编造根因

设计点：基于 trace 的阶段化归因；优先用确定性证据，再用 LLM 生成解释

节点 9：自修复与再执行

目标：评估 Agent 是否能修复失败测试、补充等待、修正 selector、调整数据或修复代码

输入：失败报告、测试代码、应用上下文、历史修复样例

输出：修复 diff、再执行结果、风险说明

指标：一次修复成功率、引入新失败率、修复 diff 人审通过率、flaky 降低率

难点：Agent 可能为了通过测试而削弱断言、删除步骤或掩盖真实缺陷

设计点：禁止降低断言强度；修复前后做语义 diff；关键测试必须人审

节点 10：报告与证据沉淀

目标：产出可复盘、可比较、可追踪的评测报告

输入：run 结果、指标、失败聚类、成本、trace、版本信息

输出：排行榜、趋势图、失败清单、改进建议、门禁结论

指标：报告完整率、可复现率、问题闭环率、阅读和采纳率

难点：报告如果只有分数，无法指导模型、提示词、工具或产品改进

设计点：报告必须包含样例、证据、失败分类、Top 问题和下一步行动

节点 11：回归门禁与线上监控

目标：将评测结果用于模型升级、工具升级、Agent 发布和生产风险监控

输入：基线分数、发布候选版本、风险等级、线上采样数据

输出：放行/阻断/灰度/回滚建议、线上告警、回归趋势

指标：阻断有效率、误阻断率、线上问题逃逸率、回滚及时性

难点：过严会阻碍迭代，过松会放过高风险 Agent 行为

设计点：分级门禁：P0 安全和资损必须强门禁，体验类采用灰度和抽样监控

3. 评测集 Dataset 设计

数据来源

历史需求：PRD、用户故事、验收标准

历史缺陷：线上事故、严重 bug、回归 bug、资损事件

历史测试资产：手工 case、自动化脚本、接口集合、Playwright trace

生产行为：脱敏流量、用户路径、失败日志、客服问题

合成样本：边界值、异常流、攻击样本、长链路任务

样本类型

Golden tasks：标准任务，预期结果清晰

Regression tasks：历史失败必须持续通过

Adversarial tasks：诱导越权、忽略规则、错误工具调用

Long-horizon tasks：跨页面、跨接口、跨系统、多轮操作

Tool-use tasks：重点评估工具选择和参数构造

Ambiguous tasks：评估澄清问题能力，而不是盲目执行

No-op tasks：验证 Agent 是否能拒绝不该做的事

Risk tasks：资损、安全、隐私、权限、合规高风险任务

样本标注字段

任务 ID、业务域、风险等级、测试类型、复杂度

输入材料：需求、接口、页面、数据、上下文

期望结果：必须覆盖点、禁止行为、通过条件、失败条件

标准 trace：可选，用于对比关键步骤是否合理

oracle 配置：规则、脚本、人工 rubric、LLM judge rubric

环境依赖：账号、数据、服务、mock、外部依赖

数据集分层

Smoke eval：每次变更快速跑，10 到 30 条，高确定性

Daily eval：每天跑，100 到 300 条，覆盖核心功能

Release eval：版本发布前跑，覆盖高风险和长链路

Deep eval：每周或模型升级前跑，包含复杂、多轮、对抗和资损样本

Online eval：线上抽样评测，关注真实用户行为和漂移

数据治理

版本化：dataset v1/v2，所有结果绑定版本

脱敏：移除用户、订单、账户、密钥和隐私信息

去重：避免同类样本过多导致指标虚高

难度校准：简单、中等、困难、极难分层

污染防护：防止评测答案泄漏进 Agent prompt 或训练材料

4. 指标体系

端到端指标

任务成功率：最终是否完成目标并满足验收条件

一次通过率：不依赖人工干预、不多次重试的成功比例

稳定通过率：同一任务多次运行结果一致程度

逃逸率：评测通过但真实场景失败的比例

人审通过率：Agent 产物被测试/研发采纳的比例

需求理解指标

需求点召回率

业务规则识别准确率

风险点召回率

澄清问题有效率

幻觉需求比例

测试设计指标

测试类型覆盖率：功能、异常、权限、兼容、资损、数据、性能

边界值覆盖率

负向场景覆盖率

业务不变量覆盖率

冗余用例比例

执行指标

工具调用正确率

非法工具调用率

执行耗时

重试次数

非业务失败占比

断言指标

强断言比例：校验业务状态、数据、消息、日志，而不只是页面存在

误判率：错误判定失败或成功

漏判率：真实问题未被断言发现

oracle 覆盖率

异步等待正确率

安全与治理指标

越权操作次数

敏感信息泄露次数

危险动作拦截率

拒答/拒绝执行正确率

沙箱逃逸风险

成本指标

单任务模型 token 成本

单任务执行资源成本

平均运行时长

人工复核耗时

失败排查耗时

5. Grader / Oracle 设计

规则型 Grader

适合：接口状态码、schema、字段值、金额、状态机、权限校验

优点：确定性强、可解释、适合门禁

难点：规则维护成本高，覆盖不了主观质量

设计点：规则版本化，支持业务域插件和不变量模板

执行型 Grader

适合：代码测试是否通过、Playwright 是否成功、API 链路是否执行完成

优点：直接验证真实可执行结果

难点：环境、数据和 flaky 会影响评分

设计点：执行前健康检查，失败分层，重复运行确认 flaky

差异型 Grader

适合：截图对比、DOM 快照、API 响应快照、DB 快照

优点：能发现非预期变化

难点：动态内容和合理变化会造成误报

设计点：忽略动态字段，设置容忍阈值和可解释 diff

LLM Judge

适合：测试计划质量、风险识别、报告质量、自然语言解释

优点：能处理非结构化输出

难点：偏差、不稳定、被提示词影响、难做强门禁

设计点：rubric 标准化；双评委 + 仲裁；抽样人工校准；禁止单独决定 P0 门禁

人工评审

适合：高风险样本、低置信度样本、新场景校准

优点：可靠，能补充业务判断

难点：成本高、主观差异大

设计点：只审抽样和争议样本；用 checklist 降低主观差异

组合评分

先用确定性规则和执行结果打底

再用 LLM judge 评估非结构化质量

高风险失败进入人工复核

最终分数由任务成功、风险覆盖、过程合规、成本共同组成

6. 场景化评测方案

测试用例生成 Agent 评测

输入：需求文档、接口文档、历史缺陷、页面链接

输出：测试点、case、优先级、自动化脚本、数据准备说明

指标：需求覆盖、风险召回、可执行率、断言强度、人审通过率

难点：测试点看似完整但缺少关键异常和业务不变量

设计点：用历史 bug 作为隐藏标准答案，评估是否能生成回归用例

UI Agent 评测

输入：页面 URL、任务目标、测试账号、初始状态

输出：操作步骤、Playwright 测试、截图、trace、断言

指标：路径完成率、selector 自愈率、视觉识别准确率、失败定位质量

难点：页面动态变化、弹窗、异步加载、权限和测试数据状态

设计点：分离结构化 Web Agent 与视觉 Agent；同一流程做多工具对照实验

API / 流程 Agent 评测

输入：OpenAPI、Arazzo/流程说明、认证信息、测试数据

输出：API case、链路执行结果、状态机断言、错误报告

指标：schema 覆盖、边界值覆盖、链路成功率、状态迁移验证率

难点：多接口数据依赖、鉴权、异步回调、幂等和环境污染

设计点：引入契约校验、状态机模型和可回滚测试数据

资损测试 Agent 评测

输入：订单/支付/退款/账务规则、历史资损案例、异常注入配置

输出：资金不变量、异常场景、执行脚本、差异对账报告

指标：资损风险召回率、不变量正确率、异常场景覆盖率、误报率

难点：业务规则复杂、真实资金不可操作、跨系统账务时延

设计点：用沙箱账本和模拟支付；先评估模型能否表达正确不变量

缺陷修复 / CI 修复 Agent 评测

输入：失败测试、日志、代码仓库、issue 描述

输出：代码 diff、测试 diff、修复说明、再执行结果

指标：修复成功率、回归通过率、覆盖率变化、人审通过率、新 bug 引入率

难点：Agent 可能删除测试、弱化断言或只修表象

设计点：强制比较修复前后断言；引入 hidden tests 和 mutation tests

Agent 安全评测

输入：越权任务、提示注入、敏感数据、危险工具调用诱导

输出：拒绝执行、请求澄清、审批申请、安全日志

指标：危险动作拦截率、越权拒绝率、敏感信息泄露率

难点：测试 Agent 往往需要较高工具权限，风险边界模糊

设计点：工具白名单、最小权限、审批流、红队样本库

7. 平台架构设计

Dataset Manager

管理评测集、样本版本、标签、风险等级和标准答案

支持脱敏、去重、难度分层和污染检查

Eval Runner

按计划调度 eval run，支持 smoke、daily、release、deep eval

记录模型、prompt、工具、代码、环境和数据版本

Sandbox / Environment Manager

隔离浏览器、测试账号、测试数据、文件系统和网络权限

支持快照、回滚、mock、服务健康检查

Tool Gateway

统一接入 Playwright、API client、DB、日志、CI、代码仓库、工单系统

做 schema 校验、权限校验、危险动作审批和调用审计

Trace Collector

采集 Agent 思考摘要、工具调用、截图、日志、网络请求、代码 diff

支持按节点重放、失败聚类和证据链导出

Grader Service

执行规则型、执行型、差异型、LLM judge 和人工复核任务

输出分数、置信度、失败原因和改进建议

Report & Dashboard

提供模型/工具/版本对比、趋势、失败 Top、成本、门禁结论

支持按业务域、风险等级、节点、失败类型下钻

Feedback Loop

将失败样本回流到 dataset

将高频失败转为改进任务：prompt、工具、规则、测试数据、产品缺陷

8. 难点与设计方案

难点：成功标准难定义

表现：自然语言任务没有唯一答案，测试计划质量难量化

方案：分层 oracle；结构化任务用规则，开放任务用 rubric + 人审校准

难点：Agent 非确定性

表现：同一任务多次运行结果不同

方案：固定版本和温度；重复运行；统计稳定通过率；对关键任务取多次一致性

难点：环境和数据导致假失败

表现：账号失效、数据污染、下游服务不可用

方案：运行前 health check；数据快照和回滚；失败分类不把环境故障算 Agent 失败

难点：LLM Judge 不稳定

表现：评分漂移、偏向长答案、被输出格式影响

方案：明确 rubric；少量样本人工金标；双 judge 仲裁；只做辅助评分

难点：长链路评测成本高

表现：浏览器、模型和环境运行时间长

方案：分层运行；smoke 快速筛选，release/deep eval 再跑长链路

难点：资损与安全场景不可真实执行

表现：真实资金、真实权限和生产数据不可碰

方案：沙箱账本、影子账户、mock 支付、只读查询、审批工具

难点：Agent 会“投机取巧”

表现：删除断言、绕过步骤、修改测试预期来通过

方案：hidden tests、断言强度检查、diff 审核、禁止弱化关键断言

难点：评测集污染

表现：Agent 记住标准答案或 prompt 泄露测试答案

方案：私有隐藏集、定期换题、任务模板化变体、答案隔离

难点：指标和业务价值脱节

表现：分数上涨但线上问题没有减少

方案：指标绑定真实缺陷、事故、逃逸率、人工节省和发布阻断收益

9. PoC 设计

PoC 1：测试用例生成评测

样本：20 条真实需求 + 20 个历史 bug

对照：人工测试点、Agent 测试点、历史遗漏点

成功标准：关键风险召回率大于 80%，可执行 case 占比大于 70%

PoC 2：UI Agent 评测

样本：3 条核心 Web 流程，简单/中等/复杂各一条

候选：Playwright Test Agents、Playwright MCP、Midscene、UI-TARS、Computer Use

成功标准：重复执行成功率、失败证据、脚本维护成本优于当前基线

PoC 3：API / 流程 Agent 评测

样本：10 到 20 个 API + 1 条下单支付退款链路

候选：OpenAPI、Arazzo、Schemathesis、Agent workflow

成功标准：发现 schema/边界/状态机问题，流程可重放

PoC 4：资损评测

样本：支付、退款、优惠、账务流水沙箱模型

注入：重复请求、回调乱序、超时、并发、跨日对账

成功标准：重复扣款、超额退款、账务不平等风险可被检出

PoC 5：Agent Eval 平台最小闭环

建设：dataset manager、runner、trace、grader、dashboard 五个最小模块

样本：50 条混合任务

成功标准：任意 Agent 版本变更后可一键回归并生成对比报告

10. 落地路线图

第 1 阶段：0 到 1 个月

明确被测 Agent 和首批高价值场景

建立 50 条评测样本和基础 rubric

打通 eval runner、trace、基础报告

先做离线评测，不接强门禁

第 2 阶段：1 到 3 个月

补齐规则型 grader、执行型 grader 和人工复核流程

接入 UI、API、代码、日志、DB 等关键工具

形成 smoke/daily/release 三层评测

对模型、prompt、工具版本做横向对比

第 3 阶段：3 到 6 个月

接入发布门禁和 Agent 发布流程

建立失败样本回流和问题闭环机制

扩展到资损、数据质量、生产 synthetic monitoring

形成业务域排行榜和风险看板

第 4 阶段：6 到 12 个月

建设企业级评测平台

支持多 Agent、多模型、多工具、多业务域统一评测

接入线上抽样、漂移监控和自动回滚建议

形成质量工程知识库和不变量库

11. 交付物

评测体系设计文档

评测集字段规范

指标与评分规则说明

Grader 设计说明

PoC 实验报告模板

Agent 版本对比报告模板

失败分类与改进闭环模板

平台架构和模块边界说明