测试平台-04-测试平台的权限模型设计
测试平台做到一定阶段后，权限模型几乎一定会变成一个绕不过去的问题。
最开始，权限往往会被理解得比较简单：
- 谁能登录
- 谁能看页面
- 谁能点按钮
但只要平台真的开始承载真实任务，很快就会遇到更复杂的场景：
- 谁能执行哪个任务
- 谁能看哪个项目的报告
- 谁能改环境配置
- 谁能操作生产巡检或高风险任务
- 谁能接 Jenkins、改告警、动密钥
到这个阶段，权限就不再是“加几个角色枚举”的问题，而是平台边界的一部分。
这篇文章就只讲这个问题：
测试平台的权限模型到底该怎么设计，才不至于后面越补越乱。
一、测试平台权限最容易被低估的，不是登录，而是“动作风险”
很多平台早期做权限，最先想到的是菜单和页面：
- 管理员能看所有菜单
- 普通用户只能看部分菜单
这一步当然要做，但它远远不够。
因为平台真正危险的不是“看到某个页面”，而是下面这些动作：
- 执行任务
- 修改环境
- 切换配置
- 查看敏感日志
- 下载报告或数据
- 触发生产巡检
所以更关注的权限问题通常是：
- 谁能对什么资源做什么动作
而不是单纯：
- 谁能看到哪个页面
二、更常用的一套权限拆分方式
如果是测试平台，通常会把权限拆成 4 层来看。
1. 身份层
这层回答的是：
- 你是谁
- 属于哪个团队、项目、组织
这一层通常和：
- 用户系统
- SSO
- 组织架构
关联更紧。
2. 角色层
这层回答的是：
- 你在平台里属于什么角色
例如：
- 平台管理员
- 项目管理员
- 普通使用者
- 只读用户
- 巡检操作者
但角色通常不适合设计得过细，因为角色只是中间层，不是全部。
3. 资源层
这层回答的是：
- 你能接触哪些对象
例如：
- 哪个项目
- 哪个任务
- 哪个环境
- 哪份报告
4. 动作层
这层回答的是：
- 你对这些资源能做什么
例如：
- 查看
- 编辑
- 执行
- 删除
- 导出
- 审批
这 4 层叠在一起，权限模型才会比较完整。
三、测试平台里最值得重点控的 5 类资源
如果从风险角度看，最优先要考虑这几类资源。
1. 任务资源
这里不仅是“能不能看任务”，更重要的是：
- 能不能执行
- 能不能改执行参数
- 能不能删除或停用
2. 环境资源
环境通常是平台权限里风险很高的一块。
因为环境一旦被误改，后面任务可能会：
- 打错系统
- 跑错环境
- 使用错误账号
3. 执行结果和报告资源
会低估这块，但报告里经常会包含：
- 日志
- 截图
- 接口返回
- 环境信息
其中可能有敏感数据。
4. 系统配置资源
例如：
- Jenkins 配置
- 告警配置
- 密钥配置
- 外部系统接入配置
这类资源通常不应该开放给所有平台使用者。
5. 高风险动作资源
这里更准确地说，不只是资源，而是动作本身需要单独控。
例如：
- 生产巡检触发
- 生产环境回归
- 批量删除
- 批量导出
四、为什么不建议只做“角色权限表”
很多平台最容易写成这样：
- 管理员：全权限
- 开发：部分权限
- 测试：部分权限
- 游客：只读
这种方式在最早期能用，但很快会遇到几个问题：
1. 同一角色不一定拥有同一资源范围
例如两个测试同学：
- 都是“测试角色”
- 但未必都能看同一个项目或同一套环境
2. 同一资源上的动作风险不同
例如：
- 看任务定义
- 执行任务
- 改任务参数
风险完全不是一个量级。
3. 环境和动作叠加后，角色很快爆炸
如果平台里有：
- 测试环境
- 预发环境
- 生产环境
再加动作差异，纯角色法很快就会变得非常难维护。
所以更推荐：
- 角色只做粗粒度身份
- 资源范围和动作权限单独建模
五、更推荐的权限判断模型
如果压缩成一句话，更推荐的平台权限模型是：
用户 + 角色 + 资源范围 + 动作权限 + 环境等级
例如判断一条执行请求时，不只是看：
- 你是不是测试角色
还要看：
- 你有没有这个项目的访问范围
- 你能不能执行这类任务
- 这个任务是不是生产级高风险任务
只有这几层一起看，结论才更稳。
六、几个特别高频的权限判断场景
1. 谁能执行任务
这通常要看三件事：
- 是否有项目访问权限
- 是否有任务执行权限
- 当前任务对应环境是否在允许范围内
2. 谁能改环境配置
这通常比执行任务风险更高。
因为一旦环境配置被改坏，影响会扩散到一整批任务。
3. 谁能看报告和日志
不要默认“能跑的人都能看所有结果”。
某些报告可能包含：
- 敏感返回
- 业务数据
- 账号信息
4. 谁能做系统级操作
例如：
- 改全局配置
- 接第三方系统
- 管理密钥
这类动作通常应被明显收紧。
七、一套更实用的最小权限骨架
如果平台从 0 到 1，更推荐至少先做下面几层。
1. 平台级角色
例如：
- 平台管理员
- 普通用户
- 只读用户
2. 项目级资源范围
例如：
- 用户属于哪些项目
- 用户能看哪些任务集合
3. 动作级权限
至少先区分：
- 查看
- 编辑
- 执行
- 删除
- 管理
4. 环境级限制
至少先区分：
- 测试环境
- 预发环境
- 生产环境
生产相关动作最好单独控制，不要跟普通测试环境混为一谈。
八、更推荐的平台权限检查点
如果要落实现实系统，通常会把权限判断尽量收在几个关键点。
1. 登录和身份加载
这里解决：
- 你是谁
- 你属于哪些组织和项目
2. 请求入口统一鉴权
这里解决：
- 有没有访问这类接口的基本权限
3. 核心业务动作统一授权判断
这里解决：
- 有没有对当前资源做当前动作的权限
不要把这一步散落在每个控制器细节里。
4. 高风险动作二次确认
这里解决：
- 生产环境执行
- 批量操作
- 系统配置修改
这类最好不仅做权限判断，还做操作确认和审计。
九、最容易踩的几个坑
1. 只做前端菜单权限
这类权限很容易给人一种“已经控住了”的错觉，但后端动作如果不控，问题还是会暴露。
2. 权限散在各个模块里
今天这里写一段判断，明天那里再补一段，后面很快会出现规则不一致。
3. 平台管理员直接全开，长期不收口
早期这么做很省事，但后面会变成极大风险源。
4. 不区分资源权限和动作权限
能看到某个对象，不代表就应该能改、能删、能执行。
十、真实案例：为什么“统一挂在测试角色下”，最后还是出了高风险误操作
场景
一个测试平台早期权限设计很粗：
- 管理员
- 测试
- 访客
当时觉得已经够用了，因为大部分用户都是测试角色。
执行
后面平台接入了更多任务，包括：
- 普通测试环境回归
- 预发巡检
- 生产只读巡检
某次一个测试同学在操作时，误把原本只该在测试环境执行的任务参数带到了更高风险环境。
现象
事后复盘会发现：
- 这个同学确实是“测试角色”
- 也确实有执行权限
但问题是：
- 系统没有把环境等级和动作权限叠加判断
换句话说，平台只判断了“是不是测试”，没有判断：
- 这个测试是否有权限对这个环境执行这个动作
排查
后面把权限逻辑拆开看，问题就很清楚：
- 角色太粗
- 环境边界没进权限模型
- 高风险动作没有单独控制
修复
最后的修复不是简单多加一个角色，而是把模型升级成：
- 项目范围控制
- 动作权限控制
- 环境等级控制
- 高风险动作二次确认与审计
这个案例很典型地说明：
测试平台权限模型如果只做到“谁是谁”，迟早会在“谁能对什么做什么”这里出问题。
十一、怎么把权限模型沉淀成长期能力
更合适的做法是从一开始就固定几个原则：
- 页面权限不等于动作权限
- 角色权限不等于资源权限
- 高风险环境必须独立控制
- 高风险动作必须留审计
只要这几个原则能被平台坚持下来，后面即使继续接更多任务类型，权限模型也不至于完全失控。
十二、写在最后
测试平台的权限设计，说到底要回答的不是“用户是什么角色”，而是：
- 他能接触哪些资源
- 他能对这些资源做什么
- 在什么环境下能做
如果把这件事压缩成一句最实用的话，可以概括为：
平台权限更稳的做法，是从“角色判断”升级到“资源 + 动作 + 环境”的联合判断。
只有这样，平台才不会在能力越来越多之后，慢慢变成一个高风险入口。