OpenClaw 装好了，然后呢？我用它跑了一次完整测试分析流程

很多人装好 OpenClaw 后，会遇到一个很现实的问题：

工具是装好了，Dashboard 也能打开了，然后到底怎么用？

如果只是拿它随便聊几句，比如：

• 帮我总结一下；
• 帮我写一段话；
• 帮我生成几个测试用例；

那 OpenClaw 的价值其实没有完全发挥出来。

真正值得探索的是：

能不能把 OpenClaw 放进测试工程师的真实工作流里，让它帮我们完成一段完整的测试分析过程？

这次我就用一个具体需求，带着 OpenClaw 跑了一遍：

输入 PRD
→ 生成需求评审问题
→ 转成测试点
→ 收敛测试范围
→ 筛选可入库用例
→ 生成正式用例初稿
→ 再做用例自检

跑完之后，我的感受是：

OpenClaw 不适合被当成“一句话生成最终用例”的工具，更适合被当成测试分析过程中的助理。

它能帮你发散，也能帮你收敛；
能帮你生成初稿，也能帮你自检问题；
但最后哪些内容能入库，仍然要靠测试工程师判断。

---

一、先确认 OpenClaw 已经可用

我本地已经完成 OpenClaw 安装，并检查了基本状态。

关键状态如下：

项目	状态
OpenClaw 版本	2026.5.22
Gateway	running
Dashboard	本地可访问
默认模型	已配置
Skills	有可用 Skill
Channel	Feishu 已配置，但本轮不用真实群聊
使用方式	先通过本地 Dashboard 跑测试工作流

这里有一个经验：

刚装好 OpenClaw，不要急着接真实群、自动发消息、写入外部系统。

第一轮最好走低风险路线：

Dashboard 本地会话
→ 手工输入需求
→ 生成分析结果
→ 人工判断输出质量

先让它在本地稳定跑通一个测试工作流，再考虑 Channel、Skill、定时任务和外部工具。

---

二、这次选择的测试场景：需求评审准备

我没有一上来让 OpenClaw 直接生成测试用例，而是先让它做一件更适合测试前置的事：

根据 PRD 生成需求评审问题。

原因很简单。

很多测试问题不是执行阶段才出现的，而是在需求评审阶段就已经埋下了。

如果需求里边界、状态、权限、导出、多端影响没说清楚，后面生成再多测试用例，也可能是建立在不确定规则上的。

所以第一步，我给 OpenClaw 的任务不是：

请生成测试用例。

而是：

请从测试工程师视角审查需求，生成需求评审问题。

---

三、输入的示例 PRD

我使用了一个中性示例需求：

PRD：报销审批规则优化

1. 普通员工可提交本人报销申请。
2. 报销金额 ≤ 5000 元时，仅直属上级审批。
3. 5000 元 < 报销金额 ≤ 20000 元时，需部门负责人审批。
4. 报销金额 > 20000 元时，需财务复审。
5. 提交后申请状态变为“审批中”。
6. 审批中可撤回，撤回后状态回到“草稿”。
7. 任一节点驳回后，状态变为“已驳回”，申请人可修改后重新提交。
8. 是否支持批量导入报销单，待产品确认。
9. 本次改动影响 PC 端、H5 端和报销数据导出。

这段 PRD 看起来不复杂，但里面其实包含很多测试风险：

• 金额边界；
• 审批人路由；
• 状态流转；
• 驳回重提；
• 批量导入待确认；
• 多端影响；
• 导出影响。

很适合用来验证 OpenClaw 的测试分析能力。

---

四、第一轮：让 OpenClaw 生成需求评审问题

我输入的核心提示词是：

你是我的测试助理，主要帮助我做需求评审准备。

请从测试工程师视角审查下面的需求，生成需求评审问题。

