本文介绍了如何使用Rational Tester for SOA Quality 对业务流程中调用的Web服务进行集成测试。通过阅读本文，您将了解如何从一个 BPEL 描述文件出发生成针对 Web 服务的集成测试脚本，如何编辑测试脚本，如何创建和使用数据池，以及如何分析 Web 服务测试结果。

　　1. 引言

　　Rational Tester for SOA Quality 是一个用于验证 Web 服务的功能测试工具，该工具支持 Web 服务测试脚本的创建、执行以及测试报告的分析。Rational Tester for SOA Quality 基于 Rational Performance Tester Framework 实现。它继承了 Rational Performance Tester 的许多强大的功能特性，例如零代码测试设计，数据池，自动数据关联以及强大的测试报告框架等等。在阅读本文之前，您需要对 Rational Performance Tester 有基本的了解。

　　在开始测试之前，先让我们一起来了解一下 Rational Tester for SOA Quality 的主要优势：

　　零代码 (code-free) 测试设计通过提供良好的用户界面，使得用户无需编写任何代码便可以自动创建、编排、修改并执行测试。这里，测试的概念是指对 Web 服务的若干操作进行调用并验证返回结果。用户可以设置或验证 Web 服务的各种信息，包括 HTTP header, cookies 以及 SOAP 消息。

　　简化无图形界面 (GUI-less) 服务的测试通过自动产生 Web 服务的客户端，该工具大大简化了对无图形化用户接口的服务测试。

　　简化服务集成测试从业务流程(由 WS-BPEL 定义)中自动产生对其调用的 Web 服务的测试。使得用户可以迅速地对复杂的业务流程进行测试并能够确保测试的最大覆盖率。

　　支持多种服务标准支持 SOAP, HTTP, JMS, WS-Security 以及 UDDI。

　　自动数据关联和数据驱动测试在记录测试的过程中，工具能够自动检测到输入数据从而进行数据驱动测试。提供表格式数据编辑器，用户可以创建定制的数据集在测试回放 (playback) 过程中将其自动插入测试脚本。

　　在接下来的内容中，我们将利用一个实际的业务流程，向您介绍如何利用 Rational Tester for SOA Quality 进行服务集成测试。

　　安装测试环境

　　本文的测试环境使用 IBM® Rational® Performance Tester 7.0.0.2(英文)，IBM® Rational® Tester for SOA Quality 7.0.0，WebSphere Process Server 6.0.2, Microsoft® Windows® 2000 Professional SP2。

　　注意：在安装 IBM® Rational® Tester for SOA Quality 7.0.0 之前，必须保证您的 IBM® Rational® Performance Tester 的版本高于 7.0。

　　在安装完测试环境之后，您需要下载本文提供的应用程序，将其安装在 WPS 上并启动。

　　这是一个简单的业务流程，接收两个整数类型的数据作为输入参数，然后调用一个外部的 Web 服务，将两个整数进行相加，将和数作为结果返回。其流程结构如图 1 所示：

　　图 1. InvokerProcess 业务流程

　　该流程包括三个活动：

　　Receive：该活动是整个流程的起点，用于从客户端接收消息并将接收到的数据存储于流程的变量中。在本流程中，该活动接收两个参数 input1, 和 input2 作为输出。BPEL 定义如下表所示。

　　表 1. Receive 活动定义

　　＜bpws:receive createInstance="yes" name="Receive" operation="operation1"
partnerLink="InvokerProcess" portType="ns0:InvokerProcess" wpc_displayName="Receive"
  wpc_id="6"＞
      ＜wpc:output＞
        ＜wpc:parameter name="input1" variable="Input1"/＞
        ＜wpc:parameter name="input2" variable="Input2"/＞
      ＜/wpc:output＞
＜/bpws:receive＞

　　InvokeArithmetic：该活动调用一个外部的 Web 服务，将输入的两个数字进行加法运算，返回和数。BPEL 定义如下表所示。

　　表 2. InvokeArithmetic 活动定义

　　＜bpws:invoke name="InvokeArithmetic" operation="add"
partnerLink="ArithmeticServiceImpl" portType="ns1:ArithmeticServiceImpl"
wpc:displayName="InvokeArithmetic" wpc_id="8"＞
      ＜wpc:input＞
        ＜wpc:parameter name="num1" variable="Input1"/＞
        ＜wpc:parameter name="num2" variable="Input2"/＞
      ＜/wpc:input＞
      ＜wpc:output＞
        ＜wpc:parameter name="addReturn" variable="Output1"/＞
      ＜/wpc:output＞
