测试领域建模

SKILL.md

---
name: qa-domain-modeling
slug: qa-domain-modeling
displayName: 测试领域建模
version: 1.7.5
description: >-
  通过构建状态机、数据流图和服务依赖图来理清复杂的业务逻辑和系统边界。当需求文档复杂、涉及多个子系统交互、或者你搞不清楚数据在不同模块之间怎么流转的时候，应当使用此技能。领域建模不是为了画图而画图——它帮你发现那些"需求文档里没写的"隐式业务规则和系统边界。适用于复杂业务流程的测试范围可视化。
  本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

when_to_use: 用户说"画状态图"、"数据流"、"服务依赖"、"建模"、"领域建模"、"状态转换"、"数据流向"、"服务调用关系"、需要理解复杂业务流程、需求文档复杂难以理解时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-scenario-tree           # 输入：场景树
  downstream:
    - qa-ai-context-engineering  # 输出：领域模型传递给上下文工程
input_format:
  required:
    - name: 场景树
      type: object
      description: 来自qa-scenario-tree的输出，包含主路径/分支/异常场景
  optional:
    - name: 需求解构表
      type: object
      description: 来自qa-req-deconstruction，包含业务规则
output_format:
  structure:
    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）
    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）
    - 覆盖率：标注口径（基于现有需求/输入文档），禁止"全覆盖/100%"绝对化表述；缺失模块标注"未覆盖+原因"
    - model_id: "MODEL-XXXX"
    - scenario_ids: ["SC-XXXX"]
    - state_machine: "状态转换图"
    - data_flow: "数据流图"
    - service_dependency: "服务依赖图"
  traceability:
    - 每个模型带唯一ID（MODEL-XXXX）
    - 关联场景ID（TC_{场景模块缩写}_{功能缩写}_{序号}）
depth_requirement_quantification:
  reference_value: "根据业务复杂度调整建模深度：简单×1/中等×2/复杂×3"
  minimum: "至少构建1个领域模型图"
categories: ['Development','Requirements']
error_recovery_guidance:
  on_failure: "领域模型遗漏子系统时回退到场景树补充"
  retry_behavior: "补全场景后重新建模"
---
> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

# 领域建模

## 核心原则

不只是画流程图，而是画出状态机、数据流向、一致性约束点。

## 三种建模视图

### 视图1：状态转换图
**用途**：跟踪关键对象的状态变化

```text
状态机要素：
1. 状态：对象可能处于的状态
2. 事件：触发状态变更的事件
3. 转换：状态变更的路径
4. 守卫：状态转换的条件
5. 动作：状态转换时执行的操作

绘制方法：
1. 识别关键对象：什么对象有状态？
2. 列举状态：这个对象有哪些状态？
3. 标注转换：什么事件触发什么转换？
4. 标注条件：转换需要满足什么条件？
5. 标注动作：转换时执行什么操作？
```

**示例（订单状态机）**：
```text
┌─────────┐    用户下单    ┌─────────┐
│  待支付  │──────────────→│  已支付  │
└─────────┘               └─────────┘
     │                          │
     │ 超时未支付               │ 商家发货
     ▼                          ▼
┌─────────┐               ┌─────────┐
│  已取消  │               │  已发货  │
└─────────┘               └─────────┘
                               │
                          用户确认收货
                               ▼
                          ┌─────────┐
                          │  已完成  │
                          └─────────┘
```

### 视图2：数据流图
**用途**：追踪数据在模块间的流转

```text
数据流要素：
1. 数据源：数据从哪里来？
2. 数据处理：数据经过什么处理？
3. 数据存储：数据存储在哪里？
4. 数据消费：数据被谁使用？
5. 数据一致性：各处数据是否一致？

绘制方法：
1. 识别数据对象：什么数据在流转？
2. 追踪数据路径：数据经过哪些模块？
3. 标注数据操作：CRUD在哪里发生？
4. 标注一致性检查点：哪里需要验证数据一致？
5. 标注数据转换：数据格式在哪里变化？
```

**示例（订单数据流）**：
```text
用户下单
    │
    ▼
┌─────────┐
│ 订单服务 │──── 创建订单 ────→ ┌─────────┐
└─────────┘                    │ 订单表  │
    │                          └─────────┘
    │ 扣减库存                       │
    ▼                               │
┌─────────┐                         │
│ 库存服务 │←──── 查询库存 ──────────┘
└─────────┘
    │
    │ 发起支付
    ▼
┌─────────┐
│ 支付服务 │──── 创建支付单 ────→ ┌─────────┐
└─────────┘                      │ 支付表  │
    │                            └─────────┘
    │ 支付回调
    ▼
┌─────────┐
│ 回调处理 │──── 更新订单状态 ────→ 订单表
└─────────┘
```

