Menu
当用户提供需求分析报告或功能描述时触发，基于结构化的需求分析设计全场景手工功能测试用例，覆盖正向、反向、边界、异常四类场景，输出标准化 CSV 文件供测试人员直接使用。这是测试用例生成链的第二环。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | testcase-generator |
| description | 当用户提供需求分析报告或功能描述时触发，基于结构化的需求分析设计全场景手工功能测试用例，覆盖正向、反向、边界、异常四类场景，输出标准化 CSV 文件供测试人员直接使用。这是测试用例生成链的第二环。 |
当用户消息中包含以下任一关键词时，必须激活此技能：
生成用例创建测试用例创建用例generate testtest case触发后，向用户确认："已激活 TestCase Generator 技能，将基于需求分析生成覆盖率 95%+ 的手工功能测试用例。"
本技能是测试用例生成链的第二环：
[需求分析评审] → [测试用例生成] → [测试用例评审]
上一步 ★ 当前 下一步
核心职责：将结构化的需求分析结果转化为高覆盖率、可执行的手工功能测试用例，输出测试人员可以直接使用的 CSV 文件。
本技能采用文件驱动的上下文管理模式，所有中间产出和最终交付物都通过文件系统持久化。
_progress.json 文件追踪执行进度和所有产出文件路径| 步骤 | 输出文件 | 说明 |
|---|---|---|
| 初始化 | _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": []
}
本技能接受两种输入模式：
直接使用 requirement-analysis 技能输出的 JSON 报告文件。
| 输入项 | 说明 | 必需 |
|---|---|---|
| 需求分析报告 JSON | requirement_analysis_xxx.json 文件路径 | 是 |
当检测到工作区内存在 requirement_analysis_*.json 文件时，自动读取并解析。
用户直接描述功能效果或提供需求信息，此时技能内部执行简化版需求分析。
| 输入项 | 说明 | 必需 |
|---|---|---|
| 功能描述/业务场景 | 自然语言需求描述 | 是 |
| 原型图/截图 | UI 设计稿 | 可选 |
一份 CSV 文件，包含完整的手工功能测试用例，测试人员可直接用于执行手工测试。同时作为 testcase-review 技能的输入。
| 列名 | 说明 | 示例 |
|---|---|---|
| 用例编号 | 唯一标识，格式 TC-XXX | TC-001 |
| 所属模块 | 功能模块名称 | 用户管理 |
| 功能点 | 具体功能点 | 用户注册 |
| 用例标题 | 简明描述测试目的，格式：[条件/操作]_[预期结果] | 输入有效手机号注册_注册成功跳转首页 |
| 前置条件 | 执行用例前需满足的条件 | 1.用户未注册 2.手机号可正常接收短信 |
| 优先级 | P0/P1/P2/P3 | P0 |
| 用例类型 | 正向/反向/边界/异常 | 正向 |
| 测试步骤 | 编号的操作步骤（步骤间用换行分隔） | 1.打开注册页面 2.输入手机号13800138000 3.点击获取验证码... |
| 预期结果 | 与测试步骤一一对应的预期结果（步骤间用换行分隔） | 1.注册页面正常展示 2.手机号输入成功 3.验证码发送成功... |
| 关联规则 | 关联的业务规则ID | R1,R3 |
| 测试结果 | 留空，手工测试时填写 | |
| 测试状态 | 留空，手工测试时填写（通过/失败/阻塞/跳过） | |
| 执行人 | 留空，手工测试时填写 | |
| 备注 | 补充说明 |
在执行任何步骤之前，检查工作区是否已有 _progress.json，如有则在其基础上追加本技能信息；如无则创建。
标记：[TC-STEP-1-DONE]
📁 文件操作：
requirement_analysis_*.json（上游技能产出）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 技能进行需求分析，可提高用例质量和覆盖度。
标记：[TC-STEP-2-DONE]
📁 文件操作：
tc_step1_context.mdtc_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** |
标记：[TC-STEP-3-DONE]
📁 文件操作：
tc_step1_context.md、tc_step2_strategy.mdtc_step3_positive_cases.md_progress.json（step3 → in_progress → completed）开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计覆盖所有正常业务流程主路径的正向用例。
设计原则：
输出格式（写入 tc_step3_positive_cases.md）：
# Step 3: 正向场景用例设计
## TC-001: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P0 |
| 用例类型 | 正向 |
| 关联规则 | R1,R2 |
| 前置条件 | 1.用户未注册 2.手机号13800138000可正常接收短信 |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 打开浏览器，访问注册页面 | 注册页面正常展示，包含手机号输入框、验证码输入框、密码输入框 |
| 2 | 在手机号输入框输入 13800138000 | 手机号正常显示，无报错提示 |
| ... | ... | ... |
## TC-002: [用例标题]
[同上格式]
标记：[TC-STEP-4-DONE]
📁 文件操作：
tc_step1_context.md、tc_step2_strategy.mdtc_step4_negative_cases.md_progress.json（step4 → in_progress → completed）开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计违反业务规则和输入约束的反向用例，每条规则至少对应 1 条反向用例。
设计原则：
输出格式（写入 tc_step4_negative_cases.md）：
# Step 4: 反向场景用例设计
## TC-XXX: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P0 |
| 用例类型 | 反向 |
| 关联规则 | R1 |
| 前置条件 | 1.已在注册页面 |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 手机号输入框保持为空 | 输入框为空 |
| 2 | 直接点击"获取验证码"按钮 | 提示"请输入手机号"，验证码不发送 |
## 必须覆盖的反向场景清单
- [ ] 每个必填字段逐个为空
- [ ] 字段格式不合法（如手机号输入字母、邮箱缺少@）
- [ ] 违反唯一性约束（如重复注册）
- [ ] 违反业务状态约束（如已禁用账号登录）
- [ ] 未授权/未登录操作
- [ ] 无权限操作（越权访问）
标记：[TC-STEP-5-DONE]
📁 文件操作：
tc_step1_context.md、tc_step2_strategy.mdtc_step5_boundary_cases.md_progress.json（step5 → in_progress → completed）开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计边界值和极端输入的测试用例。
设计原则：
输出格式（写入 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位 |
标记：[TC-STEP-6-DONE]
📁 文件操作：
tc_step1_context.md、tc_step2_strategy.mdtc_step6_exception_cases.md_progress.json（step6 → in_progress → completed）开始前必须先读取 step1 和 step2 的输出文件获取上下文和策略。
设计系统异常、环境异常和非常规操作的测试用例。
设计原则：
输出格式（写入 tc_step6_exception_cases.md）：
# Step 6: 异常场景用例设计
## TC-XXX: [用例标题]
| 属性 | 内容 |
|------|------|
| 所属模块 | [模块名] |
| 功能点 | [功能点名] |
| 优先级 | P2 |
| 用例类型 | 异常 |
| 关联规则 | — |
| 前置条件 | 1.已填写完所有注册信息 2.网络正常 |
| 步骤 | 测试步骤 | 预期结果 |
|------|---------|---------|
| 1 | 断开网络连接 | 网络已断开 |
| 2 | 点击"注册"按钮 | 提示"网络连接异常，请检查网络后重试"，不出现白屏 |
| 3 | 恢复网络连接 | 网络恢复 |
| 4 | 再次点击"注册"按钮 | 注册请求正常发送，注册成功 |
标记：[TC-STEP-7-DONE]
📁 文件操作：
tc_step3_positive_cases.md、tc_step4_negative_cases.md、tc_step5_boundary_cases.md、tc_step6_exception_cases.mdtc_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 补充用例，补充后重新写入对应文件并更新本文件的覆盖度统计。
标记：[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.mdtestcases_{功能名}_{YYYYMMDD_HHMMSS}.csv_progress.json（step8 → in_progress → completed，更新 deliverables）开始前必须先读取所有用例文件（step3~step6）和编排文件（step7），汇总为 CSV。
将所有用例输出为标准化 CSV 文件，供测试人员直接使用。
CSV 格式规范：
\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使用工具将文件写入工作区。
标记：[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技能评审和优化测试用例，输入文件为上述输出文件路径。
[TC-STEP-X-DONE] 标记_progress.jsonPostman collections, environments, pre-request scripts, and Newman CI
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.