＜/bpws:invoke＞

　　Reply：该活动是这个流程的终点，返回上一步计算出的和数。BPEL 定义如下表所示。

　　表 3. Reply 活动定义

＜bpws:reply name="Reply" operation="operation1" partnerLink="InvokerProcess"
portType="ns0:InvokerProcess" wpc_displayName="Reply" wpc_id="7"＞
      ＜wpc:input＞
        ＜wpc:parameter name="output1" variable="Output1"/＞
      ＜/wpc:input＞
＜/bpws:reply＞

　　其中被调用的 Web 服务为 ArithmeticService, 该服务提供加法和减法两种操作。接口定义如下图所示。

　　图 2. ArithmeticService 接口定义

　　本文的测试用例是一个非常典型的服务集成的应用，通过业务流程中的 INVOKE 活动调用外部的 Web 服务，Web 服务支持两种操作，加法和减法。本文将创建两个测试分别调用服务的两种操作。接下来，您将跟随我们完成以下主要工作：

　　生成测试，调用 add 方法
　　编辑测试，使用数据池、自动数据关联、验证点、IF-THEN 逻辑等功能
　　创建调度，循环多次运行测试
　　执行测试并分析测试报告，重点分析功能测试报告

　　现在，一切准备就绪，就让我们一起来体验 Rational Tester for SOA Quality 为我们所带来的愉快体验吧 !

　　2. 使用 Rational Tester for SOA Quality 进行服务集成测试

　　Rational Tester for SOA Quality 可以通过业务流程的 BPEL 描述文件自动生成对其调用的 web servcie 的测试脚本。在这一节，您将会通过一个实例的学习，了解测试流程的所有步骤。但在此之前，为了避免您在日后使用时，由于对本工具自身的支持局限不了解，而造成不必要的时间和精力上的浪费。首先，我们将介绍一下该工具对测试的支持局限：

　　在 BPEL 文件中，必须将业务流程依赖的所有 WSDL 文件通过 import 语句声明。
　　在 BPEL 文件中，必须保证 import 语句的正确性，其中的 location 属性不能包含相对路径，如 ../../name.wsdl。
　　INVOKE 在 BPEL 文件中，INVOKE 语句中不允许有值为 null 的属性出现，如
＜bpws:invoke name="CalculateOrderNumAndDate" operation="null"
 partnerLink="null
" portType="
wpc:null"
  wpc_displayName="CalculateOrderNumAndDate" wpc_id="12"＞

　　这样的语句是不符合要求的，不能被正确解析。

　　支持通过业务流程中的 INVOKE 活动产生对其调用的 Web 服务的测试，不支持 RECEIVE 活动和 REPLY 活动。

　　在 WSDL 文件中，必须保证 soap operation 元素中包含 soapAction 属性，如以上列出的几点约束是在使用过程中，不断提炼总结出来的，我们不能保证它的全面性，但却是会经常碰到的问题。希望能够对您日后的工作有所帮助。

　　现在，在一切准备工作结束之后，我们便可以进入真正的测试环节。

　　2.1 导入测试资源

　　在开始测试之前，您需要完成以下两项工作

　　创建一个测试工程，存储您的测试脚本和测试结果。
　　将业务流程的描述文件(.bpel)以及相关的 wsdl 和 schema 文件导入您的测试工程。

　　创建测试工程

　　测试工程作为存储测试的容器，是进行测试的必备元素。您可以先创建一个空的工程用于存储之后的测试脚本，也可以直接地创建一个测试，Rational Tester for SOA Quality 会自动为您的测试创建测试工程。在本节，我们选择第一种方式，首先来创建一个工程。具体步骤如下：

　　选择 File -＞ New -＞ Performance Test Project
　　在 Project name 中填写 TestInvoker，点击 Finish 按钮。

　　图 3. 创建测试工程

　　在弹出的 Create New Test from Recording 对话框中，点击 Cancel。

　　在这里，我们取消了弹出的对话框，并不直接创建测试脚本，因为在创建测试之前，我们还需要做些其他工作。Rational Tester for SOA Quality 工具是通过解析被测应用的资源文件，来创建测试脚本的，对于普通的 Web 服务测试，需要导入服务的接口描述文件(WSDL 文件)，对于本文讨论的服务集成测试，则需要导入业务流程的定义文件 (BPEL 文件 ) 以及相关的 WSDL 文件。接下来，我们就来学习如何导入资源文件。

