Skip to content

[WIP] Add test plans and cases based on code and product design#2

Merged
haochencheng merged 1 commit into
mainfrom
copilot/add-test-plans-and-cases
Mar 23, 2026
Merged

[WIP] Add test plans and cases based on code and product design#2
haochencheng merged 1 commit into
mainfrom
copilot/add-test-plans-and-cases

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Mar 23, 2026

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

The user asked to merge pull request #1 into the main branch of cliff-personal/Spec2Flow. Investigate the repository state and determine the correct action needed to complete the user's request. If direct merge is not possible in your environment, provide the necessary repository updates or guidance within a pull request or documented output to help complete the merge safely.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: 我想让openclaw 根据代码产品设计文档和 代码 设计测试方案,和测试case。然后根据测试case 自动测试 启动服务 在浏览器中模拟点击 测试功能 提交bug 我该怎么做呢

Assistant: 可以,但要拆成两层来做

  1. 让 OpenClaw/代理根据 PRD + 代码,产出测试方案和测试用例
  2. 再让它按测试用例执行自动化测试:启动服务、浏览器点击、记录结果、提交 bug

OpenClaw 官方文档明确支持一个受控浏览器,代理可以打开页面、读取页面、点击和输入;推荐流程是先 status/start,再 snapshot,然后 act(click/type/press),必要时再截图验证。它也支持独立的 openclaw 浏览器配置文件,适合做自动化验证。(docs.openclaw.ai)


你想要的完整目标,其实可以这样落地

A. 先让它“读文档 + 读代码”,生成测试设计

你可以把这些材料给 OpenClaw:

  • 产品设计文档 / PRD
  • 技术设计文档
  • 代码仓库
  • 启动方式
  • 测试环境地址
  • Bug 提交目标(GitHub Issues / Jira / 禅道等)

然后给它一个明确任务提示词,例如:

请基于以下内容为这个项目设计完整测试方案:

输入材料:
1. 产品设计文档:<放文档路径或内容>
2. 技术设计文档:<放文档路径或内容>
3. 代码仓库:<仓库路径>
4. 启动命令:<如 npm install && npm run dev>
5. 测试环境要求:<如本地 3000 端口>

请输出:
1. 测试范围
2. 功能测试点矩阵
3. 冒烟测试清单
4. 回归测试清单
5. 边界/异常测试清单
6. 每条测试用例:
   - 用例ID
   - 模块
   - 前置条件
   - 测试步骤
   - 预期结果
   - 优先级
   - 是否适合自动化
7. 自动化执行建议:
   - 哪些适合浏览器自动化
   - 哪些需要接口测试
   - 哪些需要人工验证

这样它先输出的是测试设计结果,不是直接乱点页面。


B. 再让它“根据测试 case 执行自动化测试”

OpenClaw 的浏览器能力适合做这类事情:

  • 启动浏览器
  • 打开测试地址
  • 读取页面结构
  • 点击按钮、输入表单、切换 tab
  • 截图保存证据

OpenClaw 文档说明它的受控浏览器可执行打开、点击、输入、截图、快照等动作;登录类站点建议你手动在 openclaw 浏览器里登录,不要把账号密码直接交给模型。(docs.openclaw.ai)

你可以给它这样的执行提示词:

请根据已经生成的测试用例,执行自动化冒烟测试。

目标:
1. 启动项目服务
2. 访问 http://localhost:3000
3. 按测试用例逐条执行
4. 对每条用例记录:
   - 实际步骤
   - 实际结果
   - 是否通过
   - 失败截图
   - 控制台报错/页面报错
5. 如发现 bug,生成标准 bug 报告草稿:
   - 标题
   - 复现步骤
   - 预期结果
   - 实际结果
   - 环境信息
   - 严重级别
   - 截图证据
6. 测试结束后输出总结:
   - 总用例数
   - 通过数
   - 失败数
   - 阻塞项

你提到的“自动启动服务 + 浏览器模拟点击 + 提交 bug”,建议按下面架构做

方案 1:OpenClaw 做总控,Playwright 做执行

这是最推荐的。

原因:

  • OpenClaw 很适合做“理解文档、规划测试、协调流程”
  • Playwright 很适合做“稳定的浏览器自动化”
  • bug 提交可以接 GitHub / Jira API

工作流:

  1. OpenClaw 读取 PRD 和代码
  2. 生成测试方案和 case
  3. 生成 Playwright 测试脚本
  4. 执行:
    • 安装依赖
    • 启动服务
    • 等待服务 ready
    • 跑 Playwright
  5. 收集结果:
    • trace
    • screenshot
    • video
    • console log
  6. 若失败,自动生成 bug 内容
  7. 调 GitHub Issue / Jira API 提交

这个方式比单纯让代理“临场点页面”更稳定。


方案 2:OpenClaw 直接控制浏览器逐条执行

这个方式也能做,但更适合:

  • 冒烟测试
  • 探索式测试
  • 页面流程验证
  • 小规模回归

