changye01/test-case-generator

测试用例生成器

工作流程

1. 确定输入材料 - 询问需求文档路径，并确认是否有技术文档、接口文档、原型、数据库说明、已有用例可作为补充材料。
2. 拆解需求点 - 先把需求拆成页面、接口、任务、日志、历史数据修复等可测试对象。
3. 加载测试设计规则 - 读取 references/test-design-rules.md，按规则扩展正常、边界、异常、权限、日志、数据一致性、持久化和综合场景。
4. 生成场景地图草稿 - 基于 assets/scene-template.md 先在对话中输出 Markdown 场景地图草稿，明确“测什么”，并单独整理 本次确认规则 小节，用于记录用户补充的明确规则。
5. 覆盖检查与补漏 - 读取 references/coverage-checklist.md，补充缺失维度，标记信息不足待确认项和超范围项，并检查 本次确认规则 是否已回填到场景地图。
6. 确认整份场景地图 - 用户需要先确认整份场景地图草稿（包括场景分组、待确认项、超范围项）；如有修改意见，先迭代草稿。
7. 保存确认版场景地图 - 只有在用户确认整份场景地图后，才将第一阶段结果保存为独立 Markdown 文件；保存时必须覆盖目标文件，不得把旧草稿追加到确认版文件中。
8. 生成结构化测试用例 - 基于确认后的场景地图，使用 assets/test-case-template.md 输出结构化测试用例 Markdown。第二阶段最终输出模板固定为 5 列：编号 / 测试功能点 / 前置条件 / 测试步骤 / 预期结果；Markdown 默认按场景地图中的“场景分组”分段，每个场景组下使用 5 列表格，不改写为段落叙述。
9. 保存确认版结构化测试用例 - 用户确认第二阶段结果后，必须先将 结构化测试用例.md 保存到目标位置；保存时必须覆盖旧版本，不得把旧草稿追加到确认版文件中，也不得在保存前直接提示下游 test-data-generator。
10. 验证完整性 - 运行 scripts/validate_cases.py 检查结构化测试用例 Markdown 是否包含关键字段和综合场景。
11. 校验失败则回改并重新校验 - 如果校验未通过，必须先回改同一份已保存的 Markdown，再重新运行校验；只有通过后，才可视为确认版并进入下游串联建议。

默认策略

• 默认目标为覆盖全面
• 默认流程为先场景，后用例
• 默认补齐权限、日志、数据一致性、数据持久化、综合流程
• 非功能测试默认不纳入功能测试主体，只在超范围项中提示
• 覆盖全面不等于机械穷举，禁止为了“全面”输出大量重复用例
• 如果用户提供的是目录，默认将第一、二阶段文件都保存到该目录
• 如果用户提供的是需求文档文件，默认将第一、二阶段文件都保存到该需求文档同目录
• 如果用户提供了明确输出文件路径，按用户指定路径保存
• 第一阶段先输出场景地图草稿到对话中
• 用户在对话中补充的明确规则，必须沉淀到第一阶段 本次确认规则 小节
• 用户确认整份场景地图后，再保存确认版 测试场景地图.md
• 保存确认版场景地图时必须覆盖原目标文件，不得保留旧草稿残留内容
• 第二阶段默认正式输出只有：结构化测试用例.md
• 第二阶段用户确认后，必须先保存 结构化测试用例.md，保存前不得提示下游 skill
• 第二阶段保存后，必须完成 Markdown 结构校验；校验通过前不得切换到 test-data-generator
• 第二阶段 Markdown 默认按场景地图中的“场景分组”分段，每组使用表格，不改为段落式
• 如果需求明确给出多个允许角色，第二阶段默认每个允许角色至少 1 条正向用例，另补至少 1 条无权限反向用例
• 如果需求明确给出少量关键枚举值（如状态值、类型值、角色值），第二阶段默认按 1 个值至少 1 条用例 展开；仅在用户明确要求压缩时才允许合并

引导问题

第 1 步：确定输入材料