　　导入资源文件

　　下载本文提供的资源文件 Demo.zip，将其解压后保存在您的本地。压缩文件中包括被测业务流程的 BPEL 定义文件、接口描述文件以及调用的 Web 服务的接口描述文件，具体步骤如下。

　　选择 File -＞ Import
　　在弹出的 Import 窗口中，选择 General -＞ File System，点击下一步。
　　点击 From directory 右侧的浏览按钮，找到资源文件在本地的存储位置，如图 4 所示。选中需要导入的资源文件，包括：
　　ArithmeticServiceImpl.wsdl 业务流程中被调用的 Web 服务的接口描述文件
　　InvokerProcess.bpel 业务流程的描述文件
　　InvokerProcess.wsdl 业务流程接口的描述文件
　　InvokerProcessArtifacts.wsdl 业务流程中引用资源的描述文件

　　4.点击 Into folder 右侧的 Browse 按钮，选择资源的导入地址。这里，我们选择测试工程 TestInvoker 的根目录。点击 Finish。

　　图 4. 导入资源文件

　　到此，我们将测试所需的全部资源文件导入了我们创建的测试工程下。接下来，我们便可以利用这些资源文件，来创建测试脚本。

　　2.2 创建测试

　　在本节中，我们将利用上一节中导入的 BPEL 文件，创建一个测试脚本。完整的测试脚本包括对 Web 服务的两次调用，分别对应 add 方法和 subtract 方法。其中对 add 方法的调用，是工具通过解析 BPEL 文件自动生成的，对于 subtract 方法的调用，是我们利用工具提供的功能手动进行添加的，我们将在下一节中进行介绍。现在，我们先来看一下如何通过 BPEL 文件，自动生成一个测试脚本。

　　选择 File -＞ New -＞ Other -＞ BPEL to Web Service Test，点击下一步点击 Browse 按钮，从工作空间中选择 BPEL 文件，点击下一步。如图 6 所示

　　图 5. 选择 BPEL 文件

　　3、在 web service test generation 页面，指定业务流程中活动和序列 (sequence) 的处理方式，从而计算待测路径的数量。其中，每条路径将产生一个测试。整个页面分为 5 部分

　　Flow，选择如何处理 flow 中的并发序列。由于本文的例子只有一条路经，因此我们选择 Test only the longest path。

　　Switch，选择是否测试流程中的 otherwise 活动。
　　Throw，选择是否测试流程中的 throw 活动。
　　Invoke，选择是否测试 invoke 活动中内嵌的异常处理。

　　最后，选中 Enable data correlation in generated tests，为 Web 服务调用中的参数启动自动创建引用(reference)的功能。

　　4、点击 Recount paths，重新计算测试路径，我们可以看到在页面底部，显示 1 path(s) will be tested，表明将有一个测试被自动产生。点击下一步。

　　图 6. 指定业务流程中活动的处理方式

　　5、选择操作 InokerProcess.bpel_ws_1，点击下一步。

　　6、选中 TestInvoker，在 Folder name 一栏填写 test1。将产生的测试放置于 TestInvoker 工程下的 test1 目录中。点击 Finish。

　　图 7. 指定测试生成目录

　　如果一切正常的话，您应该在工具左侧的 Test Navigator 视图中看到您的第一个 Web 服务测试。双击测试 InvokerProcess/test1/InokerProcess.bpel_ws_1，在右侧的 Performance Test 视图中展示了该测试的具体内容。在 Test Contents 区域，列出了测试的所有步骤，其中，add(“1”,”2”) 表示调用了 Web 服务中的 add 方法，输入的参数分别为 1 和 2。在这里，我们通过工具，自动创建了一个测试脚本。但在实际的测试中，这里建立的测试脚本往往是不能满足要求的，还需要对脚本进行一些额外的编辑工作。

　　图 8. 测试内容

　　2.3 编辑测试

　　测试创建完成之后，接下来我们来看一下如何编辑生成的测试。从图 8 中，我们可以看到测试中有多项属性可以进行修改，但由于本文篇幅有限，我们只介绍其中的一部分内容。在这一节中，您将会学习如何创建并使用数据池 (Datapool)，如何使用不同的验证机制对响应消息进行验证，什么是自动数据关联机制以及如何为测试添加 IF-THEN 逻辑等等。

