Req to Test

工作流概览（5 分钟速览）

本 skill 将需求文档转化为测试交付物，核心流程分 5 个阶段：

5 个检查点即可覆盖 90% 场景。核心原则：先审查文档质量；审查完成后必须先询问用户是否继续；审查未达准入标准时不直接生成用例。

执行模式

artifact_meta.execution_mode：quick/full/expert，默认 full。

数据隐私：产物中不得包含真实客户 PII，需去标识化处理。不得提交至公开 Git 仓库。

产出稳定性与可复现性

• _artifacts/ 不得在每次执行间清空；后续执行基于已有 JSON 增量扩展。
• 已存在用例保留原 TC-xxx 编号、模块名和优先级。同一项目偏差 ≤ 5%。
• Excel 用 generate_test_artifacts.py（16 列固定）；HTML 用对应脚本生成。
• 详见 references/stability_contract.md。

覆盖度基线标准

详见 references/coverage_baseline.md。核心要求：
- 10 个维度按模块风险加权覆盖（高/中/低）。
- 业务流程分支覆盖 100%：作为横切审计方法，交叉验证 10 个维度是否覆盖了所有流程分支节点。不作为 coverage 字段的独立标签，而是通过审计过程验证。
- 接口与集成维度仅覆盖冒烟级别：每个核心端点至少 1 条冒烟级接口用例（正常请求→正常响应），不要求覆盖异常参数、边界值、权限拦截等深层接口场景。
- 规则追溯：核心规则 100% 覆盖，引用规则 >= 70%。
- 标签标准化：coverage 字段使用标准标签，禁用同义词变体。
- PRD 无流程图降级：当 PRD 不包含显式流程图时，生成推断流程图并请求用户确认，覆盖率目标按置信度降级。

测试用例质量标准

详见 references/case_quality_standards.md。核心要求：
- 场景名：简要概述用例校验的功能点（"验证 + [功能] + [校验点]"），不超过 25 字。详细验证逻辑放在步骤和预期结果上。
- 前置条件：必须详细到让新人可独立构造初始环境（角色/权限 + 具体数据字段值 + 页面路径/API端点）。P0/P1 建议 50~150 字。
- 步骤："N. " 编号 + 原子化 + 每步 ≥ 15 字。表单填写写明字段名和值；接口用例写明请求参数名、参数值和完整路径。
- 预期结果：与步骤对应编号 + oracle 来源标注。必须可观察、可判定，写明具体值，禁止"操作成功"等模糊描述。expected 条目数必须与 steps 条目数一致。
- 测试数据管理：P0/P1 用例的 test_data 必须包含 teardown_method（数据清理方式）和 data_isolation（数据隔离策略）。
- 受控词汇：automation/impact/type 字段使用规定枚举值。type 可用值包含 冒烟。
- coverage 交叉标注：每条用例至少 1 个维度，最多 3 个维度，不为凑数量强行标注。详见 references/case_quality_standards.md 交叉标注规则表。

冒烟用例与 P0 功能用例的关系

• 每模块至少 1 条 type=冒烟 用例，该用例同时承担 P0 主路径验证职责，coverage 必须包含 ["功能主路径"]，priority 固定为 P0。
• 模块内额外的 P0 用例使用 type=功能（或对应的具体类型如 异常/边界）。
• 排序规则：冒烟用例最前（TC-001 起），后续为同模块的 P0/P1/P2/P3 用例。

接口测试用例专项要求

> 范围限定：接口测试用例（type=接口）仅覆盖冒烟级别的基本场景。即验证每个核心端点在正常请求参数下能返回正确响应。不需要生成接口级的异常参数校验、边界值、权限拦截等深层用例——这些由 type=功能/type=异常/type=边界 从功能视角覆盖。

接口测试用例在通用质量标准之上还有以下强制要求：
- 前置条件：必须以 API端点: <HTTP方法> <完整URL路径> 开头，后接认证方式、数据准备和关联依赖。
- 步骤：必须包含完整的请求参数信息——构造请求体（列出每个参数名和值）、发送请求（HTTP方法+路径+Header）、校验响应（状态码+响应体关键字段）。禁止只写"调用接口"或"发送请求"。
- 预期结果：必须包含 HTTP 响应状态码（冒烟级聚焦 200/201）、响应体结构校验、请求参数与响应数据逻辑一致性、副作用验证。异常状态码（400/403/500）校验不在冒烟接口用例中要求。
- 完整示例：见 references/artifact_schema.md 中的 TC-002 接口用例示例。

Excel 用例详细度要求