要求：
1. 不要替我回答问题；
2. 不要编造需求中没有的规则；
3. 只提出会影响测试范围、测试用例设计、上线风险的问题；
4. 按维度分类输出；
5. 每个问题说明“为什么要确认”和“不确认的风险”；
6. 最后把问题分为：必须确认、建议确认、可测试发现。

OpenClaw 输出了一份比较完整的问题清单。

它覆盖了：

维度	示例问题
金额边界	5000、20000 边界归属
审批路由	直属上级、部门负责人、财务复审如何确定
状态流转	撤回、驳回、重提如何处理
并发异常	审批与撤回同时发生时以谁为准
数据导出	导出字段、格式、权限是否变化
历史数据	历史已审批单据是否受影响
端一致性	PC 和 H5 是否规则一致
待确认项	批量导入是否纳入本期

这一步输出的质量是合格的。

它没有直接生成用例，而是站在测试评审视角帮我找问题。

这很重要。

因为测试工作不是从写用例开始，而是从问清需求开始。

---

五、第二轮：把评审问题转成测试点

接下来，我让 OpenClaw 基于评审问题生成测试点清单。

提示词大致是：

请基于上面输出的需求评审问题，帮我整理成测试点清单。

要求：
1. 不要生成测试用例；
2. 只生成测试点；
3. 测试点要能直接指导后续用例设计；
4. 按测试维度分类；
5. 标注优先级 P0/P1/P2；
6. 每个测试点说明来源于哪个评审问题编号；
7. 对未确认的问题，标记为“待确认后补充用例”。

这一步 OpenClaw 输出了 43 个测试点。

包括：

分类	示例测试点
金额边界	5000、5001、20000、20001
审批路由	上级缺岗、部门负责人多人、财务复审位置
状态流转	提交、撤回、驳回、重提、链路重算
并发异常	审批与撤回并发
数据导出	审批状态、当前审批节点、导出字段
数据兼容	历史已审批、审批中单据
端一致性	PC / H5 规则、操作、状态一致
功能范围	批量导入是否本期支持

这一步的价值很明显：

OpenClaw 很适合做测试分析的“发散器”。

它能从一段 PRD 中快速扩展出大量潜在测试点，尤其适合在需求评审后做测试分析初稿。

但这里也出现了第一个问题：

它会默认部分规则已经确认。

比如它把“5000 / 20000 边界归属”“PC 和 H5 是否完整支持”“批量导入本期是否支持”等内容当成了已确认结果。

这提醒我们：

AI 输出测试点后，测试工程师必须检查哪些是 PRD 明确写的，哪些只是 AI 假设的。

---

六、第三轮：把 43 个测试点做范围收敛

43 个测试点很完整，但直接全部转用例会很重。

所以我继续让 OpenClaw 做测试点收敛。

提示词是：

请基于上面的 43 个测试点，帮我做测试点收敛。

要求：
1. 不要生成测试用例；
2. 把测试点分成三类：
   - 核心必测：本期必须覆盖，进入正式用例；
   - 扩展风险：排期允许时覆盖，或作为探索测试；
   - 待确认储备：产品确认后再转用例；
3. 对重复或相近测试点进行合并；
4. 控制核心必测在 10～15 条以内；
5. 每条测试点说明保留原因。

OpenClaw 最终把测试点收敛为：

分类	数量
核心必测	10
扩展风险	7
待确认储备	12

这一步很有价值。

因为真实测试工作里，问题不是“能不能想到测试点”，而是：

想到很多测试点以后，怎么判断哪些本期必须测，哪些可以作为扩展风险，哪些要先等产品确认？

OpenClaw 在这一步已经不只是“生成内容”，而是在辅助做测试范围管理。

不过问题也随之出现：

它把“业务上重要”的测试点都放进核心必测，但核心必测不等于可以直接生成正式用例。

比如：

• 审批人缺岗；
• 财务复审是终审还是中间环节；
• 审批与撤回并发；
• 历史数据兼容；
• 当前审批节点字段取值。

这些确实重要，但 PRD 没有明确规则。