　　创建测试元素

　　从图 8 可以发现，自动生成的测试中只包含一个元素，add(“1”,”2”)。该行表示对 Web 服务中 add 方法的一次调用，输入参数为 1 和 2。为了测试的完整性，我们需要将测试元素补全。首先为 add 方法的调用增加调用响应元素 (web service call)，选中 dd(“1”,”2”)，点击右侧的 Add 按钮，出现 Web Service Return 选项。

　　图 9. 为测试增加元素

　　点击 Web Service Return 后，弹出一个对话框。您可以点击 Default，创建一个空的响应，或者点击 Update，通过执行真正的调用，创建带有返回值的响应。在这里，我们选择 Update。
　　如果调用成功，您将会看到在 Test Contents 区域中，增加了一个对 add 方法调用的响应，add(“”,”3”)，表明调用的返回值为 3。

　　图 10. 增加响应元素

　　3、在测试中增加对 Web 服务中 subtract 方法的调用。选中 InvokerProcess.bpel_ws_1，点击 Add 按钮，在弹出的列表中，选择 Web Service Call。

　　4、在 WSDL 选择页面，选择测试的 wsdl文件，/TestInvoker/ArithmeticServiceImpl.wsdl，点击下一步。

　　5、选择待测的方法 subtract，点击 Finish。

　　如果操作成功，您应该看到在 Test Contents 编辑框中，产生了一个新的测试元素，subtract(“0”,”0”)。接下来，为该调用元素添加一个调用响应元素。最终界面如图 11 所示。到这里为止，我们便看到了一个较完整的测试脚本，其中覆盖了对 Web 服务的所有方法的测试。但为了能够更加充分地体现测试自动化的优势，我们还将为测试数据创建一个数据池，具体介绍请见下一节。

　　图 11. 添加第二次调用后的测试编辑界面

　　创建数据池文件

　　数据池用于存储测试数据，在脚本回放时可以自动从数据池中取出数据，完成多组测试数据的测试。数据池在 Rational 测试中的使用率很高，通过使用数据池，可以通过简单的脚本完成大量数据的测试，缩短测试时间、提高测试效率和测试质量。在本节中，我们将创建一个数据池，数据池中包括三个字段，共十组数据。三个字段均为整数类型，分别代表 Web 服务中 add 方法的两个输入参数和一个输出参数。具体创建步骤如下：

　　选择 File -＞ New -＞ Datapool。选中 TestInvoker，在 name 一栏中填写数据池文件的名称 ArithmeticDP。点击下一步。
　　考虑到 Web 服务的操作 add 和 sunbtract，都分别有两个输入参数和一个输出参数，因此，我们定义数据表格的大小为 3 列，前两列为输入参数的值，第 3 列为输出参数的值。将表格的行数定为 10 行，记录 10 组数据。这仅仅是一个初始值，数据表格的大小随时可以进行修改。点击 Finish。

　　图 12. 定义数据池容量

　　3、如果创建成功，您应该发现在 TestInvoker 工程下，出现了一个名为 ArithmeticDP 的文件。双击该文件进入数据池编辑界面。点击第一列 Variable1，在弹出的 Edit Variable 窗口中，将 Name 改为 num1，Type 改为 int，点击 OK。

　　4、第一列的名称变为 num1::int。同理，我们将第二列更改为 num1::int，第三列更改为 result::int。然后手动输入 10 组数据。编辑后的界面如图 13 所示。最后，点击上方工具栏中的保存按钮。

　　图 13. 数据池编辑界面

　　添加动态数据

　　为了让测试能够重复多次地应用不同的数据运行，我们需要对测试进行修改，让 add 方法的输入参数动态地引用数据池中的数据，而不是单一的值(1，2)。具体步骤如下：

　　在 Test Contents 编辑框，选中 add(“1”,”2”)，在右侧可以看到该测试元素的具体属性信息。本文，我们重点关注 Overview 标签页，在该标签页中，我们看到两个输入参数的背景均为浅绿色，这表明这些输入参数的值可以使用数据池中的数据来替代。

　　图 14. 测试元素属性