### 视图3：服务依赖图
**用途**：识别服务间依赖关系和故障影响

```text
依赖图要素：
1. 服务节点：有哪些服务？
2. 依赖关系：谁依赖谁？
3. 调用方式：同步/异步？
4. 故障影响：挂了会怎样？
5. 降级方案：怎么容错？

绘制方法：
1. 识别服务：系统有哪些服务？
2. 识别依赖：服务间怎么调用？
3. 标注调用方式：同步/异步/MQ？
4. 标注故障影响：挂了影响什么？
5. 标注降级策略：怎么容错？
```

**示例（电商服务依赖）**：
```text
┌─────────┐     同步      ┌─────────┐
│ 订单服务 │──────────────→│ 库存服务 │
└─────────┘               └─────────┘
     │                          │
     │ 同步                     │ 同步
     ▼                          ▼
┌─────────┐               ┌─────────┐
│ 支付服务 │               │ 商品服务 │
└─────────┘               └─────────┘
     │
     │ 异步(MQ)
     ▼
┌─────────┐
│ 通知服务 │
└─────────┘
```

## 建模输出格式

### 状态转换表

| 当前状态 | 触发事件 | 目标状态 | 守卫条件 | 执行动作 |
|---------|---------|---------|---------|---------|
| 待支付 | 用户支付 | 已支付 | 金额正确 | 扣减库存 |
| 待支付 | 超时 | 已取消 | 超过30分钟 | 释放库存 |

### 数据流表

| 数据对象 | 源模块 | 目标模块 | 操作 | 一致性检查点 |
|---------|-------|---------|------|-------------|
| 订单 | 订单服务 | 订单表 | 创建 | 订单创建后 |
| 库存 | 库存服务 | 库存表 | 扣减 | 扣减后验证 |

### 服务依赖表

| 服务 | 依赖服务 | 调用方式 | 故障影响 | 降级策略 |
|-----|---------|---------|---------|---------|
| 订单服务 | 库存服务 | 同步 | 下单失败 | 返回库存不足 |
| 订单服务 | 通知服务 | 异步 | 通知延迟 | 重试+补偿 |

## 视图选择速查

| 业务特征 | 推荐视图 | 目的 | 产出物 |
|---------|---------|------|-------|
| 有明确状态流转 | 状态转换图 | 跟踪关键对象状态变化 | 状态转换表 |
| 数据跨模块流转 | 数据流图 | 追踪CRUD和数据一致性 | 数据流表 |
| 多个服务协同 | 服务依赖图 | 识别故障影响和降级 | 服务依赖表 |
| 三者均有 | 三种视图全建 | 完整模型 | 三表联动 |

## 输出示例

**场景：电商订单状态机建模**
→ 状态识别：待支付→已支付→已发货→已签收→已完成/已取消/已退款
→ 转换分析：正向流转（支付→发货→签收→完成）
→ 异常转换：支付失败、发货失败、退款申请
→ 输出：状态转换表 + 数据流图 + 服务依赖图

**场景：用户注册流程**
→ 数据流建模：注册表单→用户服务→数据库→消息队列→邮件服务

## 检查清单

建模完成后检查：
- [ ] 是否识别了所有关键状态？
- [ ] 状态转换是否完整？
- [ ] 数据流是否清晰？
- [ ] 服务依赖是否明确？
- [ ] 故障影响是否分析？
- [ ] 降级方案是否设计？

## 常见建模误区

1. **只画图不建表**：画了漂亮的状态图但没输出状态转换表 → 图用于理解，表用于测试，缺一不可
2. **状态遗漏**：只画了主路径状态，忽略了中间态和异常态 → 逐一检查每个对象的"非法状态"分支
3. **依赖单向**：只画了A→B的调用，没画B→A的回调 → 同步调用必须标注返回路径
4. **数据流断链**：数据流出后没画终点 → 每条数据流必须标注终点（存储/消费/丢弃）
5. **忽略降级**：只标注了故障影响，没标注降级方案 → 所有同步依赖必须附带降级策略