测试基础一次 Agent 测试用例生成 Workflow 的尝试

吼猴 · June 29, 2026 · 177 hits

背景:

近期在使用 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 道质量门，每道门都有量化指标：

门控位置	指标	阈值	不通过行为
阶段 1 auditor	完成度（文档明确回答/问题总数）	≥ 90%	回到 clarifier 补充问题
阶段 2 验证	功能点覆盖率 + 无循环依赖	100%	修正后重写
阶段 3 reviewer	覆盖度 + 不一致项	≥ 95% 且 0	回到 analyzer 补充测试点
阶段 4 reviewer	覆盖度 + 格式合规 + P0/P1 完整 + 追溯链完整	100% + ≥ 95% + 完整	回到 generator 修订

关键设计：

每一道门都是硬约束，不允许静默跳过
回环次数上限 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 前缀）

三、子技能职责矩阵

子技能	所属阶段	核心职责	输入	输出
requirements-clarifier	阶段 1-①	从需求中识别模糊、矛盾、缺失的部分，生成优先级排序的澄清问题清单	迭代范围 + 原始需求	问题清单（关键/重要/一般）
requirements-answerer	阶段 1-②	基于文档回答问题，按三类处理：明确回答、推断回答、需用户确认	问题清单 + 需求文档 + 设计文档	解答报告（含确定性/分类）
requirement-answer-auditor	阶段 1-③	审核解答质量，验证分类正确性，计算完成度，判定门控	解答报告 + 问题清单	审核报告 + 门控判定
requirement-module-splitter	阶段 2	按用户角色 + 功能目录树拆分需求为可独立测试的模块	迭代范围 + 审核报告	模块拆分报告（含依赖图 + 风险评估）
requirements-test-point-analyzer	阶段 3-①	从需求中提取结构化测试点，分析功能依赖和影响范围	迭代范围 + 模块拆分报告	测试点报告（TP001-TPnnn）
test-feature-reviewer	阶段 3-②	评审测试点的覆盖度和一致性，评估可测试性	测试点报告 + 迭代范围	评审报告 + 门控判定
test-case-generator	阶段 4-①	将测试点转化为 XMind 可导入的标准化用例	测试点报告 + test-case-format + 回归范围	XMind 格式用例文件
test-case-reviewer	阶段 4-②	最终质量门：覆盖度、格式合规、P0/P1 完整性、追溯链完整性	用例文件 + 迭代范围 + 测试点报告	评审报告 + 最终门控

还有一个内部子技能 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 轮（防死循环）
多余测试点标记为不一致项（防过度测试）
追溯链断链等同于门控不通过（防覆盖盲区）

六、适用场景与局限

适用场景

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

当前局限与改进方向

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

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

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

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 是一个设计精良的测试设计自动化工作流，其核心价值在于：

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

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

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

No Reply at the moment.

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up。

测试基础 一次 Agent 测试用例生成 Workflow 的尝试

测试基础 一次 Agent 测试用例生成 Workflow 的尝试

背景:

编写工具

可优化方向

以下为 AI 编写, 注意鉴别

一、整体概述

二、架构设计亮点

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

2.2 多层门控质量体系

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

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

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

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

三、子技能职责矩阵

四、输出文件体系

五、设计模式总结

5.1 编排器模式（Orchestrator）

5.2 门控模式（Gate Pattern）

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

5.4 渐进式细化（Progressive Elaboration）

5.5 防御性深度（Defensive Depth）

六、适用场景与局限

适用场景

当前局限与改进方向

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

九、技术栈与依赖

十、总结

测试基础一次 Agent 测试用例生成 Workflow 的尝试

测试基础一次 Agent 测试用例生成 Workflow 的尝试