　　其实，您现在就可以运行您的测试，不过此时测试只能有一组固定的输入值(1，2)。在本文中，我们的意图是希望让测试脚本能够动态地获取不同的输入值迭代多次执行。因此，这里就需要利用数据池的功能。首先，点击 Name列中的 num1，然后点击右侧 Value 一列中的 1。此时，您会看到在 1 的右侧出现了一个按钮，点击该按钮。

　　在弹出的 Edit 窗口中，右键点击 1，选择 Substitute From -＞ Datapool Variable。

　　图 15. 输入参数引用数据池中的变量

　　在弹出的 select datapool column 窗口中，点击 Add datapool。

　　在 Import Datapool 窗口中，选中 ArithmeticDP.datapool，点击 Select 按钮选择该文件。

　　如果操作正确，在 Select datapool column 中，出现了所选数据池的表结构，选中 Select datapool 表格中的第二行 Column: num1，点击 Use Column 关闭窗口。

　　点击 OK 按钮，关闭 Edit 窗口。

　　现在，您应该能够看到，在 Overview 标签页中，参数 num1 的背景变为了深绿色，这表明为参数 num1 创建了一个引用(Reference)，与数据池中的第一列数据进行了关联。这样，在测试重放的时候，会依次引用数据池中第一列的数据而不是使用固定的数据 1。同理，我们为参数 num2 创建一个引用，使其与数据池中的第二列相关联。最终界面如下图所示：

　　图 16. 数据关联

　　添加验证点

　　在测试中，很重要的一步就是要对响应信息进行验证。Rational Tester for SOA Quality 提供了多种验证点，能够帮助您方便灵活地为响应信息添加验证条件。具体类型和功能如下：

　　Equal Verification Point 和 Contain Verification Point，能够让您验证返回的消息内容是否满足您期望的条件

　　XPath Verification Point 是为了验证返回的消息内容是否与您指定的 Xpath 表达式相匹配

　　Attachement Verification Point 用于验证 Web 服务返回的附件是否满足您期望的条件。

　　本节中，我们主要介绍 Equal Verification Point，为 add 方法调用的响应信息添加该验证点，用于验证输出的结果，即和数是否和数据池中的第三个字段中的数据相等。具体步骤如下：

　　选中 Test Content 编辑框的第三行，add(“”,”3”)。该行表示对 Web 服务调用的响应，3 为返回的最终结果。点击 Add 按钮，在弹出的选项列表中，我们可以看到共有四种验证点：

　　选择 Equal Verification Point。您将会看到在 Test Contents 编辑框的第四行出现一个新的元素，Equal Verification Point。点击该行，在右侧 Overview 标签页中，展开 addResponse, 出现了 add 方法的输出参数，addReturn。

　　由于 add 方法的输入参数分别引用数据池中的变量，因此，测试的输出参数应该为数据池中的第三列数据，即变量 result。验证点的作用，即是验证实际返回的结果是否等于变量 result 的值。因此，我们需要将输出参数 addReturn 与数据池中的变量 result 相关联。具体步骤请参照上文。

　　图 17. 编辑 Equal Verification Point

　　添加 IF-THEN 逻辑

　　在实际的测试中，我们通常会遇到这样的情况，就是在执行一个测试脚本中，我们并不希望执行脚本中的全部调用，而是能够有选择地执行某些调用。Rational Tester for SOA Quality 为我们解决了这个问题，它可以为测试元素添加 IF-THEN 逻辑。测试中任何一次对 Web 服务的调用都可以被封装在 IF-THEN 逻辑块中，只有当 IF 条件被满足时，才执行该次调用。在这一部分中，我们将为测试中对 subtract 方法的调用添加 IF-THEN 逻辑，规定只有当上一步返回的结果为 7 时，才执行对 subtract 方法的调用。具体步骤如下：

　　点击 Test Contents 编辑框的第 5 行，subtract(“0”,”0”)。点击 Insert 按钮，在弹出的选项列表中，选择 Condition(If)。

　　在弹出的对话框中，点击 Yes。将对 subtract 方法的调用封装到 If-then 逻辑块中。

　　点击 Test Contents 编辑框中的第 5 行，If。右侧的编辑界面主要包括三部分：

　　First operand 第一个操作数，您可以从下拉列表中选择一个引用或指定一个具体的数据。

　　Operator 指定两个操作数之间的比较关系，包括大于、小于和等于。注意，这里的操作数都是 string 类型。

