多Agent探索性测试与边界发现流——把"人肉踩坑"变成"系统主动找bug"

一、场景演示

传统做法：

测试团队在功能上线前靠人工"点点点"，靠经验猜测哪里会出错。结果：

• 边界条件靠猜：Null、空字符串、超长文本、超大数字，全凭测试工程师"感觉"
• 历史 bug 不传承：上一个项目踩过的坑，下一个项目又踩一遍
• 组合爆炸靠运气：多个字段的排列组合，人工无法穷举
• 回归成本高：每次改动重跑全部用例，CI/CD 变成"CI/卡死"

用 OpenClaw 多Agent探索性测试流之后：

用户提交功能需求
  ↓
测试策略 Agent → 分析功能规格，生成探索路径树
  ↓
多个探索 Agent 并行出发：
  ├─ Agent-A：专攻「数据边界」——Null/空/超长/特殊字符
  ├─ Agent-B：专攻「状态组合」——并发/中断/重试/超时
  ├─ Agent-C：专攻「历史复现」——查询同类功能历史 bug 库
  └─ Agent-D：专攻「用户体验路径」——模拟真实用户操作流
  ↓
汇总 Agent → 合并所有发现，按严重程度分级，生成测试报告
  ↓
推送飞书 → 测试工程师确认 → 修复 → 验证闭环

实测效果：

• 某 SaaS 登录模块探索，发现 7 个隐藏边界 bug，其中 2 个是历史上反复出现的"经典坑"
• 探索覆盖率：人工测试约 40%，多Agent探索提升至 82%
• 每次探索结果自动入库，下个项目自动继承"历史教训库"

二、Step by Step

Step 0：准备阶段——定义被测系统入口

在飞书 Bitable 中建立「探索任务表」，字段包括：

Step 1：测试策略 Agent 生成探索路径

使用的 Skill： browser-automation + tavily-search

让一个 Agent 分析被测功能的规格说明（README、API 文档、PRD 片段），生成探索树：

提示词：
你是一个测试策略专家。分析以下功能描述，生成探索性测试路径树。
对每个路径节点，标注：
- 探索类型（边界测试/状态测试/用户体验路径/历史复现）
- 预期风险等级（高/中/低）
- 需要的数据条件

功能描述：
{粘贴功能描述或URL}

输出格式：JSON 路径树

Step 2：并行探索 Agent 执行

每个探索 Agent 独立工作，使用 browser-automation skill：

提示词（Agent-A 示例）：
你是边界测试专家。对被测系统的 {目标字段} 执行以下测试：

测试矩阵：
1. 空字符串 ("")
2. Null / undefined
3. 超长文本 (>10000字符)
4. 特殊字符 (<script>alert(1)</script> 等 XSS 模式)
5. SQL 注入试探 ('; DROP TABLE users;--)
6. 负数 / 极大正数
7. 非标准数据类型（传数组/传对象/传 null）

对每个测试：
- 记录输入值
- 记录系统响应
- 截图/抓包证据
- 判断是否有异常行为

目标系统：{URL}
认证信息：{Token或Cookie}

Step 3：历史 bug 复现 Agent

查询飞书 Bitable 中的「历史 bug 库」，对当前功能做匹配：

提示词：
从飞书 Bitable {app_token} 表 {table_id} 读取历史 bug 记录。
筛选与当前功能「{功能模块名}」相关的历史 bug。
对每条历史 bug，构造相同场景重新执行，确认是否复现。
输出：复现结果 + 相似度评分。

Step 4：汇总 Agent 合并报告

提示词：
汇总以下四个探索 Agent 的发现，生成统一报告。

发现列表：
{粘贴各 Agent 的输出}

要求：
- 去重（相同 bug 只保留一条）
- 按严重程度分级：P0(崩溃)/P1(功能异常)/P2(体验问题)/P3(边界警告)
- 每个 bug 附上：描述、复现步骤、截图证据、建议修复方向
- 输出 Markdown 格式，便于直接发布

Step 5：推送 + 修复闭环

通过飞书 Bitable API 将报告写入「待修复 bug 表」，定时追踪修复状态。

三、可复制提示词

提示词 A：启动探索任务

请用 OpenClaw 多Agent探索性测试流，对以下系统执行边界发现测试：

系统：{系统名称或URL}
认证：{Token/Cookie}
功能模块：{待测模块}
探索深度：{1-5}
并行数：{3-5}

执行流程：
1. 测试策略 Agent 分析功能，生成探索路径
2. 并行探索 Agent 执行边界测试（数据边界+状态组合+历史复现）
3. 汇总 Agent 生成结构化报告
4. 结果写入飞书 Bitable {app_token} 表 {table_id}

最终输出：Markdown 格式探索报告，包含 bug 清单、严重分级、复现步骤。

提示词 B：追加回归探索（对已有功能）

针对 {功能名} 的修改，进行针对性回归探索：

变更内容：{描述变更点}
变更范围：{影响的功能模块}

探索重点：
1. 变更点本身是否正常
2. 变更是否影响上下游依赖
3. 历史相似功能是否被误伤

使用 browser-automation 对 {目标URL} 执行 {N} 个探索路径。
结果写入飞书 Bitable。

四、使用的 Skills

五、价值与注意事项

核心价值

1. 覆盖率跃升：从"测我知道的"到"测我不知道的"——探索性测试擅长发现需求文档里没写的边界情况
2. 历史传承：每次探索结果入库，下一个项目自动继承"坑库"，同类 bug 不会重复出现
3. 并行提效：4 个探索 Agent 并行，测试时间从"人天"压缩到"分钟级"
4. 主动性：不等待 bug 上报，系统主动找 bug，测试左移

注意事项

1. 不要在生产环境裸探索：首次探索建议在测试环境，发现高危 bug 立即暂停
2. 认证信息脱敏：Token/Cookie 不要硬编码在提示词里，用环境变量或 Secret 管理
3. 探索深度控制：深度 5 的全链路探索可能产生大量无效报告，根据项目阶段选择合适深度
4. 去重与优先级：并行探索必然产生大量发现，汇总 Agent 的去重和分级是关键瓶颈
5. 隐私边界：若被测系统含用户数据，探索时需确保不触发 GDPR/个人信息保护法违规场景

附：飞书 Bitable 表结构参考

探索任务表（tbl_exploration_tasks）

历史 Bug 库（tbl_historical_bugs）

如果你也有"人肉踩坑"的经历，欢迎在评论区分享你发现的最离谱的 bug 🐞