我把 OpenClaw 从聊天工具改造成测试工作流助理：一次完整实操复盘

最近看到 OpenAI 的一篇文章，里面讲到他们如何在“智能体优先”的工程模式下使用 Codex。文章里有一个很有意思的点：他们不是只让 Agent 随便回答问题，而是围绕代码仓库、AGENTS.md、工具链、CI、文档、反馈回路等内容，给 Agent 搭建了一套可以持续工作的工程环境。

这给了我一个启发：

对测试工程师来说，OpenClaw 也不应该只是一个聊天工具。
真正有价值的用法，是把它放进测试工作流里，让它稳定完成需求评审、测试点设计、用例生成和自检。

所以这次我没有停留在“让 OpenClaw 生成几条测试用例”，而是完整走了一遍：

创建测试工作区
→ 编写 AGENTS.md
→ 建 Prompt 库
→ 输入 PRD
→ 生成需求评审问题
→ 收敛评审问题
→ 生成测试点
→ 人工纠偏
→ 测试点收敛
→ 可入库用例筛选
→ 正式用例生成
→ 用例自检
→ 输出最终修正版用例
→ 拆分成 3 个 Skill 草案

跑完之后，我最大的感受是：

OpenClaw 的价值不是“一次性生成最终用例”，而是帮助测试工程师完成一套可控、可检查、可沉淀的测试分析流程。

---

一、为什么不直接让 OpenClaw 生成测试用例？

很多人用 AI 做测试，第一句话就是：

帮我根据这个需求生成测试用例。

这个方式能用，但风险也很明显。

因为需求里经常会有很多没写清楚的地方，比如：

• 审批通过后的终态是什么？
• 财务复审是不是终审？
• 导出字段到底有哪些？
• PC 和 H5 是否完全一致？
• 批量导入是否本期支持？
• 驳回后重提是从头审批，还是从驳回节点继续？
• 在途数据上线后走新规则还是旧规则？

如果这些问题没有确认，AI 直接生成测试用例，就很容易把“待确认内容”写成“确定预期”。

比如它可能会写：

财务复审通过后，流程结束。

看起来很合理，但 PRD 没写，就是不应该进入正式用例。

所以我这次给 OpenClaw 设定的原则是：

先问问题，再拆测试点，最后才生成用例。

---

二、第一步：给 OpenClaw 建一个测试工作区

我先在本地建了一个实验目录：

mkdir -p ~/openclaw-sqa-lab/{prompts,rules,templates,examples,outputs,skills}
cd ~/openclaw-sqa-lab

目录结构如下：

openclaw-sqa-lab/
├── AGENTS.md
├── prompts/
├── rules/
├── templates/
├── examples/
├── outputs/
└── skills/

每个目录的作用很清楚：

目录	用途
AGENTS.md	测试助理工作说明
prompts/	固定 Prompt
rules/	测试规则
templates/	输出模板
examples/	示例需求
outputs/	OpenClaw 每一步输出
skills/	后续 Skill 草案

这一步很重要。

如果 Prompt、规则、案例都散落在聊天记录里，OpenClaw 每次都是从零开始。
只有把这些内容沉淀下来，它才有机会变成稳定的工作流助理。

---

三、第二步：写一份测试助理工作说明

我创建了一个 AGENTS.md，核心内容是告诉 OpenClaw：

• 你是测试助理；
• 你不能替产品确认规则；
• 不明确内容要标记“待确认”；
• 生成正式用例前必须先核对依据；
• 用例生成后必须自检。

核心规则大致如下：

# OpenClaw 测试助理工作说明

你是我的测试助理，主要帮助我完成需求分析、需求评审问题生成、测试点设计、测试用例评审、测试风险识别和测试报告整理。

## 工作原则

1. 不要编造需求中没有的规则。
2. 不明确内容必须标记为“待确认”。
3. 生成正式测试用例前，必须先完成需求依据核对。
4. 测试用例步骤必须可执行，预期结果必须可验证。
5. 不要把“待确认项”写成确定性测试用例。
6. 不要把“流程结束”“终审”“字段取值”等未确认结论写入正式用例。
7. 多端测试不要简单复制粘贴，要先判断是否需要收敛。
8. 涉及写入、发送、删除、修改外部系统等动作，必须先请求用户确认。

这份文件的作用不是写一堆理论，而是给 OpenClaw 一个稳定的工作边界。

