测试用例生成器 V2

> 版本: V2.1.0 | 最后更新: 2026-07-07
> 核心改进: 批量场景支持、四层深度硬约束、阶段精简、模块前缀编号

第一步：判断输入模式

在开始任何阶段之前，先判断输入规模：

批量模式执行策略

输入：N个需求文档（N > 3）
         │
         ▼
阶段一：一次性扫全部文档 → 生成全局业务域图
         │
         ▼
阶段二~三：逐个文档执行（每个文档重复以下循环）
  ┌──────────────────────────────────────┐
  │  文档i：阶段二（需求提取）           │
  │       → 阶段三（设计+生成用例）       │
  │       → 保存到 output/phase4_cases   │
  └──────────────────────────────────────┘
         │
         ▼
阶段四：合并全部文档结果 → Excel

关键约束（防止 token 稀释）：
- 每个文档独立执行阶段二~三，不允许同时处理多个文档
- 每个文档生成的用例数不得少于 min(10, 可测需求数*2)——防止批量时偷工减料
- 全局业务域图（阶段一输出）作为后续每个文档的共享上下文

阶段一：业务域分析

由 AI 执行，无需 Python 脚本。

输入规模决定策略

1.1 业务域识别

扫描文档，找出独立的业务域。每个域记录：

• 业务域名称 — 从文档内容推断
• 核心实体 — 该域涉及的关键数据实体
• 业务规则 — 实体间的约束和逻辑
• 状态流转 — 实体的生命周期变化
• 域间交互 — 与其他域的依赖关系

1.2 业务分层

> 层数决定最少用例数：核心层 ≥ 7 条，重要层 ≥ 5 条，辅助层 ≥ 3 条，基础层 ≥ 2 条。
> 防止 token 稀释导致每个域只有 1-2 条。

1.3 输出格式

{
  "业务域": [{
    "名称": "订单管理", "层级": "核心层",
    "核心实体": ["订单", "订单项"],
    "关键规则": ["库存扣减规则"],
    "状态流转": ["待支付→已支付→已发货→已完成"],
    "关联域": ["用户管理", "库存管理"],
    "最少用例数": 8
  }]
}

批量模式下，所有文档的业务域合并到一个 phase1_domains.json，标注 源文件 字段。

阶段二：需求提取与分类

由 AI 执行，输出保存到 output/phase2_requirements.json。

> ⚠️ 批量模式下，逐个文档执行本阶段。每完成一个文档的需求提取，立即进入阶段三，不要等到所有文档都提取完。

2.1 需求提取

从文档中提取每条可验证的需求，不遗漏。

2.2 复杂度来源分类

2.3 质量属性标记

2.4 需求可测性检查

2.5 输出格式

{
  "源文件": "01-auth.md",
  "需求": [{
    "编号": "REQ-001", "描述": "密码长度必须为 8-20 位",
    "业务域": "用户认证管理", "复杂度来源": ["输入空间"],
    "质量属性": ["功能", "安全性"], "可测性": "可测"
  }]
}

> ⚠️ 批量模式下，每条需求标注 源文件，后续独立关联。

阶段三：测试设计 + 用例生成（合并）

> V2 合并了原 V1 的阶段三和阶段四。不产生独立的 phase3 文件，设计思路直接在用例中体现。
> 原因：阶段三的输出（设计策略）和阶段四（用例生成）对于 AI 执行来说是同一思考过程的两面，分开输出白增上下文开销。

3.0 四层深度硬约束模板

设计用例的核心逻辑：不是覆盖需求文字，而是发现问题和隐患。

每个业务域必须严格按以下四层模板生成用例，不允许跳过任何一层。这是硬约束，不是建议。

每层模板（直接使用，不要跳过）：

┌─ 第一层：主流程（至少 1 条 P0）───────────────┐
│  核心业务路径正向走通，验证"用户能完成核心目标"     │
│  步骤数: 4-5 步（打开→输入→操作→验证→持久化）     │
└─────────────────────────────────────────────┘

┌─ 第二层：业务分层（至少 2 条 P1）──────────────┐
│  ├─ UI元素 + 交互逻辑（每个按钮/输入框/弹窗）    │
│  ├─ 字段值边界（0/空值/最小值/最大值/特殊格式）   │
│  └─ 元素间组合（搜索+筛选+排序、筛选+翻页）       │
│  步骤数: 3-4 步                                 │
└─────────────────────────────────────────────┘

