testcase-generator

name	testcase-generator
description	当用户提供需求分析报告或功能描述时触发，基于结构化的需求分析设计全场景手工功能测试用例，覆盖正向、反向、边界、异常四类场景，输出标准化 CSV 文件供测试人员直接使用。这是测试用例生成链的第二环。

TestCase Generator — 手工功能测试用例生成

当用户消息中包含以下任一关键词时，必须激活此技能：

• 生成用例
• 创建测试用例
• 创建用例
• generate test
• test case

触发后，向用户确认："已激活 TestCase Generator 技能，将基于需求分析生成覆盖率 95%+ 的手工功能测试用例。"

---

技能定位

本技能是测试用例生成链的第二环：

[需求分析评审] → [测试用例生成] → [测试用例评审]
  上一步          ★ 当前            下一步

核心职责：将结构化的需求分析结果转化为高覆盖率、可执行的手工功能测试用例，输出测试人员可以直接使用的 CSV 文件。

---

文件上下文管理协议

本技能采用文件驱动的上下文管理模式，所有中间产出和最终交付物都通过文件系统持久化。

核心原则

1. 写入优先：每个步骤完成后，必须立即使用文件写入工具将产出物写入对应文件
2. 读取优先：每个步骤开始前，必须先使用文件读取工具加载前置步骤的输出文件
3. 文件即上下文：禁止仅依赖对话历史传递步骤间信息，所有跨步骤引用必须通过读取文件获取
4. 索引追踪：通过 _progress.json 文件追踪执行进度和所有产出文件路径
5. 链式继承：优先读取上游技能（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.输入手机号[phone].点击获取验证码...
预期结果	与测试步骤一一对应的预期结果（步骤间用换行分隔）	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.手机号[phone]可正常接收短信 |

| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 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.输入手机号[phone]
3.点击获取验证码
4.输入收到的验证码
5.输入密码Abc@1234
6.确认密码Abc@1234
7.勾选用户协议
8.点击注册按钮","1.注册页面正常展示
2.手机号正常显示
3.验证码发送成功,按钮60秒倒计时
4.验证码正常输入
5.密码掩码显示
6.确认密码掩码显示
7.复选框选中
8.提示注册成功,跳转首页",R1;R2;R3,,,,

文件生成规则：

1. 第一行为表头
2. 用例按编号排序
3. 同一模块的用例连续排列
4. 同一功能点内按类型排序：正向 → 反向 → 边界 → 异常
5. 步骤和预期结果中的换行用实际 \n 处理，整个字段用双引号包裹
6. 关联规则使用分号 ; 分隔多个规则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 技能评审和优化测试用例，输入文件为上述输出文件路径。

---

关键约束

1. 不得跳步：必须从 Step 1 到 Step 9 顺序执行，每步完成后输出 [TC-STEP-X-DONE] 标记
2. 不得合并步骤：每个步骤独立输出，确保用户可逐步审阅
3. 覆盖度硬指标：综合场景覆盖度必须 ≥95%，不达标时必须补充用例
4. 每功能点至少 3 类场景：正向、反向、边界缺一不可
5. 步骤必须可操作：每个步骤要包含具体操作位置、输入数据，不能模糊描述
6. 预期结果必须可验证：预期结果要具体到可判断 pass/fail 的程度
7. 步骤与预期一一对应：测试步骤和预期结果必须逐条对应
8. 文件必须落盘：每个步骤的产出必须使用文件写入工具实际写入文件，不能只在对话中展示
9. 读取优先：每个步骤开始前必须通过文件读取工具加载前置步骤的输出文件，禁止仅依赖对话记忆
10. 进度索引同步：每个步骤开始和完成时都必须更新 _progress.json
11. UTF-8 BOM 编码：确保 CSV 文件 Excel 打开不乱码
12. 链式输入优先：检测到需求分析报告时必须优先使用，不重新分析