我发现，AGENTS.md 最适合做“地图”，而不是百科全书。它告诉 Agent 去哪里找规则、按什么流程工作、什么事情不能做，而不是把所有细节都塞进去。

---

四、第三步：准备 Prompt 库

接下来我把整套测试分析流程拆成 6 个 Prompt：

prompts/
├── 01-requirement-review.md
├── 02-test-point-design.md
├── 03-test-point-scope.md
├── 04-case-eligibility.md
├── 05-formal-case-generation.md
└── 06-case-self-check.md

分别对应：

Prompt	作用
01-requirement-review	生成需求评审问题
02-test-point-design	将评审问题转成测试点
03-test-point-scope	对测试点做收敛
04-case-eligibility	筛选哪些测试点可入库
05-formal-case-generation	只基于已确认规则生成正式用例
06-case-self-check	对生成用例做自检

这样做的好处是：

每一步都可检查，每一步都能纠偏，而不是把所有任务塞进一句“帮我生成测试用例”。

---

五、第四步：准备一个示例 PRD

我使用了一个报销审批规则的示例 PRD：

PRD：报销审批规则优化

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

这个需求看起来简单，但里面其实有很多测试风险：

• 金额边界；
• 审批链路；
• 状态流转；
• 撤回；
• 驳回重提；
• 批量导入待确认；
• 多端影响；
• 导出影响；
• 在途数据兼容。

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

---

六、第五步：先生成需求评审问题

我没有让 OpenClaw 直接写用例，而是先让它做需求评审问题生成。

它输出了 23 个评审问题，覆盖了：

维度	示例问题
业务规则	审批通过后的终态是什么
状态流转	驳回后重提是从头审批还是从驳回节点继续
审批路由	部门负责人如何确定
串并行	多节点审批是串行还是并行
数据兼容	在途单据上线后走新规则还是旧规则
数据导出	导出字段范围和权限如何控制
多端	PC 和 H5 是否存在端差异
待确认功能	批量导入是否纳入本期

这一步的价值很明显：

OpenClaw 能把 PRD 中没有写清楚的规则快速暴露出来。

这比一上来生成测试用例更有价值。

因为很多问题如果不在评审阶段问清楚，后面测试用例写得再多，也可能是建立在错误假设上。

---

七、第六步：评审问题收敛

第一次输出的问题有点多，所以我让 OpenClaw 做了一次收敛：

23 个评审问题
→ 收敛成 19 个问题
→ 核心必须确认 6 个
→ 建议确认 7 个
→ 扩展风险 6 个

这里也发生了第一次人工纠偏。

OpenClaw 一开始把“金额上限”放进核心必须确认。
但我认为当前 PRD 已明确：

金额 > 20000 元时，需财务复审。

所以主流程测试不依赖“是否存在更高金额上限”。
因此我把它降级为建议确认。

同时，OpenClaw 把 5000.00 / 20000.00 金额临界值放到扩展风险，但 PRD 已经通过 ≤、<、> 明确了边界归属，所以我把它重新纳入核心金额边界测试点。

这里体现了一个关键点：

OpenClaw 能帮你分类，但分类是否合理，测试工程师必须把关。

---

八、第七步：生成测试点，再做人工纠偏

之后我让 OpenClaw 基于收敛后的评审问题生成测试点。

它输出了 52 个测试点，覆盖了金额路由、状态流转、权限角色、多端交互、数据导出、兼容回归等维度。

但这里出现了三个典型问题。

问题 1：默认了完整审批链

PRD 只写：

金额 > 20000 元时，需财务复审。

OpenClaw 却一度推断为：

部门负责人 + 财务复审两层

这是一个典型的“合理推断”，但不能作为测试预期。

最终我纠偏为：

金额 >20000 只能验证“包含财务复审节点”，不能假设完整审批链组成。

问题 2：默认了导出字段

PRD 只写：

报销数据导出受影响。

OpenClaw 一度推断导出会包含：

• 审批状态；
• 审批人；
• 审批时间。

但这些字段 PRD 没写，所以不能作为正式预期。

最终我纠偏为：

导出只做基础回归：文件可生成、可打开、记录数量一致。字段明细进入待确认。

问题 3：把审批记录保留当成可测试发现

OpenClaw 认为“驳回后原已通过节点审批记录是否保留可见”可以通过测试观察出来。

但没有产品定义时，测试只能观察现象，不能判断对错。

最终我纠偏为：

