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

例如，如果您想用测试 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。

然后使用数据源向导指示要使用哪个元素的值。或者，您可以手动配置要存储到数据库或可写数据源的值，然后将响应与已保存的响应进行参数化。

除了这个 tool-to-tool 传递外，还可以通过以下方式传递值：

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

惯例（一般经验法则）

惯例目的在于：

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

  • No labels

Need assistance? Visit our support page