Excel 交付物中各字段的详细度标准：
- 场景名（F列）：简要概述功能点，≤ 25 字，仅作为快速索引。
- 前置条件（H列）：详细描写，必须包含角色/权限、具体数据字段值、页面路径或 API 端点。接口用例必须以 API 端点标注开头。
- 操作步骤（I列）：详细描写，表单填写写明字段名和值，下拉选择写明选项值，接口用例写明请求参数。禁止笼统描述。
- 预期结果（J列）：详细描写，数据变更写明具体值，页面反馈写明 UI 变化，接口用例写明状态码和响应体。禁止模糊描述。

可配置参数

稳定性与覆盖度保证

稳定性：--output-dir 不嵌套；resolve_output_dir() 防嵌套；中间产物归集 _artifacts/；Excel 时间戳固定 2024-01-01。

覆盖率维度（10 个）：功能主路径、异常与错误处理、边界值与等价类、状态流转、权限与角色、数据一致性、接口与集成（仅冒烟级）、兼容性、性能与稳定性、安全（含数据隐私合规）。业务流程分支覆盖作为横切审计方法验证上述维度是否覆盖了所有分支节点。

type 字段分类层级：type 的 12 个值分属不同概念层——测试目的（功能/异常/边界/权限/安全/数据/状态流转/兼容/性能）、测试层次（接口/端到端）、测试阶段（冒烟）。标注决策顺序：先判断是否为 冒烟（阶段角色）→ 再判断是否为 接口 或 端到端（层次）→ 最后选择具体的测试目的类型。详见 references/case_quality_standards.md 分类决策树。

自动化策略与测试分级：详见 references/automation_strategy.md。每条用例在 level 字段标注测试级别，automation 须与 level 一致。测试金字塔健康度和 API 层可降级比例均作为信息性指标 [INFO]呈现，不阻断审计。

并发与竞态：risk_level=高 的模块至少 1 条并发用例。资金/权益/权限模块必含。

回归测试：历史缺陷清单中 P0/P1 缺陷至少 1 条回归用例（coverage 标注"回归"）。

触发场景

• 用户要求根据 PRD/设计文档/接口文档生成测试方案或用例。
• 用户要求检查需求合理性、一致性、覆盖度，再输出测试设计。
• 用户要求交付 Excel 测试用例、思维导图、HTML 测试方案。

新手快速开始见 references/quickstart.md，或运行 python scripts/quickstart.py。

输入材料

支持 .docx/.pdf/.md/.txt/.html/URL 和 UE 原型链接。详见 references/quickstart.md。

python scripts/parse_source_documents.py ./input --output-dir ./output

工作流

阶段 0：材料解析与原型采集

依赖自检：检查 openpyxl/playwright/output 可写。

python scripts/parse_source_documents.py 需求.docx 设计.pdf --output-dir ./output/项目名称

UE 交互覆盖：有 UE 链接时执行 capture_ue_prototype.py 截图采集。无法访问时标记 skipped:true，不阻塞。

阶段 1：文档审查准入

审查维度见 references/review_gate.md（合理性/一致性/覆盖度/影响面/需求漏洞）。

准入结论：PASS（可继续）/ CONDITIONAL_PASS（假设和风险必须注入测试方案 HTML 风险章节）/ FAIL（不生成正式产物）。

审查后输出 HTML 报告（generate_review_report_html.py），暂停询问用户是否继续。用户已明确要求全流程时不二次询问。

需求改进建议（测试左移）：审查不仅识别问题，还给出具体的改写建议（review_gate.improvement_suggestions），帮助产品团队提升 PRD 质量。对模糊表述给出可测试的改写方案，对缺失规则给出行业惯例参考值。详见 references/review_gate.md 审查后的需求改进建议章节。

阶段 1.5：需求分析思维导图（审查通过后生成）

文档审查结论为 PASS 或 CONDITIONAL_PASS 后、进入阶段 2 之前，生成需求分析思维导图。格式见 references/req_analysis_mindmap.md。

思维导图的模块结构来源于阶段 1 审查时从 PRD/设计文档中直接提取的模块划分（而非阶段 2 的 case_plan）。

思维导图包含 7 大分支：
1. 需求模块结构：按模块→子功能（含 50~150 字自然语言详细描述）→关联规则（含规则完整文本、类型和影响范围）的层级展开，标注风险等级。每个子功能必须从 PRD 子文档的 In Scope 和功能描述中提取详细功能说明，不得仅列出子功能名称。
2. 数据实体关系：核心数据实体、关键字段、状态流转和关联关系。
3. 接口清单：所有 API 端点及其功能描述。
4. 影响面分析：上下游系统/模块影响和数据联动。
5. 审查发现：需求缺口、歧义项、假设项、风险项（同步 review_gate 数据）。
6. 验收标准追溯：每条验收标准含完整 Given/When/Then 三要素，与 PRD 高层验收标准表一一对应。
7. 覆盖度概览：规则/模块/子功能/流程分支/接口的统计汇总（阶段 1.5 为估算值，阶段 3.5 审计后更新）。

深度展开要求：
- 每个子功能必须包含 name 和 description 字段，description 为 50~150 字自然语言描述，涵盖具体功能点、业务规则、操作流程。
- 每条关联规则必须展示完整规则文本（text）、规则类型（type）和影响范围（scope），不得仅展示规则编号。
- requirement_analysis.rules_full 字段存储所有规则的完整信息（id/type/summary/text/scope）。
- 验收标准追溯分支必须包含完整的 Given/When/Then 三要素。

输出三种格式：Markdown（.md）+ HTML（.html）+ FreeMind（.mm）。源数据写入 test_artifacts.json 的 requirement_analysis 字段。

python scripts/stamp_iteration_version.py test_artifacts.json
python scripts/generate_test_artifacts.py test_artifacts.json --output-dir ./output/项目名称 --prefix 项目名称 --mindmap-only

阶段 2：HTML 测试方案

格式必须 HTML。模板见 references/test_plan_html.md。必须包含：需求分析概览/测试目标/范围/不测范围/审查摘要/影响面/策略/环境数据/入口出口准则/风险应对/用例预估/自动化策略/缺陷管理/反馈闭环。

case_plan 生成后，应与思维导图的模块结构保持一致。若出现偏差，以 case_plan 为准。

出口准则：除 P0/P1 通过外，至少 2 项可量化准则。

测试规模估算：每模块 = 主路径数 x 3 + 角色数；棕色地带 +15~25%；每端点 +3。5 次项目后，将实际用例数与估算值的偏差用于校准乘数系数（类似 CASE_DEVIATION_THRESHOLD 的动态调整机制）。

python scripts/stamp_iteration_version.py test_artifacts.json
python scripts/generate_test_plan_html.py test_artifacts.json --output-dir ./output

阶段 3：测试用例设计

探索式测试 charter

使用独立结构，写入 test_plan.exploratory_charters（非 cases 数组）：

{
  "charter_id": "CH-001",
  "module": "权益计算与冻结",
  "charter_focus": "探索换购方案生成时权益金额舍入行为",
  "investigation_questions": [
    "不同小数权益金额的舍入规则是什么？",
    "极值下的舍入行为是否一致？",
    "舍入规则是否与财务口径文档匹配？"
  ],
  "priority": "P3",
  "time_box": "30分钟",
  "source": "探索charter-金额舍入",
  "findings": [],
  "new_cases_generated": []
}

不计入规则追溯。每项目最多 {{EXPLORATORY_MAX_COUNT}} 条。priority 默认 P3，若 charter_focus 涉及 risk_level=高 的模块，允许设为 P2。

findings 和 new_cases_generated 在阶段 3 执行探索后填写，记录探索发现和由此新增的用例 ID，形成探索→发现→用例的闭环。

charter 执行步骤：常规用例设计完成后，逐个执行已定义的探索式 charter。在 time_box 时间内围绕 investigation_questions 开展自由探索，记录发现写入 findings（每条含发现描述和关联规则/端点），若发现需补充新用例则生成并写入 new_cases_generated（如 ["TC-050", "TC-051"]）。未执行的 charter 其 findings 不得保持空数组——至少记录"未发现额外问题"及原因。

3.0 项目类型感知

判断类型（页面型/后端API型/数据管道型/纯规则算法型/Jira Story型），调整覆盖维度。详见 references/test_design_toolbox.md。

3.1 需求到测试模块全量映射（强制）

步骤 A：识别 ID 前缀体系（PL/BR/RL/AC/FR/API 等）。
步骤 B：章节与规则映射，枚举全部业务规则编号，建立映射表。
步骤 C（有则强制）：历史缺陷映射，P0/P1 缺陷至少 1 条回归用例。
步骤 D：棕色地带额外要求（回归策略 + 常规流程不受影响用例）。
步骤 E：测试数据策略（[data:API]/[data:SQL]/[data:import]/[data:shared]）+ 环境标签（[env:mock]/[env:staging]）+ 用例依赖（[depends:TC-xxx]）。

P0/P1 用例必须包含结构化 test_data 字段：

"test_data": {
  "setup_method": "API|SQL|import|manual",
  "required_state": {"order_status": "已签到"},
  "isolation_risk": "低|中|高",
  "teardown_method": "API|SQL|import|manual|none",
  "data_isolation": "单用例独占|共享只读|共享写隔离"
}

映射表写入 case_plan，每条目含 rules 字段和 p0/p1/p2/p3 预估数。每个模块必须包含 risk_insights 字段记录测试设计者的独立风险判断。禁止跳过。

阶段 3.5：覆盖度审计（强制）

详见 references/coverage_baseline.md。审计 14 项 + 1 项横切审计 + 3 项一致性验证：

1. 章节回溯（每规则至少 1 条用例）
2. 规则覆盖（所有编号在 requirement_id/source 中出现）
3. 验收标准追溯（AC 逐条标注 TC 编号）
4. 模块名一致性（消除语义重叠）
5. 缺口识别（每章节 < 2 条为不足）
6. 前置条件（P0/P1 非空，含具体数据字段值）
7. automation 受控词汇（5 种，P0 自动化 >= 30%）
8. impact 字段（不仅含单一业务名词）
9. design_id 覆盖率（缺失率 <= 50%）
10. steps 格式（数组，每步一个操作；接口冒烟用例含请求参数）
11. 双向一致性（case_plan 与 cases 模块/数量一致）
12. type 匹配（type 与 coverage 按规则一致；type=接口 仅限冒烟级；type=冒烟 的 coverage 含 ["功能主路径"]）
13. 测试洞察质量：每模块至少 1 条用例含测试设计者的独立风险判断（case_plan.risk_insights + 用例级独立判断）
14. 可执行性抽样审计：max(3, floor(P0_count × 20%)) 条 P0 用例检查 precondition 可构造性、steps 可追溯性、teardown_method 完整性
15. 业务流程分支横切审计：逐模块提取流程分支节点，交叉验证 10 个覆盖维度是否覆盖所有分支出口。覆盖率必须 100%（PRD 无流程图时按降级标准）。此项不受三步绕过协议约束。
16. 思维导图与 case_plan 一致性：检查需求分析思维导图的模块结构与 case_plan 是否一致。
17. coverage_overview 更新：requirement_analysis.coverage_overview.is_estimated 必须从 true 更新为 false，并写入实际统计值。
18. 审查发现数据一致性：requirement_analysis.review_findings 的 gaps/ambiguities/assumptions/risks 必须与 review_gate 的 issues/assumptions/risks 内容一致，不得出现数据分歧。

审计不通过不得进入阶段 4。

审计结果简版示例：

编号体系：PL-01~PL-15 (15条)
章节覆盖：[PASS] 14/14, 规则覆盖率 15/15
验收标准追溯：AC-01->TC-011 / ... (20/20)
type匹配/前置条件/automation/impact/steps/design_id：[PASS]
接口冒烟覆盖：[PASS] 4/4 核心端点各有 ≥1 条冒烟级接口用例
冒烟用例映射：[PASS] 14/14 模块各含 ≥1 条 type=冒烟 用例，coverage 含功能主路径
测试洞察质量：[PASS] 14/14 模块含独立风险判断（risk_insights + 用例级）
可执行性抽样：[PASS] max(3,30×20%)=6/30 P0 抽样通过（含 teardown 完整性检查）
业务流程分支横切审计：[PASS] 模块"换购方案生成" 12/12 分支节点全覆盖
思维导图一致性：[PASS] 思维导图模块结构与 case_plan 一致
coverage_overview：[PASS] is_estimated 已更新为 false
审查发现一致性：[PASS] review_findings 与 review_gate 数据一致
探索式charter：[PASS] 3/3（含1条P2高风险模块charter，findings 已填写）
双向一致性：[PASS]
风险驱动优先级：P0:56/P1:48/P2:21/P3:7
测试金字塔：[INFO] unit(0) integration(45) e2e(87) - PRD层面E2E占比高属正常
API层可降级比例：[INFO] 87条E2E用例中约40条验证逻辑可通过API完成（46%），建议优化自动化投入
风险升级追溯：[PASS] 3条P1→P0升级均已标注 [risk_upgrade]，P0占比 42.7% [WARN] P0膨胀预警

python scripts/stamp_iteration_version.py test_artifacts.json
python scripts/generate_test_artifacts.py test_artifacts.json --output-dir ./output/项目名称 --prefix 项目名称

质量门禁

基础门禁：准入未完成不输出方案；FAIL 不生成用例；用户确认后自动完成全部后续阶段；每条用例有来源依据；P0/P1 覆盖主路径+关键异常+关键边界；方案必须 HTML；用例必须有 Excel + 思维导图；需求分析思维导图必须在阶段 2 前生成；审查输出必须包含需求改进建议。

覆盖度门禁：章节覆盖（每章/规则 >= 2 条）；规则追溯（核心 100%）；AC 追溯（逐条对应用例）；非功能需求（每高风险模块 >= 1 性能 + 1 安全）；业务流程分支横切审计 100%（不受三步绕过协议约束，PRD 无流程图时按降级标准）；接口与集成维度仅需冒烟级覆盖（每核心端点 ≥1 条冒烟接口用例）；思维导图与 case_plan 模块一致性；coverage_overview 估算值已更新为实际值。

用例详细度门禁：场景名简要概述功能点（≤ 25 字）；前置条件含具体数据字段值（接口冒烟用例含 API 路径）；步骤含具体参数（接口冒烟用例含请求体参数名和值）；预期结果可观察可判定（禁止模糊描述）；expected 条目数与 steps 条目数一致。

测试数据门禁：P0/P1 用例的 test_data 必须包含 teardown_method（修改数据的用例不得为 none）和 data_isolation；isolation_risk=高 的用例必须使用 单用例独占。

字段合规门禁：模块名唯一性；type 与 coverage 匹配（type=接口 仅限冒烟级；type=冒烟 的 coverage 含 ["功能主路径"]）；P0/P1 precondition 非空；模块可追溯到映射表；automation 5 种受控值；impact 非单一业务名词；design_id 缺失率 <= 50%；steps 为数组；coverage 标签标准化。

策略门禁：回归覆盖（棕色地带：策略 + >= 2 条不受影响用例）；探索式 charter（>= 1 条，<= MAX_COUNT，含 findings 和 new_cases_generated 字段，charter 必须已执行）；出口准则（>= 2 项可量化）；估算反推（偏差 <= THRESHOLD）；风险驱动优先级（risk_level + P1->P0 升级 + 升级追溯标记）；测试设计技术（判定表/状态转换表）；双向一致性（case_plan = cases）；CONDITIONAL_PASS 假设标记（审查结论为 CONDITIONAL_PASS 时，基于假设的用例 remark 自动标注 [assumption:A-xxx]）。

新增门禁：
- 测试洞察质量：每模块至少 1 条用例含独立风险判断，且 case_plan.risk_insights 非空。
- 可执行性审计：P0 用例 max(3, 20%) 抽样，precondition 可构造、steps 可追溯、teardown_method 完整。
- 测试金字塔（INFO 级）：分布作为信息性指标呈现，倒金字塔标注 [INFO]，不阻断审计。
- API 层可降级比例（INFO 级）：统计 level=e2e 用例中验证逻辑可通过 API 完成而不需要 UI 的比例，指导自动化投入优化，不阻断审计。
- 冒烟自动化率：≥ 90%（< 90% 标注 [WARN]，不阻断审计）。

三步绕过协议：初次→修正重审；二次→缩小范围；三次→标记已知风险越过。严禁第一次直接绕过。例外：业务流程分支横切审计不受三步绕过协议约束——未覆盖的分支节点必须补充用例，不得以"已知风险"标记越过。

回退协议：阶段 3→2 回退修正 case_plan，禁止跳过 3.5 审计。

Phase Gates：每阶段完成后在 phase_gates 记录状态，未 true 不得进入下一阶段。

基础用例生成规则

• 冒烟（P0）：每模块至少 1 条 type=冒烟，coverage 含 ["功能主路径"]，priority=P0。该用例同时承担模块 P0 主路径验证职责。
• P0（额外）：核心主路径的补充验证（type=功能 或具体类型）。P1：重要分支/常见异常。P2：边界值/非核心异常。P3：低频/兼容/灰度。
• 风险驱动优先级：case_plan 中标注 risk_level，高风险 P1→P0 升级。升级后在 remark 中标注 [risk_upgrade] 原P1→P0，保留原优先级追溯。若升级后 P0 占比 > 40%，标注 [WARN] P0 膨胀预警 并建议产品团队复核风险等级。
• 排序：冒烟最前，TC-001 起连续递增，模块内按功能→异常→边界→权限。

资源

