测试用例生成 Skills v2.0

该压缩包包含 15 个测试用例生成相关子 Skill，可按流水线完成从产品资料和需求文档到测试用例 Excel 的生成。

安装方法

1. 解压文件

将 test-case-generation-skills.zip 解压到任意位置。

2. 复制到 Trae IDE skills 目录

将解压后的 15 个文件夹复制到 Trae IDE 的 skills 目录下：

• Windows: %USERPROFILE%\.trae-cn\skills\
• macOS/Linux: ~/.trae-cn/skills/

复制后的目录结构应如下：

.trae-cn/
└── skills/
    ├── module-mapper/
    │   └── SKILL.md
    ├── negative-test-case-writer/
    │   └── SKILL.md
    ├── positive-test-case-writer/
    │   └── SKILL.md
    ├── product-manual-reader/
    │   └── SKILL.md
    ├── product-model-builder/
    │   └── SKILL.md
    ├── requirement-clarifier/
    │   └── SKILL.md
    ├── requirement-element-extractor/
    │   └── SKILL.md
    ├── requirement-prioritizer/
    │   └── SKILL.md
    ├── requirement-type-identifier/
    │   └── SKILL.md
    ├── test-case-excel-generator/
    │   └── SKILL.md
    ├── test-case-pipeline/
    │   └── SKILL.md
    ├── test-case-quality-checker/
    │   └── SKILL.md
    ├── test-scope-analyzer/
    │   └── SKILL.md
    ├── test-step-reality-checker/
    │   └── SKILL.md
    └── test-technique-selector/
        └── SKILL.md

3. 重启 Trae IDE

关闭并重新启动 Trae IDE，Skills 会自动加载。

使用方法

最简用法（一步生成）

直接将产品说明书 PDF 和需求文档 PDF 发给 AI，说：

请阅读产品说明书和需求文档，生成测试用例

AI 会自动按照 15 步流水线生成完整的测试用例 Excel 文件。

分步用法

也可以在特定阶段单独调用子 Skill：

Skill 列表

版本

v2.0 - 2026年7月

---

子 Skill：module-mapper\SKILL.md

---

name: "module-mapper" description: "基于产品知识模型，将新需求映射到对应模块，识别集成点和影响范围。在product-model-builder之后调用，输出模块映射结果JSON。"

模块映射器

目标

将新需求准确映射到产品知识模型中的对应模块，识别需求涉及的集成点和影响范围。

输入

• 产品知识模型（JSON，来自product-model-builder）
• 新需求描述（文本）

输出

• 模块映射结果（JSON格式）

映射流程

1. 需求关键词提取

从需求描述中提取关键词和业务术语。

2. 多维度匹配

3. 集成点识别

识别需求涉及哪些模块间的交互：API调用、数据传递、状态回调。

4. 影响范围分析

输出结构

{
  "requirement": {"description": "需求描述", "keywords": ["关键词"]},
  "module_mapping": {
    "primary_module": {"id": "MOD-001", "name": "模块名", "match_score": 0.95},
    "secondary_modules": [{"id": "MOD-002", "relationship": "数据依赖"}],
    "related_features": ["功能1", "功能2"]
  },
  "integration_points": [
    {"source": "MOD-001", "target": "MOD-002", "type": "API调用"}
  ],
  "impact_analysis": {
    "functional_impact": ["影响项"],
    "data_impact": ["影响项"]
  }
}

---

子 Skill：negative-test-case-writer\SKILL.md

---

name: "negative-test-case-writer" description: "编写负面/反向/边界测试用例，覆盖非法输入、异常操作和边界条件。在positive-test-case-writer之后调用，输出负面测试用例列表。"

负面测试用例编写器

目标

编写负面测试用例，覆盖非法输入、异常操作、边界条件场景，验证系统正确处理。

输入

• 优先级需求列表
• 模块映射结果
• 测试技术选择

输出

• 负面测试用例列表（含具体操作步骤和预期错误提示）

必须覆盖的反向场景

1. 输入类

2. 操作类

3. 边界类

预期结果编写规范

❌ 错误：
预期: 保存失败，提示错误

✅ 正确：
预期: 弹出错误提示对话框，标题为[保存错误]，内容为[文件名不能包含非法字符\\/:*?"<>|]，对话框下方有[确定]按钮，编辑器文件标签仍为[untitled *]未变化

覆盖率标准

• P0功能：至少1条关键负面用例
• P1功能：至少1条负面用例
• P2功能：负面用例可酌情覆盖

---

子 Skill：positive-test-case-writer\SKILL.md

---

name: "positive-test-case-writer" description: "编写正向测试用例，覆盖正常操作路径和有效输入。遵循真实操作步骤规范，每条命令独立成步。在test-technique-selector之后调用。"

正向测试用例编写器

目标

编写正向测试用例，覆盖功能的正常操作路径和有效输入场景。

输入

• 优先级需求列表
• 模块映射结果
• 测试技术选择

输出

• 正向测试用例列表（含具体操作步骤）

核心规范

操作步骤6要素

每个步骤必须包含：

禁止写法

测试用例模板

测试用例ID: [模块]-[功能]-[序号]
测试场景: [场景描述]
前置条件:
  1. [环境准备]
  2. [数据准备]
测试步骤:
  1. [在什么位置做什么操作]
  2. [输入什么内容]
  ...
预期结果:
  1. [步骤1后的界面反馈]
  ...
优先级: P0/P1
测试类型: 功能测试

---

子 Skill：product-manual-reader\SKILL.md

---

name: "product-manual-reader" description: "读取产品说明书原始内容，识别文档结构和关键章节。当用户提供PDF/Word/Markdown产品手册时调用，作为测试用例生成流程的初始步骤。"

产品说明书读取器

目标

读取产品说明书原始文档，解析文档结构，定位产品概述、功能列表、模块划分、操作指南等关键章节。

输入

• 产品说明书文件（PDF / Word / Markdown / HTML）
• 用户手册

输出

• 文档原始文本内容
• 文档目录结构（章节层级）
• 关键章节定位（产品概述、功能列表、模块划分、约束条件）

执行步骤

1. 格式识别与内容提取

识别文档格式并提取文本内容：

• PDF: 使用PyPDF2/pdfplumber提取
• Word: 使用python-docx提取
• Markdown/HTML: 直接解析文本

2. 章节结构分析

分析文档的层级结构，识别章节标题：

• 一级标题（产品名称、概述）
• 二级标题（模块划分、功能介绍）
• 三级标题（具体子功能）

3. 关键章节定位

在文档中定位以下关键章节的位置（行号/页码）：

• 产品概述（名称、版本、目标用户、主要用途）
• 模块划分列表
• 功能点清单
• 操作流程说明
• 约束条件（系统要求、性能指标）
• 界面交互说明
• 验收标准

4. 输出文档元信息

文档元信息：
- 文档标题：[标题]
- 总页数/总行数：[N]
- 章节总数：[N]
- 关键章节定位：
  ├─ 产品概述：第X页
  ├─ 模块划分：第X页
  ├─ 功能清单：第X页
  └─ 约束条件：第X页

输出传递给

product-model-builder（构建知识模型）

---

子 Skill：product-model-builder\SKILL.md

---

name: "product-model-builder" description: "基于说明书原始内容构建结构化产品知识模型（模块/功能/约束/接口）。在product-manual-reader完成之后调用，输出JSON格式产品知识模型。"

产品知识模型构建器

目标

从产品说明书原始内容中提取关键信息，构建结构化的JSON产品知识模型。

输入

• 产品说明书原始文本（来自product-manual-reader）
• 文档章节结构

输出

• 结构化产品知识模型（JSON格式）

产品知识模型结构

{
  "product": {
    "name": "产品名称",
    "version": "版本号",
    "description": "产品描述",
    "target_users": ["目标用户1", "目标用户2"],
    "purpose": "主要用途"
  },
  "architecture": {
    "modules": [
      {
        "id": "MOD-001",
        "name": "模块名称",
        "description": "模块描述",
        "type": "core|auxiliary|extension",
        "features": ["功能1", "功能2"],
        "dependencies": ["MOD-002"]
      }
    ],
    "relationships": [
      {"source": "MOD-001", "target": "MOD-002", "type": "调用|数据传递|依赖"}
    ]
  },
  "features": [
    {
      "id": "FEA-001",
      "name": "功能名称",
      "module_id": "MOD-001",
      "category": "核心功能|辅助功能",
      "priority": "high|medium|low"
    }
  ],
  "constraints": {
    "system": ["系统约束"],
    "business": ["业务规则"],
    "data": ["数据约束"],
    "performance": ["性能指标"],
    "security": ["安全要求"]
  },
  "interfaces": [
    {"id": "INT-001", "name": "接口名称", "type": "API|UI|文件", "module": "所属模块"}
  ],
  "business_flows": [
    {"id": "FLOW-001", "name": "流程名称", "steps": ["步骤1", "步骤2"], "involved_modules": ["MOD-001"]}
  ]
}

执行步骤

1. 提取产品基本信息

从产品概述章节提取：名称、版本、描述、目标用户、主要用途。

2. 提取模块架构

从模块划分章节提取：模块列表、模块类型（核心/辅助）、模块间的依赖关系。

3. 提取功能点

从功能清单章节提取：每个功能名称、所属模块、功能类别、优先级。

4. 提取约束条件

从约束/非功能需求章节提取：系统要求、业务规则、性能指标、安全要求。

5. 提取接口信息

从接口/集成章节提取：外部接口、API、文件格式。

6. 提取业务流程

从操作指南/使用流程章节提取：主要业务流程和操作步骤。

---

子 Skill：requirement-clarifier\SKILL.md

---

name: "requirement-clarifier" description: "识别需求文档中的模糊、不完整、冲突的需求并标记为待澄清项。在requirement-element-extractor之后调用，输出待澄清问题列表。"

需求待澄清标记器

目标

识别需求中的模糊不清、不完整、冲突或矛盾之处，标记为待澄清项。

输入

• 结构化需求要素（来自requirement-element-extractor）
• 需求原始文本

输出

• 待澄清问题列表

需要标记的待澄清场景

输出格式

待澄清问题列表：
1. REQ-002 - 模糊表述
   原文："适当的错误信息"
   问题：请明确错误信息的具体文案是什么？
   
2. REQ-005 - 缺少边界
   原文："快速响应"
   问题：请明确响应的具体时间上限（毫秒/秒）？

---

子 Skill：requirement-element-extractor\SKILL.md

---

name: "requirement-element-extractor" description: "从需求文本中提取可测试的关键要素（参与者/输入/输出/前置后置条件/业务规则/验收标准）。在requirement-type-identifier之后调用，输出要素结构。"

需求要素提取器

目标

从每条需求中提取可测试的关键要素，形成结构化需求定义。

输入

• 需求文档文本
• 需求类型列表（来自requirement-type-identifier）

输出

• 结构化需求要素列表

可测试要素提取规范

执行步骤

1. 逐条提取要素

对每条需求，扫描文本并填充上述7个要素。

2. 标记缺失要素

对于没有明确描述的要素，标记为"未明确指定"。

3. 要素去重与合并

合并多条需求中重复的要素定义。

输出格式

{
  "requirements": [
    {
      "id": "REQ-001",
      "actors": ["用户"],
      "inputs": ["邮箱", "密码"],
      "outputs": ["登录凭证"],
      "preconditions": ["用户已注册"],
      "postconditions": ["已建立会话"],
      "business_rules": ["密码长度6-20字符"],
      "acceptance_criteria": ["有效凭证登录成功"]
    }
  ]
}

---

子 Skill：requirement-prioritizer\SKILL.md

---

name: "requirement-prioritizer" description: "对需求进行优先级分级，基于业务影响/技术风险/用户影响三维度评分。在requirement-clarifier之后调用，输出P0-P3优先级矩阵。"

需求分级器

目标

基于业务价值、技术风险、用户影响三维度对需求评分，确定P0-P3优先级。

输入

• 结构化需求要素（来自requirement-element-extractor）
• 模块映射结果（来自module-mapper）

输出

• 优先级矩阵（需求ID → 优先级P0/P1/P2/P3）
• 测试覆盖建议

优先级体系

三维度评分法

总分 = 业务价值x0.4 + 技术风险x0.3 + 用户影响x0.3

输出格式

| 需求ID | 业务价值 | 技术风险 | 用户影响 | 总分 | 优先级 | 测试覆盖 |
|--------|----------|----------|----------|------|--------|----------|
| REQ-01 | 10 | 8 | 10 | 9.4 | P0 | 100% |
| REQ-02 | 7 | 5 | 6 | 6.2 | P1 | 80% |

---

子 Skill：requirement-type-identifier\SKILL.md

---

name: "requirement-type-identifier" description: "识别需求文档中的每一条需求属于功能/非功能/UI/集成/业务规则类型。当module-mapper完成之后调用，输出需求类型列表。"

需求类型识别器

目标

将需求文档中的每条需求分类到标准需求类型体系中。

输入

• 需求文档原始文本
• 模块映射结果（来自module-mapper）

输出

• 需求类型清单（每条需求标记类型）

需求类型分类标准

执行步骤

1. 逐条提取需求

将需求文档按编号或段落拆分为独立的需求条目。

2. 关键词匹配分类

根据文本中的关键词匹配到对应的需求类型。如果一条需求匹配多个类型，以功能需求优先。

3. 特殊规则处理

• 含"时间""速度""容量"等 → 非功能需求（性能子类）
• 含"按钮""菜单""窗口"等 → UI/UX需求
• 含"导入""导出""格式" → 集成需求
• 含"不能""必须""上限" → 业务规则

4. 输出需求类型列表

需求ID | 需求描述摘要 | 需求类型 | 子类型
REQ-01 | 用户登录功能 | 功能需求 | 认证
REQ-02 | 页面加载<2秒 | 非功能需求 | 性能
REQ-03 | 支持MF4导出 | 集成需求 | 数据交换

---

子 Skill：test-case-excel-generator\SKILL.md

---

name: "test-case-excel-generator" description: "将审查通过的测试用例按标准Excel格式输出（Sheet1测试用例清单 + Sheet2执行步骤-预期结果）。在test-case-quality-checker之后调用。"

测试用例Excel生成器

目标

将审查通过的测试用例输出为标准Excel格式，包含两个标签页。

输入

• 审查通过的测试用例（含操作步骤和预期结果）

输出

• Excel文件（.xlsx格式）

Excel结构

Sheet1: 测试用例清单

Sheet2: 执行步骤-预期结果

格式规范

• Sheet2中[用例名称]仅第一行填写，后续行留空（符合参考模板格式）
• 排序号在同一个用例内从1开始递增
• 每个用例的步骤数2-10步
• 负面测试用例的[测试类型]填写"负面测试"

---

子 Skill：test-case-pipeline\SKILL.md

---

name: "test-case-pipeline" description: "测试用例生成全流程编排器，协调产品说明书读取→知识模型构建→模块映射→需求类型识别→要素提取→待澄清标记→优先级分级→测试范围分析→技术选择→正向用例编写→负面用例编写→现实性审查→质量审查→Excel输出的15步流水线。"

测试用例全流程编排器

概述

协调15个子Skill按顺序执行，从产品说明书和需求文档生成完整的测试用例Excel文件。

子Skill列表

Phase1: 产品知识（前置步骤）

Phase2: 需求分析

Phase3: 测试策略

Phase4: 质量审查

Phase5: 输出

调用方式

完整流程

用户: "阅读此产品说明书和需求，生成测试用例"
执行: 按顺序调用Phase0→Phase1→Phase2→Phase3→Phase4→Phase5

简化流程（无产品说明书时）

从Phase2开始（跳过Phase1），requirement-type-identifier直接处理需求文本

分步调用

用户: "帮我分析这个需求的类型" → requirement-type-identifier
用户: "帮我审查这些用例的操作步骤" → test-step-reality-checker

核心原则

测试用例的操作步骤必须描述测试人员在软件界面上的真实操作，每一步必须是：在什么位置、用什么方式、做什么操作、看到什么结果。 每条命令独立成一步，禁止"依次输入N条命令"等概括性描述。 每条用例必须有明确的预期结果，禁止"显示正常""均成功"等模糊表述。

---

子 Skill：test-case-quality-checker\SKILL.md

---

name: "test-case-quality-checker" description: "审查测试用例的清晰度、完整性、独立性、可重复性、可追溯性和负面测试覆盖度。在test-step-reality-checker之后调用，输出审查报告。"

测试用例质量审查器

目标

从清晰度、完整性、独立性、可重复性、可追溯性、负面测试覆盖度六个维度审查测试用例质量。

输入

• 经过现实性审查的测试用例

输出

• 质量审查报告

六个审查维度

1. 清晰度

2. 完整性

3. 独立性

• 每个用例不依赖其他用例的执行结果
• 前置条件中明确如何准备测试数据

4. 可重复性

• 使用具体测试数据，结果稳定
• 每次执行结果一致

5. 可追溯性

• 每个用例关联到需求ID
• 覆盖需求中的所有功能点

6. 负面测试覆盖度

输出格式

质量审查报告：
清晰度：通过 | 问题数：X
完整性：通过 | 问题数：X
独立性：通过 | 问题数：X
可重复性：通过 | 问题数：X
可追溯性：通过 | 问题数：X
负面测试覆盖度：需要补充N条用例

建议：
1. [用例ID] - [问题描述]

---

子 Skill：test-scope-analyzer\SKILL.md

---

name: "test-scope-analyzer" description: "基于优先级需求分析测试范围，确定每个需求的测试深度和策略。在requirement-prioritizer之后调用，输出测试范围定义。"

测试范围分析器

目标

根据需求的优先级和类型，确定测试范围、测试深度和测试策略。

输入

• 优先级矩阵（来自requirement-prioritizer）
• 模块映射结果（来自module-mapper）

输出

• 测试范围定义（每个需求的测试深度、测试类型）

测试深度定义

测试策略矩阵

执行步骤

1. 根据优先级确定深度

对照优先级确定每条需求的测试深度。

2. 根据需求类型确定策略

对照测试策略矩阵确定每条的测试策略。

3. 输出测试范围表

需求ID | 优先级 | 测试深度 | 测试策略 | 应覆盖用例数
REQ-01 | P0 | 全覆盖 | 正向+反向+边界+集成 | 8-12
REQ-02 | P1 | 高覆盖 | 正向+关键反向+集成 | 5-8

---

子 Skill：test-step-reality-checker\SKILL.md

---

name: "test-step-reality-checker" description: "审查测试用例的操作步骤是否真实反映软件的实际操作方式，纠正功能描述代指、一步多操作等错误。在positive-test-case-writer之后调用。"

操作步骤现实性审查器

目标

审查测试用例的每个操作步骤是否真实反映软件的实际界面操作，确保测试人员可按照步骤直接执行。

输入

• 测试用例草稿（来自positive-test-case-writer、negative-test-case-writer）

输出

• 经审查的可执行测试用例
• 问题列表（格式：用例ID - 步骤X - 问题描述 - 修改建议）

审查维度

1. 操作符合真实界面

2. 菜单路径完整

3. 输入内容具体

4. 禁止概括性输入

5. 禁止一步多操作

审查流程（角色扮演法）

1. 读步骤：读一条操作步骤
2. 看视口：想象当前软件界面状态
3. 找对象：界面上有没有步骤描述的操作对象？
4. 做动作：步骤描述的操作是否可在该对象上执行？
5. 看结果：操作后的预期结果是否可观察？

如果以上任何一步卡住，说明步骤需要优化。

输出格式

审查报告：
- 总用例数：N
- 需要修改：M

问题详情：
1. ED-001 - 步骤3 - 概括性描述
   "依次输入6条命令" → 应拆分为6个独立步骤
   
2. ED-002 - 步骤2 - 一步多操作
   "新建脚本并编写代码" → 应分为步2.1和步2.2

---

子 Skill：test-technique-selector\SKILL.md

---

name: "test-technique-selector" description: "根据需求类型和测试场景选择合适的测试设计技术（等价类/边界值/决策表/场景法等）。在test-scope-analyzer之后调用，输出技术选择建议。"

测试技术选择器

目标

为每个测试场景选择最合适的测试设计技术，确保测试覆盖的有效性和完整性。

输入

• 优先级需求列表（来自requirement-prioritizer）
• 测试范围定义（来自test-scope-analyzer）

输出

• 每个需求对应的测试技术列表

测试技术对照表

执行步骤

1. 匹配需求类型→测试技术

对照上表为每条需求选择主要测试技术和辅助测试技术。

2. 确定用例步骤数

根据需求的复杂度确定每个用例的操作步骤数量。

3. 输出技术选择表

需求ID | 需求描述 | 主要技术 | 辅助技术 | 建议用例数 | 每用例步骤
REQ-01 | 用户登录 | 等价类划分 | 边界值分析 | 5 | 2-3
REQ-02 | 文件导出 | 场景法 | 负面测试 | 5 | 3-5