• 请提供需求文档路径；如果你已经确定了输出目录或目标文件路径，也请一并提供。
• 是否还有技术文档、接口文档、页面原型、数据库说明或已有测试用例可一起参考？
• 若你只提供目录，默认输出到该目录；若你提供需求文档文件，默认输出到需求文档同目录。
• 优先使用 Markdown (.md) 作为输入；txt 次之，docx 和 pdf 可用但建议先转成纯文本或 Markdown。
• 如果原始材料在飞书文档中，优先建议先用 Chrome 中的 Cloud Document Converter 转成 .md。
• 如果拿到的是 .docx 文件，也建议先转成 .md，再交给本 Skill 处理。
• 转换后应快速检查标题层级、表格、编号和图片引用是否正常，再继续生成测试用例。

第 2 步：确定范围与目标

• 本次默认按“覆盖全面”生成，是否有明确不测范围？
• 默认会先输出场景地图草稿，待你确认并保存 测试场景地图.md 后，再展开结构化测试用例；是否还有命名、输出位置或格式约束？

输出要求

第一阶段：场景地图

必须包含：

• 功能模块
• 需求点列表
• 场景分组
• 补充维度
• 信息不足待确认项
• 超范围项

第一阶段输出要求：

• 必须先在对话中给出场景地图草稿，供用户整体审阅
• 用户未确认前，不得保存正式文件，也不得进入第二阶段
• 用户可以修改场景分组、待确认项、超范围项和覆盖范围
• 用户确认后，才保存为独立 Markdown 文件
• 若用户只提供目录，默认保存到该目录；若用户提供需求文档文件，默认保存到需求文档同目录
• 用户补充确认过的明确规则必须单独沉淀为 本次确认规则
• 正式保存时必须覆盖目标文件，不得把旧草稿或历史版本拼接到确认版文件中
• 不得被第二阶段输出覆盖
• 推荐文件名：<需求名称>_测试场景地图.md

第二阶段：结构化测试用例

必须包含：

• 编号
• 测试功能点
• 前置条件
• 测试步骤
• 预期结果
• Markdown 默认按场景地图中的“场景分组”分段；每个场景组下使用 5 列表格，不改写为段落式
• Markdown 中场景分组名称与顺序应继承第一阶段场景地图
• 推荐文件名：<需求名称>_结构化测试用例.md
• 用户确认第二阶段结果后，必须先保存 结构化测试用例.md
• 若用户只提供目录，默认保存到该目录；若用户提供需求文档文件，默认保存到需求文档同目录
• 未保存前不得提示下游 test-data-generator
• 保存后必须立即运行校验脚本；未通过前不得视为确认版，也不得切换到下游 skill
• 如果存在明确权限角色列表，必须展开到角色级别，不得只写“有权限用户”
• 如果存在少量关键枚举值，默认拆成独立用例，不得为了去重把多个关键值压成 1 条
• 模块、场景组、关联需求点、优先级 等信息默认保留在第一阶段场景地图中，不再作为第二阶段默认列

资源

• 测试设计规则: 见 references/test-design-rules.md
• 覆盖检查清单: 见 references/coverage-checklist.md
• 内容质量评审标准: 见 references/quality-rubric.md
• 场景地图模板: 见 assets/scene-template.md
• 测试用例模板: 见 assets/test-case-template.md
• 测试用例示例: 见 assets/test-case-example.md

验证

生成结构化测试用例后，运行：

python scripts/validate_cases.py <测试用例文件路径>

完成结构校验后，再参考 references/quality-rubric.md 做一轮内容质量自查，重点检查可追溯、可执行、可验证、不混测、不重复和关键覆盖是否到位。

如果提示缺少关键字段或缺少综合场景，必须先回改已保存的 Markdown 再重新校验；如果结构无问题但仍存在漏测、弱预期、混测或重复问题，则按质量评审标准继续修正。

串联建议

完成验证并确认这版结构化测试用例可作为后续输入后，若用户下一步目标是“根据已确认测试用例准备执行数据”，建议继续提供：

• 已确认的 结构化测试用例.md
• 技术方案 / 接口说明
• reference-pack 路径（通常位于 reference-packs/...，包含 tables/*.sql + table_samples/*.csv）

其中技术方案是 test-data-generator 的核心输入之一；如果涉及派生字段、状态映射、历史修复、权限规则或日志映射，应该优先补齐技术方案，再切换到 test-data-generator。随后由其在保留 结构化测试用例.md 作为基线稿的前提下，继续输出 测试执行清单.md。