2009-12-15 133 views
5

我知道如何在Rails中运行功能/集成测试,这个问题是关于最佳实践的。比方说,授权使用四个不同的用户角色来执行:Rails授权功能测试

  • 基本
  • 编辑
  • 管理
  • 超级

这意味着,对于每个动作有五种不同的行为可能(4个角色+未经认证/匿名)。一种方法我已经采取是测试上的每一个动作每一个角色,例如:

  • test_edit_by_anonymous_user
  • test_edit_by_basic_user
  • test_edit_by_editor_user
  • test_edit_by_admin_user
  • test_edit_by_super_user

但这显然导致lot测试(网站上的每个控制器动作确实需要测试五次)。相反的做法是单独测试授权机制,然后在测试每个操作(设置)之前验证为超级,并且仅测试每个页面的一个版本。

我已经尝试了不同程度的特异性的几种方法,但还没有完全满足任何事情。当我测试更多案例时,我感觉更舒适,但测试代码的数量和抽象难度一直是关闭的。有没有人有办法解决他们满意的问题?

回答

4

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

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

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

然后,我们在控制器测试中添加了正在调用正确过滤器的检查。我们使用早该并写了一些简单的扩展,所以我们可以添加检查,如:

should_filter_before_with :check_admin, :new 

这样,我们正在测试需要测试什么,并没有更多的。

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

此外,对于包含逻辑,只显示某些角色的某些项目模板,我们试图和代码转移到助手,或者共同如管理工具,为谐音。然后我们可以自己测试这些,而不是包含它们的每个动作。

总结一下,只测试一下给定动作需要的东西。就像你不会在你的单元测试中测试Rails内部部分一样,如果你为你的角色检查编写通用代码并测试它,你不需要在每个动作上再次测试它。

2

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

几年前,瑞恩·戴维斯做了一个关于“功能测试矩阵”,这是ZenTest的一部分呈现。 Dr. Nic did a writeup,,并且在帖子结尾处您可以在评论中找到更新链接。此解决方案专为您所描述的问题而设计。例如,您也可以通过在嵌套循环中运行测试来推出自己的解决方案 - 这个想法基本相同。

+0

谢谢!视频和Ryan的文章*真的很有用。我很高兴知道有人在讨论这个问题。 – 2009-12-23 01:44:16

+0

如果任何人有困难访问视频: [视频是YouTube上的点击这里](http://www.youtube.com/watch?v=KUjnAztX9yk) – 2012-06-26 23:24:21

0

考虑其具有2个角色admin和只读 执行以下测试的应用程序:

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

现在基于类型可为您的应用决定测试用例的作用。