8 月 23 日，软件测试巨头 Tricentis 发布一整套 AI 创新，核心是 Tricentis Aida：一个不需要任何预置测试套件或脚本的自主 Agent，会自动探索 Web 与 Windows 桌面应用，像资深测试员一样发现缺陷与覆盖缺口。配套推出 AgentScore——用概率方式评估 AI Agent 在真实工作流中的行为表现，以及 Release Risk Intelligence——发布级风险提示。企业问 AI 的问题，正从「模型能不能编译」变成「Agent 干得靠不靠谱」。
🐞 本教程适合：测试工程师、质量负责人与正在引入 AI Agent 的开发团队。我们讲清 Aida 的工作原理、AgentScore 的用法与 CI 接入。
先搞懂：为什么需要「让 Agent 测 Agent」
过去我们让 AI 写测试用例，人再跑；现在应用越来越 Agent 化，问题倒过来了——谁来测这些 Agent 干活的水平？传统测试套件是按「已知需求」设计的，测不出 Agent 的「意外行为」。Aida 换了个思路：不给脚本，让 Agent 自己像真人一样「逛应用」，把逛出来的问题记下来。
| 传统自动化测试 | Aida 探索式测试 |
|---|---|
| 需要先写测试脚本 | 零脚本，即开即用 |
| 按已知需求覆盖 | 发现未知缺陷 |
| 验证「对不对」 | 探索「哪里不对」 |
| 人写用例 | Agent 自主探索 |
| 覆盖率固定 | 覆盖缺口自动暴露 |
它不是替代，是补充：Aida 适合补「传统自动化测不到」的部分；回归测试、精确断言仍靠既有测试体系。两者配合才完整。
Step 1：Aida 怎么工作——探索式缺陷发现
1 像新员工一样「逛应用」
Aida 的工作循环：
1. 启动
· 指定目标应用
（Web / Windows 桌面）
· 不需要测试脚本、
不需要先例
2. 自主探索
· Agent 模拟真实用户
点击、输入、导航
· 覆盖主要功能路径
+ 边界与异常路径
· 边逛边记录
3. 缺陷发现
· 崩溃、报错、功能
失效、交互异常
· 附截图与操作路径
（可复现步骤）
4. 覆盖缺口报告
· 哪些模块/功能
没被探索到
· 提示「这里可能有
风险但没测到」
5. 产出报告
· 缺陷清单 + 严重级
· 覆盖热力图
· 与发布风险联动
适用场景：
· 新应用首轮冒烟
· 老系统无测试文档
· Agent 改造后的
回归摸底💡 与《AI 自动化测试 Agent》的区别：那篇是「让 Agent 写测试用例」，Aida 是「让 Agent 直接当测试员探索」——互补关系，可叠加使用。
Step 2：AgentScore——给 Agent 行为打分
2 从「模型能不能跑」到「Agent 靠不靠谱」
AgentScore 要解决的问题：
· 传统评测只看模型
单次输出质量
· 但生产里 Agent 是
在真实工作流里
连续行动
AgentScore 的做法：
1. 在真实工作流中
观测 Agent 行为
2. 按概率评估：
· 任务完成率
· 路径合理性
· 出错概率
· 返工倾向
3. 输出概率化评分
· 不是 0/1 通过
· 而是「这个 Agent
在这个流程里的
可靠度」
使用场景：
· 选型：两个 Agent
框架谁更稳
· 验收：Agent 改造
上线前是否达标
· 监控：线上 Agent
行为漂移预警
与《Agent 评测 Evals》
的关系：
· Evals 测「能力基线」
· AgentScore 测
「生产行为」别只看一个分数：AgentScore 是概率估计，不是事实断言。配合失败样本分析看「为什么扣分」，才有改进方向——评分是起点不是终点。
Step 3：Release Risk Intelligence——发布风险前置
3 发布前，先看「风险地图」
Release Risk Intelligence
把测试数据升级为决策信息：
1. 发布级风险提示
· 汇总缺陷、覆盖缺口、
变更范围
· 标注「这次发布
高风险区域」
2. 建议行动
· 哪些模块建议
补测
· 哪些缺陷必须
修复才能发
3. 变更影响分析
· 本次改动影响了
哪些功能路径
· 对应风险等级
变化
使用方式：
· 每次发布候选
跑一轮
· 风险报告给
发布决策人
· 高风险 → 拦下
补测，低风险 →
放行
与《CI/CD 自动化》
衔接：
· CI 流水线里加
「Aida + 风险检查」闸门
· 风险过高自动
拦截发布💡 这就是《Agent 可观测性》在测试侧的延伸：可观测性解决「上线后看不见」，Release Risk 解决「上线前没把握」。
Step 4：在 CI/CD 里把 Aida 跑起来
4 一键接入流水线
最小接入示例：
CI 阶段新增一步：
aida-explore:
image: tricentis/aida
script:
- aida explore
--target https://staging.example.com
--duration 20m
--output reports/
- aida risk-check reports/
--gate high
artifacts:
paths: [reports/]
when: on_success
流程说明：
1. 部署到测试环境后触发
2. Aida 自主探索 20 分钟
3. 生成缺陷 + 覆盖报告
4. risk-check 按阈值
决定是否放行
建议频率：
· 每日构建：冒烟探索
（10-15 分钟）
· 发布候选：深度探索
（30-60 分钟）
资源注意：
· 探索式测试吃计算
资源，用测试环境
而非生产
· 与既有自动化测试
并行跑，不互斥注意环境隔离：Aida 会真实点击操作，务必在 staging/测试环境跑，别让它探索生产环境——它可不知道哪些按钮不能点。
Step 5：读懂报告——缺陷、缺口与行动
5 报告怎么用，比报告本身重要
拿到报告后按三步走：
1. 分类
· 真缺陷：需要修
· 误报：Agent 操作
路径不真实导致
· 环境问题：测试数据
不对引发的假错误
· 建议：先抽 20-30%
人工复核校准
2. 优先级
· 按「严重级 × 用户
触达概率」排序
· 覆盖缺口里挑
「高风险未测区」
优先补测
· 参考《39 项体检清单》
的思路分级
3. 闭环
· 缺陷 → 转 Issue
指派修复
· 误报 → 调整 Aida
配置/提示词
· 下次发布候选
回归验证
团队分工：
· 测试工程师：复核
与分类
· 开发：修真缺陷
· 质量负责人：盯
风险趋势
避免「报告躺灰」：
· 把 Aida 报告接入
周会
· 缺陷数/覆盖率
进质量看板💡 让 Aida 更聪明的关键是给它「业务上下文」：告诉它哪些流程最重要、哪些操作是禁区，探索质量会显著提升——和调教 Agent 是一个道理。
Step 6：团队落地建议
6 从尝鲜到质量基础设施
落地三步：
第一步：单个应用试点
· 挑一个中风险 Web 应用
· 跑 1 轮 20 分钟探索
· 团队看报告，讨论
价值与误报率
第二步：接入流水线
· CI 里加冒烟探索
· 发布候选跑深度
探索 + 风险闸门
· 建立误报校准机制
第三步：规模化
· 覆盖核心应用群
· AgentScore 纳入
Agent 选型流程
· 风险报告进
发布决策会
配套能力：
· 测试数据准备
（干净、可重复）
· 报告消费流程
（分类/转单/闭环）
· 参考《AgentRun 云原生底座》
的思路治理 Agent
测试基础设施
关键收益：
· 未知缺陷提前暴露
· 发布风险可量化
· 「Agent 干得好不好」
从感觉变成数据误报率是落地第一道坎：探索式 Agent 前期误报可能不少，别因噎废食——先校准配置，再谈规模化。给它业务上下文 + 禁区清单，误报能降一大截。
常见问题速查
| 你遇到的现象 | 大概率原因 & 解决 |
|---|---|
| 误报太多 | 缺业务上下文：给 Aida 流程说明、数据准备与操作禁区 |
| 探索不充分 | 时间太短或入口受限：加时长、给登录态/测试账号、指定入口页 |
| 和现有测试重复 | 分工错位：Aida 补「未知缺陷」，回归断言仍走既有套件 |
| AgentScore 分数波动 | 工作流定义不稳定：固定流程版本与观测窗口再对比 |
| 报告没人看 | 缺消费机制：接入周会 + 质量看板，缺陷转 Issue 闭环 |