如何高效使用Cucumber BDD测试多角色权限场景？

问题背景 #

我希望高效运用Cucumber开展BDD测试，现有一款多层架构应用，包含从基础管理员到完全所有者的多类用户角色，不同角色在首页拥有不同权限：基础用户仅可见1个板块，权限随角色等级提升，完全所有者最多可见20个板块。

我初步计划使用Cucumber的Examples表格编写测试用例，示例如下：

Feature: Home Page
  As a user of the app
  I want to see my homepage options
  So I can interact with the correct applications

Background:
  Given I have signed into my account

  Scenario: User can view all their allowed apps
    And my role is '<user>'
    And I navigate to the homepage
    When I click on the available apps option
    Then I should have '<apps>' available
    Examples:
    | user | apps |
    ...

但由于高等级角色继承低等级角色的权限，直接编写表格会产生大量重复内容，例如：

...
Examples:
| user     | apps     |
| level_1  | app_1    |
| level_2  | app_1    |
| level_2  | app_2    |
| level_3  | app_1    |
...

当角色等级到10级时，重复问题会非常严重。请问是否有更优的实现方式？比如在步骤定义中处理权限继承逻辑？

可行优化方案 #

方案一：在步骤定义中封装权限继承逻辑 #

核心思路是不用在Examples表格里罗列所有继承的权限，而是在步骤定义中根据角色等级自动计算该角色应拥有的全部权限集合，Examples只需要维护角色等级即可。

优化后的Feature文件

Feature: Home Page
  As a user of the app
  I want to see my homepage options
  So I can interact with the correct applications

Background:
  Given I have signed into my account

  Scenario Outline: User sees all inherited + new apps for their role
    And my role is '<role_level>'
    And I navigate to the homepage
    When I view the available apps section
    Then I should see all apps allowed for <role_level>
    Examples:
    | role_level |
    | level_1    |
    | level_2    |
    | level_3    |
    ...
    | level_10   |

对应的步骤定义（Java示例）

@Then("I should see all apps allowed for {string}")
public void verifyAllowedApps(String roleLevel) {
    // 按规则自动生成预期权限：level_n包含level_1到level_n的所有app
    List<String> expectedApps = new ArrayList<>();
    int level = Integer.parseInt(roleLevel.split("_")[1]);
    for (int i = 1; i <= level; i++) {
        expectedApps.add("app_" + i);
    }
    // 获取页面实际展示的app列表
    List<String> actualApps = homePage.getAvailableApps();
    // 断言权限匹配
    assertEquals(expectedApps, actualApps);
}

如果权限规则不是严格线性累加，也可以提前维护一个角色-权限映射表（比如Map<String, List<String>>），每个角色的权限列表已包含继承内容，步骤定义直接查表验证即可。

方案二：拆分场景，聚焦增量权限 #

既然高等级角色继承低等级权限，我们可以把测试拆成两类场景，避免重复验证：

• 基础场景：只验证一次低等级角色的基础权限
• 增量场景：只验证高等级角色新增的权限，同时确认继承的权限仍存在

优化后的Feature文件

Feature: Home Page
  As a user of the app
  I want to see my homepage options
  So I can interact with the correct applications

Background:
  Given I have signed into my account

  Scenario: Level 1 user sees only app_1
    And my role is 'level_1'
    And I navigate to the homepage
    Then I should see exactly 1 app: 'app_1'

  Scenario Outline: Higher level user gets new app plus inherited ones
    And my role is '<role_level>'
    And I navigate to the homepage
    Then I should see the new app '<new_app>'
    And I should still see all apps from lower levels
    Examples:
    | role_level | new_app |
    | level_2    | app_2   |
    | level_3    | app_3   |
    ...
    | level_10   | app_10  |

这种方式既减少了重复代码，又贴合BDD的核心：每个场景只验证一个明确的用户价值点。

方案三：用外部配置维护权限规则 #

如果权限规则复杂（比如存在特殊角色例外、非标准继承），可以把角色-权限的继承关系放在外部配置文件（JSON/YAML）中，步骤定义读取配置自动合并权限，Feature文件只需要传递角色名。

示例YAML配置（roles_permissions.yaml）

roles:
  level_1:
    apps: ["app_1"]
  level_2:
    inherits: level_1
    apps: ["app_2"]
  level_3:
    inherits: level_2
    apps: ["app_3"]
  # 特殊角色示例
  special_admin:
    inherits: level_5
    apps: ["app_audit", "app_settings"]

步骤定义中解析配置，自动合并继承的权限列表，再与页面实际权限做对比，后续权限规则变更只需要修改配置文件，不用动测试代码。

内容的提问来源于stack exchange，提问作者BasMan