测试领域建模

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

⚠️ 本技能单独使用效果有限，建议配合完整技能集（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. 忽略降级：只标注了故障影响，没标注降级方案 → 所有同步依赖必须附带降级策略