如果直接生成正式用例，就会把未确认规则写成确定预期。

---

七、第四轮：筛选哪些测试点能直接入库

为了避免把未确认内容写成正式用例，我又让 OpenClaw 做了一次“可入库用例筛选”。

提示词是：

请基于上面的收敛结果，进一步筛选“可直接生成正式用例”的测试点。

要求：
1. 不要生成测试用例；
2. 判断每个核心必测测试点是否具备明确规则；
3. 如果规则不明确，不允许进入正式用例，只能进入“核心待确认”；
4. 将测试点分成：
   - 核心已确认：规则明确，可直接生成正式用例；
   - 核心待确认：业务重要，但规则未确认，需评审确认后再生成用例；
   - 扩展风险：排期允许时覆盖，或作为探索测试。

OpenClaw 输出了一个很严格的判断：

分类	数量
核心已确认	1
核心待确认	9
扩展风险	7

它认为当前 PRD 里只有“提交 → 审批中 → 撤回 → 草稿”这条基础状态流转足够明确。

这一步非常有意思。

因为它说明 OpenClaw 已经开始关注：

这条测试点能不能写成可验证预期？

但它也筛得过严。

比如金额规则其实 PRD 已经写清楚了：

金额 ≤ 5000：直属上级审批
5000 < 金额 ≤ 20000：部门负责人审批
金额 > 20000：财务复审

所以 5000 和 20000 的边界归属是明确的。

这时候就需要测试工程师人工纠偏。

我对分类进行了修正：

类型	处理
金额分档和边界	PRD 已明确，可以生成正式用例
提交、撤回、驳回、重提	PRD 已明确基础状态，可以生成正式用例
PC / H5 范围	PRD 已明确影响范围，可以生成基础双端用例
导出	PRD 只写受影响，可以做基础导出回归，但字段细节待确认
财务复审是否终审	未明确，不能写终态用例
历史数据兼容	未明确，先作为待确认
并发冲突	未明确，先作为待确认
缺岗流转	未明确，先作为待确认

这一步是整个流程里最关键的一步。

OpenClaw 可以帮你筛选，但测试工程师要判断它是过度乐观还是过度保守。

---

八、第五轮：基于人工修正结果生成正式用例

接下来，我让 OpenClaw 只基于“核心已确认测试点”生成正式用例。

要求非常明确：

1. 只基于“核心已确认测试点”生成正式测试用例；
2. 不要为待确认问题生成确定性用例；
3. 待确认问题单独输出为清单；
4. 用例步骤必须可执行；
5. 预期结果必须可验证；
6. 不允许补充 PRD 中没有的规则。

OpenClaw 生成的用例覆盖了：

模块	示例用例
金额分档	3000、5000、8000、20000、25000
金额边界	5001、20001
状态流转	提交后审批中
状态流转	审批中撤回后草稿
状态流转	驳回后已驳回
状态流转	已驳回修改后重新提交
PC / H5	两端基础提交流程、撤回、重提
导出	导出基础回归

这一版已经比“一句话生成测试用例”靠谱很多。

因为它经历了前面的分析过程。

但它仍然不是最终版本。

---

九、第六轮：让 OpenClaw 对自己生成的用例做自检

生成用例后，我没有直接拿来入库，而是让 OpenClaw 自检。

提示词是：

请对刚才生成的正式测试用例做一次自检。

检查要求：
1. 是否把待确认问题写成了确定性用例；
2. 是否存在 PRD 中没有明确说明的预期；
3. 是否有“流程结束”“终审”“字段取值”等未确认结论；
4. 是否有 PC/H5 重复用例过多的问题；
5. 是否有预期结果不可验证的问题；
6. 是否遗漏待确认问题清单。

这一步非常有价值。

OpenClaw 自己发现了几个问题：