审批记录是否保留、谁可见、如何展示，属于产品规则，必须待确认。

---

九、第八步：测试点收敛

经过纠偏后，OpenClaw 把测试点收敛成：

分类	数量
核心已确认	10
核心待确认	14
扩展风险	9
合计	33

核心已确认包括：

• ≤5000 仅直属上级审批；
• 5000<金额≤20000 触发部门负责人审批；
• >20000 包含财务复审节点；
• 提交后状态变为审批中；
• 审批中可撤回，撤回后回到草稿；
• 任一节点驳回后状态变为已驳回；
• 已驳回后可修改并重新提交；
• 普通员工可提交本人报销；
• PC / H5 基础流程回归；
• 导出基础回归。

核心待确认包括：

• 审批通过后的终态；
• 驳回后重提链路；
• 串行还是并行；
• 部门负责人如何确定；
• 财务复审角色定义；
• 在途单据上线切换策略；
• 导出字段清单；
• PC/H5 是否存在端差异；
• 批量导入是否纳入本期。

这一步很关键。

它把测试内容分成了三层：

能直接写用例的
需要评审确认后再写的
排期允许时探索的

这就避免了“重要但不明确”的内容直接进入正式用例。

---

十、第九步：可入库用例筛选

接下来，我让 OpenClaw 做可入库筛选。

它逐条检查核心已确认测试点，并输出结论：

分类	数量
可直接入库	8
可入库但需限制范围	2
核心待确认	14
扩展风险	9

其中两个“需限制范围”的点是 PC 和 H5：

• PC 可以执行已知流程回归，但不能包含审批通过后的终态；
• H5 可以做核心状态流验证，但不要机械复制 PC 全量用例。

它还明确了几个重要限制：

金额 >20000：只验证包含财务复审节点，不假设完整链路。
导出：只验证可用性和数量一致，不校验字段明细。
批量导入：只输出待确认，不生成正式用例。
审批通过终态：待确认，不生成正式用例。

这一步让我觉得 OpenClaw 的价值开始变得稳定：

它不只是生成内容，还能帮助判断哪些内容不能进入正式用例。

---

十一、第十步：生成正式测试用例

基于核心已确认测试点，OpenClaw 生成了正式用例。

第一次生成后，经过自检和修正，最终保留了 15 条正式用例：

维度	用例数量
金额路由-低档	2
金额路由-中档	2
金额路由-高档	1
状态流转-提交	1
状态流转-撤回闭环	1
状态流转-驳回闭环	1
权限-本人提交	1
PC 端回归	3
H5 端回归	1
数据导出	2

例如金额路由用例中：

金额	预期
3000	仅触发直属上级审批
5000	仍触发直属上级审批
10000	触发部门负责人审批
20000	仍触发部门负责人审批
25000	审批链包含财务复审节点

注意，这里对 25000 的预期非常克制：

仅验证财务复审节点存在，不假设其前是否有其他审批节点。

这就是前面纠偏的价值。

---

十二、第十一步：用例自检

正式用例生成后，我没有直接接受，而是让 OpenClaw 自检。

自检发现了 3 个问题：

问题	原因	修正
H5 用例写“状态展示与 PC 端一致”	PRD 未明确两端一致	改为“状态正确展示为审批中、草稿、已驳回”
PC 用例写“页面跳转”	PRD 未定义交互方式	改为“提交后状态展示为审批中”
PC 驳回用例写“查看驳回信息展示”	PRD 未定义驳回信息字段	改为“查看状态是否为已驳回”

这一步很有价值。

因为 OpenClaw 自己发现了前一步输出里的隐含假设。

最终它给出的判定是：

修改后可入库。

这说明一个完整的闭环跑通了：

生成
→ 自检
→ 修正
→ 最终输出

---

十三、最终用例示例

最终用例里，有几条比较有代表性。

示例 1：金额边界

用例编号	用例标题	预期结果
TC-002	≤5000元报销-边界值5000元仍触发直属上级审批	提交成功，状态为审批中；直属上级待办中出现该单；仅直属上级一个审批节点
TC-004	5000<金额≤20000元-边界值20000元触发部门负责人审批	提交成功，状态为审批中；部门负责人待办中出现该单

这里唯一要手工修的小点是标题：

5000~20000元报销

建议改成：

5000<金额≤20000元报销

避免误解 5000 属于中档。

示例 2：高金额审批

