nuonuo0518 测试用例生成器
工作流程
Step 1：收集文档
根据用户提供的输入读取文档（可并行）：
- iWiki 需求文档：通过
mcp__iWiki__getDocument工具读取，入参为 docid 或从 URL 中提取的 docid - 本地 Figma 设计文档：用 Read 工具读取本地
.md文件（通常位于功能目录下，文件名含"figma设计文档"或"交互设计"） - 本地需求文档：用 Read 工具读取
Step 2：分析并建立功能点清单
读完所有文档后，先梳理出所有可测功能点，用表格列出：
| 功能点 | 来源文档 | 计划覆盖优先级 |
|---|---|---|
| （示例）投票按钮点击 → 状态切换 | 需求文档 §3.1 | P0 |
| （示例）历史记录展示 | Figma 第5屏 | P1 |
这一步的目的是在提问和写作之前就和用户对齐"我们打算测哪些东西"，避免写完才发现整块遗漏。将此清单展示给用户，让用户有机会在正式开始前补充或排除。
然后系统性地检查矛盾和缺失：
- 两份文档间的逻辑矛盾（如按钮状态描述不一致、流程步骤不一致）
- 文档内的缺失信息（如重置目标状态不明确、Toast 文案未指定）
- 设计文档中仅有组件列表但无功能映射的模糊点
将所有疑问集中，一次性通过 AskUserQuestion 工具提问——不要边写边问，不要在不同轮次分散提问。
Step 3：复述理解后编写
收到用户对所有疑问的答复后，先用简短的几条复述关键澄清结论，例如：
"根据您的确认：
- 投票后按钮立即变灰，不等服务器返回
- Toast 文案为"投票成功"，3秒后消失
- 历史记录按时间倒序，无分页
我将按此标准编写测试用例。"
这给用户一个纠错窗口，不需要用户明确回复才继续——复述后直接开始编写即可。
获得理解确认后，开始编写测试用例。
禁止捏造规则（严格执行）：
- 每条测试用例的预期结果必须有文档原文或用户答复作为依据
- 对于文档中未明确描述的细节，用"[待确认]"标注，不得自行推断
- 不得添加文档未提及的测试场景（如"网络断开重连"，除非文档有描述）
Step 4：输出文档
按用户指定路径保存，文件名格式：[功能名称]测试用例.md
文档格式参考 assets/测试用例模板.md，核心结构：
- 功能概述（含核心交互说明）
- 测试用例（按功能模块分章节，Markdown 表格）
- 测试优先级（P0/P1/P2/P3）
- 澄清问题与结论（列出所有发问及答复，便于追溯）
- 功能点覆盖验证表（Step 2 中列出的功能点 → 对应用例 ID，确认无遗漏）
| 功能点 | 对应用例 ID |
|---|---|
| 投票按钮点击 → 状态切换 | TC_001, TC_002, TC_003 |
| 历史记录展示 | TC_011, TC_012 |
测试用例编写规范
参见 references/writing-rules.md 获取完整规范，核心要点：
- 用例ID全局不重复，格式
TC_NNN，模块间留间隔（每模块起始编号递增10） - 操作步骤用
<br>分隔多步 - 预期结果包含：UI 变化 + 数据变化 + Toast/弹窗文案（文案需与文档一致）
- 优先级：P0=核心主流程，P1=重要场景，P2=次要交互，P3=边界/性能/异常
- 禁止在预期结果中出现具体色值（如
#E5183A）和像素尺寸（如62×30px）——颜色和尺寸由视觉设计决定，不在功能测试验收范围内；描述 UI 变化时只说"变为红色""显示角标"即可，无需精确数值
文档模板
输出格式模板见 assets/测试用例模板.md。