在现代公司中通过定义系统角色来管理用户和授权访问系统资源。在大多数系统实现中，至少存在两个角色，管理员和普通用户。前者代表允许访问特权功能和敏感信息的角色，后者代表允许访问常规业务功能和信息的角色。良好开发的角色应该匹配应用支持的业务流程。
记住冷酷、困难的授权不是管理访问系统对象的唯一方法这一点是非常重要的。在一下可信度高的环境中，秘密性不是特别关键，更柔和的管理措施比如应用工作流程和审计记录措施能支持数据完整性要求，而并不限制用户接触这些功能或创建难以管理的负责角色结构。在角色工程中考虑金发姑娘原则（译注：凡事要有度，不要超越极限）是重要的。定义太少或泛泛的角色（这暴露了用户不需要访问的功能）和定义太多，太细的角色（这限制访问需要的功能）一样不好。
验证应用定义的系统角色是足够有效定义并区别了系统和业务角色来管理访问系统功能和应用的权限。
通过或不通过系统开发者或管理员的帮助，做一个角色权限矩阵列表。这个矩阵应该枚举了所有有权限的角色和探索他们被赋予于对象的权限包括其中的约束条件。如果是应用提供的矩阵，那么应该被测试人员验证。如果没有，那么测试者应该创建一个，并确定矩阵满足应用所希望的访问控制策略。
| 角色 | 权限 | 对象 | 约束条件 |
|---|---|---|---|
| 管理员 | 读取 | 客户记录（多个） | |
| 经理 | 读取 | 客户记录（多个） | 只有业务单元的记录 |
| 职工 | 读取 | 客户记录（多个） | 只有被经理分配相关的记录 |
| 客户 | 读取 | 客户记录 | 只有自己的记录 |
真实世界的角色定义例子可以参考WordPress 角色文档。WordPress有六个默认角色，从超级管理员到订阅者。
虽然大部分完全和精准测试方法是使用手工测试，但是 spidering tools 也非常有用。使用每个不同的角色登陆并爬行整个应用（不要忘记在使用过程中排除登出链接）。
这个问题的整改措施可以采取下面形式：