5

我知道如何在 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

但这显然会导致大量的测试（站点上的每个控制器操作确实需要测试五次）。相反的方法是单独测试授权机制，然后在测试每个操作（设置时）之前验证为超级，并且只测试每个页面的一个版本。

我尝试了几种具有不同程度特异性的方法，但对任何事情都没有完全满意。当我测试更多用例时，我会感觉更舒服，但是测试代码的数量和抽象的难度一直是关闭的。有没有人对此问题感到满意的方法？

4

3 回答 3

4

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

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

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

然后我们在控制器测试中添加检查是否调用了正确的过滤器。我们使用 shoulda 并编写了一些简单的扩展，因此我们可以添加以下检查：

should_filter_before_with :check_admin, :new

这样，我们正在测试需要测试的内容，仅此而已。

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

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

总而言之，只测试给定操作所需的内容。就像您不会在单元测试中测试 Rails 内部一样，如果您为角色检查编写通用代码并对其进行测试，则无需在每个操作上再次对其进行测试。

于 2009-12-15T00:29:35.143 回答
2

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

几年前，Ryan Davis 做了一个关于 ZenTest 一部分的“功能测试矩阵”的演讲。Nic 博士写了一篇文章，在帖子的最后，您会在评论中找到更新的链接。该解决方案专为您描述的问题而设计。例如，您还可以通过在嵌套循环中运行测试来推出自己的解决方案 - 想法基本相同。

于 2009-12-22T22:57:15.303 回答
0

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

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

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

于 2017-01-08T04:34:12.867 回答