　　Second operand 第二个操作数，与第一个操作数相同，可以选择一个引用或者指定一个具体的数据。如果您要求判断条件总是能够被满足的话，您可以将两个操作数都指定为 true，将比较关系指定为 Equals。

　　从 First operand 下拉列表中，选择引用 result，即上一次调用返回的值，作为第一个操作数。将比较关系指定为 Equals，第二个操作数指定为一个具体的值 7。这个判断条件的意思是，如果上一次对 add 方法调用返回的值等于 7 的话，执行对 subtract 方法的调用。

　　图 18. 编辑 IF-THEN 条件表达式

　　接下来，点击 Test Contents 编辑框的第六行，subtract(“0”,”0”)。将输入参数 num1 与数据池中的第三列数据关联，即与引用 result 关联，将输入参数 num2 与数据池的第一列数据关联，即与引用 num2 关联。

　　应用正则表达式

　　现在，我们为第二次调用响应添加一个验证点。Rational Tester for SOA Quality 为我们提供的另外一个重要功能，就是可以使用正则表达式进行数据匹配。由于我们为测试中第二次调用添加了判断逻辑，只有当第一次调用的结果为 7 时，才执行第二次调用，并将 7 作为第二次调用的第一个输入参数，将 4 作为第二个输入参数，那么输出结果应该为 3。但是，为了向您展示正则表达式的功能，我们并不简单地在验证点中将输出数据指定为数值 3，而是使用看起来更繁琐的方式，定义一个正则表达式。当然，本文的例子不太合适介绍正则表达式的功能。但考虑到本文的意图是向您介绍功能的使用，为了保证全文的统一，我们仍然使用本例。

　　点击 Test Contents 编辑框的最后一行，subtract(“”,”0”)，然后点击 Add 按钮，创建一个 Equal 类型的验证点。

　　将验证点中，输出参数的值赋予一个正则表达式：[0-9]。该表达式用于匹配 0 到 9 之间的数字，也就是说返回值是一个 0 到 9 之间的数字。最后，我们还需要设定一个标识用于表明 [0-9] 是一个正则表达式，而不是一个具体的数值。点击 Regexp 列，出现 X 符号，表明返回值应该满足正则表达式。

　　图 19. 编辑验证点

　　到此为止，测试就编辑完毕了，我们建议您在这里暂作调整，先来回顾一下我们刚刚所作的工作。首先，我们通过业务流程的定义文件自动生成了一个测试脚本，然后，我们对这个测试进行了大量的编辑工作，首先，为第一个调用添加响应，使其成为一个对 add 方法的完整的调用，然后我们为输入参数定义引用，与数据池中的数据相关联，并为响应信息创建验证点，验证返回值是否等于我们指定的数值。接下来，我们手动创建了第二个调用，为该调用增加了 IF-THEN 逻辑，并为响应创建了一个验证点，用于验证返回值是否是 0 到 9 之间的数字。

　　下一步，我们将创建一个调度用于执行测试，最后分析测试结果。

　　2.4 运行测试

　　您可以独立运行一个测试，只需在 Test navigator 视图中，右键点击 InvokerProcess.bpel_

　　ws_1，选择 Run As -＞ Performance Test，便可以执行一个测试。但是如果采取这样的执行方式，我们之前对测试的大量编辑工作将变得毫无意义，因为，测试只能引用数据池中的第一条记录执行一次，并且由于不能满足测试中第二次调用的条件，只能执行测试中的第一部分。那如何才能让我们之前的工作发挥作用呢?这就需要定义一个调度，通过调度去执行测试。

　　创建调度(Schedule)

　　调度用于指定将要执行哪些测试，以及以何种顺序执行这些测试。在本节中，我们将创建一个调用，循环多次地执行测试。

　　选择 File -＞ New -＞ Performance Schedule

　　在 Performance Schedule 窗口中，点击 TestInvoker 工程，在页面下方的 Name 文本框中，填写将要创建的调度的名称，schedule1。点击 Finish。

　　在调度的编辑界面，您可以添加用户组，测试以及其他属性，以便模拟实际测试情况。由于本文的意图是介绍如何使用 Rational Tester for SOA Quality 对 Web 服务进行功能测试，不考虑性能测试方面的问题，因此为了简单起见，我们将用户组定为单一用户。

　　点击 Schedule Contents 编辑框的第二行，User Group。然后点击 Add 按钮，在弹出的选项列表中选择 Loop。