┌─ 第三层：黑盒方法（至少 3 种不同方法）──────────┐
│  场景法（1条正常+1条分支+1条异常）               │
│  边界分析（有效边界+无效边界）                    │
│  等价类划分（有效类+无效类）                      │
│  判定表（多条件组合决策）                         │
│  状态迁移（合法转换+非法转换）                     │
│  模糊测试/错误猜测/表单测试/CRUD测试              │
│  （选3种以上，保证每个需求至少1条正向+1条异常）     │
└─────────────────────────────────────────────┘

┌─ 第四层：探索性（每个业务域至少 2 条 P3，──────────┐
│  总数不超过总用例数 20%）                        │
│  ├─ 边界数据（零数据/最大值/空列表）              │
│  ├─ 特殊操作（特殊字符/超长输入/快速点击）        │
│  ├─ 环境异常（网络中断/超时/权限越界）            │
│  ├─ 数据一致（前端展示 vs 数据库核对）            │
│  └─ 隐式推测（分页/防抖/空状态/响应式）           │
│  步骤数: 3 步                                    │
└─────────────────────────────────────────────┘

3.1 每层完成检查

逐层检查，当前层不通过不进下一层：

3.2 设计方法选择矩阵

根据复杂度来源选择方法（直接使用，不查外部文件）：

3.3 方法数量约束

每个业务域至少使用 3 种不同设计方法。单文档所有用例至少覆盖 4 种方法。

3.4 异常场景分类

异常测试覆盖以下六类，每个业务域至少覆盖输入+流程+权限三类：

3.5 优先级分配

3.6 测试数据生成规则

按以下优先级生成具体值：

1. 边界值数据 — 自动推导最小/最大值的具体数字
2. 有效等价类数据 — 合规范围内的典型值
3. 无效等价类数据 — 每个违规类型各一条
4. 特殊值数据 — 空值、null、0、空格、Unicode字符

> 暴露真实数据的用例，统一使用测试专用假数据，标注 [测试数据] 前缀。

3.7 用例字段结构

3.8 用例编号规则

> 模块前缀编号取代了旧版的全局连续编号。好处：每个文档独立生成，编号不冲突，可并行执行。

3.9 输出格式

{
  "源文件": "01-auth.md",
  "测试用例": [{
    "用例编号": "TC-AUTH-001",
    "业务域": "用户认证管理",
    "优先级": "P0",
    "测试维度": "功能",
    "用例类型": "冒烟测试",
    "设计方法": "场景法",
    "测试场景": "主流程：用户登录成功",
    "测试点": "验证正确的用户名和密码可以成功登录",
    "操作步骤": [
      {"步骤": 1, "操作": "访问 /login 页面", "预期": "页面正常加载"},
      {"步骤": 2, "操作": "输入有效用户名和密码", "预期": "输入正常"},
      {"步骤": 3, "操作": "点击「登录」按钮", "预期": "跳转到首页"}
    ],
    "测试数据": "用户名: admin, 密码: Admin@123",
    "前置条件": "用户已创建且未锁定",
    "需求来源": "REQ-AUTH-001",
    "源文件": "01-auth.md"
  }]
}

阶段四：合并输出

4.1 合并所有文档的结果

批量模式下，将所有文档的阶段二和阶段三输出合并：

{
  "元数据": {
    "源文件": ["01-auth.md", "02-file-management.md", "..."],
    "生成时间": "ISO格式",
    "需求总数": 212,
    "用例总数": 263,
    "覆盖率": "100%"
  },
  "业务域": [/* 从 phase1_domains.json */],
  "测试用例": [/* 从所有文档的 phase4 合并 */],
  "覆盖统计": {
    "按业务域": {"用户认证管理": 22, "文件管理": 24, ...},
    "按优先级": {"P0": 22, "P1": 64, "P2": 88, "P3": 89},
    "按设计方法": {"场景法": 124, "边界分析": 11, ...}
  }
}

4.2 调用 writer.py

python3 scripts/writer.py output/test_data.json

4.3 输出验证

• [ ] 每个文档独立标注源文件
• [ ] 用例编号格式正确（TC-{前缀}-NNN）
• [ ] 每个业务域有绿色分隔行
• [ ] 优先级颜色正确（P0红/P1橙/P2绿/P3灰）
• [ ] 优先级分布合理（P0 10-20%, P1+P2 60-80%, P3 10-20%）
• [ ] 每个业务域最外层结构 > 设计方法 ≥ 3 种
• [ ] 每个业务域覆盖异常场景 ≥ 3 类
• [ ] 每条用例操作步骤 3-5 步
• [ ] 测试数据提供具体值

单文档模式最少用例数参考

> 为什么要有最少用例数：防止给多个文档时 token 稀释，每个文档只出 1-2 条 Happy Path。这个数字是底线，不是上限。

引用文件一览

> 核心约束已内联到本文件。不再需要阅读 quality.md、design_methods.md、templates.md。

版本历史