轨道授权功能测试

它实际上取决于您如何设置用于检查授权的代码,以及如何在操作中对其进行测试。我可以告诉你我们做什么作为例子。我们有和您一样的角色,还有一些需要登录的页面,一些需要角色,还有一些根据角色有不同的输出。我们对每种类型的测试都略有不同。

首先,我们分别测试授权和登录。

此外,我们还为需要用户登录的操作创建了过滤器,然后为需要特定角色的操作创建了其他过滤器。例如 check_admin , check_account_owner 等等,然后我们可以测试这些过滤器是否可以独立工作。

然后,我们在控制器测试中添加检查,以确定调用了正确的过滤器。我们使用shoulda并编写了一些简单的扩展,这样我们就可以添加如下检查:

should_filter_before_with :check_admin, :new

这样我们就可以测试需要测试的东西,而不再测试了。

现在,对于根据角色执行不同逻辑的更复杂的操作,我们要为包含特殊逻辑的每个角色测试这些操作。我们不为将被过滤的操作上的角色编写测试,也不为其他角色的超集编写测试。例如,如果该操作向表单中添加了更多字段(如果您是管理员),我们将测试非管理员和管理员。我们不测试admin和super admin,因为角色检查的代码理解super admin是管理员。

此外,对于包含逻辑以仅显示特定角色的特定项的模板,我们尝试将该代码移动到帮助程序中,或者如果常见,例如管理工具栏,则移动到部分。然后我们可以单独测试它们,而不是对包括它们在内的每个操作进行测试。

综上所述,只测试给定操作所需的内容。就像您不会在单元测试中测试Rails内部一样,如果您为角色检查和测试编写了通用代码,就不需要在每个操作中再次测试它。

在某些情况下,您可能需要针对不同的操作测试所有可能的角色和授权级别-例如,在银行工作时:)在这种情况下,采取更动态的测试方法是有意义的。不是定义每个测试用例,而是生成所有组合。

几年前,RyanDavis做了一个关于“功能测试矩阵”的演示,它是Zentest的一部分。 Dr. Nic did a writeup, 在文章的最后,你会在评论中找到更新的链接。这个解决方案正是为您描述的问题而设计的。例如,通过在嵌套循环中运行测试,您还可以滚动您自己的解决方案——其思想基本上是相同的。

考虑一个具有两个角色的应用程序:管理和只读 执行以下测试:

1. 以只读模式登录执行一些操作并注销。现在,从同一个系统和具有管理员角色的同一个浏览器登录,查看系统的行为。反之亦然。
2. 使用管理员角色登录,复制cookie值并注销。现在使用普通角色登录并使用CookiManager+或EditThisCookie工具编辑cookie值。如果应用程序按预期工作,那么这是一个问题。 从同一台机器、同一台机器、不同的浏览器、不同的机器重复上述测试用例2
3. 如果是厚客户端应用程序,则执行反向工程并分析代码。尝试改变授权管理的逻辑(需要有人对此有编码经验),重新编译代码并重复测试2-3。
4. 使用代理中断工具(如burp套件)分析两个角色的get/post请求。

现在,根据可用于应用程序的角色类型来决定测试用例。