generator-testcase-xmind

name	generator-testcase-xmind
description	资深测试工程师技能。当用户提供用户故事（User Story）文本或文档，需要拆解测试点、生成测试用例、进行测试设计与评审时，使用此技能。输出为 XMind 思维导图格式的完整测试点清单，覆盖功能、边界值、异常、业务规则、非功能性五大维度，并按 P0/P1/P2 标注优先级。

测试用例 XMind 生成器

概述

本技能以资深测试工程师的视角，根据用户提供的用户故事（User Story），系统化拆解测试点，生成结构化的测试点清单，并以 XMind 思维导图格式输出。覆盖功能、边界值、异常、业务规则、非功能性五大测试维度，确保测试点不遗漏、不重复。

触发条件

当用户出现以下场景时使用本技能：

• 提供用户故事（User Story）文本，要求拆解测试点
• 提供用户故事文档（.docx / .txt），要求生成测试用例
• 要求对需求进行测试评审
• 要求生成测试点思维导图
• 提及"测试点"、"测试用例"、"测试设计"、"功能测试"、"黑盒测试"等关键词

工作流程

第一步：接收与解析用户故事

1. 接收用户输入：

   • 用户直接输入用户故事文本
   • 用户上传用户故事文档（.docx / .txt 文件）→ 使用 Read 工具读取文件内容

2. 解析用户故事：

   • 提取每个用户故事的编号（如 US-001）、标题和描述
   • 如果用户未提供编号，自动按 US-001、US-002... 编号
   • 识别用户故事中的关键功能点、输入字段、业务规则、异常分支

3. 识别输入项与约束：

   • 找出所有涉及用户输入的字段（表单、参数等）
   • 找出所有明确的业务规则和约束条件
   • 找出所有明确提到的异常场景

第二步：系统化拆解测试点

按照以下五大维度逐一拆解，确保不遗漏：

2.1 功能测试点

从用户故事中提取所有功能点，分为：

• 正常流程：用户故事描述的核心"快乐路径"
• 分支流程：用户故事中的条件分支、可选路径

拆解规则：

• 每个功能点至少一个正向测试点
• 涉及条件判断的，每个分支一个测试点
• 涉及多种角色/权限的，每种角色一个测试点
• 涉及操作顺序的，不同顺序各一个测试点

2.2 边界值测试点

对涉及输入的测试点，必须应用等价类划分和边界值分析：

• 输入长度边界：最小长度-1、最小长度、最小长度+1、最大长度-1、最大长度、最大长度+1
• 数值范围边界：下限-1、下限、下限+1、上限-1、上限、上限+1
• 字符类型边界：合法字符、非法字符、特殊字符、空格
• 时间/日期边界：起始日-1天、起始日、结束日、结束日+1天、跨时区

拆解规则：

• 每个有效等价类至少覆盖一次
• 每个无效等价类单独设计测试点（避免缺陷掩盖）
• 参照 references/testing_methodology.md 中边界值分析章节

2.3 异常测试点

覆盖三类异常场景：

• 错误输入异常：无效格式、超范围值、非法字符、空输入、全空格
• 系统异常：服务不可用、数据库异常、文件不存在、权限不足
• 网络异常：请求超时、网络中断、弱网环境、重复提交

拆解规则：

• 覆盖用户故事中明确提到的所有异常分支
• 补充用户故事未明确但测试视角应覆盖的隐含异常场景
• 每个异常场景验证错误提示的准确性和用户引导

2.4 业务规则测试点

覆盖业务逻辑约束和状态转换：

• 业务逻辑约束：前置条件、互斥规则、依赖关系、唯一性约束
• 状态转换规则：合法状态转换、非法状态转换、并发状态变更

拆解规则：

• 使用判定表法确保逻辑组合全覆盖
• 使用状态迁移法确保所有状态转换被测试
• 参照 references/testing_methodology.md 中相关章节

2.5 非功能性测试点

从三个维度补充：

• 性能：响应时间、并发能力、吞吐量、资源占用、长时间运行稳定性
• 安全性：输入验证（SQL注入/XSS/命令注入）、认证授权、数据保护、接口安全
• 兼容性：浏览器兼容、设备兼容、系统兼容、分辨率适配、网络环境适配

拆解规则：

• 涉及用户输入的功能点必须补充安全性测试点
• 涉及大量数据/高并发的功能点必须补充性能测试点
• 涉及前端展示的功能点必须补充兼容性测试点

第三步：标注优先级

对每个测试点按以下标准标注优先级：

优先级	判定标准	典型场景
P0	阻塞主流程、影响核心功能、无替代方案	核心功能正向流程、安全漏洞、数据丢失风险
P1	重要功能异常、有替代方案、影响用户体验	分支流程、边界值、常见异常场景
P2	边缘场景、UI细节、低概率异常	极端边界值、罕见异常、兼容性细节

第四步：构建 JSON 数据

将所有测试点整理为结构化 JSON 数据，格式遵循 references/json_template.md 规范：

{
    "title": "项目名称 - 测试点分析",
    "user_stories": [
        {"id": "US-001", "title": "...", "description": "..."}
    ],
    "categories": [
        {
            "name": "功能测试",
            "test_points": [
                {
                    "id": "TC-001",
                    "description": "测试点描述",
                    "user_story_id": "US-001",
                    "priority": "P0",
                    "sub_points": ["子点1", "子点2"]
                }
            ]
        }
    ]
}

编号规则：

• 测试点编号全局连续（TC-001, TC-002, ...），不按分类重新编号
• 五大分类名称固定为：功能测试、边界值测试、异常测试、业务规则测试、非功能性测试

第五步：生成 XMind 文件

1. 将 JSON 数据写入临时文件
2. 执行 scripts/generate_xmind.py 脚本生成 XMind 文件：

python3 <skill_path>/scripts/generate_xmind.py <input.json> <output.xmind>

3. 将生成的 XMind 文件交付给用户

注意事项

• 不遗漏：五大维度必须逐一覆盖，不可跳过任何一个分类
• 不重复：同一测试点不跨分类重复出现，边界值测试与功能测试中的正向验证要区分清楚
• 等价类原则：每个有效等价类至少覆盖一次，每个无效等价类单独设计用例
• 隐含场景：除用户故事明确提到的场景外，必须补充测试视角的隐含异常
• 优先级判断：严格按照 P0/P1/P2 标准标注，不因个人偏好调整
• 输出格式：最终必须以 XMind 思维导图格式交付，确保用户可直接打开查看和编辑