软件功能测试用例设计

一、先选交付格式（未选定禁止生成）

生成用例或测试要点之前，必须让用户选定交付格式。选定前：不写文件、不输出用例/要点正文、不往下执行第二～四节、不读 xmind/excel/testpoint 细则。评审已有用例不选格式，直接按第二节「评审已有用例」。未指定格式就开写，只能猜成某一种交付物，后面经常和要入库的格式对不上。

只有下面这些情况才跳过选择（只认说交付物的词，说输入材料的不算，如「飞书表格里的需求」「按这些测试点」；信号冲突就问）：

• 「XMind / 思维导图 / xmind格式」→ XMind 版
• 「Excel / CSV / 表格」「含前置·步骤·预期」→ Excel/CSV 完整可执行。只说「完整版」「可执行」不算
• 「测试要点 / 测试点」→ 只要测试要点
• 附了现成的用例文件说「照这个格式」→ 按该文件对应的那一项
• 同一次对话里已经选过，只是补条、改稿或按同一格式再出一版。要点确认后展开成用例是新交付物，XMind / Excel 仍按本节定
• 工作区已有这个需求的 STATE 文件（第三节第 8 步）且未到「已交付」→ 格式以 STATE 为准，续跑

「直接产出 / 不要再问 / 按默认」但没说出具体格式 → 仍要选，禁止擅自按 XMind 开写；回复里带一句原因（格式定错，后面的生成和评审整条白跑），只问这一个。无人值守运行时 prompt 里须写明格式，否则会停在这里。

如何选：环境有结构化选项工具（如 AskQuestion）时，发起单选，标题用「请选择用例交付格式」。没有该工具则在回复里列出下面三项并停步等待。需求材料也还没给时，同一条回复里一并要需求，不分两轮问。

选项固定为下面三项（第一项可标「常用」）：

1. XMind 版（交 Markdown 由 XMind 导入；每条只有标题和预期，无前置、步骤）
2. Excel/CSV 完整可执行（交 CSV；含前置、步骤、预期）
3. 只要测试要点（不写用例）

选定之后，按第二节路由读对应文件并生成。

二、产物路由与评审已有用例

{输出目录} 三种格式通用：默认 testcases/，用户指定了目录就用该目录，不再镜像到 testcases/。{需求名称} 取需求文档标题，没有标题就用用户对这份需求的叫法，全程沿用。表里的规则主 agent 读；闭环里的写作 / 评审子 agent 按 review-loop 模板自己再读一遍，不靠主 agent 转述。

评审已有用例

输出问题清单，不直接改稿。主 agent 自己按 references/review-loop.md 第三节「初评」模板执行，把自己当那个评审 agent：先读的规则、评审方法、反向核对、进清单前剔除、输出合同都照模板，不另立口径。与闭环只有下面几处不同：

1. 输入是用户给的用例文件和需求。需求按 references/testcase-design-rules.md 1.1 取全；没有需求就只评 testcase-design-rules.md 第三节的编写规范和格式指南，不评覆盖，报告开头写明「未评覆盖：无需求」。
2. 没有拆解文件：范围、不测、已登记缺口从需求和用例自带的范围声明 / 备注里取；评审方法 1 只做「顺需求原文扫」那一半，检查项 6「搬运」不适用。
3. 脚本只读 .csv / .md；.xlsx / .xmind 先另存为 CSV / Markdown 再跑，转不了就跳过脚本、按格式指南逐条核对结构，并在报告里写明。脚本按本 skill 的格式合同校验：评审本 skill 产出的文件时 FAIL 全部进清单；评审别处来的文件时 FAIL 单列为「与本 skill 格式的差异」、不计入判定，用户要求按本 skill 格式入库时才算需修改。
4. 报告写在回复里，不落 work/，不写评审指引。

三、生成-评审闭环（仅 XMind / Excel）

主 agent 只做取材、拆解、派生、收集、修复、写指引、交付，不代写全量用例正文；按评审清单补写或改写单条属于修复，由主 agent 落盘。落盘规范、提示词模板与修复原则见 references/review-loop.md；派生子 agent 前把模板里的 <skill根目录> 替换成本 SKILL.md 所在目录的绝对路径。

目录约定（{输出目录}、{需求名称} 的取值见第二节）：用例文件写 {输出目录}/{需求名称}-测试用例.md（XMind）或 .csv（Excel），同一需求只写一份、不论条数，用户明确要求拆分才分文件；人工评审指引（下文简称指引）写 {输出目录}/{需求名称}-评审指引.md，与用例同一目录；过程文件（需求原文、拆解结论、评审报告、修复说明、遗留清单、STATE、图片副本）一律写 {输出目录}/work/。