用例编号	用例标题	预期结果
TC-005	>20000元报销-审批链包含财务复审节点	提交成功，状态为审批中；财务复审人员待办中存在该报销单；不假设完整审批链

这一条非常关键。

它没有写“部门负责人 + 财务复审”，也没有写“财务复审通过后流程结束”。

示例 3：导出基础回归

用例编号	用例标题	预期结果
TC-014	报销数据导出功能可用性验证	导出成功，文件可下载并正常打开
TC-015	导出记录数量与筛选范围一致性验证	导出文件内记录条数与列表记录总数一致

它没有写审批状态、审批人、审批时间等字段，因为字段清单还未确认。

这就是比较稳的用例生成方式。

---

十四、最后把 Skill 拆成 3 个，而不是 1 个

一开始我想把整个流程做成一个大 Skill：

输入 PRD
→ 评审问题
→ 测试点
→ 收敛
→ 用例
→ 自检

但演练后发现，这个 Skill 太重了。

一次完整流程输出太长，中间还需要人工纠偏，Dashboard 甚至出现过输出截断。

所以最终我把它拆成 3 个 Skill 草案：

sqa-prd-review
sqa-test-design
sqa-test-case-gen

分别对应：

Skill	作用
sqa-prd-review	需求评审问题生成与收敛
sqa-test-design	测试点设计、收敛与可入库筛选
sqa-test-case-gen	正式用例生成、自检与修正

这样拆分有几个好处：

1. 每个 Skill 只做一个阶段；
2. 输出不容易超长截断；
3. 用户可以从任意阶段开始；
4. 人工纠偏节点更清晰；
5. 后续维护成本更低。

这也符合 Agent 工程里的一个经验：

不要把所有规则和流程塞进一个超长说明里。
更好的方式是给 Agent 清晰的阶段、清晰的输入、清晰的输出和清晰的边界。

---

十五、这次实操总结出的 5 条经验

1. OpenClaw 适合做测试工作流助理，不只是聊天工具

如果只拿它聊天，它的价值有限。

把它放进流程里，让它按步骤完成评审、测试点、收敛、筛选、用例、自检，价值会明显提升。

---

2. 不要直接生成用例，要先做需求评审

这次最有价值的不是最终 15 条用例，而是前面发现的 23 个评审问题。

测试设计的前提是需求规则清楚。

---

3. AI 容易用“合理推断”填补 PRD 空白

本次出现过几类典型问题：

AI 推断	问题
>20000 推断为部门负责人 + 财务复审	PRD 没写完整链路
导出受影响推断为新增审批字段	PRD 没写字段清单
H5 状态与 PC 一致	PRD 没写两端一致
页面跳转	PRD 没写 UI 交互方式

这类问题不是模型“不会”，而是它太容易补全。

测试工程师要做的事，就是把“补全”改成“待确认”。

---

4. 用例自检非常必要

如果没有自检，H5 一致性、页面跳转、驳回信息展示这些问题很可能就进入正式用例。

自检不是形式主义，它真的能挡住一部分 AI 幻觉和过度推断。

---

5. Skill 不宜太大，拆成阶段更稳

一开始做一个大 Skill 看起来方便，但实际容易：

• 输出过长；
• 上下文混乱；
• 人工纠偏点不清楚；
• 难以复用某一个子流程。

拆成 3 个 Skill 后更合理：

需求评审
→ 测试设计
→ 用例生成与自检

这更接近真实测试工作的自然阶段。

---

十六、最终结论

这次完整实操让我确认了一点：

OpenClaw 真正适合的定位，不是“自动生成最终测试用例”，而是“测试工作流助理”。

它可以帮助测试工程师完成：

• 需求评审问题生成；
• 评审问题收敛；
• 测试点设计；
• 测试点收敛；
• 可入库用例筛选；
• 正式用例生成；
• 用例自检；
• 修正版输出；
• Skill 化沉淀。

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

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

• 哪些是 PRD 明确的；
• 哪些是 AI 推断的；
• 哪些是待确认的；
• 哪些用例可以入库；
• 哪些预期不可验证；
• 哪些内容应该降级为扩展风险；
• 哪些流程应该拆成 Skill。

所以，我更愿意把这次实践总结成一句话：

AI 工具能提高测试设计效率，但真正决定质量的，是我们能否把测试经验沉淀成可复用的流程、规则和自检机制。

OpenClaw 装好了只是第一步。

把它变成测试工作流助理，才是真正开始发挥价值。