设计理念传统测试用例管理的常见思路是上传需求到平台生成 XMind 或 Excel用例再被下载、导入、复制、维护。即使接入了 AI本质上仍然是把 AI 包装进平台流程里测试用例依旧是孤立的表格资产。Casebook 的设计从一开始就是 AI-native 的工程项目需求文档放在docs/requirements/成为 AI 理解业务的输入。测试设计方法写进.agents/skills/让 AI 知道如何像测试人员一样设计用例。用例结构由schema/test-case-schema.json约束保证 AI 输出稳定可校验。YAML 用例存放在releases/可以被 Git 管理、Code Review、回滚和追踪。评审标记、执行结果和报告数据独立保存不污染用例定义。本地 Web UI 只负责查看、评审、标记、轻量编辑、执行和报告不试图替代 AI Agent 的生成能力。因此Casebook 不是把 AI 当作平台上的一个“生成按钮”而是把 AI Agent 当作测试用例工程的主要生产力。Casebook 下的分工 人负责判断需求是否理解正确、风险是否覆盖充分、用例是否值得执行、失败是否真实有效。 AI Agent 负责生产读取需求和技能包生成、补充、删除、重构 YAML 用例。 Schema 负责约束保证用例结构稳定降低 AI 输出漂移。 Git 负责协作让用例变成可审查、可追踪、可回滚的工程资产。 Casebook 负责工作台浏览、筛选、标记、轻量编辑、执行统计和报告生成。完整工作流程Casebook 推荐的流程是一个闭环docs/requirements/ 需求文档 .agents/skills/ 测试设计技能包 schema/test-case-schema.json 格式约束 - AI Agent 理解需求并生成 YAML 用例 - releases/需求或版本目录/功能.yaml - casebook export 需求或版本目录 - 可分发的静态 HTML 评审/冒烟用例包 - casebook serve 需求或版本目录 - 本地浏览、评审、标记、轻量编辑、执行 - .casebook/marks.json test-runs/run-id.json - casebook report run-file - HTML 测试报告这也是 Casebook 和一般AI测试用例平台最大的区别对比维度一般 AI 测试用例平台Casebook中心测试管理平台Git 仓库 AI AgentAI 角色生成用例文本的接口理解需求、维护用例、重构资产的生产者用例资产平台数据库记录YAML 文件需求资产平台字段、附件、富文本docs/requirements/中的 Markdown/文档约束方式平台表单和后端校验schema/test-case-schema.json协作方式平台流程Git diff / PR / Code Review人的工作填表、编辑、维护状态Review、判断、执行、验收去掉 AI 后平台仍完整运行Casebook 仍能浏览/执行但用例生产和持续维护能力大幅下降传统平台本质上是“人填数据AI 辅助生成”。Casebook 本质上是“AI 维护工程资产人做质量判断”。安装在本仓库中安装pip install casebook安装后可以使用casebook --help Usage: casebook [OPTIONS] COMMAND [ARGS]... Render, review, and edit YAML test cases locally. ╭─ Options ───────────────────────────────────────────────────────────────────────────────────╮ │ --version Show the Casebook version and exit. │ │ --help Show this message and exit. │ ╰─────────────────────────────────────────────────────────────────────────────────────────────╯ ╭─ Commands ──────────────────────────────────────────────────────────────────────────────────╮ │ serve Start the local Casebook web UI. │ │ init Create a new Casebook test case project. │ │ export Export YAML test cases to a standalone review HTML file. │ │ report Generate an HTML test report from a test run JSON file. │ │ renumber Renumber test case IDs in one YAML file. │ ╰─────────────────────────────────────────────────────────────────────────────────────────────╯Casebook 使用旅程下面用一个从需求到报告的完整闭环快速跑通 Casebook。1. 创建用例工程先创建一个新的 Casebook 项目casebook init my-casebook cd my-casebook初始化后你会得到一套标准工程结构my-casebook/ AGENTS.md .agents/skills/casebook-test-cases/SKILL.md docs/requirements/login.md releases/example/login.yaml schema/test-case-schema.json其中docs/requirements/login.md和releases/example/login.yaml是一组配套示例可以直接用来体验完整流程。2. 启动本地工作台如果使用初始化自带示例可以运行casebook serve releases/example默认地址http://127.0.0.1:80893. 评审和轻量编辑用例在本地工作台中你可以按文件浏览 YAML 用例。按优先级、Mark 状态和关键词筛选用例。展开用例查看前置条件、步骤和预期结果。使用 Mark 标记需要关注或后续调整的用例。对已有用例做轻量编辑并保存回 YAML 文件。评审插入或删除用例后使用ID 更新按当前 YAML 顺序重排用例 ID。如果评审后需要新增、删除、拆分或重构用例推荐继续交给 AI Agent 修改 YAML而不是在页面中逐条维护。ID 更新只适合评审阶段选择测试计划后会禁用避免执行结果和用例 ID 错位。4. 导出静态 HTML 用例包如果评审场景无法使用自己的电脑或者需要把冒烟用例发给开发可以将 YAML 用例导出为一个可离线打开的 HTMLcasebook export releases/example默认目录会聚合为一个 HTML例如releases/example - casebook-example.html也可以导出单个 YAML或指定输出文件casebook export releases/example/login.yaml casebook export releases/example --output login-review.html导出的 HTML 是评审视图支持搜索、筛选、展开/收起并内置Needs update标记和备注。标记和备注保存在浏览器本地也可以通过Export review notes下载为 JSON。可以按标签或优先级导出部分用例casebook export releases/example --tag smoke casebook export releases/example --priority P05. 创建测试计划并执行用例测试计划默认折叠不影响用例评审。进入执行阶段后可以展开顶部测试计划面板创建或选择测试计划。为每条用例选择Passed、Failed或Blocked。记录执行备注和 JIRA 缺陷链接。查看执行进度条和统计数据。点击Complete plan完成测试计划并写入测试环境和测试人员。执行数据会保存到test-runs/run-id.json这些数据不会写入 YAML 用例文件而是作为后续生成测试报告的依据。6. 生成 HTML 测试报告执行完成后使用测试计划 JSON 生成报告casebook report test-runs/run-20260625093000-login-smoke.json --output reports/login-smoke.html将命令中的 run 文件名替换成你本地test-runs/目录下实际生成的文件。报告包含测试计划基本信息。执行概览和通过率统计。ECharts 图表。失败用例列表包含执行备注和缺陷链接。阻塞用例列表包含执行备注和缺陷链接。到这里一个从需求、AI 生成用例、本地评审、用例执行到 HTML 测试报告的 Casebook 闭环就完成了。使用 AI Agent 生成用例Casebook 的推荐方式不是在页面里点击“生成用例”而是在项目工程里让 AI Agent 直接读取需求、技能包、schema 和已有 YAML 文件然后写入releases/目录。这样做有几个好处AI 能同时理解需求、历史用例和项目规范。用例变更可以被 Git 追踪、审查和回滚。新增、删除、拆分、合并、重构用例可以一次性完成不需要人在页面里逐条维护。schema/test-case-schema.json可以约束 AI 输出减少格式漂移。AI 需要读取哪些文件每次让 AI Agent 生成或维护用例时建议明确让它读取这些文件文件作用AGENTS.md告诉 AI 当前项目如何工作以及应该引用哪个技能包.agents/skills/casebook-test-cases/SKILL.md告诉 AI 如何理解需求、设计用例、写得像测试人员schema/test-case-schema.json约束 YAML 用例结构确保输出可被 Casebook 读取docs/requirements/需求、接口、业务规则和验收标准releases/已有 YAML 用例也是 AI 写入和维护的目标目录生成用例新需求第一次生成用例时可以直接把下面这段提示词给 AI Agent请阅读以下文件 - AGENTS.md - .agents/skills/casebook-test-cases/SKILL.md - schema/test-case-schema.json - docs/requirements/login.md 请根据需求生成 YAML 测试用例写入 releases/v1-auth/login.yaml 要求 - 严格符合 schema/test-case-schema.json。 - 用例要覆盖正常场景、异常场景、边界条件、权限/状态相关场景。 - 优先级使用 P0/P1/P2。 - 用例标题要像测试人员写的不要像需求标题。 - 步骤和预期结果要具体可执行、可评审。 - 如果需求信息不足请在生成前指出缺失信息并基于合理假设继续生成。生成完成后启动当前需求目录进行评审casebook serve releases/v1-auth生成后的检查清单AI Agent 完成修改后建议做一次检查YAML 文件是否在releases/需求或版本目录/下。是否符合schema/test-case-schema.json。是否覆盖正常场景、异常场景、边界条件和关键业务规则。用例标题是否清晰步骤是否可执行预期结果是否可验证。是否存在重复用例、空泛用例或与需求无关的用例。是否可以通过casebook serve 目录在本地工作台正常浏览。Casebook 的核心思路是AI Agent 负责生成和维护 YAML人负责评审、判断和执行。这样测试用例不再是散落在平台里的表格而是可被 AI 理解、可被 schema 校验、可被 Git 管理的工程资产。用例 ID 重排用例评审阶段经常会删除、插入或调整用例。Casebook 推荐保持 YAML 中的用例顺序不变只按当前文件顺序重新整理用例 ID。重排范围是当前 YAML 文件不会跨文件处理。重排规则是以第一条用例 ID 为起点例如第一条是TC_LOGIN_018后续用例会依次变成TC_LOGIN_019、TC_LOGIN_020。命令行重排casebook renumber releases/example/login.yaml本地工作台重排打开某个 YAML 文件。确认当前没有选择测试计划。点击用例列表上方的ID 更新。测试计划模式下不支持 ID 重排。测试计划的执行结果以文件路径#用例ID记录重排会导致执行结果和用例错位因此页面会在选择测试计划后禁用ID 更新。重排时当前文件里的 Mark 标记会按旧 ID 到新 ID 自动迁移避免评审标记丢失。静态 HTML 用例导出casebook serve适合本机评审和执行但会议室电脑、开发冒烟用例交付、离线分享等场景更适合直接打开一个静态 HTML 文件。导出整个需求或版本目录casebook export releases/v1-auth目录会默认聚合为一个 HTML 文件命名规则类似releases/v1-auth - casebook-v1-auth.html导出单个 YAML 文件casebook export releases/v1-auth/login.yaml单个 YAML 默认输出同名 HTMLreleases/v1-auth/login.yaml - releases/v1-auth/login.html指定输出位置casebook export releases/v1-auth --output login-review.html