开始前先查 {输出目录}/work/ 下有没有这个需求的 -STATE.md：有且阶段未到「已交付」→ 不从头来，直接按第 8 步续跑。

1. 取材与拆解：先写 STATE（模板见 review-loop 第五节），再按 references/testcase-design-rules.md 1.1 取全需求（飞书四类，拉到什么落什么，拉不到的写明缺口），按 review-loop 第一节的结构落盘为 {输出目录}/work/{需求名称}-需求原文.md；再按 testcase-design-rules.md 第一节做需求拆解，产出原子需求清单（每条一个判定点：对象 + 规则/约束）与范围 / 不测 / 缺口 / 范围判断，落盘为 {输出目录}/work/{需求名称}-拆解.md。缺口标【待确认】继续写，只有连测哪块都定不下来才问一次（提问策略见 testcase-design-rules.md 第一节）。
2. 派生写作 agent：只派 1 个，用 review-loop 第二节模板，模板里只给第 1 步两个文件的路径、不贴全文。禁止按模块拆派多个（2.1 的共享规则折叠、代表字段选择要全局视角，拆派会各写各的）、禁止主 agent 代写全量正文。记下写作 agent id。
3. 收集：跑 python scripts/validate_testcase.py <产物>；再把写作 agent 回报的「未覆盖 R」与拆解的不测、范围判断比对。validate FAIL 或 R 对不上 → resume 同一写作 agent 只补结构和漏的 R，最多 2 次，不算评审轮次；仍 FAIL 则主 agent 自己补结构（修层级、标记不算写正文），R 仍对不上的留给评审。通过才进评审。
4. 初评（r1）：新开 1 个全新评审 agent（禁止 resume 写作 agent 充当评审），用 review-loop 第三节模板。评审只挑刺、禁止改文件。报告写到 {输出目录}/work/{需求名称}-评审-r1.md。记下评审 agent id。
5. 修复：判「需修改」→ 主 agent 先按 review-loop 第四节做准入过滤。过滤后清单为空 → 视同 r1 通过，不开 r2，回复里写明剔除理由。否则按剩下的清单逐条直接改（不问用户、不派修复 agent），逐条记修复说明，改完再跑 validate。
6. 复审（r2）：resume 初评那个评审 agent 做增量复审（只验本轮改动 + 是否修出新问题），报告写 {输出目录}/work/{需求名称}-评审-r2.md。id 丢失或环境不支持 resume，则新开一个只做增量复审的 agent，仍计入第 2 轮。
7. 出口（评审最多 2 轮）：r1 或 r2 通过，或 r2 仍需修改而主 agent 已做完最后一遍修复并 validate 通过 → 用例定稿。定稿后按 references/review-guide.md 写 {输出目录}/{需求名称}-评审指引.md，再交付；之后用例再改，指引整份重抽。用户拍板待确认后：按结论改用例（去掉【待确认】或改预期）、跑 validate、重抽指引，不重开评审。回复里说明评审结论（第几轮通过，或遗留文件路径）并给出指引路径；指引全文不贴进回复。禁止第 3 次生成评审。指引不进入评审轮次。
8. 断点续跑：STATE 在第 1 步开始时写入，每完成一个阶段更新一次（字段见 review-loop 第五节）。中断后接手先读 STATE 按「下一步」续跑：需求原文、拆解、产物已写的不重做，报告已落盘不重评，agent id 丢失或环境不支持 resume 按 fallback 新开。阶段已是「已交付」但指引文件不存在 → 只补写指引，不重写用例。

四、执行约定

• scripts/、references/ 都相对本 SKILL.md 所在目录。主 agent 自己跑脚本时也要换成绝对路径：当前工作目录通常是用户的项目，不是 skill 目录。
• 用户要 .xmind 时交 Markdown，说明用 XMind 按标题导入。要表格时直接交 CSV。不要为了转格式去装新依赖或编写转换器。
• 产物写完后，环境有 Python 时运行 python scripts/validate_testcase.py <产物文件>（部分环境是 python3）。有 FAIL 项先修好再交付。没有 Python：按对应格式指南逐条核对结构，回复和指引证据列写明「未跑脚本」。CSV 不带 BOM 时，Excel 打开会乱码，用 python scripts/validate_testcase.py --fix-bom <csv> 补齐。