• references/review_gate.md — 文档审查准入标准（含 AI 生成内容审查、数据隐私合规、需求改进建议）
• references/quickstart.md — 快速上手说明（含完整输出文件列表）
• references/source_input_formats.md — 输入格式支持说明
• references/test_plan_html.md — HTML 测试方案模板（含需求分析概览章节+缺陷管理协议章节）
• references/artifact_schema.md — 测试用例 JSON 数据结构（含功能用例+接口冒烟用例+需求分析思维导图+探索式 charter 闭环+execution_result 完整示例）
• references/excel_format.md — Excel 与思维导图字段规范（C 列含状态流转类型）
• references/image_processing.md — PDF 图片处理建议
• references/stability_contract.md — 稳定编号、排序、增量更新、思维导图稳定性和 review_findings 数据一致性规则
• references/coverage_baseline.md — 覆盖度基线标准（含业务流程分支横切审计+PRD无流程图降级+接口冒烟覆盖+思维导图一致性验证）
• references/case_quality_standards.md — 测试用例质量标准（含详细度、冒烟/P0映射、type 分类决策树、接口冒烟用例专项、test_data管理、coverage交叉标注、expected/steps条目数一致）
• references/automation_strategy.md — 自动化策略与测试分级（含冒烟自动化率 ≥90%、API 层可降级比例）
• references/test_design_toolbox.md — 测试设计技术工具箱（含判定表/状态转换表/Pairwise/并发测试/安全专项）
• references/req_analysis_mindmap.md — 需求分析思维导图格式规范（模块来源说明、层级结构、节点标注、JSON 数据格式、FreeMind 格式、质量要求）
• scripts/parse_source_documents.py — 解析输入材料
• scripts/capture_ue_prototype.py — UE 原型截图采集
• scripts/extract_pdf_images.py — 提取 PDF 图片
• scripts/generate_review_report_html.py — 生成 HTML 审查报告
• scripts/generate_test_plan_html.py — 生成 HTML 测试方案
• scripts/stamp_iteration_version.py — 自动维护迭代版本
• scripts/stamp_iteration_cases.py — 增量合并用例
• scripts/generate_test_artifacts.py — 生成 Excel、思维导图与需求分析思维导图
• scripts/convert_xlsx_to_md.py — Excel 转 Markdown
• scripts/quickstart.py — 交互式引导

版本策略

禁止每次项目执行都 bump 版本。

版本历史

v1.4.4 (2026-06-12)

• [修复] 探索式 charter 执行闭环缺失：阶段 3 新增 charter 执行步骤，明确 time_box 内探索、发现记录、新增用例生成流程，禁止 findings 保持空数组
• [修复] review_findings 与 review_gate 数据同步无强制保证：新增审计第 18 项，强制校验两者一致性
• [修复] artifact_schema 与 req_analysis_mindmap 示例数据不一致：统一两个文件的 coverage_overview 数据为同一项目实例
• [新增] type 字段分类层级说明与决策树：明确测试目的/测试层次/测试阶段三层分类，提供标注决策顺序
• [修复] 风险驱动优先级升级缺边界控制：新增 [risk_upgrade] 追溯标记和 P0 占比 >40% 膨胀预警
• [修复] 可执行性抽样审计下限过低：改为 max(3, floor(P0_count × 20%))，确保小项目至少抽样 3 条
• [新增] API 层可降级比例信息性指标：替代纯金字塔分布，指导自动化投入优化
• [新增] execution_result 字段结构定义：支持测试执行结果回写，形成设计→执行→反馈闭环
• [新增] 并发测试设计技术章节：包含竞态条件识别、锁粒度分析、幂等性验证模式
• [新增] 缺陷管理协议章节：在 test_plan_html.md 模板中新增缺陷分级/上报流程/回归策略
• [新增] CONDITIONAL_PASS 假设标记：审查结论为条件通过时，基于假设的用例自动标注 [assumption:A-xxx]
• [修复] 接口用例步骤长度约束过严：接口用例步骤最小长度从 15 字降为 10 字
• [修复] data_isolation 枚举缺“不适用”：纯只读用例可用 不适用
• [修复] 增量迭代中思维导图更新时序模糊：明确为 case_plan 变更后立即同步
• [新增] 测试规模估算公式校准机制：5 次项目后基于实际偏差校准乘数系数

v1.4.3 (2026-06-12)

