E2E 测试与证据

bpmax-cli 的 E2E 能力用于验证一个 BPMAX 业务流程是否真的能被用户使用。它不只检查接口是否返回成功，还会管理正式测试用例、约束执行顺序、驱动真实页面操作、保存本轮证据，并检查测试报告能否支撑“通过”结论。

它适合 OpenClaw、Codex 等 Agent 执行流程上线验收、配置修改回归、客户演示数据验证和批量业务场景测试。

能解决什么问题

在内部，正式用例管理负责约束执行顺序和报告结论，页面测试能力负责创建页、审批步骤、缓存、模板和批量场景等自动化。Agent 会组合使用这些能力，普通用户无需分别调用。

适合测试哪些场景

• 流程发起、表单填写、复杂选择器和自动回填。
• 金额、地区、品类等条件分支是否进入正确审批路线。
• 审批、驳回、退回修改、重新提交和结束状态。
• 不同角色是否能看到并执行正确操作。
• 列表字段、筛选、详情模块和导航入口是否真实可用。
• 必填、格式、金额范围、库存等正向和负向校验。
• 消息、子流程、数据集更新等流程副作用。
• 配置修改后的完整回归和多条业务样本批量验证。

用户需要提供什么

通常只需要说明：

• 要测试的业务场景或流程名称。
• 要运行的用例；不知道用例编号时可以直接描述业务目标。
• 需要覆盖的角色，例如申请人、部门负责人和财务审批人。
• 符合实际业务逻辑的样本数据和特殊边界。
• 是首次建立测试，还是重新运行已有测试。

Agent 负责查找正式用例、准备本轮执行、选择浏览器工具、管理证据和检查报告。用户不需要了解内部文件名、运行编号或命令参数。

如何开始

根据是否已有正式用例，选择一种说法即可。

还没有测试用例：

请为供应商准入流程建立完整测试，覆盖申请、审批、驳回修改和最终通过。

已有测试用例：

请重新运行采购申请完整测试。

Agent 会自动判断是先建立并评审测试场景，还是直接按已有正式用例执行。用户只需要补充业务数据、测试角色或特殊边界，不需要指定内部执行方式。

首次建立测试场景

没有现成用例时，可以直接描述要验证的业务结果：

请为供应商准入流程建立完整测试，覆盖申请、审批、驳回修改和最终通过。

Agent 应先建立测试草稿，逐步骤写清角色、单一动作、输入和即时预期，再完成评审和检查。草稿通过后才能成为正式用例，不能边写用例边宣布页面测试通过。

测试步骤必须保持清晰粒度：打开页面、填写字段、提交、审批和验证应分别记录，不能聚合成一段模糊描述。编辑已有正式场景时，Agent 还必须先展示测试资产差异，等待确认后再替换。

正式执行如何工作

正式测试开始时，Agent 会创建本轮独立执行记录，并且每次只执行正式用例中的当前步骤。完成一个步骤后立即保存页面证据；当前步骤没有通过时，不能跳到后续步骤。

失败或阻塞后，Agent 会先定位原因，再决定修配置、换身份、补数据、刷新缓存或更新测试资产。诊断动作会与正式测试结果分开，不能被写成用例通过。

整个测试过程

用户只负责描述目标、补充必要业务信息并确认测试范围。用例管理、身份切换、页面操作、证据保存和报告检查由 Agent 完成。

重新运行已有用例

直接对 Agent 说：

请重新运行采购申请完整测试。

“重新运行”本身就是完整重跑指令。Agent 必须自动重新执行正式用例中的全部步骤，使用真实用户身份操作页面，保存本轮的新证据，并在检查报告后给出通过、失败或阻塞结论。旧报告、旧截图和旧通过结果只能用于对照，不能替代本轮执行。

场景示例

创建页与复杂表单

请为武汉研发中心的设备采购测试创建一条 30 万元申请，产品线为泳池机器人。

适合验证人员、项目、预算、城市、组织和子表等复杂控件。Agent 可以生成可复用的真实页面自动化脚本，但生成脚本本身不等于测试通过；必须实际打开页面、确认字段、点击提交并保存证据。

条件分支

请测试采购金额 40 万和 60 万两种情况，确认只有 60 万进入财务总监审批。

两条样本应分别证明不同路线，不能只检查流程图配置或接口返回的下一节点。

多角色审批