问题	说明
审批通过后“流程结束”不可验证	PRD 没有定义终态
财务复审是否终审未确认	不能写“复审通过后流程结束”
部门负责人是否唯一节点未确认	不能假设完整链路
导出“核心字段”未定义	不能写模糊预期
PC/H5 用例重复过多	需要合并收敛
待确认问题遗漏	审批链路是否逐级累加未确认

这说明 OpenClaw 的另一个价值是：

不只帮你生成内容，还可以帮你反向检查内容质量。

但同样，测试工程师仍然需要判断自检结果是否合理。

---

十、最后得到的用例处理方式

经过自检后，正式用例可以分成三类。

1. 可以保留的正式用例

方向	示例
金额分档	3000、5000、8000、20000、25000
金额边界	5001、20001
状态流转	提交后审批中
状态流转	审批中撤回后草稿
状态流转	驳回后已驳回
状态流转	已驳回修改后重新提交
PC / H5	两端基础流程
导出	基础导出可用性

2. 需要修改的用例

用例方向	修改建议
8000 / 20000 审批链路	只写“包含部门负责人节点”，不要假设完整链路
25000 审批链路	只写“包含财务复审节点”，不要假设复审是终审
PC / H5 重复流程	合并成 PC 基础流程、H5 基础流程
导出用例	明确已知字段，不要写“核心字段”等模糊词

3. 暂不作为正式用例

方向	原因
审批通过后流程结束	终态未定义
财务复审通过后流程结束	财务复审是否终审未确认
缺岗流转	缺岗规则未确认
并发冲突	冲突策略未确认
历史数据兼容	兼容策略未确认
当前审批节点字段取值	字段语义未确认

这才是一份更接近真实可入库的结果。

---

十一、这次实操带来的几个结论

结论一：OpenClaw 很适合做“测试分析助理”

它不是只会生成用例。

这次它完整参与了：

需求评审问题生成
→ 测试点生成
→ 测试范围收敛
→ 可入库筛选
→ 用例生成
→ 用例自检

这比单纯让 AI 写一张用例表有价值得多。

---

结论二：OpenClaw 能发散，也能收敛

第一次它从 PRD 里发散出大量问题。
第二次它把问题转成 43 个测试点。
第三次它把 43 个测试点收敛成核心必测、扩展风险和待确认储备。

这对测试工程师很有帮助。

因为测试设计不只是“想得多”，还要“收得住”。

---

结论三：OpenClaw 会犯两类典型错误

第一类是 默认假设已确认。

比如把未确认的端一致性、字段取值、导出内容，当成已确认规则。

第二类是 为了闭环自动补预期。

比如写出：

流程结束
无更多待审批节点
财务复审通过后流程结束

这些看起来合理，但 PRD 没写，就不能直接入库。

---

结论四：测试工程师必须做最后判断

OpenClaw 可以帮你生成：

• 问题；
• 测试点；
• 用例；
• 自检结论。

但最终要靠测试工程师判断：

• 哪些规则已经明确；
• 哪些问题必须评审确认；
• 哪些用例能入库；
• 哪些预期不可验证；
• 哪些内容只是 AI 的合理猜测。

这不是 OpenClaw 的缺点，而是 AI 测试工作流必须保留的人为把关。

---

十二、我建议的 OpenClaw 测试工作流

经过这次实操，我更推荐这样用 OpenClaw：

第一步：输入 PRD，生成需求评审问题
第二步：把评审问题转成测试点
第三步：把测试点分成核心必测、扩展风险、待确认储备
第四步：筛选哪些测试点规则明确，可以生成正式用例
第五步：只基于规则明确的测试点生成用例
第六步：让 OpenClaw 对用例做自检
第七步：测试工程师人工评审后再入库

这个流程比“直接生成测试用例”更稳。

核心原因是：

它把测试设计拆成了多个可检查的中间过程。

每一步都能发现问题，每一步都能人工纠偏。

---

十三、可以复用的 Prompt

1. 生成需求评审问题

