| name | testcase-generator |
| description | 当用户提供需求分析报告或功能描述时触发，基于结构化的需求分析设计全场景手工功能测试用例，覆盖正向、反向、边界、异常四类场景，输出标准化 CSV 文件供测试人员直接使用。这是测试用例生成链的第二环。 |
TestCase Generator — 手工功能测试用例生成
当用户消息中包含以下任一关键词时，必须激活此技能：
生成用例创建测试用例创建用例generate testtest case
触发后，向用户确认："已激活 TestCase Generator 技能，将基于需求分析生成覆盖率 95%+ 的手工功能测试用例。"
技能定位
本技能是测试用例生成链的第二环：
[需求分析评审] → [测试用例生成] → [测试用例评审]
上一步 ★ 当前 下一步
核心职责：将结构化的需求分析结果转化为高覆盖率、可执行的手工功能测试用例，输出测试人员可以直接使用的 CSV 文件。
文件上下文管理协议
本技能采用文件驱动的上下文管理模式，所有中间产出和最终交付物都通过文件系统持久化。
核心原则
- 写入优先：每个步骤完成后，必须立即使用文件写入工具将产出物写入对应文件
- 读取优先：每个步骤开始前，必须先使用文件读取工具加载前置步骤的输出文件
- 文件即上下文：禁止仅依赖对话历史传递步骤间信息，所有跨步骤引用必须通过读取文件获取
- 索引追踪：通过
_progress.json 文件追踪执行进度和所有产出文件路径
- 链式继承：优先读取上游技能（requirement-analysis）的产出文件作为输入
文件清单
| 步骤 | 输出文件 | 说明 |
|---|
| 初始化 | _progress.json | 进度索引（如已存在则追加/更新） |
| Step 1 | tc_step1_context.md | 输入解析与上下文建立 |
| Step 2 | tc_step2_strategy.md | 测试策略制定 |
| Step 3 | tc_step3_positive_cases.md | 正向场景用例 |
| Step 4 | tc_step4_negative_cases.md | 反向场景用例 |
| Step 5 | tc_step5_boundary_cases.md | 边界值场景用例 |
| Step 6 | tc_step6_exception_cases.md | 异常场景用例 |
| Step 7 | tc_step7_arrangement.md | 用例编排与覆盖度统计 |
| Step 8 | testcases_{功能名}_{timestamp}.csv | 最终 CSV 文件 |
| Step 9 | tc_step9_summary.md | 生成摘要 |
_progress.json 更新
在现有 _progress.json 基础上追加本技能的进度（如文件不存在则创建）：
{
"skill": "testcase-generator",
"started_at": "2026-03-10T13:00:00",
"status": "in_progress",
"upstream": {
"requirement_analysis_file": "requirement_analysis_xxx.json"
},
"steps": {
"step1": { "status": "not_started", "output_file": null },
"step2": { "status": "not_started", "output_file": null },
"step3": { "status": "not_started", "output_file": null },
"step4": { "status": "not_started", "output_file": null },
"step5": { "status": "not_started", "output_file": null },
"step6": { "status": "not_started", "output_file": null },
"step7": { "status": "not_started", "output_file": null },
"step8": { "status": "not_started", "output_file": null },
"step9": { "status": "not_started", "output_file": null }
},
"deliverables": []
}
输入
本技能接受两种输入模式：
模式 A：链式输入（推荐）
直接使用 requirement-analysis 技能输出的 JSON 报告文件。
| 输入项 | 说明 | 必需 |
|---|
| 需求分析报告 JSON | requirement_analysis_xxx.json 文件路径 | 是 |
当检测到工作区内存在 requirement_analysis_*.json 文件时，自动读取并解析。
模式 B：直接输入
用户直接描述功能效果或提供需求信息，此时技能内部执行简化版需求分析。
| 输入项 | 说明 | 必需 |
|---|
| 功能描述/业务场景 | 自然语言需求描述 | 是 |
| 原型图/截图 | UI 设计稿 | 可选 |
输出
一份 CSV 文件，包含完整的手工功能测试用例，测试人员可直接用于执行手工测试。同时作为 testcase-review 技能的输入。
CSV 列定义
| 列名 | 说明 | 示例 |
|---|
| 用例编号 | 唯一标识，格式 TC-XXX | TC-001 |
| 所属模块 | 功能模块名称 | 用户管理 |
| 功能点 | 具体功能点 | 用户注册 |
| 用例标题 | 简明描述测试目的，格式：[条件/操作]_[预期结果] | 输入有效手机号注册_注册成功跳转首页 |
| 前置条件 | 执行用例前需满足的条件 | 1.用户未注册 2.手机号可正常接收短信 |
| 优先级 | P0/P1/P2/P3 | P0 |
| 用例类型 | 正向/反向/边界/异常 | 正向 |
| 测试步骤 | 编号的操作步骤（步骤间用换行分隔） | 1.打开注册页面 2.输入手机号13800138000 3.点击获取验证码... |
| 预期结果 | 与测试步骤一一对应的预期结果（步骤间用换行分隔） | 1.注册页面正常展示 2.手机号输入成功 3.验证码发送成功... |
| 关联规则 | 关联的业务规则ID | R1,R3 |
| 测试结果 | 留空，手工测试时填写 | |
| 测试状态 | 留空，手工测试时填写（通过/失败/阻塞/跳过） | |
| 执行人 | 留空，手工测试时填写 | |
| 备注 | 补充说明 | |
执行步骤（必须严格按顺序，每步完成后输出标记）
初始化：创建/更新进度索引
在执行任何步骤之前，检查工作区是否已有 _progress.json，如有则在其基础上追加本技能信息；如无则创建。
Step 1: 输入解析与上下文建立
标记：[TC-STEP-1-DONE]
📁 文件操作：
- 读取（模式A）：
requirement_analysis_*.json（上游技能产出）
- 读取（模式B）：无前置文件，解析用户消息
- 写入：
tc_step1_context.md
- 更新：
_progress.json（step1 → in_progress → completed）
判断输入模式并解析需求上下文。
模式 A（链式输入）：
使用文件读取工具加载 requirement_analysis_*.json，解析其中的 modules、business_rules、user_flows 等结构。
输出格式（写入 tc_step1_context.md）：
# Step 1: 输入解析与上下文建立
## 输入模式: 链式输入（模式A）
- 输入文件: requirement_analysis_xxx.json
- 来源技能: Requirement Analysis v2.0
- 生成时间: 2026-03-10T12:00:00
## 解析结果
- 功能模块数: N 个
- 功能点数: N 个
- 业务规则数: N 个
- 操作流程数: N 个
- 完整度评分: X%
## 功能模块概要
[从 JSON 中提取的模块和功能点列表]
## 业务规则概要
[从 JSON 中提取的规则列表]
## 操作流程概要
[从 JSON 中提取的流程列表]
模式 B（直接输入）：
执行快速需求分析（精简版），提取功能模块、规则和操作流程。
输出格式（写入 tc_step1_context.md）：
# Step 1: 输入解析与上下文建立
## 输入模式: 直接输入（模式B）
- 原始描述: [用户原文]
- 状态: 未经需求分析评审，用例覆盖度可能受限
## 快速分析结果
### 功能模块
[识别的模块和功能点]
### 关键规则
[推导的业务规则]
### 操作流程
[推导的用户流程]
> 建议: 先使用 requirement-analysis 技能进行需求分析，可提高用例质量和覆盖度。
Step 2: 测试策略制定
标记：[TC-STEP-2-DONE]
📁 文件操作：
- 读取：
tc_step1_context.md
- 写入：
tc_step2_strategy.md
- 更新：
_progress.json（step2 → in_progress → completed）
开始前必须先读取 tc_step1_context.md 获取需求上下文。
基于需求分析结果，制定测试策略和覆盖目标。
输出格式（写入 tc_step2_strategy.md）：
# Step 2: 测试策略制定
## 覆盖目标
- 功能覆盖: 100%（所有 P0/P1 功能点必须覆盖）
- 规则覆盖: 100%（所有业务规则至少 1 条正向 + 1 条反向）
- 流程覆盖: 100%（所有主流程 + 关键分支流程）
- 场景覆盖: ≥95%（综合覆盖度目标）
- 步骤粒度: 每条用例步骤数 3-10 步，确保可操作性
## 用例分布规划
| 场景类型 | 预估占比 | 设计原则 |
|---------|---------|---------|
| 正向场景 | 25-30% | 覆盖所有正常业务流程的主路径 |
| 反向场景 | 30-35% | 每个校验规则至少 1 条违反用例 |
| 边界值场景 | 20-25% | 每个有约束的输入字段测试边界值 |
| 异常场景 | 10-20% | 网络异常、权限、并发、中断操作 |
## 按功能点用例规划
| 模块 | 功能点 | 正向 | 反向 | 边界 | 异常 | 合计 |
|------|--------|------|------|------|------|------|
| M1 | F1 用户注册 | 2 | 5 | 4 | 2 | 13 |
| ... | ... | ... | ... | ... | ... | ... |
| | **合计** | X | Y | Z | W | **N** |
Step 3: 正向场景用例设计
标记：[TC-STEP-3-DONE]
📁 文件操作：
- 读取：
tc_step1_context.md、tc_step2_strategy.md
- 写入：
tc_step3_positive_cases.md
- 更新：
_progress.json（step3 → in_progress → completed）
开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计覆盖所有正常业务流程主路径的正向用例。
设计原则：
- 每个主流程至少 1 条完整的端到端用例
- 使用合法、典型的输入值
- 步骤要具体到可操作级别（包含具体输入数据）
- 预期结果要与步骤一一对应
输出格式（写入 tc_step3_positive_cases.md）：
# Step 3: 正向场景用例设计
## TC-001: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P0 |
| 用例类型 | 正向 |
| 关联规则 | R1,R2 |
| 前置条件 | 1.用户未注册 2.手机号13800138000可正常接收短信 |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 打开浏览器，访问注册页面 | 注册页面正常展示，包含手机号输入框、验证码输入框、密码输入框 |
| 2 | 在手机号输入框输入 13800138000 | 手机号正常显示，无报错提示 |
| ... | ... | ... |
## TC-002: [用例标题]
[同上格式]
Step 4: 反向场景用例设计
标记：[TC-STEP-4-DONE]
📁 文件操作：
- 读取：
tc_step1_context.md、tc_step2_strategy.md
- 写入：
tc_step4_negative_cases.md
- 更新：
_progress.json（step4 → in_progress → completed）
开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计违反业务规则和输入约束的反向用例，每条规则至少对应 1 条反向用例。
设计原则：
- 每个校验规则至少 1 条违反用例
- 必填项为空测试
- 格式不合法测试
- 业务逻辑违反测试（如重复注册）
- 权限不足测试
输出格式（写入 tc_step4_negative_cases.md）：
# Step 4: 反向场景用例设计
## TC-XXX: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P0 |
| 用例类型 | 反向 |
| 关联规则 | R1 |
| 前置条件 | 1.已在注册页面 |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 手机号输入框保持为空 | 输入框为空 |
| 2 | 直接点击"获取验证码"按钮 | 提示"请输入手机号"，验证码不发送 |
## 必须覆盖的反向场景清单
- [ ] 每个必填字段逐个为空
- [ ] 字段格式不合法（如手机号输入字母、邮箱缺少@）
- [ ] 违反唯一性约束（如重复注册）
- [ ] 违反业务状态约束（如已禁用账号登录）
- [ ] 未授权/未登录操作
- [ ] 无权限操作（越权访问）
Step 5: 边界值场景用例设计
标记：[TC-STEP-5-DONE]
📁 文件操作：
- 读取：
tc_step1_context.md、tc_step2_strategy.md
- 写入：
tc_step5_boundary_cases.md
- 更新：
_progress.json（step5 → in_progress → completed）
开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计边界值和极端输入的测试用例。
设计原则：
- 字符串字段：空串、最小长度、最小长度-1、最大长度、最大长度+1、特殊字符
- 数字字段：最小值、最小值-1、最大值、最大值+1、0、负数
- 选择类字段：不选、单选、全选（如适用）
- 文件上传：空文件、最小大小、最大大小、超出大小、非法格式
输出格式（写入 tc_step5_boundary_cases.md）：
# Step 5: 边界值场景用例设计
## TC-XXX: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P1 |
| 用例类型 | 边界 |
| 关联规则 | R3 |
| 前置条件 | 1.已在注册页面 |
| 边界值说明 | 密码要求8-20位，测试下界-1（7位） |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 在密码输入框输入 "Abc@123"（7位，低于最小8位要求） | 密码正常输入 |
| 2 | 点击"注册"按钮 | 提示"密码长度不能少于8位"，注册不成功 |
## 边界值矩阵
| 字段 | 空值 | 下界-1/下界 | 上界/上界+1 | 特殊字符 | 超长输入 |
|------|------|-----------|-----------|---------|---------|
| 手机号 | "" | 10位/11位 | 11位/12位 | 字母/汉字 | 30位数字 |
| 密码 | "" | 7位/8位 | 20位/21位 | 纯数字/纯字母 | 100位 |
| 用户名 | "" | 1位/2位 | 20位/21位 | <>'";\& | 255位 |
Step 6: 异常场景用例设计
标记：[TC-STEP-6-DONE]
📁 文件操作：
- 读取：
tc_step1_context.md、tc_step2_strategy.md
- 写入：
tc_step6_exception_cases.md
- 更新：
_progress.json（step6 → in_progress → completed）
开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计系统异常、环境异常和非常规操作的测试用例。
设计原则：
- 网络异常（断网、弱网、超时）
- 操作中断（提交过程中关闭页面、重复点击）
- 并发操作（多终端同时操作）
- 浏览器兼容（前进/后退、刷新）
- 会话异常（登录过期、Token失效）
输出格式（写入 tc_step6_exception_cases.md）：
# Step 6: 异常场景用例设计
## TC-XXX: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P2 |
| 用例类型 | 异常 |
| 关联规则 | — |
| 前置条件 | 1.已填写完所有注册信息 2.网络正常 |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 断开网络连接 | 网络已断开 |
| 2 | 点击"注册"按钮 | 提示"网络连接异常，请检查网络后重试"，不出现白屏 |
| 3 | 恢复网络连接 | 网络恢复 |
| 4 | 再次点击"注册"按钮 | 注册请求正常发送，注册成功 |
Step 7: 用例编排与执行顺序
标记：[TC-STEP-7-DONE]
📁 文件操作：
- 读取：
tc_step3_positive_cases.md、tc_step4_negative_cases.md、tc_step5_boundary_cases.md、tc_step6_exception_cases.md
- 写入：
tc_step7_arrangement.md
- 更新：
_progress.json（step7 → in_progress → completed）
开始前必须先读取 step3~step6 的所有用例文件，汇总进行编排。
组织用例的执行顺序和依赖关系。
输出格式（写入 tc_step7_arrangement.md）：
# Step 7: 用例编排与执行顺序
## 按模块分组执行顺序
### 模块: [模块名]
Phase 1 - 正向主流程:
TC-001 → TC-002 → TC-003（按业务流程顺序）
Phase 2 - 反向校验:
TC-004 ~ TC-010（可独立执行，无依赖）
Phase 3 - 边界值:
TC-011 ~ TC-018（可独立执行，无依赖）
Phase 4 - 异常场景:
TC-019 ~ TC-022（需特殊环境准备）
## 用例依赖关系
- TC-005（修改用户信息）依赖 TC-001（注册成功）先执行
- TC-008（删除账号）依赖 TC-001（注册成功）先执行
## 覆盖度统计
| 覆盖维度 | 已覆盖/总数 | 覆盖率 |
|---------|-----------|--------|
| 功能点覆盖 | X/Y | XX% |
| 业务规则覆盖 | X/Y | XX% |
| 操作流程覆盖 | X/Y | XX% |
| **综合场景覆盖** | | **X%（目标 ≥95%）** |
覆盖度不达标处理：如果综合覆盖度 <95%，需要回到 Step 3~6 补充用例，补充后重新写入对应文件并更新本文件的覆盖度统计。
Step 8: 生成 CSV 文件
标记：[TC-STEP-8-DONE]
📁 文件操作：
- 读取：
tc_step3_positive_cases.md、tc_step4_negative_cases.md、tc_step5_boundary_cases.md、tc_step6_exception_cases.md、tc_step7_arrangement.md
- 写入：
testcases_{功能名}_{YYYYMMDD_HHMMSS}.csv
- 更新：
_progress.json（step8 → in_progress → completed，更新 deliverables）
开始前必须先读取所有用例文件（step3~step6）和编排文件（step7），汇总为 CSV。
将所有用例输出为标准化 CSV 文件，供测试人员直接使用。
CSV 格式规范：
- 编码：UTF-8 with BOM（确保 Excel 正确识别中文）
- 分隔符：逗号
- 文本限定符：双引号（字段内含逗号或换行时必须用双引号包裹）
- 步骤内换行：使用实际换行符
\n（在双引号包裹内）
CSV 表头和示例：
用例编号,所属模块,功能点,用例标题,前置条件,优先级,用例类型,测试步骤,预期结果,关联规则,测试结果,测试状态,执行人,备注
TC-001,用户管理,用户注册,输入有效手机号注册_注册成功跳转首页,"1.用户未注册
2.手机号可正常接收短信",P0,正向,"1.打开注册页面
2.输入手机号13800138000
3.点击获取验证码
4.输入收到的验证码
5.输入密码Abc@1234
6.确认密码Abc@1234
7.勾选用户协议
8.点击注册按钮","1.注册页面正常展示
2.手机号正常显示
3.验证码发送成功,按钮60秒倒计时
4.验证码正常输入
5.密码掩码显示
6.确认密码掩码显示
7.复选框选中
8.提示注册成功,跳转首页",R1;R2;R3,,,,
文件生成规则：
- 第一行为表头
- 用例按编号排序
- 同一模块的用例连续排列
- 同一功能点内按类型排序：正向 → 反向 → 边界 → 异常
- 步骤和预期结果中的换行用实际
\n 处理，整个字段用双引号包裹
- 关联规则使用分号
; 分隔多个规则ID
使用工具将文件写入工作区。
Step 9: 输出生成摘要
标记：[TC-STEP-9-DONE]
📁 文件操作：
- 读取：
tc_step7_arrangement.md、testcases_{功能名}_{timestamp}.csv（Step 8 产出）
- 写入：
tc_step9_summary.md
- 更新：
_progress.json（step9 → completed，顶层 status → completed）
开始前必须先读取 Step 7 的覆盖度统计和 Step 8 的 CSV 文件。
输出摘要（同时写入 tc_step9_summary.md 并在对话中展示）：
| 指标 | 结果 |
|---|
| 输入来源 | [需求分析报告 / 直接输入] |
| 功能模块 | N 个 |
| 功能点 | N 个 |
| 生成用例 | N 条 |
| — 正向 | X 条（XX%） |
| — 反向 | Y 条（YY%） |
| — 边界 | Z 条（ZZ%） |
| — 异常 | W 条（WW%） |
| 功能覆盖 | X% |
| 规则覆盖 | X% |
| 流程覆盖 | X% |
| 综合覆盖 | X% |
| 输出文件 | testcases_xxx.csv |
下一步: 使用 testcase-review 技能评审和优化测试用例，输入文件为上述输出文件路径。
关键约束
- 不得跳步：必须从 Step 1 到 Step 9 顺序执行，每步完成后输出
[TC-STEP-X-DONE] 标记
- 不得合并步骤：每个步骤独立输出，确保用户可逐步审阅
- 覆盖度硬指标：综合场景覆盖度必须 ≥95%，不达标时必须补充用例
- 每功能点至少 3 类场景：正向、反向、边界缺一不可
- 步骤必须可操作：每个步骤要包含具体操作位置、输入数据，不能模糊描述
- 预期结果必须可验证：预期结果要具体到可判断 pass/fail 的程度
- 步骤与预期一一对应：测试步骤和预期结果必须逐条对应
- 文件必须落盘：每个步骤的产出必须使用文件写入工具实际写入文件，不能只在对话中展示
- 读取优先：每个步骤开始前必须通过文件读取工具加载前置步骤的输出文件，禁止仅依赖对话记忆
- 进度索引同步：每个步骤开始和完成时都必须更新
_progress.json
- UTF-8 BOM 编码：确保 CSV 文件 Excel 打开不乱码
- 链式输入优先：检测到需求分析报告时必须优先使用，不重新分析