请使用申请人、部门负责人和财务审批人三个角色重新运行采购审批测试。

每个角色必须使用自己的真实登录身份。不同角色不能共享登录状态，也不能只用接口中的处理人列表代替页面按钮和权限验证。

驳回与重新提交

请测试部门负责人驳回申请，申请人修改金额后重新提交的完整链路。

需要验证驳回按钮、退回目标、修改权限、重新提交后的审批路线和历史记录。

必填和业务校验

请测试采购数量为空、金额为负数和预算超限时的页面提示。

负向用例必须记录用户看到的提示和阻断结果，不能因为接口拒绝请求就直接认定页面校验正确。

列表、详情和导航

请验证采购申请入口可以打开，列表显示申请人和金额，点击后详情页展示预算明细。

该场景同时覆盖入口可见性、列表字段映射、详情模块和真实数据渲染。

消息和流程副作用

请验证采购申请通过后，审批消息正常发送，并生成对应的采购方案记录。

页面通过只证明用户动作成功。消息、子流程和数据集更新还需要相应的运行态或回读证据，且必须区分页面证据与系统副作用证据。

批量业务样本

请运行采购全周期 DEMO04 到 DEMO20 的批量测试。

Agent 会先检查批量场景计划并维护可恢复的状态清单，支持从失败点继续且避免重复提交。状态清单不能替代每条记录中的真实页面步骤；每个正式步骤仍需按用例执行并保存证据。

首次运行与加速缓存

用户无需额外要求。首次成功运行一个复杂创建页或审批步骤时，Agent 必须自动沉淀可复用模板，不需要等待重复多次。

• 从一次成功执行中生成可复用的步骤模板。
• 缓存流程、表单和步骤的稳定结构，减少重复探测。
• 对允许自动化的审批步骤复用已验证的安全执行方式。
• 为真实创建页生成可复用的浏览器自动化模板。

缓存中的每一步必须带预期检查，例如当前处理人、环节状态、必填字段和可用动作。预期不匹配时必须停止并自动重建缓存，不能继续使用旧的提交数据推进流程。

什么算真实页面证据

浏览器步骤至少证明：

• 使用了正确用户身份。
• URL、项目和流程对象正确。
• 页面上的字段、按钮和提示真实可见。
• 用户实际完成了点击、输入或选择。
• 页面跳转或状态变化符合预期。
• 截图属于本轮且能定位到对应步骤。
• Console 和 Network 没有被忽略的关键错误。

接口查询、配置回读、缓存命中和状态矩阵只能作为辅助证据，不能代替真实页面动作。

问题诊断与正式测试

Agent 可以在正式执行之外进行接口探测、结构检查等诊断，但诊断输出必须与正式结果隔离，不能写成用例通过。

失败后如何继续

请继续本轮测试，并处理当前失败的问题。

Agent 应先区分：

• 客户配置或流程运行态缺陷。
• 业务数据不足或旧样本不再适用。
• 用户身份或权限不正确。
• 页面、环境或网络问题。
• 缓存和模板已经失效。
• 测试资产本身缺少步骤或预期。
• bpmax-cli 自身能力缺陷。

配置问题会回到对应配置 Skill 修复，修复后优先创建新样本回归。确认属于 bpmax-cli 自身问题时，Agent 应自动整理证据、预检内容并提报 issue。

全量重跑与历史证据

当用户说“重新运行”“重新回归”或“全量重跑”时：

• 本轮报告目录、状态和截图必须重新创建。
• 每个通过用例和步骤必须有本轮证据。
• 历史报告只能作为对照。
• 出现 blocked、未执行或跳过时，整体结果必须降级。
• 不能用旧截图、旧状态文件或旧 pass 补齐完整通过结论。

报告验收

最终报告应让读者看清：

• 测试了哪些业务场景和角色。
• 使用了哪些业务数据，为什么符合真实业务逻辑。
• 哪些步骤实际执行、通过、失败或阻塞。
• 每一步对应的页面截图、URL 和证据路径。
• 发现的是配置、数据、权限、环境、缓存、测试资产还是 CLI 问题。
• 当前结论是资产更新、诊断、部分回归还是完整通过。

Agent 必须在交付前检查报告。报告检查未通过时，不能宣告完整测试通过。

高级参考

高级实施人员可以使用 bpmax-cli test-suite --help 和 bpmax-cli e2e --help 查看命令参数；普通用户无需管理这些参数。