测试平台-03-测试平台的模块边界应该怎么拆
测试平台做到一定阶段后，最容易冒出来的一类问题不是：
- 技术栈不对
- 页面不好看
- 接口不够多
而是更底层的一件事：
模块边界开始混了。
一旦边界混掉，后面通常会出现这些症状：
- 一个功能改动牵动很多模块
- 新需求一来，需求归属很快就说不清该落在哪一层
- 执行、环境、报告、权限互相引用
- 某些公共逻辑到处复制
- 平台明明还能跑，但越来越没人敢动
所以测试平台做大之后，真正决定它能不能继续长的，往往不是框架，而是边界。
这篇文章就只讲这个问题：
测试平台的模块到底该怎么拆，才不至于越做越乱。
一、模块拆分最先要回答的，不是“按页面拆”还是“按表拆”，而是“按责任拆”
很多平台一开始拆模块，最容易走两条偏路：
1. 按页面拆
例如：
- 首页模块
- 列表模块
- 执行页模块
- 报告页模块
这种拆法早期写页面很顺，但后面业务逻辑会被页面结构牵着走。
2. 按表拆
例如：
- 任务表模块
- 报告表模块
- 用户表模块
这种拆法看起来整齐，但很容易把“数据结构”误当成“业务边界”。
更偏向的一条原则是：
平台模块先按责任边界拆，再落到表和页面。
二、更常用的测试平台核心边界
如果是自动化测试平台，通常先把边界收在下面几块。
1. 任务定义边界
它回答的是：
- 平台里到底有哪些任务
- 每种任务需要什么参数
- 谁能触发
- 它应该怎么被执行
注意，这里只是“定义”，不是“执行”。
2. 执行边界
它回答的是：
- 任务怎么被真正跑起来
- 执行状态怎么流转
- 执行中日志和产物怎么收集
很多平台最容易出问题，就是把任务定义和执行边界混到一起。
3. 环境边界
它回答的是：
- 任务运行依赖哪些环境
- 地址、账号、设备、数据、密钥放在哪里
- 不同环境如何隔离
环境边界如果没单独拉出来，后面几乎一定会污染任务逻辑。
4. 报告边界
它回答的是：
- 一次执行的结果如何被沉淀
- 日志、截图、断言、指标如何组织
- 什么叫成功、失败、部分成功
报告边界不等于“前端展示页”，它本质上是结果资产层。
5. 权限边界
它回答的是：
- 谁能看到什么
- 谁能执行什么
- 谁能改环境和配置
- 哪些动作属于高风险动作
6. 接入边界
它回答的是：
- Jenkins 怎么接
- 告警怎么接
- 外部系统怎么接
这层边界如果不单独处理，平台内部逻辑很容易被外围系统拖乱。
三、最容易拆错的 4 组边界
1. 任务定义和任务执行混在一起
这是最常见的一种。
表现通常是：
- 任务对象里既有定义字段，又有运行态字段
- 代码里一个模块既负责配置任务，又负责调度任务
后果是：
- 一次运行把任务定义污染掉
- 执行逻辑难复用
- 状态管理变得很乱
2. 环境和任务参数混在一起
很多平台早期会把：
- 环境地址
- 账号信息
- 特定任务参数
全塞进一套大表单。
短期看方便，长期会导致：
- 同类环境配置重复很多份
- 敏感信息和普通参数混着流动
- 换环境时任务定义被迫跟着改
3. 报告和执行过程混在一起
例如：
- 执行器直接决定页面报告怎么展示
- 报告字段和运行时状态强耦合
后面只要报告结构一变，执行链路也容易跟着动。
4. 权限控制散落在各模块
这会导致：
- 这里做一层判断
- 那里又做一层判断
- 不同入口规则不一致
最后最容易出现的不是没权限，而是权限规则互相打架。
四、更推荐的拆法：对象边界先于页面边界
如果现在让我从 0 到 1 设计一个测试平台，先按对象边界想，再映射到页面和接口。
例如：
TaskDefinitionTaskExecutionEnvironmentExecutionReportUserRoleExternalIntegration
然后再问：
- 这些对象谁拥有谁
- 谁依赖谁
- 哪些变化应该互不影响
这一步想清楚后，再去设计：
- 页面入口
- API 路由
- 数据表结构
会稳很多。
五、一套更实用的最小模块划分
如果只看第一版平台，更推荐至少先切成下面这几块。
1. 任务中心
职责：
- 维护任务定义
- 维护参数模板
- 管理触发入口
不要在这里直接写执行细节。
2. 执行中心
职责：
- 创建执行记录
- 驱动执行器
- 更新状态机
不要把环境配置和报告展示塞进这里。
3. 环境中心
职责：
- 管理环境信息
- 管理账号、地址、依赖资源
- 提供执行所需的运行配置
4. 报告中心
职责：
- 汇总执行结果
- 管理日志、截图、附件
- 提供统一查看入口
5. 权限中心
职责：
- 用户、角色、资源授权
- 高风险动作控制
6. 接入中心
职责：
- Jenkins 集成
- 告警集成
- Webhook / 外部系统接入
这套划分不一定是最终形态，但足够帮助平台早期不乱成一锅。
六、模块之间最重要的不是“有没有关系”，而是“关系是否可控”
平台模块不是不能互相调用，而是不能无边界互相渗透。
更在意几条基本规则：
1. 任务定义不直接操心报告展示
否则任务一改，报告一起抖。
2. 执行中心不持有环境细节
执行中心应该消费环境，而不是把环境逻辑写死在自己内部。
3. 权限中心尽量收口
权限判断最好有统一入口，不要到处散。
4. 接入中心不要反向污染核心业务
Jenkins、Webhook、告警这些外部接入，只应该影响触发方式，不该把核心领域对象拖得很碎。
七、更推荐的一个检查问题：如果删掉某个页面，这个模块还成立吗
这是我很常用的一个判断方式。
如果删掉某个页面或某个前端入口后，这个“模块”就完全失去意义，那它大概率不是模块，只是页面切片。
真正稳定的模块应该是：
- 即使页面改版
- 即使 API 改路由
它的核心责任仍然成立。
八、最容易踩的几个坑
1. 早期为了快，把所有逻辑先写一起
这在第一个月通常很爽，但到了第二阶段会特别痛。
2. 公共能力没有明确归属
例如：
- 日志收集谁负责
- 产物存储谁负责
- 任务状态流转谁负责
如果归属不清，后面一定会重复实现。
3. 页面改版牵动后端边界
这通常说明后端模块其实是按页面切出来的，而不是按责任切的。
4. 权限作为“附加功能”后补
后补权限通常意味着：
- 各模块都已经暴露了很多入口
- 再补统一规则会很费劲
九、真实案例：为什么一个“执行任务”需求，最后把任务、环境、报告全改乱了
场景
一个测试平台早期只有少量任务类型，所有逻辑基本都放在一个任务模块里：
- 任务定义
- 任务执行
- 环境选择
- 报告查询
一开始功能不多，这种写法看起来还能撑住。
执行
后来平台新增一个需求：
- 同一任务支持按不同环境、不同账号、不同参数模板触发
看起来只是“执行入口更灵活一点”，但改动一开始就很痛：
- 任务模块要改
- 环境模块要改
- 报告展示要改
- 权限也要跟着改
现象
问题的根因并不是需求复杂，而是边界早就混了：
- 任务定义直接持有环境细节
- 执行记录和任务定义没拉开
- 报告直接依赖任务表中的运行字段
于是一个执行需求，变成整个平台都在震。
排查
后面把边界重新拆开后，问题就清楚了：
- 任务定义应该只描述“是什么任务”
- 环境中心应该描述“在哪跑”
- 执行中心应该描述“这次怎么跑”
- 报告中心应该描述“跑完产出了什么”
修复
真正有效的修复不是再补几个字段，而是重构边界：
- 任务定义和执行记录拆表
- 环境能力抽成独立中心
- 报告只依赖执行结果，不反向依赖任务运行态
这个案例很典型地说明：
模块边界拆错时，后续每个需求都会看起来比实际更重。
十、写在最后
测试平台的模块边界设计，真正要解决的不是“好不好看”，而是平台后面还能不能安全演进。
如果把这件事压缩成一句最实用的话，可以概括为：
先按责任切边界，再让页面、接口、表结构去映射这些边界。
只要这一步做对，平台后面即使继续长，也更容易保持清晰，而不是慢慢变成谁都不敢碰的大泥球。