4. 系统核心架构
图形化测试流程编排系统的本质，是把“测试逻辑”从脚本代码中抽离出来，变成一张可编辑、可执行、可观测的有向图。要让这张图真正跑起来，系统需要在六个层面协同工作：前端画布负责“画”，节点引擎负责“懂”，执行调度负责“跑”，结果反馈负责“看”，插件体系负责“扩”，数据存储负责“记”。理解这六者的职责边界与数据流向，是掌握整个系统架构的关键。
一、六层架构的职责与协作
前端画布是用户接触系统的第一界面。它提供节点面板、画布区域、属性配置栏和工具栏，用户通过拖拽节点、连线、填写参数来完成流程编排。画布并不直接执行任何测试逻辑，它的核心产出是一份结构化的流程描述文件，通常以 JSON 格式保存，包含节点列表、连线关系、参数配置和全局变量定义。
节点引擎拿到这份 JSON 后，首先要做的是“理解”它。引擎会解析节点类型、识别依赖关系、构建有向无环图（DAG），并进行拓扑排序，确定哪些节点可以并行、哪些必须串行。同时，引擎还会做变量绑定和类型校验，确保上游节点的输出能正确传递给下游节点。如果图中存在环或孤立节点，引擎会在执行前就报错，避免无效执行。
执行调度层负责把可执行任务图变成真实的执行动作。它维护任务队列，控制并发度，处理超时和重试，驱动状态机在“待执行→执行中→成功/失败/跳过”之间流转。调度层还需要处理条件分支和循环节点，根据上游节点的执行结果动态决定下一步走哪条路径。
结果反馈层贯穿整个执行过程。它收集每个节点的实时日志、断言结果、耗时、截图或报告，并把执行状态回写到画布上，让用户能直观看到哪个节点正在执行、哪个节点失败了。失败定位是结果反馈层的重要能力，它需要把错误信息关联到具体的节点和参数上。
插件体系层决定了系统的扩展能力。测试场景千变万化，系统不可能内置所有节点类型。插件体系提供节点注册机制、协议适配层和生命周期钩子，让开发者可以按统一规范接入 HTTP 接口、数据库操作、消息队列、自定义脚本等能力。插件与核心引擎之间通过标准接口通信，保证可插拔。
数据存储层负责持久化所有关键数据：流程定义与版本、执行记录与结果、环境配置与凭证。流程定义需要版本管理，支持回滚和对比；执行记录需要按时间、状态、流程 ID 检索；凭证需要加密存储，避免明文泄露。
二、一次完整执行的数据流
下面以一次典型的接口测试流程为例，展示数据在各层之间的流转过程：
1. 用户在画布拖入「HTTP 请求」→「断言」→「数据库校验」三个节点并连线
2. 画布生成 flow.json：
{
"nodes": [
{"id": "n1", "type": "http", "method": "POST", "url": "/api/login"},
{"id": "n2", "type": "assert", "expr": "status == 200"},
{"id": "n3", "type": "db", "sql": "SELECT FROM sessions"}
],
"edges": [{"from": "n1", "to": "n2"}, {"from": "n2", "to": "n3"}]
}
3. 节点引擎解析 JSON，构建 DAG，拓扑排序结果：n1 → n2 → n3
4. 执行调度层按顺序调度：n1 执行 → 返回 → 绑定到上下文
5. n2 读取上下文中的 status，断言通过
6. n3 使用上下文中的 查询数据库，返回结果
7. 结果反馈层将每个节点的状态、日志、耗时回写到画布
8. 数据存储层保存本次执行记录和结果快照关键设计原则：画布只负责“描述”，引擎只负责“解析”，调度只负责“执行”，反馈只负责“呈现”，插件只负责“扩展”，存储只负责“持久化”。六层之间通过标准数据契约通信，任何一层的内部实现变化都不应影响其他层。
三、各层核心能力对比
| 层级 | 核心输入 | 核心输出 | 关键能力 | 典型技术选型 |
|---|---|---|---|---|
| 前端画布 | 用户拖拽操作 | flow.json | 拖拽、连线、校验、撤销 | React Flow / X6 / G6 |
| 节点引擎 | flow.json | 可执行任务图 | DAG 构建、拓扑排序、变量绑定 | 自研解析器 / 图算法库 |
| 执行调度 | 可执行任务图 | 执行事件流 | 并发控制、重试、状态机 | Celery / 自研调度器 |
| 结果反馈 | 执行事件流 | 可视化反馈 | 实时日志、断言、失败定位 | WebSocket / SSE |
| 插件体系 | 节点注册请求 | 可插拔能力 | 协议适配、生命周期钩子 | SPI / 动态加载 |
| 数据存储 | 流程与执行数据 | 持久化数据 | 版本管理、检索、加密 | PostgreSQL / MongoDB |
四、常见误区与复盘
误区一：画布直接执行测试逻辑。有些实现为了省事，在画布的前端代码里直接发起 HTTP 请求或执行脚本。这会导致执行状态无法统一管理、无法并发调度、无法持久化记录。正确做法是画布只生成描述文件，执行完全交给后端调度层。
误区二：节点引擎与插件体系耦合过紧。如果引擎代码里写满了各种节点类型的 if-else 分支，新增一种节点就要改引擎核心代码。正确做法是定义统一的节点接口，插件按接口实现并注册，引擎只面向接口编程。
误区三：结果反馈只存日志不关联节点。如果执行日志是一大段文本，用户很难定位到具体哪个节点出了问题。正确做法是每条日志都携带节点 ID 和执行上下文，反馈层能精确高亮到画布上的对应节点。
复盘建议：在架构设计初期，先明确六层之间的数据契约（flow.json 的 schema、执行事件的格式、插件接口的定义），再分别实现各层。契约稳定后，各层可以独立演进和测试。对于中小规模系统，可以先合并执行调度与结果反馈，但画布、引擎、插件、存储四层建议从一开始就分离。
理解这六层架构，不仅有助于读懂系统的代码组织方式，更能在排查问题时快速定位故障层：画布问题看 JSON 生成，引擎问题看 DAG 解析，调度问题看任务队列和状态机，反馈问题看事件通道，插件问题看注册与接口实现，存储问题看数据模型和索引。分层清晰，排障才能高效。