测试领域建模

领域建模

核心原则

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

三种建模视图

视图1：状态转换图

用途：跟踪关键对象的状态变化

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

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

示例（订单状态机）：

┌─────────┐    用户下单    ┌─────────┐
│  待支付  │──────────────→│  已支付  │
└─────────┘               └─────────┘
     │                          │
     │ 超时未支付               │ 商家发货
     ▼                          ▼
┌─────────┐               ┌─────────┐
│  已取消  │               │  已发货  │
└─────────┘               └─────────┘
                               │
                          用户确认收货
                               ▼
                          ┌─────────┐
                          │  已完成  │
                          └─────────┘

视图2：数据流图

用途：追踪数据在模块间的流转

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

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

示例（订单数据流）：

用户下单
    │
    ▼
┌─────────┐
│ 订单服务 │──── 创建订单 ────→ ┌─────────┐
└─────────┘                    │ 订单表  │
    │                          └─────────┘
    │ 扣减库存                       │
    ▼                               │
┌─────────┐                         │
│ 库存服务 │←──── 查询库存 ──────────┘
└─────────┘
    │
    │ 发起支付
    ▼
┌─────────┐
│ 支付服务 │──── 创建支付单 ────→ ┌─────────┐
└─────────┘                      │ 支付表  │
    │                            └─────────┘
    │ 支付回调
    ▼
┌─────────┐
│ 回调处理 │──── 更新订单状态 ────→ 订单表
└─────────┘

视图3：服务依赖图

用途：识别服务间依赖关系和故障影响

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

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

示例（电商服务依赖）：

┌─────────┐     同步      ┌─────────┐
│ 订单服务 │──────────────→│ 库存服务 │
└─────────┘               └─────────┘
     │                          │
     │ 同步                     │ 同步
     ▼                          ▼
┌─────────┐               ┌─────────┐
│ 支付服务 │               │ 商品服务 │
└─────────┘               └─────────┘
     │
     │ 异步(MQ)
     ▼
┌─────────┐
│ 通知服务 │
└─────────┘

建模输出格式

状态转换表

数据流表

服务依赖表

视图选择速查

输出示例

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

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

检查清单

建模完成后检查：

• 是否识别了所有关键状态？
• 状态转换是否完整？
• 数据流是否清晰？
• 服务依赖是否明确？
• 故障影响是否分析？
• 降级方案是否设计？

常见建模误区

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