在多人共用的测试台架上，权限的边界一旦没划清楚，就会直接影响到设备的预约、任务的执行、数据的查看，还有环境的维护，testbed的权限分组到底要怎么去划分，还有当权限被改过了以后，为什么它看起来好像还是没有生效，碰到这种事，可不能只是去瞅一眼，那个账号还能不能登得进去就算了，还得去看一看，角色、项目、资源池、执行的队列，还有缓存里的状态，这些东西，是不是都走到一块儿去了，权限要是设计得太粗糙了，那普普通通的测试人员，就有可能会不小心去改动了环境；可要是设计得太细碎了呢，项目真正跑起来的时候，又会被各种各样的申请流程，给死死地卡住，所以，这得照着真实使用时的场景，去把它给划分开。

　　一、testbed权限分组要怎么划分

　　给testbed分权限组，得先照着职责来划，而不是简简单单地，就按部门去分一下，一个人，他到底是归研发管，还是归测试管，这还不够，更要紧的是，得去看他是不是需要去管那些设备、要不要去改动环境、是不是要去亲手执行任务、需不需要去查看报告，或者是要不要去维护那些脚本。

　　1、管理员组

　　管理员，是负责用户的管理、资源池的维护、让设备上线还是下线、审批大家的权限、管着全局的那些配置，还有去处理各种异常的，这个组里面的人，数量最好还是别太多了，为的是要避免，好几个人在同一时间，都去动手改配置，结果到了最后，责任就怎么也说不清楚了。

　　2、环境维护组

　　环境维护的人，是可以去安装依赖的库、更新镜像、维护驱动、调整测试的服务，还有去处理台架的故障的，但是，他们倒不一定非要去管着所有用户的那些权限，这么做，就能把技术上的维护，和账号的管理，给分开来了。

　　3、测试执行组

　　测试的人员，他们主要的需求，就是去创建任务、预约设备、执行测试用例、去看看自己跑出来的那些运行的日志，还有把最后的结果给下载下来，要是项目上需要大家在一块儿协作，那可以让他们，去看一看挂在同一个项目下面的那些任务，但是，不太建议把能跨着项目去看报告，还有去修改配置的权限，也一块儿给开放出去。

　　4、只读审查组

　　项目经理、质量的人、还有客户的接口人，这几位呢，通常就只需要去翻一翻任务的状态、测试的报告、失败的记录，还有趋势变化的数据，有一套只能看、不能动手改的权限，就足够去满足他们，想要追踪进度的需求了，同时，也能少掉好多误操作的风险。

　　二、权限变更后为何没有生效

　　testbed的权限明明已经被改过了，可是它看起来就是没有生效，比较常见的原因，倒不一定是修改这个动作它失败了，而是权限到底是从哪里来的、系统里的缓存、登录的会话、项目覆盖的范围，还有资源能管的范围，这几样东西，它没有跟着同步过来，尤其是在那种接上了LDAP、单点登录，或者是企业统一账号的环境里面，更是得要一层一层地去查清楚，到底是哪一关，还在那里管着权限。

　　1、用户可能还挂在旧的会话上面

　　在权限刚刚被改完了以后，用户要是没有退出去，再重新登进来一次，那系统这边，就有可能会还在用着旧会话里存着的那些信息，可以让用户先去点一下退出的按钮，把浏览器给整个关掉，然后再重新进来看一看，权限到底变了没有。

　　2、角色是给改了，可是项目那边还没给授权

　　有一些testbed的系统，它用的是那种，把角色和项目的范围，绑在一块儿的方式，一个用户，他虽然已经被拉进了测试执行的组里面，可是，要是还没有被加到对应的那个项目里头去，那他还是照样，会看不见任务、设备，或者是报告。

　　3、资源池的权限，它没有跟着一起同步过来

　　设备呢，通常会被搁在不同的资源池里面，就比如，硬件的在环台架、软件的在环环境、仿真的环境，还有硬件的板卡组，一个用户，他手里攥着项目的权限，这可不代表，他就自动地，也拿到了每一个资源池的预约，还有执行的权力。

　　4、上头的权限，被更上层的策略给盖过去了

　　要是系统里面，已经设好了，像是不许普通用户去修改全局的配置、不许跨着项目去下载报告、不许不是维护人员的人去重启设备，这一类的死规矩，那么就算是单独去给某一个角色，加上了一些权限，它也是有可能会被那更上层的、全局的策略，给硬生生地拦下来的。

　　三、权限变更后要怎么复核

　　在testbed的权限被改动了以后，是一定要去做一次复核的，可不能就只是去问上用户一句“这下能不能用了”，就拉倒了，一种更叫人觉得心里踏实的法子，是拿着一张清单，去把登录、菜单的显示、项目的入口、设备的列表、任务的提交，还有数据的查看，这几个顶顶关键的地方，一个一个地，都给验证一遍。

　　1、去核对一下，账号它到底是从哪儿来的

　　先去闹明白，这个用户，他用的到底是一个本地建的账号、LDAP那边同步过来的账号，还是单点登录的账号，要是同一个人，他名下挂着两个不同的号，那管理员那边，就有可能是只把本地号给改了，可那个用户，他真正登进来的时候，用的却还是企业那边的号。

　　2、去查一下，角色和项目之间的映射关系

　　进到管用户，或者是管权限的那个界面里头去，去瞅瞅这个用户，他呆在哪个组里头、是从哪儿继承来的角色、他跟哪些项目挂上了钩、还有他能管的资源池，到底有多大的范围，要重点去瞧一瞧，会不会有好几个不同的组，它们给的权限是互相打架的，又或者，那些旧的、早该退掉的组，是不是还赖在那里，没有给清掉。

　　3、拿一套最小的动作，去把它给验一遍

　　就让那个用户，去试着打开一下项目的页面、去试着预约一台设备、去提交上一条最简单的测试任务、去翻看一下执行的日志，还有去点一下下载报告的按钮，要等到这每一步，他都能顺顺当当地走下来，这才能说，整套权限的链条，基本上是没毛病了。

　　4、去把这次为什么要改，给记到记录里头去

　　每一次动权限，都得要把是谁申请的、是谁批的、是什么时候改的、都动了哪些内容，还有这次改动，它只在多大的一个范围里头有效，这些都给留下来，那些临时的权限，等到日子一到，就得去收回来，要不然的话，等项目都完事了，可那个能执行，或者是能维护的权限，还挂在那里，这就很容易，给后面悄悄地埋下一个雷。

　　总结

　　testbed的权限分组，到底要怎么去划，还有当权限被改过了以后，又是因为什么，它才没有能马上生效，这里面的关键，就是要把角色的职责，和资源能管到的范围，给拆开来，当成两码事去瞅，在动手分组的时候，就照着管理员、维护环境的、跑测试执行的，还有那种只能看、不能碰的审查，这几种角色去把边界给划出来；等到要去排查，它为什么不生效的时候，就要顺藤摸瓜地去查，是不是旧会话还挂着、项目有没有给授权、资源池的那部分权限是不是没同步、是不是有更上层的全局策略在拦着，还有那个账号，它到底是从哪个源头过来的，等这一套权限的变更，全都捣鼓完了以后，还得再用实际的操作，去亲手把它给验上一遍，要确认好了，这个用户，他该干的事，都能干得成，而那些他不该碰的配置，他也确确实实，是没那个本事去越权瞎改的。