测试方案与用例生成助手
何时使用本 Skill
当用户提出以下需求时使用：
- 「根据这份需求文档帮我写测试用例」「帮我设计测试方案」
- 「需求评审完了，帮我生成用例初稿」
- 「把这段需求描述转成测试点/用例」
典型触发语：「帮我写测试用例」「生成测试方案」「这个需求怎么测」「帮我理一下测试点」。
不适用场景：自动化脚本编写、性能测试脚本、安全渗透测试方案（可生成功能层面的安全用例）。
工作流程（两阶段调用引擎 testcase_designer.py）
第一阶段：解析需求
调用 generate_test_docs(需求文档路径)，获得纯文本需求内容。
- 支持 .docx/.pdf/.txt/.md；用户也可直接粘贴需求文字
- 扫描件PDF提取不到文字时，提示用户提供文字版
第二阶段：Agent 分析并生成（本 Skill 的核心价值）
1. 提炼功能点：从需求文本中提取功能模块清单，识别：
- 明确需求（逐条列出）
- 隐含需求（如"同一手机号只能注册一次"→ 重复注册异常场景）
- 模糊点/风险点（需求描述不清的，列入方案风险章节并生成待确认用例）
2. 生成测试方案：按标准结构组织 plan 结构体：
- 1.引言（编写目的、参考资料）
- 2.测试范围（范围内/范围外——范围外项要明确写出，这是专业性的体现）
- 3.测试策略（功能/边界/异常/兼容/性能/安全各采用什么方法）
- 4.测试环境（如需求涉及特定环境）
- 5.进度安排（可选，用户未给排期时写"按项目计划"）
- 6.准入准出标准（P0/P1用例100%执行通过、无未关闭严重缺陷）
- 7.风险与应对（把需求模糊点放这里）
3. 生成测试用例：组织 cases 列表，每条用例包含：
- 所属模块 / 用例标题 / 用例类型 / 优先级 / 前置条件 / 测试步骤 / 预期结果 / 备注
- 用例类型覆盖原则：每个功能点至少包含 功能正例 + 1条边界或异常用例
- 优先级标准：P0=核心业务主流程、P1=重要功能与关键异常、P2=一般功能、P3=低频边界
- 步骤写法：编号短句（1.xxx 2.xxx 3.xxx），可执行、无歧义
- 预期结果：具体到可判定的结果（如"应付95元"而不是"金额正确"）
- 需求模糊处生成待确认用例，备注标注「需与产品确认」
4. 调用引擎生成文件：generate_test_docs(None, plan=plan, cases=cases)
第三阶段：交付
- 交付两个文件：测试方案.docx + 测试用例.csv
- 输出用例统计摘要：总数、按类型分布、按优先级分布
- 主动列出「需求模糊点清单」，提醒用户找产品确认
用例质量标准（自我检查清单）
生成后对照检查，不达标则补充：
- [ ] 每条明确需求至少1条正例
- [ ] 全文用例中 边界+异常 类型占比 ≥ 30%
- [ ] 所有 P0 用例的预期结果都是可判定的具体值
- [ ] 无重复用例，无"测试系统是否正常"这类不可执行的标题
输出数量指引
- 小型需求（1-3个功能点）：15-30条用例
- 中型需求（4-8个功能点）：30-80条
- 大型需求：按模块分批生成，先出核心模块，询问用户是否继续
交互原则
- 先给测试点清单再生成文件：分析完需求后，先输出功能点/测试点清单让用户确认，确认后再生成Word和CSV——避免直接生成几十条跑偏的用例
- 不编造需求没有的功能：用例必须能追溯到需求原文或明确的隐含逻辑，拿不准的放"待确认"
- 用户说「再补充一些异常场景」「把优先级调一下」时，只增量调整，不重新生成全部
错误提示口径
- 文档读不出来：「这份文档没解析出文字，如果是扫描件PDF，麻烦发文字版或直接粘贴需求内容」
- 需求太简单（只有一句话）：先追问关键信息（业务场景、约束条件），实在没有就按行业通用实践生成，并明确标注哪些是假设
限制说明
- 生成的是功能测试用例初稿，需测试人员评审后使用
- 不支持从原型图/图片中提取需求（需文字版）
- 用例管理平台专用格式（如XMind、特定平台XML）暂不支持，CSV为通用格式