因为浏览器直接操作虽然灵活,但大规模回归的稳定性、可复现性、可维护性通常不如 Playwright/Cypress 这类脚本化方案。OpenClaw 官方也强调浏览器工具是通过快照和动作接口做确定性控制。(docs.openclaw.ai)


“提交 bug” 怎么做

如果你要自动提交 bug,最好定义一个统一模板。OpenClaw 的 issue 指南建议至少包含:

  • 标题
  • 最小复现步骤
  • 预期 vs 实际
  • 影响范围 / 严重度
  • 环境信息
  • 日志 / 截图证据
  • 是否新问题或回归问题
    这些字段很适合直接作为自动提单模板。(docs.openclaw.ai)

你可以让代理输出这样的 bug 草稿:

标题:[登录] 点击“登录”按钮后页面无响应

环境:
- URL: http://localhost:3000/login
- 分支: feature/auth-refactor
- 浏览器: OpenClaw managed Chrome
- 日期: 2026-03-22

复现步骤:
1. 打开登录页
2. 输入正确用户名和密码
3. 点击“登录”

预期结果:
成功跳转到首页

实际结果:
页面停留在当前页,无报错提示

证据:
- 截图:login-submit-failed.png
- 控制台错误:TypeError: Cannot read properties of undefined

然后再把它接到:

  • GitHub Issues API
  • Jira REST API
  • 企业内部缺陷系统

实操上你该怎么开始

第一步:先准备这些输入

你至少要有:

  • PRD / 设计文档
  • 代码仓库
  • 启动命令
  • 测试环境 URL
  • bug 提交目标
  • 登录账号(如果需要,建议手动登录到 openclaw 浏览器)

第二步:让 OpenClaw 先只做“测试设计”

不要一开始就要求它“全自动提 bug”。

先让它输出:

  • 测试范围
  • 测试点
  • 测试 case
  • 自动化优先级

这样你可以先审核一遍,避免生成的 case 很差。


第三步:再让它做“冒烟自动化”

只选最关键 5~10 条用例,比如:

  • 首页打开
  • 登录
  • 新建记录
  • 编辑记录
  • 删除记录
  • 搜索
  • 提交表单

这是最容易跑通的一批。


第四步:最后接入 bug 自动提交

建议先做成“两阶段”:

  1. 自动生成 bug 草稿
  2. 你确认后再提交

因为如果完全自动提交,容易制造很多重复/低质量 bug。


给你一个推荐的标准流程

阶段1:分析
- 读取 PRD
- 读取技术设计文档
- 阅读代码结构
- 输出测试方案

阶段2:设计
- 生成测试点矩阵
- 生成测试 case
- 标记可自动化 case

阶段3:执行
- 安装依赖
- 启动服务
- 打开浏览器
- 按 case 执行点击/输入/提交
- 保存截图和日志

阶段4:判定
- 对比预期结果
- 记录 pass/fail
- 汇总失败原因

阶段5:提单
- 生成 bug 模板
- 附截图、日志、重现步骤
- 提交到 GitHub/Jira

最重要的建议

不要把“测试设计”和“自动执行”混成一句模糊指令。

你应该给 OpenClaw 下达两个独立任务:

任务 1:测试设计

根据 PRD、设计文档和代码,输出测试方案和测试用例。

任务 2:自动执行

根据测试用例启动服务,使用浏览器自动执行冒烟测试,记录失败并生成 bug 草稿。

这样成功率会高很多。


如果你要最短可执行版本,可以直接这样说

你可以直接对 OpenClaw 说:

请完成以下任务:

第一阶段:测试设计
1. 阅读项目的产品设计文档、技术设计文档和代码。
2. 输出测试方案,包括测试范围、风险点、冒烟测试、回归测试、边界测试。
3. 生成结构化测试用例,每条包含:ID、模块、前置条件、步骤、预期结果、优先级、是否可自动化。

第二阶段:自动执行
1. 根据可自动化的冒烟测试用例,安装依赖并启动项目。
2. 等待服务可访问后,打开浏览器访问本地地址。
3. 在浏览器中模拟用户点击、输入、提交等操作执行测试。
4. 对每条测试用例记录实际结果、通过/失败、截图和错误日志。
5. 如果发现缺陷,生成标准 bug 报告草稿。
6. 在我确认后再提交到 GitHub Issues/Jira。

现实中的限制你也要注意

  • 需要登录的网站:建议手动登录,不要把账号密码交给模型。OpenClaw 官方也是这么建议的。(docs.openclaw.ai)
  • 动态页面很复杂时:直接浏览器点击可能不稳定,建议生成 Playwright 脚本
  • 自动提交 bug:建议先“人工确认后提交”...

This pull request was created from Copilot chat.


⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.

@haochencheng haochencheng marked this pull request as ready for review March 23, 2026 01:08
@haochencheng haochencheng merged commit 0c0583e into main Mar 23, 2026
1 check failed
Copilot AI requested a review from haochencheng March 23, 2026 01:08
Copilot stopped work on behalf of haochencheng due to an error March 23, 2026 01:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants