背景:

近期在使用 AI 生成测试用例的方向进行一定的探索, 从一开始的直接贴需求通过提示词让 AI 生成, 到网上找的/各路大佬分享的 skills 生成, 都进行了一定的尝试,然而始终不得劲.
在几个月前的思考中想起多年前初入测试的某个下午, 参加了一个部门分享的测试分析方法《海盗派测试分析》, 觉得其中部分理念与当下 AI 生成的场景比较契合, 故根据其核心思路做出这一版的测试用例生成工作流
https://github.com/wadr2009/requirements-to-test-workflow (持续迭代中,求 star 万一被裁还能往简历写写...)

海盗派测试分析: 从需求理解→覆盖识别→功能拆分→测试点→用例, 在需求理解阶段: 澄清模糊需求、识别漏洞、拆分测试范围、提前锁定风险

编写工具

使用 Hermes + deepseek-v4-pro 进行 Workflow + Skills 编写和设计
使用 Codebuddy + gml-5.2/deepseek-v4-pro 进行用例生成 (执行 skills)

可优化方向

• 未接入知识库
• 未处理 case 审核/修改 人-AI 之间的协调 (感觉太重了, 也不适合放里面, 后续单独写个项目处理)

以下为 AI 编写, 注意鉴别

一、整体概述

requirements-to-test-workflow 是一个将原始 PRD 需求文档自动转化为 XMind 可导入标准化测试用例的完整流水线技能。它由 1 个顶层编排器 + 8 个子技能组成，覆盖了从需求澄清、模块拆分、测试点分析到测试用例生成的完整测试设计流程。

原始 PRD 文档
    │
    ▼
┌──────────────────────────────────────────────┐
│  阶段 0：准备工作（迭代范围识别 + REQ 编号）    │
└──────────────────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────────────────┐
│  阶段 1：需求澄清循环（clarifier → answerer   │
│          → auditor），门控 ≥ 90%               │
└──────────────────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────────────────┐
│  阶段 2：模块拆分（按角色 + 目录树）            │
└──────────────────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────────────────┐
│  阶段 3：测试点分析循环（analyzer → reviewer） │
│          门控：覆盖度 ≥ 95% + 不一致项 = 0     │
└──────────────────────────────────────────────┘
    │
    ▼ （可选：阶段 3.5 跨迭代回归分析）
    │
    ▼
┌──────────────────────────────────────────────┐
│  阶段 4：测试用例生成循环（generator →        │
│          reviewer），门控：覆盖度 100% +       │
│          格式合规 ≥ 95% + 追溯链完整           │
└──────────────────────────────────────────────┘
    │
    ▼
  交付物：XMind 用例文件 + 全链路追溯矩阵 + 审查报告

二、架构设计亮点

2.1「文件即契约」的阶段间通信机制

这是整个工作流最核心的设计决策：所有阶段间数据传递必须通过文件系统，禁止在对话上下文中直接传递数据。

阶段 N 产出 ──write_file──▶ {OUTPUT_DIR}/0X-xxx.md
                                   │
阶段 N+1 开始 ──read_file──────────┘

设计价值：

• 可审计性：每个阶段的输入/输出都是可追溯的物理文件
• 断点续跑：产出文件已存在则跳过该阶段，支持从任意阶段恢复
• 并行安全：文件作为唯一权威数据源，避免并发上下文污染
• 人工审查：中间产物可独立审阅，不依赖对话记录

2.2 多层门控质量体系

工作流设计了 4 道质量门，每道门都有量化指标：

关键设计：

• 每一道门都是硬约束，不允许静默跳过
• 回环次数上限 3 轮，超过则阻塞并展示决策清单
• 门控判定必须从文件读取数据计算，不得凭记忆

2.3 v4.0 的关键改进：「推断 ≠ 已完成」

阶段 1 的 answerer 在 v4.0 做了一个关键调整——只有文档明确回答才计入完成度：

v3.0: 完成度 = (明确回答 + 推断回答) / 问题总数
v4.0: 完成度 = 明确回答 / 问题总数

这个改动解决了"伪通过"问题：之前可以通过大量"推断回答"来凑完成度，导致门控形同虚设。v4.0 强制要求文档必须提供直接证据，推断回答流转到下一轮澄清作为补充问题素材。

2.4 REQ → TP → TC 全链路可追溯性

v4.0 新增的可追溯性矩阵是贯穿全流程的核心数据资产：

阶段 0：分配 REQ ID（REQ-001, REQ-002...）
    │
阶段 3：建立 REQ → TP 映射（每个测试点标注来源 REQ）
    │
阶段 4：建立 REQ → TP → TC 矩阵（每条 REQ 的对应用例）
    │
交付时：生成 99-可追溯性矩阵.md

这个设计确保了：任何一个测试用例都能追溯到它覆盖的原始需求，任何一条需求都能验证它的测试覆盖程度。

2.5 并行策略与命名空间隔离

对于大型项目（15 页 + 或 5+ 独立模块），工作流支持按模块并行执行阶段 3+4：

阶段 2 产出 4 个模块
    │
    ├─ 子代理 A（REQ 前缀 REQ-A）→ 阶段 3+4
    ├─ 子代理 B（REQ 前缀 REQ-B）→ 阶段 3+4
    ├─ 子代理 C（REQ 前缀 REQ-C）→ 阶段 3+4
    └─ 集成代理（REQ 前缀 REQ-X）→ 跨模块集成点
    │
    └─ 合并：前缀替换为全局连续 REQ → 统一评审

命名空间隔离通过三层命名体系实现：

• 模块 REQ：REQ-A01, REQ-A02（模块内部）
• 集成 REQ：REQ-X01（跨模块集成点）
• 回归 REQ：REQ-R01（回归测试项）

合并时通过 prefix_to_global_mapping 统一替换为全局连续 REQ ID。

2.6 跨迭代回归分析（阶段 3.5）

这是一个容易被忽视但非常实用的阶段。当存在历史迭代的测试产出时，自动分析当前变更对历史功能的影响：

• 从状态机变更、接口变更、数据表变更、业务规则变更四个维度评估影响
• 生成受影响的历史测试点清单（含影响等级和建议操作）
• 在阶段 4 中为受影响项生成回归用例（tc-reg-P0/P1/P2 前缀）

三、子技能职责矩阵

还有一个内部子技能 test-case-format，是 XMind 格式规范的唯一权威来源，test-case-generator 和 test-case-reviewer 都依赖它。

四、输出文件体系

工作流在 output/{迭代号}/ 下生成完整的文件体系：

output/{迭代号}/
├── README.md                          ← 全链路汇总
├── 00-原始需求.md                      ← 完整需求
├── 00-迭代范围.md                      ← 经识别的当前迭代需求清单（含 REQ ID）
├── 00-req-namespace.json              ← 并行模式下的 REQ 命名空间映射
├── 01-clarifier-问题清单.md            ← 澄清问题（关键/重要/一般）
├── 01-answerer-解答报告.md             ← 问题解答（明确/推断/需确认）
├── 01-auditor-审核报告.md              ← 审核 + 门控判定
├── 02-module-splitter-模块拆分.md       ← 模块拆分报告（角色+目录树+依赖图+风险）
├── 03-test-point-analyzer-测试点.md     ← 测试点分析（TP001-TPnnn）
├── 03-test-feature-reviewer-评审.md     ← 测试点评审 + 门控判定
├── 03-regression-scope.md             ← 跨迭代回归范围
├── 04-test-case-generator-用例.md      ← XMind 可导入的标准化测试用例
├── 04-test-case-reviewer-评审.md        ← 最终质量门评审
└── 99-可追溯性矩阵.md                   ← REQ→TP→TC 全链路追溯

五、设计模式总结

5.1 编排器模式（Orchestrator）

顶层 requirements-to-test-workflow 是一个纯编排器，不执行具体分析逻辑，而是：

• 管理阶段顺序和门控流转
• 加载子技能并传递输入文件路径
• 处理回环和人工介入
• 管理并行策略和合并步骤

5.2 门控模式（Gate Pattern）

每个阶段末尾都有量化的门控检查，不合格自动回环。这是一个关键的质量保障机制，防止质量缺陷向下游传播。

