📚 课程目录第3章审批流基础

3. 审批流基础：审批流定义、典型审批节点与状态机模型

审批流（Approval Workflow）是企业业务系统中用于将单据、申请或任务按照预定义的路径和规则，依次提交给相关角色进行审核、决策或处理的核心流程。在集成测试与契约测试的语境下，审批流是验证系统间交互正确性的关键场景，其状态转换的严谨性直接影响业务数据的完整性与合规性。

3.1 审批流定义与核心要素

审批流本质上是一个有向图，其中节点代表审批状态或操作，边代表状态之间的合法转换。一个完整的审批流定义包含以下核心要素：

要素	说明	示例
流程模板	定义审批流的整体结构、节点顺序、分支条件	采购审批模板（金额≤1万走简易流程）
审批节点	流程中的最小执行单元，包含操作人与操作类型	部门经理审批、财务复审
流转规则	决定节点间如何跳转的条件表达式	金额>5万需总经理审批
参与者	执行审批操作的用户、角色或系统	审批组、指定用户、上级主管
超时策略	节点在规定时间内未处理时的自动动作	自动转审、自动驳回、升级通知

集成测试视角： 审批流定义中的每个要素都可能成为系统间契约的边界。例如，流转规则中的条件表达式若涉及外部系统的数据（如预算系统返回的可用余额），则必须在契约测试中明确该接口的响应格式与取值范围。

3.2 典型审批节点详解

企业审批流中，以下四种节点构成了绝大多数业务场景的基础操作单元。理解每个节点的语义与触发条件是构建正确状态机的前提。

提交（Submit）：流程的起始节点。申请人填写表单并触发流程实例化。提交操作通常伴随数据校验与完整性检查。提交后，流程进入第一个待审批节点。
审核（Approve）：核心决策节点。审批人根据业务规则对申请内容进行审查，并做出“同意”或“拒绝”的决策。审核通过后，流程沿正向路径流转至下一节点或结束。
驳回（Reject）：终止或回退节点。审批人认为申请不符合要求时，将流程驳回。驳回可分为“驳回至发起人”和“驳回至上一节点”两种模式，前者要求重新提交，后者允许修改后继续。
转审（Transfer）：任务委派节点。当前审批人因权限不足、利益冲突或临时缺席，将审批任务转交给其他指定人员处理。转审不改变流程的整体路径，仅变更当前节点的执行人。

  关键区别： 审核与转审的本质区别在于决策权的转移。审核是做出最终决策，而转审是保留决策权但更换执行人。在契约测试中，转审接口通常需要额外传递“原审批人”与“目标审批人”字段。

3.3 审批流状态机模型

状态机（State Machine）是描述审批流行为最严谨的数学模型。它将审批流抽象为有限个状态（State）以及状态之间的转换（Transition），每个转换由事件（Event）触发，并可附加守卫条件（Guard）。

下图展示了一个典型的三级审批流状态机模型，包含提交、部门审核、财务审核、总经理审核、驳回、结束等核心状态及其转换关系。

3.4 状态机模型的形式化定义

在契约测试中，审批流状态机通常被形式化为一个五元组，以便于生成测试用例与验证交互逻辑：

审批流状态机 = (S, E, T, s0, F)

其中：
  S  = 有限状态集合
       {草稿, 待部门审核, 待财务审核, 待总经理审核, 驳回(部门), 驳回(财务), 已结束}
  E  = 触发事件集合
       {提交, 审核通过, 驳回, 转审, 重新提交}
  T  = 状态转换函数: S × E → S
       例如: T(待部门审核, 审核通过) = 待财务审核
             T(待部门审核, 驳回)     = 驳回(部门)
  s0 = 初始状态 (草稿)
  F  = 终态集合 {已结束}

契约测试陷阱： 状态机定义中的“隐式转换”是集成测试的常见遗漏点。例如，某些系统允许在“待财务审核”状态下直接“驳回至发起人”，而另一些系统则强制要求先“驳回至部门”。契约测试必须显式覆盖所有合法转换路径，并验证非法转换是否被正确拒绝（返回 403 或业务错误码）。

3.5 审批流状态机与契约测试的映射关系

将审批流状态机模型映射到契约测试中，可以形成清晰的测试覆盖策略。下表展示了状态、事件与契约接口之间的对应关系：

状态机元素	对应契约接口	测试验证点
状态 S	查询审批状态接口	返回的状态枚举值是否在允许集合内
事件 E	审批操作接口（提交/审核/驳回/转审）	请求参数是否包含必要字段，响应是否返回新状态
转换 T	状态变更回调接口	回调通知中的旧状态与新状态是否满足转换函数定义
守卫条件	业务规则校验接口	条件不满足时是否返回明确的拒绝原因

通过这种映射，测试团队可以基于状态机模型自动生成覆盖所有合法路径与边界条件的契约测试用例，确保审批流在系统集成环境中的行为与业务定义完全一致。