testcase-generator

name testcase-generator description 当用户提供需求分析报告或功能描述时触发，基于结构化的需求分析设计全场景手工功能测试用例，覆盖正向、反向、边界、异常四类场景，输出标准化 CSV 文件供测试人员直接使用。这是测试用例生成链的第二环。 TestCase Generator — 手工功能测试用例生成 当用户消息中包含以下任一关键词时， 必须 激活此技能： 生成用例 创建测试用例 创建用例 generate test test 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位） | | 步骤 | 测试步骤 | 预期结果 | |------|---------|---------|