• [修复] 阶段 1.5 思维导图对 case_plan 的时序依赖矛盾：思维导图模块结构改为来源于阶段 1 审查时从 PRD 直接提取的模块划分，阶段 2 生成 case_plan 后反向校验一致性
• [修复] coverage_overview 数据在阶段 1.5 为估算值：新增 is_estimated 字段，阶段 3.5 审计后更新为实际值
• [修复] type=冒烟 与 coverage 映射关系不明确：交叉标注表新增冒烟用例行，明确 type=冒烟 的 coverage 必须含 ["功能主路径"]
• [修复] 冒烟用例与 P0 功能用例边界模糊：明确每模块至少 1 条 type=冒烟 承担 P0 主路径职责，额外 P0 用 type=功能
• [修复] Excel C 列测试类型枚举值缺 状态流转：对齐 type 字段完整枚举
• [修复] test_plan_html.md 模板缺需求分析思维导图章节：新增"需求分析概览"章节
• [修复] artifact_schema.md TC-001 示例 expected(5条) 与 steps(4步) 不匹配：合并附加验证到最后一步预期
• [新增] 审查输出增加需求改进建议（测试左移）：review_gate.improvement_suggestions 字段，给出具体改写方案和行业惯例参考
• [新增] AI 生成内容审查维度：识别疑似 AI 生成且未经 SME 验证的规则，标记 [AI_UNVERIFIED]
• [新增] 数据隐私合规审查：覆盖度维度安全项增加数据隐私合规要求
• [新增] 探索式 charter 执行反馈闭环：新增 findings 和 new_cases_generated 字段
• [新增] FreeMind(.mm) 格式基本结构示例
• [调整] 冒烟自动化率从 100% 改为 ≥ 90%，允许不可自动化场景标注 手工测试 并说明原因
• [新增] stability_contract.md 需求分析思维导图稳定性规则
• [新增] 覆盖度审计校验清单新增思维导图一致性验证和 coverage_overview 更新验证

v1.4.2 (2026-06-12)

• [新增] 需求分析思维导图产物：阶段 1 审查通过后、进入阶段 2 之前自动生成，可视化展示需求结构、业务规则层级、数据实体关系、接口清单、影响面分析、审查发现和覆盖度概览
• [新增] requirement_analysis JSON 字段：存储思维导图源数据（含 modules/data_entities/api_endpoints/impact_analysis/review_findings/coverage_overview）
• [新增] references/req_analysis_mindmap.md：需求分析思维导图格式规范（6 大分支层级结构、节点标注规范、JSON 数据结构、质量要求）
• [新增] 思维导图输出三种格式：Markdown（.md）+ HTML（.html）+ FreeMind（.mm）
• [新增] 阶段 1.5：需求分析思维导图生成步骤（含 --mindmap-only 生成命令）
• [新增] 基础门禁：需求分析思维导图必须在阶段 2 前生成

v1.4.1 (2026-06-12)

• [调整] 接口测试用例（type=接口）范围限定为冒烟级别基本用例：仅验证核心端点在正常请求参数下返回正确响应，不要求覆盖异常参数校验、边界值、权限拦截等深层接口场景
• [调整] "接口与集成"覆盖维度从"每个项目至少 4 个核心端点"改为"仅覆盖冒烟级别基本接口用例"（每核心端点 ≥1 条冒烟级）
• [调整] 风险加权基线中接口维度统一为冒烟级（高/中/低风险均只需冒烟覆盖）
• [调整] type=接口 仅用于冒烟级基本接口用例；异常参数校验、边界值、权限拦截等深层场景使用 type=异常/type=边界/type=权限，不标记为 type=接口
• [调整] 接口冒烟用例预期结果聚焦正常响应（200/201），异常状态码（400/403/500）校验由功能视角用例覆盖

v1.4.0 (2026-06-12)

• [修复] artifact_schema.md 最小示例 TC-001 全面重写，使 precondition/steps/expected 完全符合 V1.3.0 质量标准（含具体字段值、步骤详细描写、oracle来源标注、步骤与预期条目数匹配）
• [新增] artifact_schema.md 补充完整的 API 测试用例 JSON 示例（TC-002），展示接口用例的前置条件 API 端点标注、请求体参数、响应校验和副作用验证
• [修复] 业务流程分支覆盖与三步绕过协议矛盾：明确声明"业务流程分支横切审计不受三步绕过协议约束"
• [重构] "业务流程分支"从第 11 个覆盖维度降级为横切审计方法，覆盖维度恢复为 10 个，消除与功能主路径/状态流转/权限角色/异常处理的语义重叠
• [新增] PRD 无显式流程图时的降级策略：生成推断流程图（含 high/medium/low 置信度标注），请求用户确认，按置信度降级覆盖率目标
• [新增] test_data 字段扩展：新增 teardown_method（数据清理方式）和 data_isolation（数据隔离策略）
• [新增] 测试数据门禁：P0/P1 修改数据的用例必须有 teardown_method，isolation_risk=高 必须单用例独占
• [改进] 探索式 charter 数量从固定 2 条改为动态公式（基线 2 + 每多 5 模块额外 1，上限 6）
• [改进] 探索式 charter 优先级弹性：默认 P3，高风险模块允许 P2
• [新增] case_plan.risk_insights 字段：每个模块必须记录测试设计者的独立风险判断
• [新增] coverage 字段交叉标注规则表：明确多维度组合的推荐标注方式
• [新增] artifact_schema.md case_plan 示例补充 risk_insights 字段

