Page tree

Skip to end of metadata
Go to start of metadata

您可以通过从一个测试中提取值,然后在另一个测试中使用它们来参数化测试(用于数据驱动测试)。这是通过以下工具实现的:

例如,如果您想用测试 1 响应的 id 值参数化测试 3 的一个请求值,那么可以将该字段设置为 Parameterized...

然后使用数据源向导指示您想要使用来自测试 1 的 id 元素的值(它将存储在自动添加到测试套件的 XML 数据库工具中)。
 


下面的部分解释了在测试之间传递值的两种不同策略。除了这个 test-to-test 值传递外,还可以通过以下方式传递值:

  • 通过变量:变量可用于参数化工具编辑器中所有或部分文本字段值。例如,文本字段可以引用当前套件定义的环境变量、数据源列、数据库列或变量。关于更多详情,请查阅  Parameterizing Tools with Variables
  • 通过脚本:这主要用于当您需要传递一个类型不是字符串的对象时。您只能通过脚本访问这些值。这是使用 com.parasoft.api.Context get(String) 和 put(String, Object) 实现的。  有关更多详情,请查阅 扩展和脚本基础

将值从一个测试传递到另一个测试

Parasoft SOAtest 支持两种实现测试链接的主要方法(即,从一个测试中提取值,然后在随后的测试中使用):

使用数据库 - 捕获单次运行的值

当需要捕获来自单个测试执行的值以便后续重用时,此方法用于简单的情况。 

例如,可以配置测试银行 Web 服务交易的测试套件。  该测试套件的测试 1 可以使用用户 ID 登录到服务中,然后 SOAP 响应将向测试 1 返回一个会话 ID。  可以将该测试套件的测试 2 配置为使用测试 1 的会话 ID,以执行交易。可以在测试套件中配置任何测试,以使用 SOAP 响应参数作为 SOAP 请求参数。

本例的测试场景可能如下所示:

  • Test 1: 登录并检索 ID
    • XML 数据库: 提取用户 ID
  • 测试 2:使用 ID 调用服务 1
  • Test 3: 使用 ID 调用服务 2
  • ...

在本例中,我们假设每次执行测试套件时,在整个场景中都使用一个不同的 Id,但是对于每个场景的运行,它都是一个单一的 ID。

需要注意的是,同样的原则适用于所有 SOAtest 的数据库工具(XML、浏览器、Header、JSON、对象、文本)。您可以将单个值提取到任何这些数据库工具中,然后在后续测试中使用它(作为参数化的值,以及通过使用 com.para-soft.api.ScriptingContext.getValue(String, String) 编写脚本)。  提取的值存储为字符串。  

该功能的设计目的在于适应广泛的定制需求;上面给出的示例只是一个示例应用程序。

教程

有关此功能如何工作的逐步示例,请参见 Storing Results to Be Used in Subsequent Tests

使用具有可写数据源的数据库 - 捕获值以在多次运行中进行迭代

当您需要提取一个未知计数的值列表,然后让测试或测试套件遍历已提取的每个值时,这种情况非常有用。假设以下测试场景:

  • 数据源:
    • 可写的: 捕获的用户ID
  • Set-Up 测试: 获取用户 IDs
    • XML 数据库: 提取用户 Ids 并将其写入可写数据源
  • Test 1: 使用捕获的 Ids 调用服务 1(使用“Captured User IDs”参数化)
  • Test 2: 使用捕获的 Ids 调用服务 2(使用“Captured User IDs”参数化)

在这种情况下,“Get User IDs”测试假设一个服务返回一个用户 ID 列表(一个序列),并且每个用户 ID 都被提取并写入所需的可写数据源列。用户 Ids 的确切数量可以是未知的,也可以是可变的。“Get User IDs”测试执行和可写数据来源填充值之后,该场景继续到测试套件的其余部分(测试 1 和测试 2 ),并且后续测试用可写数据源参数化(例如,通过选择适当的数据源,然后对该数据源中的字段和列进行参数化)。这意味着测试可以遍历它,并使用“Get User IDs”写入其中的所有 IDs。换句话说,它们将对检索到的每个 ID 执行。

如果生成值的测试一次检索一个值,但是在一个数据源上迭代,并将提取的值存储到一个可写数据源中,则可写数据源非常有用。在这种情况下,一个示例测试场景可能是:

  • 数据源:
    • 表格: 用户名
    • 可写的: 捕获的用户ID
  • Set-Up 测试: 获取和存储用户 ID(用户名参数化)
    • XML Data Bank: 提取用户 ID 并将其写入可写数据源
  • Test 1: 使用捕获的 Ids 调用服务 1(使用“Captured User IDs”参数化)
  • Test 2: 使用捕获的 IDs 调用服务 2(使用“Captured User IDs”参数化)

在本例中,“获取和存储用户 ID”测试步骤将运行多次:每次运行“Usernames”数据源提供的每个用户名。对于每次运行,它都将向“Captured User IDs”数据源写入一个用户 ID。现在“Captured User IDs”可写数据源被填充(使用用户 Id),测试套件的其余部分将使用这些 ID 执行测试 1 和测试 2。

有关可写数据源的详细信息,请查阅 Configuring a Writable Data Source

惯例(一般经验法则)

惯例目的在于:

  • 从消息中提取内容,只需将其作为场景的一部分,然后单独使用数据库。
  • 提取一个值列表,然后让另一个测试迭代这些值并逐个使用它们,可以使用带有可写数据源的 XML 数据库。

  • No labels