权限系统测试经验和沉淀

对于权限测试中的一些总结沉淀

本文是对于在测试工作中，常见的权限测试中的一些测试思路的总结，还有可能会出现的问题的记录。

在QA的日常测试工作中，权限测试是一种常见的测试类型。这种类型的业务逻辑，其实可以类比到日常的社会生活中的单位组织，公司组织结构，政府机关单位。具体到细节便是，谁是谁的下属，谁的权限比谁多，谁可以看到重要文件，谁可以提拔谁，谁可以开除谁。这些细节如果罗列一下，并让其通过code实现后，业务逻辑上看起来是这样

• 谁是谁的下属 -（父，子级节点关系）
• 谁的权限比谁多 -（相对高级角色能有更多的权限）
• 谁可以看到重要文件，谁不可以 - （不同角色的数据展示范围的限定）
• 谁有提拔，开除的权限 - （Root账户可以改变非Root账号的角色属性）

---

上述4个要点的核心是在角色

• 功能权限：
  如果这个项目中是用户有客户端页面的，那么直接在页面上的区别就是，相对高级角色会多一些按钮，button，入口之类的；若没有客户端页面，类似于开发机，Linux机器的话，就是文件的执行这类操作进行权限控制。
• 数据权限：
  如果这个项目中是用户有客户端页面的，那么直接在页面上的区别就是，相对高级角色会看到自己的次级节点的所有，而相对低级角色只能看到自身数据；若没有客户端页面，类似于开发机，Linux机器的话，就是文件的执行这类操作进行权限控制。
  总体逻辑可以直接图示
  

---

账号，角色，组织节点关系
对于这三个事物的描述，如果用面向对象的思想的话，可以先去创建三个类，然后账号类中的属性是另外两个类中的属性，这样即可。可以简单的用代码描述（语法可能有错，我就大概描述一下思路）

// 创建一个账户类
class account{
	int role;
	int organization;
}

// 创建一个类型的role类
class role{
	int super_admin;
	int manager;
	int employer;
}

// 创建一个organization类
class organization{
	int root_point;
	int middle_level_point;
	int base_point;
}

图示的思路如下

---

目前经历过两个项目中的权限测试，这两个项目中的的组织架构基本一致。不同处在于账号，角色，组织节点相互的配置关系上有所区别。

项目一：
A公司的Debt Collection System系统，简称DCS，当然为了避嫌，只会大概阐述整个组织结构和权限逻辑。
组织结构示意图：

配置过程描述
以账号为维度，去给账号添加三个属性：功能权限，数据权限，数据；功能权限的属性中还会以"角色"的维度再分类，数据权限属性中也会以"角色"的维度再分类。本项目的权限设计的过程中，账号并不强关联到组织架构中的某个节点。也就是说，在组织节点末端的账号配置一个顶级角色的功能权限、顶级角色的数据权限，这个账号也还是有所有的功能，所有数据的查看，账号的所在节点位置并不会限制账号的角色的功能权限和数据权限。

优点：组织节点不限制账号本身的角色权限，所以账号的角色权限可以灵活多变，配合业务需求来进行更替。
缺点：过于自由配置，容易出现基层人员可以看到非权限内所看的数据，和非权限内所拥有的功能，容易出现越权操作，造成数据污染。

---

项目二
公司B