为功能测试增加以不同用户身份运行的能力

https://blueprints.launchpad.net/barbican/+spec/add-run-as-for-functional-tests

目前所有 Barbican 功能测试都在同一个用户 ID 下运行。此蓝图增加了 Barbican 功能测试以不同于默认用户 ID 的用户身份运行的能力。这是为了支持并行执行测试,并确保底层系统状态不会因其他并发执行的测试而改变。

问题描述

目前所有 Barbican 功能测试都在同一个用户下运行。由于这些测试并行运行,因此对底层系统状态的任何假设都是无效的——例如,对分页密钥的测试可能会失败,如果另一个测试并行执行密钥操作。

提议的变更

拟议的更改不仅解决了这个问题,还提供了一种以隔离的方式运行测试的方法,即在自己的用户 ID 下运行。

第一步是确定哪些测试需要以非默认用户身份运行。这在测试用例创建时由测试用例作者完成。

接下来,测试用例作者将在一个扩展了新类(functionaltests.api.base.DynamicUserTestCase)的类中创建他们的测试,该类扩展了现有的 functionaltests.api.base.TestCase,以指示测试不应在默认用户下运行,而应在新的用户下运行。

此新用户的用户名、密码和租户名称来自 barbican 的 etc/dev_tempest.conf 文件中的设置。在新的 [key-manager] 部分中,有三个新的设置

dynamic_user_userid_prefix=testuser_
dynamic_user_password=topsecret
dynamic_user_tenant_prefix=testtenant_

作为每次测试调用的一部分,DynamicUserTestCase setUp() 代码的 oslotest fixture 将

  1. 生成一个新的、唯一的用户 - 新用户 ID = dynamic_user_userid_prexfix 与 UUID 拼接而成 - 新密码 = dynamic_user_password 的值 - 新租户名称 = dynamic_user_tenant_name_prefix 的值与用于新用户 ID 的相同 UUID 拼接而成。

  2. 登录该用户

  3. 运行测试

  4. 注销并删除上述创建的用户

接下来,测试将像往常一样运行。

当测试完成时,oslotest fixture tearDown() 代码将注销并删除新用户。

需要更新 Barbican 的组件以支持此新功能的是

  1. 添加到 functionaltests.api.base.py 的新类 DynamicUserTestCase,它将创建一个新用户并登录该用户以供该测试用例使用。

  2. DynamicUserTestCase.setup() 将创建并登录新用户

  3. DynamicUserTestCase.tearDown() 将删除该用户

  4. functionaltests.api.base.TestCase 中的支持函数,用于与身份验证提供程序进行用户 ID 创建、登录和删除的通信。

备选方案

讨论的另一种方案是创建一个新的装饰器 @run_as,它可以用于任何测试,而无需对 TestCase 进行新的子类化。

我们拒绝了这种方法,原因如下

  1. 需要此装饰器的测试通常具有其他测试重点。例如,密钥的分页测试的重点是分页,而不是密钥。这些测试不应与密钥分组在同一类中,而应放在自己的子类中。

  2. 在并非最佳机制的情况下添加装饰器可能会导致混乱且难以调试的代码。应小心确保装饰器确实是实现最佳方法。

数据模型影响

没有数据模型影响。

REST API 影响

没有 REST API 影响。

安全影响

此更改允许基于每个测试用例的动态用户创建和删除。它还允许测试用例指定要运行的现有用户。所有这些更新都集中在 functionaltests 下,不影响 Barbican API,因此不会对任何 API 进行更改。

通知与审计影响

此更改没有通知/审计影响。

其他最终用户影响

测试日志将显示每个测试在测试日志中运行的用户 ID。它们不是 API 的一部分,但对于问题确定和调试可能很有用。

性能影响

此 CR 的唯一性能影响在于 functionaltests 路径。它对产品的性能没有影响。

请求不同用户的测试将产生额外的路径长度以

  • 创建和登录用户(在测试运行之前)

  • 删除用户(在测试完成后)

其他部署者影响

需要确保 etc/dev_tempest.conf 中用于动态用户创建的字段对测试人员来说是可以接受的。

开发人员影响

添加功能测试的开发人员可以选择让这些测试在不同的用户 ID 下运行(如果他们希望)。否则,所有功能测试都将在默认用户下运行。

单元测试不受此更改的影响。

实现

负责人

主要负责人

sheyman (hockeynut)

工作项

在批准此蓝图后,我们将编写并发布新类的实现以及实用程序和 fixture 中的支持代码以供审查。

依赖项

此功能依赖于 keystone 的用户和租户创建和删除 API。

测试

此代码是 Barbican 功能测试的一部分,将在 devstack gate 以及在开发人员/测试人员机器上通过运行“tox -e functional”来执行。

文档影响

目前没有关于如何编写 Barbican 测试的文档(这是一个 Barbican 工作积压中的开放故事)。此蓝图中的散文可以用作描述 DynamicUserTestCase 用法的起点。

文档中需要涵盖的重要事项是关于何时需要将测试作为 DynamicUserTestCase 运行的指导。我们应该使用一个例子,例如

  • 测试 A 创建大量密钥,然后获取所有密钥的列表并根据创建的数量验证该列表的大小。

  • 测试 B 只是创建一个新的密钥。

如果测试 B 在测试 A 的执行过程中运行,那么测试 A 期望的密钥计数将减少一个,并且测试 A 将失败。

但是,如果测试 A 以与测试 B 不同的用户身份运行,那么两者之间将不会有干扰,并且两个测试都将按预期通过。

参考资料