　　在 User Group 下方，出现一个新的元素 loop，点击该元素，在右侧 Schedule Element Details 编辑区域中，将迭代次数指定为 5。这表明，测试将被重复执行 5 次，每一次执行都依次引用数据池中不同的数据。

　　点击 Loop，然后选择 Add-＞ Test。

　　在弹出的 Select Performance Test 窗口，选择测试 InvokerProcess.bpel_ws_1，点击 OK。

　　图 20. 调度编辑界面

　　到这里，我们便完成了一个调度的创建工作。该调度模拟了这样一个场景，即一个测试用户对测试脚本迭代运行了六次。接下来，我们便可以应用该调用运行我们的测试脚本。

　　运行测试

　　接下来，我们将使用刚刚定义的调度执行测试。

　　右键点击 TestInvoker 工程中的调度 schedule1，选择 Run as -＞ Performance Schedule。

　　此时，弹出一个 Launch Schedule 窗口，您可以通过 Web Service Performance Report 视图，实时察看测试的运行状况。

　　测试运行完毕后，我们将进入下一部分，对测试结果进行分析。

　　2.5 分析测试报告

　　Rational Tester for SOA Quality 为用户提供了两类测试报告，一类是性能测试报告，一类是功能测试报告。本文，我们重点关注的是功能测试报告，不涉及对性能测试报告的分析。

　　在工具左下方的 Performance Test Runs 视图中，右键点击 TestInvoker 工程下的 schedule1，您可以看到在选项列表中有多种测试报告可供查看。这里需要说明的是，选择 Display Test Log，打开功能测试报告页面。

　　我们可以看到，测试报告包括两部分，Overview 和 Events。在 Overview 视图中，您可以查看一些基本信息和公共属性信息。基本信息包括测试名称，描述以及相对路径。常见属性信息包括测试执行的启动和结束时间，测试运行结果，测试的类型等等。其中，测试结果包括 Error, Fail, Inconclusive 和 Pass 四种情况。

　　Error 表示对 Web 服务的调用不成功，或返回的响应信息不完整或不能被正确解析。

　　Fail 表示验证点没有通过或者没有接收到预期的响应信息。

　　Inconclusive 仅当您在自定义代码(Rational Tester for SOA Quality 提供的功能，让用户可以插入 Java 代码，来查询测试运行状态并控制测试行为，本文没有介绍)中定义了该种类型的结果时，才会出现。

　　Pass 表明验证点全部通过或返回了期望的响应信息。

　　您可以看到，本例中，测试结果为 Pass。

　　图 21. 测试报告概要界面

　　在 Events 页面，您可以查看测试运行中每一个步骤的详细信息。如图 22 所示，页面左边是一棵事件树，列出了所有测试执行事件，包括测试的启动和终止，循环，调用，响应，验证点等。当您在事件树中选择了某一事件节点后，该事件的详细信息将显示在右侧的页面中。在 Properties 中，显示了事件的开始时间和事件执行结果。在 Defects 部分，工具和 ClearQuest 进行了集成，让您可以记录或查看相关的错误信息。

　　图 22. 测试报告事件界面

　　对于本例的测试报告，您可以通过上图看出，测试脚本共执行了 5 次，从 Loop[1] 到 Loop[5]。展开每一次循环，您可以发现，只有 Loop[3] 执行了两次调用，其余 4 次循环都只执行了一次对 add 方法的调用。如果您觉得有些疑惑的话，那您肯定不太记得我们对测试脚本进行的编辑了。我们在编辑测试时，为第二次调用引入了一个条件逻辑，判断只有当上一次调用执行的结果为 7 时，才执行第二次调用。测试依次引用数据池中的前 5 组数据，只有第三组数据才满足条件(3，4，7)，因此，只有在第三次执行测试时，才执行第二次调用。

　　通过查看测试报告，我们对测试脚本的执行结果有了深入的了解，可以得出这样的结论，本文中被测应用的功能是完全正确的。

　　3. 总结

　　本文通过一个具有代表性的实例，介绍了如何使用 Rational Tester for SOA Quality 工具完成对 Web 服务集成测试脚本的创建、编辑以及测试结果的分析。相信，通过阅读并学习本文，您能更好的了解 Rational Tester for SOA Quality 的主要功能，并且掌握如何利用该工具进行服务集成测试。