一、为什么要写这个 Skill背景AI 编程助手很强大但通用对话写测试用例不够系统痛点每次都要重复描述需求、格式不统一、覆盖度靠人工保证目标让 Claude 按固定方法论 固定格式输出测试用例成果预览一个触发词 一次对话 完整测试用例表格二、什么是 SkillSkill 的本质给 AI 封装“能力模块”与普通 prompt 的区别结构化、可复用、可约束行为Claude Code Skill 本质上是一个包含 SKILL.md 文件的文件夹。这个文件夹可以被 Claude 按需发现和加载从而赋予 Claude 完成特定任务的专业能力。它不是可执行的程序代码而是一种动态的上下文增强机制——当 Claude 判断某个 Skill 与当前任务相关时会将这个 Skill 的指令注入到对话上下文中指导 Claude 如何完成任务。1.核心结构SKILL.md 文件每个 Skill 的核心是一个名为 SKILL.md 的 Markdown 文件。这个文件由两个关键部分组成YAML 前置元数据Frontmatter文件开头用 — 包裹的 YAML 格式元数据用于 Claude 的发现和匹配---name:your-skill-namedescription:简要描述该技能的功能以及何时使用---Markdown 指令正文元数据之后是正文用自然语言编写告诉 Claude 具体怎么做。2.文件夹结构your-skill/├── SKILL.md # 核心指令文件必须├── reference # 详细参考文档按需加载├── examples # 更多示例├── templates/ # 模板文件└── scripts/ # 可执行脚本3.存储位置类型路径适用范围个人 Skills~/.claude/skills/当前用户的所有项目项目 Skills.claude/skills/当前代码库可提交 Git 与团队共享插件 Skills插件包内的 skills/ 目录安装插件的用户三、整体设计思路核心问题拆解如何让 AI 理解功能需求将需求文档资料放在test_input/prd目录下让AI读取并解析该目录下的需求文档。因为我们项目的需求和原型需要汇总处理所以我一般会使用xmind将需求进行初步整理拆解因此我会将xmind文件作为需求输入文件为了让AI快速读取xmind文件我让AI成功读取xmind后将读取步骤也封装成了一个skillxmind-reader--- ### 第一步需求深度分析 **调用工具**: xmind-reader 1. 检查 test_input/{版本 需求名称}/prd/ 下是否有 xmind 格式的需求 - 如有需求文件调用 bash python .claude/skills/xmind-reader/xmind-reader.py test_input/{版本}/{需求}/prd/*.xmind -f tree - 如无需求文件向用户提问请提供需求文档XMind 文件或原型说明以便进行用例设计 3. 识别业务核心流程、关键功能模块及潜在依赖 4. 提取业务规则、输入输出识别隐含需求和边界条件 5. 列出需要澄清的模糊点或缺失的信息 **本步输出**: 需求分析结果供第二步使用 ---如何让 AI 应用测试方法将测试方法编码为可执行规则### 二、测试设计技术黑盒测试方法 **1. 等价类划分** - **有效等价类**符合需求的输入数据 - **无效等价类**不符合需求的输入数据 - 应用场景输入框校验、数据类型验证 **2. 边界值分析** - 关注输入域的边界最小值、最大值、空值、极大值 - 典型边界0、1、最大值、最大值 1、空字符串、超长字符串 - 应用场景数值输入、文本长度、时间范围、分页页码 **3. 场景法流程分析法** - **基本流**用户正常操作流程 - **备选流**其他合法操作路径 - **异常流**错误操作或异常条件 - 应用场景多步骤流程、状态变迁、端到端业务 **4. 状态迁移法** - 识别业务对象的所有状态 - 定义状态转换条件和触发事件 - 验证合法转换和非法转换 - 应用场景订单状态、审批流程、任务生命周期 **5. 判定表法** - 适用于多条件组合的业务规则 - 列出所有条件桩和动作桩 - 生成条件组合并确定预期动作 - 应用场景权限控制、费用计算、规则引擎 **6. 正交分析法** - 从全面组合中选取代表性组合 - 减少测试用例数量同时保证覆盖率 - 应用场景多条件筛选、配置组合测试如何保证输出格式统一精确格式模板 负向约束 ### 第四步测试用例模板确认 **调用工具**: excel-reader 1. 使用 excel-reader 读取 test-case-design/examples/testcases/ 下的 Excel 格式测试用例模板 bash python .claude/skills/excel-reader/excel-reader.py test-case-design/examples/testcases/*.xlsx --json 2. 分析模板结构理解每个字段的含义 3. 学习历史编写习惯 **学习要点**: - 前置条件粒度数据少时指定具体名称数据多时概括描述 - 步骤描述粒度核心/首次操作详细重复/相似操作概括 - 预期对应关系步骤数预期数一一对应 - 用例命名习惯自由描述不体现预期结果 - 优先级划分标准1 级核心正向/冒烟2 级重要功能3 级完整验证4 级增强探索 **本步输出**: 模板规范供第六步使用 ### 第五步测试用例设计 基于第四步确认的模板设计测试用例转化策略。 **设计原则**: 1. **可执行性原则**强制每个测试用例必须能被任何人独立执行 - **前置条件**环境要求、数据准备、系统状态 - **测试步骤**操作顺序、输入数据、操作描述 - **预期结果**可验证断言、数据变化、状态变化 2. **单一验证原则**强制一个测试用例只验证一个核心业务场景或规则 - 正向连续操作可合并为一个用例 - 反向校验、边界值、无效等价类每个独立场景拆分为独立用例 - 端到端流程测试除外验证流程完整性是单一业务目标 3. **用例命名规范**强制: - 名称体现场试工作内容精简控制在 20 字以内 - 不包含预期结果 - 不使用数字前缀如1、2、3、 - 不使用【】等符号标记模块、按钮等内容 - ✅ 示例正确密码登录 、错误密码登录 、 空用户名登录 - ❌ 示例1、【登录】输入正确密码登录成功 4. **格式规范**强制: - 前置条件、步骤、预期内容换行分隔 - **前置条件使用编号 1. 2. 3.** - 步骤与预期严格一一对应步骤数预期数 - 每个前置条件/步骤/预期使用编号1. 2. 3.开头 5. **用例拆分/合并原则**: - 正向连续操作类连续添加、批量操作合并为一个用例 - 反向校验、边界值、无效等价类每个独立场景拆分为独立用例 6. **用户视角原则**: 单个用例保持视角一致核心完整流程可跨角色合并 7. **用例独立性**: 用例之间无显式依赖数据通过前置条件准备 8. **步骤数量控制**: 每个用例不超过 5 条操作步骤 9. **预期可验证**: 不写正确显示写具体内容和跳转动作 10. **测试数据具体**: 不写合法值写张三 **不同测试类型的转化要点**: | 测试类型 | 特点 | 转化要点 | |---|---|---| | 正向/反向测试 | 验证需求功能是否实现 | 覆盖所有需求条目按用户操作习惯设计步骤预期结果明确对应需求描述 | | 异常/边界测试 | 验证系统健壮性 | 明确异常触发条件预期结果强调优雅失败关注错误提示准确性 | | 模块交互测试 | 验证模块间交互和数据流 | 关注接口和数据边界验证数据一致性包含异常数据流测试 | | 用户场景测试 | 验证端到端业务体验 | 业务闭环使用真实数据流多角色协同状态流转验证 | **本步输出**: 设计策略供第六步使用四、Skill 结构设计1. 元信息名称、触发条件、适用场景---name:test-case-designdescription:根据需求描述设计测试用例。综合运用等价类划分、边界值分析、场景法等方法生成结构化的测试用例文档。当用户提到设计用例写测试用例帮我出用例测试点分析时触发。---2. 角色设定# 测试用例设计助手 你是一名经验丰富的软件测试工程师擅长将复杂需求转化为系统化、可执行的测试方案。3. 核心方法论## 核心方法论 ### 一、功能点定义强制 **功能点 ≠ 需求点**不是直接复制 XMind 中的需求描述 **功能点定义标准**同时满足 |维度|说明| |---|---| |可观测|有明确的输入/输出或状态变化| |可测试|可以设计测试用例来验证| |原子性|不可再分的最小可测单元| |业务价值|对用户有明确的业务意义| **功能点分类**按交互模式 1. **数据展示类**列表页、详情页、仪表板/数据看板 2. **数据操作类**表单页新增/编辑/搜索、批量操作、导入/导出 3. **流程类**向导/多步骤流程、审批/工作流 4. **交互类**搜索、筛选/过滤、排序 5. **系统功能类**用户账户管理、权限/角色管理、系统配置 6. **特殊功能类**文件管理、消息/通知、支付功能 **功能点梳理原则** - **以页面/二级页为单位**每个功能子模块的页面、二级页为单位梳理功能 - **功能类型**列表展示功能、搜索功能、新增功能、编辑功能、详情功能、删除功能、导入导出功能等 ### 二、测试设计技术黑盒测试方法 **1. 等价类划分** - **有效等价类**符合需求的输入数据 - **无效等价类**不符合需求的输入数据 - 应用场景输入框校验、数据类型验证 **2. 边界值分析** - 关注输入域的边界最小值、最大值、空值、极大值 - 典型边界0、1、最大值、最大值 1、空字符串、超长字符串 - 应用场景数值输入、文本长度、时间范围、分页页码 **3. 场景法流程分析法** - **基本流**用户正常操作流程 - **备选流**其他合法操作路径 - **异常流**错误操作或异常条件 - 应用场景多步骤流程、状态变迁、端到端业务 **4. 状态迁移法** - 识别业务对象的所有状态 - 定义状态转换条件和触发事件 - 验证合法转换和非法转换 - 应用场景订单状态、审批流程、任务生命周期 **5. 判定表法** - 适用于多条件组合的业务规则 - 列出所有条件桩和动作桩 - 生成条件组合并确定预期动作 - 应用场景权限控制、费用计算、规则引擎 **6. 正交分析法** - 从全面组合中选取代表性组合 - 减少测试用例数量同时保证覆盖率 - 应用场景多条件筛选、配置组合测试 ### 三、测试点分析维度 1. **功能正确性验证**基础层正常流程验证、输入输出验证、界面元素验证 2. **业务逻辑深度**核心层业务规则验证、状态机完整性、数据一致性、权限控制验证 3. **异常与边界**防御层异常流程验证、边界值分析、错误恢复能力、兼容性验证 4. **集成与端到端**系统层端到端流程、数据流完整性、系统集成点 5. **用户体验与业务价值**拓展层可用性验证、性能体验、业务目标支持 ### 四、常见功能测试点覆盖清单 **列表页测试点** - 数据展示数据准确性、完整性、空状态处理、格式与样式 - 分页测试分页控件显示、导航按钮、数据一致性、分页与筛选/排序联动 - 查询/筛选基础搜索、高级筛选、实时搜索、重置功能 - 排序功能单列排序、多列排序、排序状态指示器、默认排序规则 - 列表操作行内操作、批量操作、操作项启用/禁用条件 **表单页测试点** - 输入框校验必填项、等价类、边界值、数据类型、特殊字符 - 下拉框选择性和可填性、模糊匹配、二级联动 - 单选/复选框独选型、多选型 - 时间选择开始/结束时间关系、时间格式化 - 提交按钮回车/单击支持、防重复提交、弱网提交、提交后提示、权限校验 - 业务约束业务规则校验、状态依赖校验 **导入导出测试点** - 导入正常流程、文件格式支持、文件类型异常、文件内容异常、数据格式异常、业务逻辑异常 - 导出正常流程、导出范围、导出内容、资源限制 - 模板模板下载、模板格式、说明 sheet 页 **文件上传测试点** - 文件类型限制、脚本文件拦截、文件内容校验 - 浏览后删除文件、超大文件处理 - 文件命名冲突处理、存储方式验证4. 工作流程6 步执行顺序### 第一步需求深度分析 **调用工具**: xmind-reader 1. 检查 test_input/{版本 需求名称}/prd/ 下是否有 xmind 格式的需求 - 如有需求文件调用 bash python .claude/skills/xmind-reader/xmind-reader.py test_input/{版本}/{需求}/prd/*.xmind -f tree - 如无需求文件向用户提问请提供需求文档XMind 文件或原型说明以便进行用例设计 3. 识别业务核心流程、关键功能模块及潜在依赖 4. 提取业务规则、输入输出识别隐含需求和边界条件 5. 列出需要澄清的模糊点或缺失的信息 **本步输出**: 需求分析结果供第二步使用 --- ### 第二步功能点分解 基于第一步的需求分析结果你将需求分解为原子化的功能点清单。 **功能点定义**强制: - **功能点 ≠ 需求点**不是直接复制 XMind 中的需求描述 - **以页面/二级页为单位**每个功能子模块的页面、二级页为单位梳理功能 - **功能类型**列表页、搜索功能、新增功能、编辑功能、详情功能、导入导出功能等 - **判断标准** - 有明确的页面载体列表页、详情页、弹窗等 - 可独立操作的功能单元搜索、新增、编辑、删除、查看等 - 可测试可设计用例验证 - 有业务价值 **本步输出**: 功能点清单供第三步使用 --- ### 第三步测试点分析与输出 基于**第二步输出的每个功能点**系统化分析测试点。 **覆盖维度**每个功能点至少覆盖: 1. 正向流程基础操作、核心链路 2. 输入域验证边界值、等价类、格式校验、空值处理、极大值输入 3. 业务规则校验针对存在业务约束条件、状态依赖的功能需从约束条件反向推导测试点 4. 异常场景网络/超时、数据异常 **测试点定义**: 描述怎么测即操作和验证动作不含预期结果 **输出路径**强制: - 文件路径test_output/{版本需求名称}/testpoint/{版本} 测试点.md - 示例test_output/v1.11.2.8 济源 3 月 20 日需完成任务/testpoint/v1.11.2.8 济源测试点.md **本步输出**: Markdown 格式测试点文档保存到上述路径 --- ### 第四步测试用例模板确认 **调用工具**: excel-reader 1. 使用 excel-reader 读取 test-case-design/examples/testcases/ 下的 Excel 格式测试用例模板 bash python .claude/skills/excel-reader/excel-reader.py test-case-design/examples/testcases/*.xlsx --json 2. 分析模板结构理解每个字段的含义 3. 学习历史编写习惯 **学习要点**: - 前置条件粒度数据少时指定具体名称数据多时概括描述 - 步骤描述粒度核心/首次操作详细重复/相似操作概括 - 预期对应关系步骤数预期数一一对应 - 用例命名习惯自由描述不体现预期结果 - 优先级划分标准1 级核心正向/冒烟2 级重要功能3 级完整验证4 级增强探索 **本步输出**: 模板规范供第六步使用 --- ### 第五步测试用例设计 基于第四步确认的模板设计测试用例转化策略。 **设计原则**: 1. **可执行性原则**强制每个测试用例必须能被任何人独立执行 - **前置条件**环境要求、数据准备、系统状态 - **测试步骤**操作顺序、输入数据、操作描述 - **预期结果**可验证断言、数据变化、状态变化 2. **单一验证原则**强制一个测试用例只验证一个核心业务场景或规则 - 正向连续操作可合并为一个用例 - 反向校验、边界值、无效等价类每个独立场景拆分为独立用例 - 端到端流程测试除外验证流程完整性是单一业务目标 3. **用例命名规范**强制: - 名称体现场试工作内容精简控制在 20 字以内 - 不包含预期结果 - 不使用数字前缀如1、2、3、 - 不使用【】等符号标记模块、按钮等内容 - ✅ 示例正确密码登录 、错误密码登录 、 空用户名登录 - ❌ 示例1、【登录】输入正确密码登录成功 4. **格式规范**强制: - 前置条件、步骤、预期内容换行分隔 - **前置条件使用编号 1. 2. 3.** - 步骤与预期严格一一对应步骤数预期数 - 每个前置条件/步骤/预期使用编号1. 2. 3.开头 5. **用例拆分/合并原则**: - 正向连续操作类连续添加、批量操作合并为一个用例 - 反向校验、边界值、无效等价类每个独立场景拆分为独立用例 6. **用户视角原则**: 单个用例保持视角一致核心完整流程可跨角色合并 7. **用例独立性**: 用例之间无显式依赖数据通过前置条件准备 8. **步骤数量控制**: 每个用例不超过 5 条操作步骤 9. **预期可验证**: 不写正确显示写具体内容和跳转动作 10. **测试数据具体**: 不写合法值写张三 **不同测试类型的转化要点**: | 测试类型 | 特点 | 转化要点 | |---|---|---| | 正向/反向测试 | 验证需求功能是否实现 | 覆盖所有需求条目按用户操作习惯设计步骤预期结果明确对应需求描述 | | 异常/边界测试 | 验证系统健壮性 | 明确异常触发条件预期结果强调优雅失败关注错误提示准确性 | | 模块交互测试 | 验证模块间交互和数据流 | 关注接口和数据边界验证数据一致性包含异常数据流测试 | | 用户场景测试 | 验证端到端业务体验 | 业务闭环使用真实数据流多角色协同状态流转验证 | **本步输出**: 设计策略供第六步使用 --- ### 第六步测试用例输出 基于**第三步输出的测试点**按照**第四步确认的模板格式**应用**第五步的设计策略**逐条转化测试点为测试用例。 **转化规则**: 1. 将审阅通过的测试点严格遵循确认的模板和策略转化为可执行的测试用例 2. 格式要求 - 用例编号、用例名称、前置条件、步骤、预期、优先级完整输出 - 步骤与预期严格一一对应 - 优先级使用1/2/3/4不使用P1/P2/P3/P4 3. 前置条件、步骤、预期使用实际换行不是 \n 字符 4. 调用 test-case-export 脚本输出为 Excel **输出路径**强制: - 文件路径test_output/{版本需求名称}/testcase/{版本} 功能测试用例.xlsx - 示例test_output/v1.11.2.8 济源 3 月 20 日需完成任务/testcase/v1.11.2.8 功能测试用例.xlsx - **必须输出为 .xlsx 格式** **输出格式**: Excel | 列名 | 说明 | |------|------| | 所属模块 | /平台/模块 路径 | | 用例名称 | 精简≤20 字无预期无前缀| | 前置条件 | 1.2.3.编号换行分隔 | | 步骤 | 1.2.3.编号换行分隔 | | 预期 | 与步骤一一对应换行分隔 | | 优先级 | 1/2/3/4 | | 用例类型 |功能测试| | 适用阶段 |功能测试| | 设计方法 | 用了什么方法得出的 |四、可扩展方向基础版 Skill 已经能够根据用户输入的功能描述生成测试用例但还有很大的扩展空间。以下是两个核心扩展方向让 Skill 读项目代码当前 Skill 依赖用户手动描述功能需求可让 Skill 直接读取项目代码自动提取测试所需信息## 扩展功能代码分析 用户提供代码路径且输入中包含以下关键词时触发代码读取 - 根据代码生成用例 - 分析这个文件/模块的测试用例 - 从代码中提取测试点反馈“补充遗漏用例”形成闭环建立用户反馈闭环让 Skill 能够从用户的补充和修正中学习。## 反馈闭环流程图 第一步用户使用 Skill 为登录功能设计测试用例 ↓ 第二部Skill 生成初始用例 TC-01 正常登录 TC-02 密码错误 TC-03 用户名不存在 ...可能遗漏场景 ↓ 第三步用户审查用例 你漏了验证码场景 密码大小写敏感没测 并发登录场景需要补充 ↓ 第四步Skill 记录反馈 • 识别遗漏类型 • 提取场景模式 • 记录用户补充的用例 ↓ 第五步Skill 更新规则 • 本次会话立即补充遗漏用例 • 长期学习更新规则库下次自动包含 第六步输出完整用例集 初始用例 用户补充用例 Skill 自动补充用例核心收获Skill 是把“隐性经验”显性化的好方式完整 Skill 配置文件源码https://gitee.com/evening-li/ai-generate-testcase.git