5.3 不可变数据传递（Immutable Data Transfer）

阶段间数据通过文件系统传递而非上下文变量，每个阶段独立读写文件。这使得工作流天然支持断点续跑、并行执行和独立审计。

5.4 渐进式细化（Progressive Elaboration）

需求信息在流水线中逐步细化：

• 原始 PRD → 迭代范围 + REQ ID（阶段 0）
• REQ → 澄清后的明确需求（阶段 1）
• 需求 → 按角色拆分的模块（阶段 2）
• 模块 → 结构化测试点（阶段 3）
• 测试点 → 标准化测试用例（阶段 4）

5.5 防御性深度（Defensive Depth）

多层防御机制：

• 推断回答不计入完成度（防伪通过）
• 回环上限 3 轮（防死循环）
• 多余测试点标记为不一致项（防过度测试）
• 追溯链断链等同于门控不通过（防覆盖盲区）

六、适用场景与局限

适用场景

1. xxxxxx 项目相关
2. 多迭代、长周期的复杂项目（跨迭代回归分析价值最大）
3. 需求文档频繁变更的项目（澄清循环可快速响应变化）
4. 测试团队需要标准化测试用例交付物（XMind 导入格式）

当前局限与改进方向

1. 强依赖需求文档质量：如果 PRD 非常简略，阶段 1 会产生大量"需用户确认"项，需要大量人工介入
2. 子代理并行仅在阶段 3+4 生效：阶段 1 的澄清循环是串行的，大文档的澄清可能成为瓶颈
3. 格式规范与业务逻辑耦合：test-case-format 同时定义了 XMind 格式和测试设计规则，职责可以进一步分离
4. 缺乏测试数据管理：测试用例中的测试数据是静态描述的，没有与测试数据构造工具的集成
5. 未涉及自动化测试执行：工作流止步于测试用例设计文档，没有延伸到自动化测试脚本生成或执行

七、技能生态与上下游衔接

该工作流已与上下游技能建立桥接，形成完整的"需求提取 → 测试交付"链路：

prd-extraction（需求文档提取技能）
    │
    ▼ 00-原始需求.md
requirements-to-test-workflow（本工作流）
    │
    ▼ 04-test-case-generator-用例.md
test-case-format（XMind 格式规范技能）
    │
    ▼
XMind 导入

上游 prd-extraction 技能负责从 Mockplus 等平台提取完整 PRD 内容并输出为标准化的需求文件；本工作流消费该文件作为阶段 0 的输入。下游 test-case-format 技能定义 XMind 导入格式规范，test-case-generator 在生成用例前必须加载该技能以确保输出格式合规。

九、技术栈与依赖

• 执行方式：编排器可启动子代理并行执行阶段 3+4
• 文件格式：Markdown（产出文件）、JSON（命名空间映射）
• 核心能力：文件读写、文件搜索、用户交互确认、子任务委派
• 文件系统：所有产出通过文件系统传递，输出目录 output/{迭代号}/

十、总结

requirements-to-test-workflow v4.0 是一个设计精良的测试设计自动化工作流，其核心价值在于：

1. 端到端自动化：从原始 PRD 到 XMind 可导入的测试用例，整个过程由编排器驱动
2. 多层质量保障：4 道门控 + 回环机制 + 3 轮上限，确保交付质量
3. 全链路可追溯：每条需求 → 每个测试点 → 每个用例，双向可追溯
4. 工程化意识强：文件即契约、断点续跑、并行策略、命名空间隔离
5. 实战驱动设计：v4.0 的改进（推断不计入完成度、追溯链完整性）都是来自实际使用中的问题修复

该工作流特别适合需要标准化测试交付物、多迭代并行的企业级项目。对于有兴趣在自己的项目中应用类似流程的团队，可以从以下几个方面入手：

• 先实现阶段 0（迭代范围识别 + REQ 编号）和阶段 2（模块拆分），建立基础的文档规范
• 逐步叠加阶段 1（澄清循环）和阶段 3（测试点分析）
• 最后接入格式规范和门控体系
• 当项目规模增长时引入并行策略