请从测试工程师视角审查以下需求，生成需求评审问题。

要求：
1. 不要替我回答问题；
2. 不要编造需求中没有的规则；
3. 只提出会影响测试范围、测试用例设计、上线风险的问题；
4. 按维度分类输出；
5. 每个问题说明“为什么要确认”和“不确认的风险”；
6. 最后把问题分为：必须确认、建议确认、可测试发现。

2. 生成测试点

请基于上面输出的需求评审问题，整理成测试点清单。

要求：
1. 不要生成测试用例；
2. 只生成测试点；
3. 按测试维度分类；
4. 标注优先级 P0/P1/P2；
5. 每个测试点说明来源问题编号；
6. 对未确认的问题，标记为“待确认后补充用例”。

3. 测试点收敛

请基于上面的测试点，做测试点收敛。

要求：
1. 把测试点分成三类：
   - 核心必测；
   - 扩展风险；
   - 待确认储备；
2. 对重复或相近测试点进行合并；
3. 控制核心必测在 10～15 条以内；
4. 每条测试点说明保留原因。

4. 筛选可入库用例

请基于上面的收敛结果，进一步筛选“可直接生成正式用例”的测试点。

要求：
1. 判断每个核心必测测试点是否具备明确规则；
2. 如果规则不明确，不允许进入正式用例；
3. 将测试点分成：
   - 核心已确认；
   - 核心待确认；
   - 扩展风险。

5. 生成正式用例

请只基于“核心已确认”测试点生成正式测试用例。

要求：
1. 不要为待确认问题生成确定性用例；
2. 待确认问题单独输出；
3. 用例步骤必须可执行；
4. 预期结果必须可验证；
5. 不允许补充 PRD 中没有的规则。

6. 用例自检

请对刚才生成的正式测试用例做一次自检。

检查要求：
1. 是否把待确认问题写成了确定性用例；
2. 是否存在 PRD 中没有明确说明的预期；
3. 是否有“流程结束”“终审”“字段取值”等未确认结论；
4. 是否有 PC/H5 重复用例过多的问题；
5. 是否有预期结果不可验证的问题；
6. 是否遗漏待确认问题清单。

---

十四、小结

OpenClaw 装好之后，不要急着接群，也不要急着让它自动执行复杂动作。

更稳的第一步，是让它进入一个低风险、高频的测试工作流。

这次我用它跑了一次完整测试分析流程，最终发现：

OpenClaw 的价值不是替我直接生成最终用例，而是帮我把测试分析过程拆开、加速和结构化。

它能帮我：

• 从 PRD 里挖出需求评审问题；
• 把问题转成测试点；
• 把测试点收敛成核心范围；
• 筛选哪些规则明确、哪些需要确认；
• 生成用例初稿；
• 再反向自检用例质量。

但它不能替代测试工程师做最终判断。

尤其是这些地方，必须人工把关：

• 是否编造了 PRD 没有的规则；
• 是否把待确认项写成确定用例；
• 是否自动补了“流程结束”“终审”等未确认预期；
• 是否把重要但未明确的规则直接写进正式用例；
• 是否有重复用例、模糊预期和不可验证结果。

所以，对测试工程师来说，OpenClaw 最合适的定位不是“自动测试设计师”，而是：

测试分析助理。

它负责加速发散和整理。
测试工程师负责判断、收敛和把关。

---

写在最后

这次实操让我更明确一件事：

AI 工具真正进入测试工作，不是靠一句“帮我生成测试用例”。

而是要把测试思考过程拆成多个步骤：

先问问题
再拆测试点
再收敛范围
再筛选入库
再生成用例
最后做自检

每一步都让 AI 参与，但每一步都保留人工判断。

这才是比较稳的 AI 测试工作流。

OpenClaw 装好了只是开始。

真正让它有价值的，是把它放进你的日常测试流程里，让它成为一个能持续辅助你分析需求、设计测试、发现风险的测试助理。