v1.3.0 (2026-06-12)

• [新增] 业务流程分支覆盖要求（全部业务场景和流程分支节点 100% 覆盖）
• [新增] 接口测试用例专项要求（API 端点标注、请求参数、响应校验）
• [改进] 场景名称/前置条件/步骤/预期结果详细度标准全面提升
• [新增] 用例详细度门禁
• [新增] UE 原型交叉验证

v1.2.0 (2026-06-12)

• [重构] SKILL.md 从 1275 行压缩至约 530 行，详细规则拆分到 4 个 reference 文件
• [修复] artifact_schema/test_plan_html/excel_format 多项 Bug 修复
• [改进] 探索式 charter 改独立结构、测试金字塔降级为 INFO
• [新增] 测试洞察质量门禁 + 可执行性抽样审计门禁 + test_data 字段

v1.1.2 ~ v1.1.1 (2026-06-03 ~ 2026-06-09)

• 初始版本到 v1.1.2 的全部功能：审查准入、测试方案、用例设计、多格式交付、增量合并、UE 采集、门禁体系、多语言支持、项目类型检测等。

执行异常处理

常见失败路径

准出质量要求

快速执行检查表

[ ] 依赖自检：openpyxl + playwright + output 可写
[ ] 阶段 0：文档解析
[ ] UE 截图采集（若有）
[ ] 阶段 1：文档审查（含需求改进建议）
[ ] 阶段 1.5：需求分析思维导图
[ ] 阶段 2：测试方案（含需求分析概览章节）
[ ] 阶段 3：用例生成（含探索式 charter 执行与发现记录）
[ ] 阶段 3.5：覆盖度审计（含洞察质量 + 可执行性 + 分支横切审计 + teardown 检查 + 接口冒烟覆盖 + 冒烟映射 + 思维导图一致性 + coverage_overview 更新 + charter 闭环检查）
[ ] 阶段 4：全部产物交付
[ ] 项目后记
[ ] 幂等性验证

增量/迭代生成策略

1. 识别变更范围（对比新旧 PRD）。
2. 增量审查（仅新增/修改章节；历史保留标记 [v1.0.0审查通过]）。
3. 用例增量追加（新章节→新模块；修改→原模块追加标记 [v2-deprecated]；删除→标记不删除）。
4. case_plan 更新（新增模块追加末尾）。
5. 版本号递增（stamp_iteration_version.py，指纹变化自动 patch）。
6. 已审计章节不重新审计（除非交叉依赖受影响）。
7. 需求分析思维导图随 case_plan 变更立即同步更新模块结构（非延迟到审计阶段）。
8. coverage_overview.is_estimated 在增量审计后保持 false。

项目后记（Retrospective）

阶段 4 后在 artifact_meta 添加 retrospective（tokens/bottleneck/gate_retries/doc_count/case_count/improvements）。结果指标 outcome_metrics（cases_executed/defects_found/false_oracle_count/execution_blockers）由执行团队反馈。5 次以上记录后回顾分析。

多代理人协作

指定主代理人维护 JSON 和 phase_gates。分阶段交接。同一时间只一个代理人写入。分歧由主代理人裁决，记录 design_conflicts。

产物移交

Excel→QA 团队；HTML 审查报告→产品+技术（含需求改进建议）；HTML 测试方案→技术+QA；需求分析思维导图→产品+技术+QA（帮助快速理解需求全貌）；JSON→CI/CD。一周内反馈，超两周标记 [HANDOFF_UNACKNOWLEDGED]。

阶段跳跃检测

每次阶段切换计算 phase_gates SHA-256 记录在 phase_chain，不连续标记 [PHASE_SKIP]。

维护说明

• 每新增 5 条规则至少审视删除 1 条旧规则。
• [清理] 变更需说明删除了什么。
• 当前约 534 行，后续新增时评估拆分到 references/。