从“能生成“到“生成得对“：用 Claude Code Skill 造一条测试用例生成流水线
一、为什么要写这个 Skill
背景：AI 编程助手很强大，但通用对话写测试用例不够系统。
痛点：
- 每次都要重复描述需求、格式不统一
- 覆盖度靠人工保证
- AI 记不住历史业务规则——每期需求都是孤立分析，上一期的状态机、权限规则、字段约束全部重新推一遍
- AI 会"抄近路"——读到需求标题就开始写用例，叶子节点的搜索条件、业务约束全漏了
- AI 会"基于上一轮输出做翻译"——读 test_output/ 里已有的测试点，而不是从需求源头重新分析，导致错误被一届届继承
- 反馈无法沉淀——用户指出"你漏了验证码场景"，下一期同样的错误还会再犯
目标：让 Claude 按固定方法论 + 固定格式输出测试用例，并且越用越懂这个项目。
成果预览：一个触发词 + 一次对话 = 完整测试用例表格。
二、什么是 Skill
Skill 的本质：给 AI 封装"能力模块"。
与普通 prompt 的区别：结构化、可复用、可约束行为。
Claude Code Skill 本质上是一个包含 SKILL.md 文件的文件夹。这个文件夹可以被 Claude 按需发现和加载，从而赋予 Claude
完成特定任务的专业能力。
它不是可执行的程序代码，而是一种动态的上下文增强机制——当 Claude 判断某个 Skill 与当前任务相关时，会将这个 Skill
的指令注入到对话上下文中，指导 Claude 如何完成任务。
1. 核心结构：SKILL.md 文件
每个 Skill 的核心是一个名为 SKILL.md 的 Markdown 文件。这个文件由两个关键部分组成：
1.1 YAML 前置元数据（Frontmatter）
文件开头用 — 包裹的 YAML 格式元数据，用于 Claude 的发现和匹配：
name: your-skill-name
description: 简要描述该技能的功能以及何时使用
1.2 Markdown 指令正文
元数据之后是正文，用自然语言编写，告诉 Claude 具体怎么做。
▎ 一个容易被忽略的点：description 不只是"简介"，它是触发开关。Claude 靠它判断当前任务该不该加载这个
▎ Skill。所以描述里要同时写清楚"做什么"和"什么时候用"——比如 test-case-design 的 description
▎ 里明确列了"设计用例"“写测试用例”“帮我出用例”"测试点分析"这几个触发词。
2. 文件夹结构
your-skill/
├── SKILL.md # 核心指令文件（必须）
├── references/ # 详细参考文档（按需加载）
├── examples/ # 更多示例
├── templates/ # 模板文件
└── scripts/ # 可执行脚本
3. 存储位置
| 类型 | 路径 | 适用范围 |
|---|---|---|
| 个人 Skills | ~/.claude/skills/ | 当前用户的所有项目 |
| 项目 Skills | .claude/skills/ | 当前代码库，可提交 Git 与团队共享 |
| 插件 Skills | 插件包内的 skills/ 目录 | 安装插件的用户 |
三、整体设计思路
问题 1：如何让 AI 理解功能需求？
将需求文档资料放在 test_input/{版本}/{需求}/prd/ 目录下，让 AI 读取并解析。
因为项目的需求和原型需要汇总处理，我一般会使用 XMind 将需求进行初步整理拆解，所以 XMind 是核心输入文件。为了让 AI
快速读取 XMind，我把读取步骤也封装成了一个 skill：xmind-reader。
但只读 XMind 还不够。真实项目里 prd/ 目录下往往是混合输入：
| 输入类型 | 读取方式 |
|---|---|
| .xmind | xmind-branch-extract.py 按模块关键词切出完整分支，写入临时文件后再读 |
| HTML 原型源码目录 | HTML 是空壳（Next.js 是 CSR），真正内容在 _next/static/chunks/*.js 里以 \uXXXX 逃逸格式存储，必须用 Python 脚本提取中文文本 |
| JSON / Word / Markdown | 直接读取 |
所以第一步的核心原则是：prd 目录下有什么读什么，所有输入源必须全部读取并交叉结合，不是二选一。
问题 2：如何让 AI 记住历史业务规则？
把每期需求里的业务知识提炼出来，沉淀成结构化知识库。
knowledge-base（业务知识库提炼技能）
│
├── 从 test_input/ 当期需求/原型/对话中提炼
└── 写入 .claude/knowledge/
├── business-flow/ 核心业务流程
├── modules/ 页面和功能说明
├── roles/ 角色权限
└── rules/ 业务规则
提炼的粒度是字段级的，比如业务规则要落到这张维度表：
| 字段 | 说明 |
|---|---|
| 规则名称 | 一句话概括，如"岗位状态机规则" |
| 适用场景 | 规则生效的上下文 |
| 规则内容 | 详细的 if/then 描述 |
| 触发条件 | 规则何时触发 |
| 前置条件 | 触发前必须满足的条件 |
| 异常处理 | 不满足条件时的行为 |
| 关联规则 | 与其他规则的关系 |
然后 test-case-design 在第一步会主动读取相关知识库文件，与本期需求交叉，输出三类差异：
- 与知识库一致的内容
- 与知识库冲突的内容（以本期需求为准，并提示用户更新知识库）
- 知识库未覆盖、本期新增的内容
优先级原则是硬约束：本期需求 > 知识库。知识库只是"参考补充"，绝不能因为历史存在某条规则就削弱对本期新需求的覆盖。
知识库带来的实际收益很直观，一些容易被忽略的细节，一旦沉淀，之后任何涉及资源发布的版本都会自动带上这条规则的测试点。
knowledge-base 的职责边界是刻意收紧的：
- 只做提炼和写入
- 不做需求澄清、不写测试点、不写测试用例
- 遇到材料缺失标注"待补充"，不自行脑补
职责边界清晰，两个技能才能各司其职：一个负责"记住业务"，一个负责"用业务出用例"。
问题 3：如何让 AI 应用测试方法？
将测试方法编码为可执行规则：
### 二、测试设计技术（黑盒测试方法）
**1. 等价类划分**
- **有效等价类**：符合需求的输入数据
- **无效等价类**：不符合需求的输入数据
- 应用场景：输入框校验、数据类型验证
**2. 边界值分析**
- 关注输入域的边界：最小值、最大值、空值、极大值
- 典型边界：0、1、最大值、最大值 +1、空字符串、超长字符串
- 应用场景：数值输入、文本长度、时间范围、分页页码
**3. 场景法（流程分析法）**
- **基本流**：用户正常操作流程
- **备选流**：其他合法操作路径
- **异常流**：错误操作或异常条件
- 应用场景：多步骤流程、状态变迁、端到端业务
**4. 状态迁移法**
- 识别业务对象的所有状态
- 定义状态转换条件和触发事件
- 验证合法转换和非法转换
- 应用场景：订单状态、审批流程、任务生命周期
**5. 判定表法**
- 适用于多条件组合的业务规则
- 列出所有条件桩和动作桩
- 生成条件组合并确定预期动作
- 应用场景：权限控制、费用计算、规则引擎
**6. 正交分析法**
- 从全面组合中选取代表性组合
- 减少测试用例数量同时保证覆盖率
- 应用场景：多条件筛选、配置组合测试
问题 4：如何保证覆盖度不是"靠感觉"？
方法是把遗漏过的场景固化成强制覆盖检查项，每轮必须逐项确认：
**强制覆盖检查项**（必须逐项确认）:
- **空状态覆盖**：每个列表、看板、筛选结果、下拉选择器数据源为空时的展示
- **数据联动刷新覆盖**：增删改操作后，相关展示区域是否同步更新
- **边界操作覆盖**：批量操作需覆盖多选、混合状态
- **文件上传覆盖**：除格式、大小外，必须覆盖数量限制（达到上限后继续上传）
- **安全测试覆盖**：XSS 注入、SQL 注入、空格处理，优先级 3 级
- **认证与越权覆盖**：涉及登录、多角色、数据归属的功能点，必须覆盖未登录访问、垂直越权、水平越权（篡改 id）、前端绕过直调接口
问题 5：如何保证输出格式统一？
精确格式模板 + 负向约束：
### 第四步：测试用例模板确认
1. 使用 `excel-reader` 读取 `test-case-design/examples/testcases/` 下的 Excel 格式测试用例模板
2. 分析模板结构，理解每个字段的含义
3. 学习历史编写习惯
**学习要点**:
- 前置条件粒度：数据少时指定具体名称，数据多时概括描述
- 步骤描述粒度：核心/首次操作详细，重复/相似操作概括
- 预期对应关系：步骤数=预期数，一一对应
- 用例命名习惯：自由描述，不体现预期结果
- 优先级划分标准：1 级核心正向/冒烟，2 级重要功能，3 级完整验证，4 级增强探索
第四、五步的策略已完全固化，不再需要用户逐轮确认——但每轮执行时仍要求"完整过一遍"，让规则保持"热加载"状态。
问题 6：如何防止 AI 走捷径？
### ⚠️ 关键防错规则
1. **禁止读已有测试点文件代替需求分析**：`test_output/` 下的测试点和用例文件是
**本轮输出目标**，不是输入。第一步只能读 `test_input/` 下的原始需求文件。
2. **第一步必须输出澄清问题**：在 XMind + 源码 + 其他输入源全部读取完成后，
必须列出至少 3-5 个澄清问题向用户提问。如果没有任何问题，说明需求分析不够深入。
2a. **务必获取全部需求内容**：读取 XMind 等需求文档时，必须完整读取到叶子节点，
禁止仅读取顶层标题或浅层结构后就开始分析。
3. **第二步功能点分解必须输出清单**：必须在对话中列出以页面/二级页为单位的
**功能点清单**（模块 → 页面 → 功能点）。
4. **第三步必须基于功能点清单重新生成测试点**：不能读取或复用 `test_output/`
下的已有测试点文件。必须从需求源头重新分析。
5. **第六步基于详细版转化**：测试用例必须基于测试点转化，覆盖全部测试点
第 1 条和第 4 条针对的是同一个陷阱：循环引用。AI 为了"省事"，会去读上一轮生成的测试点，然后照着翻译一遍——看起来产出了
用例，实际上错误被完整继承，而且再也回不到需求源头。所以必须在规则里明令禁止。
四、Skill 结构设计
1. 元信息：名称、触发条件、适用场景
name: test-case-design
description: >
根据需求描述设计测试用例。综合运用等价类划分、边界值分析、场景法等方法，生成结构化的测试用例文档。当用户提到"设计用
例""写测试用例""帮我出用例""测试点分析"时触发。
2. 角色设定
# 测试用例设计助手
你是一名经验丰富的软件测试工程师，擅长将复杂需求转化为系统化、可执行的测试方案。
3. 核心方法论
3.1 功能点定义：两层拆分
功能点 ≠ 需求点：不是直接复制 XMind 中的需求描述。
功能点定义标准（同时满足）：
| 维度 | 说明 |
|---|---|
| 可观测 | 有明确的输入/输出或状态变化 |
| 可测试 | 可以设计测试用例来验证 |
| 原子性 | 不可再分的最小可测单元 |
| 业务价值 | 对用户有明确的业务意义 |
第一层：识别功能模块类型（按交互模式分类）
| 类型 | 说明 | 示例 |
|---|---|---|
| 数据展示类 | 列表页、详情页、数据看板、主从视图 | 岗位列表、统计看板 |
| 数据操作类 | 表单页（新增/编辑）、批量操作、导入/导出 | 新增岗位、批量删除 |
| 流程类 | 向导/多步骤流程、审批/工作流 | 审批流程 |
| 系统功能类 | 用户账户、权限/角色管理、系统配置 | 角色管理 |
| 特殊功能类 | 文件管理、消息/通知、支付功能 | 文件上传 |
第二层：识别模块内具体功能点
- 列表页：数据展示、分页、查询/筛选、排序、行操作、批量操作、导入导出
- 表单页：输入框校验、下拉选择、日期时间选择、文件上传、提交保存
- 数据看板：指标卡片、图表展示、筛选联动、数据下钻、实时刷新
拆分示例：
运维端 - 岗位标准模块
├── 数据看板（数据展示类）
│ ├── 岗位总数统计
│ └── 各状态岗位数量统计
├── 列表页（数据展示类）
│ ├── 数据展示功能
│ ├── 分页功能
│ ├── 查询/筛选功能
│ ├── 排序功能
│ ├── 行操作功能（查看/编辑/删除等）
│ └── 批量操作功能
└── 表单页（数据操作类）
├── 基础信息填写
└── 工作职能与能力拆解
这一步不产出文件，但必须以清单形式在对话中列出来——它是第三步的输入，也是防止"漏掉一个模块"的唯一保障。
3.2 测试点分析维度
- 功能正确性验证（基础层）：正常流程验证、输入输出验证、界面元素验证
- 业务逻辑深度（核心层）：业务规则验证、状态机完整性、数据一致性、权限控制验证
- 异常与边界（防御层）：异常流程验证、边界值分析、错误恢复能力、兼容性验证
- 集成与端到端（系统层）：端到端流程、数据流完整性、系统集成点
- 用户体验与业务价值（拓展层）：可用性验证、性能体验、业务目标支持
3.3 测试点输出的树形嵌套规则
在原始 XMind 需求上补充测试点（原需求内容不允许修改），保持树形嵌套，只在叶子节点下追加 - 测试点概括节点。
租户信息管理
├── 列表页
│ ├── 数据展示
│ │ └── - 测试点
│ │ ├── 正向：验证列表数据展示完整...
│ │ └── ...
│ ├── 操作项
│ │ ├── 编辑
│ │ │ └── - 测试点
│ │ ├── 管理员管理
│ │ │ └── - 测试点
│ │ ├── 启用/停用
│ │ │ └── - 测试点
│ │ └── 删除
│ │ └── - 测试点
│ └── 搜索
│ └── - 测试点
├── 新增表单
│ └── - 测试点
└── 导入 License
└── - 测试点
配套的颗粒度一致性规则，专治"越往后写得越潦草"：
- 搜索/筛选功能统一覆盖：正向搜索（含极大值）、各筛选项枚举值、多条件组合、
重置、搜索无结果、搜索内容超长、XSS/SQL 注入 - 数据展示统一覆盖：字段完整性、空状态、各字段边界值/极大值展示
- 新增/编辑表单统一覆盖：完整填写保存、必填项为空、各输入字段边界值（合并
为一个用例）、下拉框数据源为空、数字输入框格式校验、XSS/SQL 注入 - 预览/详情页统一覆盖：字段完整性、各字段边界值/极大值展示
- 跨模块禁止衰减：通用页面结构在所有模块中必须保持相同层级深度，
禁止因模块靠后而压缩为平级 bullet - 逐级检查：每完成一个模块后，必须回检该模块与前一个模块的测试点深度是否一致
3.4 常见功能测试点覆盖清单
列表页测试点：
- 数据展示：数据准确性、完整性、空状态处理、格式与样式
- 分页测试：分页控件显示、导航按钮、数据一致性、分页与筛选/排序联动
- 查询/筛选：基础搜索、高级筛选、实时搜索、重置功能
- 排序功能：单列排序、多列排序、排序状态指示器、默认排序规则
- 列表操作：行内操作、批量操作、操作项启用/禁用条件
表单页测试点：
- 输入框校验：必填项、等价类、边界值、数据类型、特殊字符
- 下拉框：选择性和可填性、模糊匹配、二级联动
- 单选/复选框：独选型、多选型
- 时间选择：开始/结束时间关系、时间格式化
- 提交按钮：回车/单击支持、防重复提交、弱网提交、提交后提示、权限校验
- 业务约束：业务规则校验、状态依赖校验
导入导出测试点：
- 导入：正常流程、文件格式支持、文件类型异常、文件内容异常、数据格式异常、业务逻辑异常
- 导出：正常流程、导出范围、导出内容、资源限制
- 模板：模板下载、模板格式、说明 sheet 页
文件上传测试点：
- 文件类型限制、脚本文件拦截、文件内容校验
- 浏览后删除文件、超大文件处理
- 文件命名冲突处理、存储方式验证
4. 工作流程：七步执行顺序
第一步：需求深度分析与澄清 → 输出：需求分析结果 + 澄清问题列表
↓
第二步：功能点分解（两层拆分） → 输出：功能点清单（模块 → 页面 → 功能点）
↓
第三步：测试点分析与输出 → 输出：测试点列表（树形嵌套 Markdown）
↓
第四步：测试用例模板确认 → 策略已固化，直接应用
↓
第五步：测试用例转化策略 → 策略已固化，直接应用
↓
第六步：测试用例输出 → 输出：测试用例（Excel）+ 自检清单
↓
第七步：反馈闭环与调整 → 输出：差异分析 + 调整策略
流程强制性：每一步的输出是下一步的输入，不允许跳过或并行执行。
第一步：需求深度分析与澄清
- 扫描 prd/ 目录下所有文件 + 读取 .claude/knowledge/ 相关知识库文件
- 用 xmind-branch-extract.py 按模块关键词提取 XMind 完整分支（必须读到叶子节点）
- 如有 HTML 原型源码，用 Python 脚本提取 JS chunk 中的中文文本
- 交叉分析后必须提出至少 3-5
个澄清问题，覆盖业务规则、状态机、数据联动、异常处理、集成点、功能实现范围、知识库差异七个维度 - 等待用户回答后再进入第二步
UI 层面（颜色、字体、布局）以设计稿为准，无需提问。
第二步：功能点分解
按 3.1 的两层拆分法分解，输出功能点清单。参考 references/ 分类清单、knowledge/modules/
已有模块说明、knowledge/business-flow/ 核心流程。
第三步：测试点分析与输出
- 基于功能点清单从需求源头重新分析（明令禁止读取 test_output/ 已有文件）
- 参考 references/ 覆盖清单、knowledge/rules/ 业务规则、knowledge/roles/ 角色权限、knowledge/business-flow/ 核心流程
- 每个功能点覆盖七个维度：正向流程、输入域验证、业务规则校验、异常场景、角色权限视角、流程回归视角、认证与越权视角
- 按 3.3 的树形嵌套规则输出
输出路径：test_output/{版本需求名称}/testpoint/{版本} 测试点.md
第四步：测试用例模板确认（策略已固化）
| 策略项 | 固定规则 |
|---|---|
| 用例编号 | 按业务模块缩写 + 序号自动生成，如 TC-001、TC-SC-001 |
| 用例名称 | "操作 + 对象"或"验证 + 约束"格式，体现测试目的 |
| 前置条件 | 详细数据准备，分段描述；登录/进入模块操作放在此处 |
| 操作步骤 | 概括性描述核心操作，不展开每个点击细节；登录/进入模块不写入步骤 |
| 预期结果 | 严格与步骤编号一一对应；无法描述时可仅保留序号占位 |
| 优先级 | 1=核心正向/冒烟，2=重要功能/异常流程，3=边界/安全/辅助，4=增强探索 |
第五步：测试用例转化策略（策略已固化）
设计原则：
- 可执行性原则（强制）：前置条件、测试步骤、预期结果三要素齐备，任何人可独立执行
- 单一验证原则（强制）：一个用例只验证一个核心业务场景或规则
- 用例命名规范（强制）：≤20 字，不包含预期结果，不使用数字前缀或【】符号
- 格式规范（强制）：前置条件/步骤/预期使用实际换行 + 1. 2. 3. 编号，步骤数 = 预期数
- 用例拆分/合并原则：正向连续操作合并；反向校验、边界值、无效等价类独立拆分
- 用户视角原则：单个用例保持视角一致，核心完整流程可跨角色合并
- 用例独立性：用例之间无显式依赖，数据通过前置条件准备
- 步骤数量控制：每用例 ≤ 5 条操作步骤
- 预期可验证：不写"正确显示"，写具体内容和跳转动作
- 测试数据具体：测试数据用字段语义描述
| 策略项 | 固定规则 | 示例 |
|---|---|---|
| 合并与拆分 | 正向连续操作合并；反向/边界/无效等价类独立拆分 | 连续添加 3 个订单班→1 个用例；必填校验、格式校验、重复校验→各 1个独立用例 |
| 步骤无包含 | 禁止"步骤 A 包含步骤 | 错误：“添加多个"用例中包含"添加单个"完整步骤B”，已存在状态作为前置条件 |
| 多状态组合 | 同一操作的不同可操作状态合并为一个用例 | "编辑各可编辑状态岗位合规修改数据保存"涵盖四个状态 |
| 批量操作覆盖 | 必须覆盖多选、混合状态 | 批量选中各状态岗位验证按钮置灰逻辑 |
| 辅助功能处理 | 辅助/次要功能独立用例，优先级 3 级 | “验证列表字段超长时截断并悬浮展示完整内容” |
| 安全测试覆盖 | XSS/SQL/空格覆盖重要输入框和查询接口，优先级 3级 | “岗位基础信息页各输入字段注入 xss” |
| 认证与越权覆盖 | 未登录访问、垂直越权、水平越权各拆独立用例，优先级 2~3 | “专家角色凭证直接调用试卷管理接口” |
第六步：测试用例输出
基于第三步的测试点，应用第四、五步的固化策略，结合知识库转化为可执行用例。
输出前自检（必须逐项确认）：
- 是否已读取
.claude/knowledge/中相关知识库文件（仅作为参考补充） - 是否已识别本期需求与知识库历史规则的冲突或变更点，并确认以本期需求为准
- 是否覆盖所有空状态场景（列表、看板、筛选结果、弹窗搜索）
- 是否覆盖数据联动刷新场景（增删改后相关区域同步更新）
- 批量操作是否覆盖多选、混合状态
- 文件上传是否覆盖数量限制（单张/多张、达到上限）
- 安全测试是否覆盖 XSS/SQL/空格（重要输入框和查询接口）
- 用例名称是否体现测试目的（非直接复用需求描述）
- 多状态操作是否合并为一个用例
- 辅助功能是否独立用例且优先级为 3 级
- 多角色/权限场景是否按角色拆分或用前置条件明确角色身份
- 认证与越权是否覆盖（未登录/登录态失效直访接口、垂直越权、水平越权篡改 id、前端绕过直调接口）
输出格式（Excel）：
| 列名 | 说明 |
|---|---|
| 用例 ID | TC-0001 开始编号 |
| 所属模块 | /平台/模块 路径 |
| 用例名称 | 精简，≤20 字，无预期，无前缀 |
| 前置条件 | 1.2.3. 编号，换行分隔 |
| 步骤 | 1.2.3. 编号，换行分隔 |
| 预期 | 与步骤一一对应，换行分隔 |
| 优先级 | 1/2/3/4 |
输出路径：test_output/{版本需求名称}/testcase/{版本} 功能测试用例.xlsx
第七步：反馈闭环与调整
三种反馈类型：
| 类型 | 场景 | 处理方式 |
|---|---|---|
| A | 用户提供自编用例 | 风格对比 → 调整输出策略 |
| B | 用户指出执行偏差（如"没有按步骤执行"） | 过程纠偏 → 回溯修正 → 重新生成 |
| C | 用户澄清需求细节（如某功能本期是否实现） | 影响评估 → 修正测试点/用例 → 重新导出 |
反馈入口有两个：把自编文件放进 user/ 目录，或直接在对话里说。
test_output/{版本需求名称}/
├── testpoint/
│ ├── {版本} 测试点.md
│ └── user/{版本} 测试点 - 用户版.md # 用户反馈目录
└── testcase/
├── {版本} 功能测试用例.xlsx
└── user/{版本} 功能测试用例 - 用户版.xlsx
对比分析要输出四块内容：用例风格特征总结（粒度、前置条件描述、步骤描述、优先级标准）、遗漏场景对比（AI 漏的 / 用户漏的）、优先级差异对比、双方都遗漏的场景。
读取用户用例时必须完整读取，不允许只读前 20 行或部分数据：
python .claude/skills/excel-reader/excel-reader.py <文件路径> -n 999999 --json
# 读取后必须验证：returned_rows == total_rows
记忆固化：如果用户确认了某种用例设计风格，或指出了流程执行偏差，就把经验写入 .claude/memory/，避免下一期重犯。
这是"反馈闭环"从初版的设想变成现实的地方：它不是一次性的对话修正，而是跨会话的长期记忆。
5. 步骤间关卡（Gate）
光有步骤定义不够——AI 会在"看起来完成了"的时候跳步。所以每一步之间加了强制关卡：
| 关卡 | 从→ 到 | 检查项 |
|---|---|---|
| Gate1 | 第一步→第二步 | XMind + 源码 + 其他文件 + 知识库全部读取完成；至少 3-5 个澄清问题已提出；等待用户回答 |
| Gate2 | 第二步→ 第三步 | 已有模块说明 已输出功能点清单（模块→页面→功能点的分层结构）；参考了 references/ 分类清单和 knowledge/ |
| Gate 3 | 第三步→ 第六步 | 测试点已写入文件；数量与功能点清单对应；已结合 knowledge/rules/ 和 knowledge/roles/ 验证覆盖；涉及登录/多角色/数据归属的功能点已补充认证与越权测试点 |
| Gate4 | 第六步→ 第七步 | 用例数量 ≥ 测试点数量；步骤/预期编号匹配验证通过；自检清单全部勾选；已验证用例与知识库规则无冲突 |
| Gate5 | 第七步→ 结束 | 用户反馈已处理；相关文件已重新生成并验证；如规则发生变更，已提示用户更新知识库 |
6. 执行前检查清单
-
确认 test_input/{版本}/{需求}/prd/ 目录下有什么文件
- 如果有 .xmind 文件 → 必须使用 xmind-branch-extract.py 按模块关键词提取完整分支
- 如果有 HTML 原型源码目录 → 必须用 Python 脚本提取中文文本
- 如果有其他文件（JSON、API文档等）→ 一并读取
- 如果目录为空 → 向用户请求提供需求文件，停止执行
-
扫描并读取
.claude/knowledge/目录下相关知识库文件- 读取 README.md 了解知识库结构
- 根据 XMind 中心主题、模块、角色名称匹配并读取相关文件
- 若无法判断相关性，读取全部知识库文件
- 若知识库为空，继续执行，不阻塞
-
确认读取的是 test_input/（输入）而非 test_output/（输出）
- 任何从 test_output/ 读取文件的尝试都是错误的
-
确认第一步完成后向用户提出澄清问题
- 必须等待用户回答后再进入第二步
-
读取反馈记忆（如有）
- 启动时检查 .claude/memory/ 目录下是否有 type: feedback 的记忆文件，如有，必须读取，确保过往的流程纠偏、用例风格偏好被当前轮次继承
五、技能全景
test-case-design（核心编排技能）
│
├── 第一步：xmind-branch-extract.py 提取 XMind 分支 + Python 脚本提取原型中文
├── 第一步a：读取 .claude/knowledge/ 已有业务知识（参考补充）
├── 第二步：功能点两层拆分
├── 第三步：调用 test-markdown-generator 输出测试点
│ └── 结合 knowledge/ 中的规则/角色/流程
├── 第四步：调用 excel-reader 读取历史用例模板
├── 第五步：应用固化转化策略
├── 第六步：调用 test-excel-generator 生成用例
│ └── 调用 test-case-export 输出 Excel
└── 第七步：调用 excel-reader 读取用户反馈用例 → 记忆固化
knowledge-base（业务知识库提炼技能）
│
├── 从 test_input/ 当期需求中提炼知识
└── 写入 .claude/knowledge/
├── business-flow/
├── modules/
├── roles/
└── rules/
辅助技能
├── test-plan-generator 测试计划生成
├── xmind-reader XMind 分支提取（脚本）
├── excel-reader Excel 读取（COM 方式，脚本）
└── test-case-export 测试用例导出（脚本）
技能分工的一个原则：脚本只做机械的读写（解析 ZIP、调 Excel COM、写 xlsx），所有分析和设计由 AI 完成。
六、可扩展方向
- 让 Skill 读项目代码
当前 Skill 依赖用户手动整理需求，可让 Skill 直接读取项目代码，自动提取测试所需信息：
## 扩展功能：代码分析
用户提供代码路径且输入中包含以下关键词时触发代码读取：
- "根据代码生成用例"
- "分析这个文件/模块的测试用例"
- "从代码中提取测试点"
值得做的原因：需求文档写的是"应该怎样"，代码写的是"实际怎样"。两者一比，往往能直接发现需求与实现不一致的地方——这是测试
最高价值的产出之一。
- 知识库冲突自动检测与更新提醒
目前知识库差异分析靠 AI 在第一步人工比对。可以进一步：
- 在 knowledge/rules/ 里给每条规则加"来源版本"标记
- 设计用例时自动比对本期的规则变更，输出"需更新知识库"清单
- 用户确认后一键触发 knowledge-base 增量更新
现状是冲突会被标注、会提示用户更新知识库，但更新动作仍需人工发起。
- 需求 → 测试点 → 用例 双向追溯矩阵
现在 Gate 4 靠"用例数量 ≥ 测试点数量"做粗粒度把关。更彻底的做法是给每个测试点编号，在 Excel
里增加"来源测试点"列，输出一张追溯矩阵，让"哪条需求没被覆盖"一目了然。
- 多 AI 工具适配
Skill 绑定的是 Claude Code 的 .claude/skills/ 目录。目前项目已经额外维护了一套 AGENTS.md +
.agents/skills/，把同样的方法论适配到其他支持 AGENTS.md 约定的 AI 编程工具上，团队里用不同工具的人可以共享同一套规范。
核心收获：Skill 是把"隐性经验"显性化的好方式。
初版的时候我以为难点在于"怎么把测试方法论写进prompt"。做完几个版本之后才明白，方法论反而是最容易的部分——真正难的是这三件事：
- 让 AI 记住业务，而不是每期从零开始（→ 知识库）
- 让 AI 老老实实走流程，而不是抄近路、跳步、循环引用（→ Gate 关卡 + 关键防错规则）
- 让反馈沉淀下来，而不是同一类错误反复纠正（→ 第七步 + 记忆固化）
流程越复杂，越需要"关卡"去约束；业务越复杂，越需要"知识库"去承载。
完整 Skill 配置文件源码：https://gitee.com/evening-li/ai-generate-testcase.git
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
23
0- 0
已为社区贡献2条内容
所有评论(0)