SoapUI使用说明

1、一 soapUI基本概念由于 Web 服务是被程序调用的， 一般不会提供界面让最终用户或测试人员直接使用，soapUI是针对这种情况开发的一个工具，用户可以在 soapUI 中通过简单的操作完成复杂的测试。目前我们系统中电子渠道接口、充值卡接口都是用WebService实现的，因此需要用到SoapUI进行测试。SoapUI不仅可以简单地执行测试，而且可以自动运行已经准备好的测试用例，另外它也有性能测试的功能，虽然不及Loadrunner强大，但相对比较简单易用。下文中主要介绍它的基本功能，不包括性能测试的部分。在创建测试用例之前，我们先来看一看在 soapUI 中的基本概念，soapUI 把

2、REST 服务、资源及其操作组织为一个层次结构。如图 1所示，主要包括如下层次： 项目定义：位于最上层 (BookStoreTest)，项目可以包含多个服务的定义。 REST 服务定义：服务其实是对多个 REST 资源的一个分组，在我们的例子中只有一个服务 BookStoreServie REST 资源定义：具体描述该资源的名称，URI, 参数等属性 REST 方法定义：针对每个资源的方法 (GET,POST,PUT,DELETE 等 )，图 1 中的方法名就是 GetBookList REST 操作请求定义：基于每个方法，可以有一个或多个请求操作，如 GetBookListRequest，这

3、些请求操作才是真正被 soapUI 所调用执行的。每个请求可以设置非常丰富的信息，例如 Accept 类型，请求的 Header 信息，运行了该请求以后，就能以各种方式查看运行结果。但是这里还不能加入断言来验证结果 - 必须在建立测试用例以后才能使用。对于测试用例来讲，同样是一个层次结构： TestSuite：类似于 Junit 中的测试套件，其中可以加入多个 TestCase TestCase：可以包含多个 TestStep TestStep：一个 TestCase 可以包含多个 TestStep,TestStep 有多种类型，它可以是上面提到一个 REST 操作请求，也可以是一个 Groo

4、vy 的脚本，还可以试一个设置属性的操作。 TestStep 甚至支持分支跳转操作：根据特定的条件，从一个 step 可以跳转到其他 step，而不必顺序执行。soapUI 实际上是一个平台，它支持强大的编程能力，开发或者测试人员可以利用 groovy 脚本来访问 soapUI 中的对象，在运行时修改 REST request/response，这就提供了极大的灵活性。二 怎样用soapUI测试Webservice 接口安装过程比较简单，大家从33/SoapUI/ 上下载安装程序安装就可以了。先从创建项目开始，菜单文件创建项目：说明：Create sample

5、requests for all operations?：为每个接口创建一个请求的例子Creates a TestSuite for the imported WSDL or WADL：为WSDL 或WADL 创建一个测试包Create a Web Service Simulation of the imported WSDL：为WSDL创建一个模拟的服务端Initial WSDL/WADL：指定一个WSDL/WADL的路径，可以是本地或网络URL。这里我们填写232 的充值卡接口路径：32:8080/interf/services/ServiceForRMP

6、?wsdl然后点击 OK 到下一步生成初始的测试用例：说明：One TestCase for each Operation：每个接口创建一个用例 Single TestCase with one Request for each Operation：创建一个用例包含每个接口对应的请求Use existing Requests in Interface：使用已有的请求Create new empty requests：创建一个空的请求Generates a default LoadTest for each created TeseCase：每个用例生成一个负责测试确定后进入下一步，生成Mock

7、Service。Path 是生成的本地服务路径，Port是端口。Starts the MockService immediately 选项可选可不选。完成之后会在左边的树形结构中生成3部分：1 ServiceForRMPSoapBinding 服务的集合创建项目的时候我们选择了Create sample requests for all operations，所以每个接口都会自动创建一个请求，双击它就可以打开编辑面板，左边是请求内容，右边是响应内容。把每个节点的“？”替换成需要的内容，点击绿色的箭头发送就可以了。右边的内容就是服务器返回的结果，同时可以看到系统后台有相同的日志显示。发送后返回的

8、内容：2 ServiceForRMPSoapBinding TestSuite 测试用例的集合TestSuite 是测试用例的集合，且里面每个测试用例包含测试步骤和负载测试。负载测试可以测试响应时间，统计测试结果。这里不讨论。在创建时已经自动给每个接口生成了一个发送请求的测试步骤，如图，同样，初始的节点内容是“？”，要修改。除了这个步骤，还可以加入其它步骤，它提供了几种用例步骤，包括：简单说明一下其中几种步骤：Test Request：发送一个soap请求Groovy Script：用Groovy脚本定义的步骤。Groovy 是一种脚本语言，语法跟java类似。Properties：定义变量/

9、属性Property Transfer：传值。可以把指定的属性的值传给另一个属性，也可以给请求中节点赋值。Conditional Goto：跳转，符合一定条件就跳到第N步Delay：延迟，可以调整用例执行时间，模拟人工思考时间。Run TestCase：在用例中执行另一个用例。下面举一个简单的例子来说明：（这个用例包含9个步骤，但只看这前3个）用例中第一步：Properties（2）。这里定义了两个变量，CAID 和SerialNo。第二步：Property Transfer，把上面定义的变量值传给下一步的recharge 请求的相应节点。图中所示的是设置Property Transfer的面

10、板。上面是值的来源，选择上一步定义的变量，下面是目标，选择下一步的recharge 请求，property属性为Request。因为整段请求XML是作为一个属性保存在这个步骤的。下面的空白框要指明传给哪个节点，这里默认用的是Xpath语言。Xpath是一种对XML格式文档操作的语言，功能很多，大家可以自行研究。这里的“/customerId”意思是在全文中寻找这个名称的节点。这样就可以把CAID传到充值请求中的customerId字段，设置好之后可以点击上方的绿色箭头（第一个）执行这个步骤，然后可以看到下一步的recharge请求中对应字段已经改变。第三步：recharge。这一步是发送请求。

11、这里要说明是添加断言，也就是检查点。如图所示，这个步骤包含2个检查点。点击下面的Assertions 或上方的按钮可以添加断言。soapUI定义了多种断言类型：简单说明其中几种：Not SOAP Fault：不是“失败响应”。SOAP Response：是一个SOAP 响应。Contains：响应内容包含的文本。XPath Match：指定XML节点的内容。SOAP Fault：是一个“失败响应”。Not Contains：响应内容不包括哪些文本。例子中用了Contains 和XPath Match。Contains比较简单，只要指定包含的文本内容即可，介绍一下XPath Match：这里上面

12、的部分指明了要检查哪个节点，/multiRefid 的意思是：在全文中寻找名称为multiRef ，并且有一个属性名称是id 的节点。这个节点是返回结果编码。下面的“0” 是这个节点的期望值。0表示充值成功。运行用例先设置一下运行属性。右键点击一个用例options：Abort on Error 选项，发生错误时终止运行，如果不希望这样，就取消它。Fail TestCase on Error 选项，发生错误时把用例fail。大家运行时可以按需要来决定。然后可以运行用例。双击TestSuite 会弹出运行面板。这里列出了TestSuite 里面的全部用例，点击绿色箭头就会顺序执行。点击下面的Te

13、stSuite Log 按钮可以查看执行日志，可以看到每一步骤的执行情况。如下图。这样我们就可以对Webservice接口进行简单的自动化测试。3 ServiceForRMPSoapBinding MockService 设置虚拟的服务端这部分是设置虚拟的服务端，它会在本机启动一个虚拟的服务，返回指定的响应内容。当服务端还没开发完，或者条件不允许与其他系统一起调试时，这个功能便于在开发完成前就可以把测试用例准备好。下图所示，recharge接口下面建了3个response。右键单击对应的接口，新建一个response。右边的内容是自动生成的，只要节点的“？”替换成实际需要的内容即可。也可以创建

14、一个“失败响应”，点击这个按钮，就会生成一个默认格式的失败响应，与实际系统返回的格式不一样，我们把已有的失败响应内容复制上去即可。内容填写好之后，可以把响应与请求关联起来。点击，选择一个已有请求或新建一个，如下图。然后启动MockService，运行一下请求，就会返回刚刚设置的response。但要注意，要把请求响应的服务地址改为本机的虚拟地址，如下图要选择图中的灰色的那个，前面部分是本机名称。启动MockService：右键单击ServiceForRMPSoapBinding MockService，选择restart即可，会看到 这个绿色的小图标在闪，表示正在运行。三 使用变量soapUI

15、 支持使用自定义变量（Property）在 Project 中存储和共享数据。Property 是一个命名的字符串可以被 Groovy Script，Property Transfer 或者 Property-Expansion 引用， 目前所有的变量均被处理为字符串。soapUI 允许在项目的各个层次中定义变量，常用的层次包括：Project，TestSuite，TestCase，Global 等。1. 使用 Property 编辑器定义变量。用户可以使用 soapUI 自带的 Property Editor 定义各个层次的变量。以 Project 变量为例，点击 BookStoreTest

16、，在 Properties 面板中添加自定义变量，如下图所示：图 5. 使用 Property 编辑器定义项目变量2. 使用命令行指定变量。修改 soapUI.bat 文件中的 Java 参数如下：清单 x. 使用命令行指定变量set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx256m -Dperties=properties.txt其中，properties.txt 为指定的全局变量文件名字，可以通过添加如下代码到全局变量文件来设置 project/testsuite/testcase 等层次的变量：清单 x. 使用命令行指定变量soapui.

17、properties.<shortened-name-of-object>=pathtopropertiesfile<shortened-name-of-object> 为相应对象的名字。3. 使用变量soapUI 使用如下语法引用项目中定义的变量：清单 x. 使用命令行指定变量$scopepropertyName#xpath-expression其中，scope 可以为 #Project#，#TestSuite#，#TestCase# ，#Global#，#System#，#MockService#，#Env#，TestStep name#。四 验证结果测试用例建好之

18、后，需要向测试用例中添加 Assertions 以便验证结果的正确性。soapUI 支持 Response SLA, Script Assertion, Contains, XQuery Match, Schema Compliance, XPath Match 以及 Not Contains 等多种断言来对 response 进行判断来保证对 Web 服务高质量的测试。本文以 XPath Match 和 Script Assertion 为例来对在线书店服务返回的 XML 和 JSON 格式的 response 进行判断。1. 使用 XPath Match 测试请求 GetBookListR

19、equest_XML 返回的结果中，id 为 1234 的 book 的 price 为 29.0， response 参见 代码清单 2。点击 TestCase 的添加 Assertions 按钮，如 图 4所示。 在弹出的 Select Assertion 窗口中选择 XPath Match 断言，点击 OK。配置 XPath 如下图所示：图 6. 使用 XPATH 测试 XML 格式的书籍列表在 XPath Expression 面板中书写用于匹配 Response 的 XPath 表达式，Expected Result 面板中填写期望的值。soapUI 将使用 XPath Expres

20、sion 面板中填写的 XPath 表达式与 Service 调用结果匹配， 将匹配结果与期望值比较，如果相同则测试通过，否则失败。2. 使用 Script Assertion 测试请求 GetBookListRequest_JSON 返回的结果，response 参见 代码清单 1。Assertion 添加过程与 XPath Match 类似，在 Select Assertion 窗口中选择 Script Assertion，并在之后弹出的 Script Assertion 窗口中书写如下代码：清单 5. 使用 Script Assertion 测试 JSON 格式的书籍列表 /a

21、ssert the response header assert messageExchange.responseHeaders"Content-Type"="application/json;charset=UTF-8" assert messageExchange.responseHeaders"Cache-Control" = "no-cache"  /assert the repsonse body  def booksRoot = net.sf.json.JSONSerializer.

22、toJSON(messageExchange.responseContent);  def books = booksRoot.get("books");  /assert book detail  assert books0.get("book").get("id") = "1234"  assert books0.get("book").get("name") = "book1"  assert boo

23、ks0.get("book").get("price") = 29; 3. 使用 Property 测试请求 GetBookRequest_JSON 返回的结果， response 参见 代码清单 3。在 Script Assertion 窗口中写入如下代码：清单 6. 使用 Property 测试 JSON 格式的书籍详情 /get property  def expectedID = context.expand('$#Project#book.id');  def expectedName = 

24、; context.expand('$#Project#');  /assert the response header  assert messageExchange.responseHeaders"Cache-Control" = "no-cache"  /assert the response body  def bookRoot = net.sf.json.JSONSerializer.toJSON(messageExchange.responseContent);

25、60;assert bookRoot.get("id") = expectedID;  assert bookRoot.get("name") = expectedName;  assert bookRoot.get("price") = 29.0; 上述使用 Groovy Script 对 Service 调用结果进行验证，可用的 soapUI 对象包括 :messageExchange， context 以及 log。 messageExchange： 当前交互 request/response 的 Messa

26、geExchange，可以用来直接访问 message content， HTTP Headers，Attachment 等对象。 context： 运行当前 TestCase 的 TestRunContext 对象，具体使用方式请参见 soapUI API 文档。 log： 一个标准的 Log4j Logger 对象，可以用来输出日志。依照上述步骤定义好 TestCase 并添加适当的断言之后，就可以对在线书店 REST 服务进行测试。双击 BookStoreSerive_TestSuite, 点击 Run 按钮来运行所有的 TestCase，结果如下图所示：图 7. 运行测试用例五 性能测

27、试性能测试在 soapUI 中称为 Load Test, 针对一个 soapUI 的 TestCase, 可以建立一个或多个 LoadTest, 这些 LoadTest 会自动的 把 TestCase 中的所有步骤都添加到其中， 在运行的时候，soapUI 会自动的使用多个线程来运行这些 TestStep，同时也会监控 它们的运行时间， 例如最短时间，最长时间，平均时间等等。这样用户能够很直观的看到 REST 服务的响应时间，从而对性能进行调优。建立 LoadTest 非常简单，只需要在“Load Tests”上点击右键， 选择"New LoadTest", 然后输入名称即

28、可，下图是一个针对 GetBookList 的 性能测试， 可以看到有两个 TestStep : "GetBookList_xml" 和"GetBookList_json" , 100 个线程并发执行， 时间限制是 60 秒。 最后的结果是，最短时间 4 毫秒，最长时间 1204 毫秒，平均时间 20.54 毫秒。图 8. 性能测试性能测试还支持断言，用户可以对一个 TestStep 或 TestCase 设置运行时间要求，例如平均时间大于 2 秒就认为失败，点击 图 8 中中的 “LoadTest Assertions”就可以设置。 当然根据需要，用户

29、也可以编写脚本来做一些准备工作，或者清除工作。 参见 图 8 中的"Setup Script"和“TearDown Script”。六 与 BuildForge 集成测试可以有效的保证代码的质量，但是仅仅手工的、在本机上运行的 REST 服务测试时远远不够的。实际上把测试作为软件构建的一部分，加入到持续集成中去是一个常见的敏捷开发实践，通过频繁的，自动化的测试， 可以更有效的发现缺陷，保证代码质量。IBM Rational BuildForge 是一个管理软件构建和发布的平台 , 它提供了一个框架来自动化整个构建流程，不仅仅自动化单独的任务，可以集成多种用户现有的脚本和工具

30、，最大限度的保护用户投资。作为一个框架，BuildForge 几乎可以调用操作系统上的任何脚本。本文重点不在介绍 BuildForge, 假定读者对 BuildForge 已经比较熟悉， 不熟悉的读者可以查看参考资料中的相关文章。对于 soapUI 来说，最简单的一种集成方式就是提供命令行脚本让 BuildForge 调用。在上文中我们已经展示了通过 soapUI 的 GUI 运行 TestCase 的功能，那么 soapUI 可不可以通过命令行完成类似的功能呢？ 答案是肯定的。soapUI 提供了一个命令行工具 testrunner.bat 来运行一个项目中的 TestSuite, 可以在

31、<soap_ui_home>/bin 下找到它， 它的使用非常简单，只需要设置下面的几个常用参数即可：-s 指定要运行的 TestSuite-f 指定运行结果的输出目录-j 生成 junit 风格的 report-r 运行完成以后打印一个简单的 summary下面这行命令就是运行 bookstore.xml 这个 soapUI 项目中的 BookstoreTestSuite, 把结果输出到 c:tempreports 中。testrunner.bat -sBookstoreTestSuite -r -j C:developerWorkssoapuibookstore.xml -f

32、c:tempreports有了 testrunner，把 soapUI 的测试集成到 BuildForge 中就很简单了，只需要在 BuildForge 的项目中添加一个步骤，参见下图：图 9. BuildForge 中使用 testrunner七 关于SoapUI的sample示例文件1 SoapUI的安装与启动安装完 SoapUI，我安装的目录是D盘，版本是3.6，则在D盘下会生成D:soapUI-Pro-3.6-beta1 这个目录，进入D:soapUI-Pro-3.6-beta1bin 这个文件夹，双击soapUI-Pro-3.6-beta1，则启动了SoapUI软件。2 导入Soap

33、UI示例的文件 在打开的SoapUI界面中，在Project上右键Import Project导入文件的目录是：D:soapUI-Pro-3.6-beta1Tutorials目录下的sample-soapui-pro-project.xml文件，这时工程里的界面如下图：出现这样的界面就说明工程导入成功了，这个工程文件是SoapUI自带的示例工程，在SoapUI上的任何操作都会使整个工程变化，为了以后重用这个工程，可将Tutorials这个文件夹复制一份，以备将来还原。3 详解Sample Project工程用EditPlus(其他软件也可以)打开sample-soapui-pro-projec

34、t.xml，找到<con:soapui-project name="Sample Project" soapui-version="3.6-beta1" xmlns:con=".</con:soapui-project>这个标签是整个工程文件最大的标签，其中soapui-project代表这是一个SoapUI工程，name=" Sample Project "代表这个工程的名字叫做Sample Project；soapui-version="3.6-beta1"表示这个SoapUI的版本

35、为3.6-beta1；</con:soapui-project>表示整个工程结束。以后介绍的的所有标签都包含在这个标签的内部。工程截图如下：4 详解SampleServiceSoapBinding服务在打开的文件中，找到<con:testSuite name="Sample Simple TestSuite" id="93f915cc-dfd5-492c-850d-831ccda88ca4"> .</con:testSuite>这个标签，其中testSuit表示这个服务的类型，name="Sample Sim

36、ple TestSuite"表示这个服务的名字，id="93f915cc-dfd5-492c-850d-831ccda88ca4"> 表示这个服务的UUID，这个标签在第二章所说工程标签的内部。单击samPleServiceSoapBinding左侧的加号，出现如图的界面这说明这个服务有5个接口，分别为：login，logout，search，buy，return。4.1 关于login接口这个接口用于用户登录的，用户名随意输入，密码是用户名后面再加上123，单击login左侧的加号，出现如图界面 ， 双击Request 1右侧界面如图 这个就是login接

37、口需要的参数，在打开的文件中找到<con:operation action=/sample/login name="login" . . </con:operation>这个标签，其中 name=“login” 表示这个接口的名字，这个标签包含在上面的服务的标签内部。在这个标签内部含有<soapenv:Body> <sam:login> <username>Login</username> <password>Login123</password>

38、; </sam:login> </soapenv:Body>在<username>Login</username><password>Login123</password>里面的值就是接口需要添加的参数，也就是上图中Test里面添加的值。这个接口会生成一个UUID，供下面的接口使用。4.2 关于logout接口这个接口用于用户的退出，输入的sessionID就是login接口生成的UUId单击login左侧的加号，出现如图界面 双击Request 1右边截图如下这就是logout接口需要添加的参数，也就是login生成的U

39、UID，在打开的文件中找到标签<con:operation action="/sample/logout" name="logout" bindingOperationName="logout" </con:operation>这个标签，其中 name="logout" 表示这个接口的名字，这个标签在上面的服务的标签内部。在这个标签内部含有<soapenv:Body> <sam:logout> <sessionid>219

40、74891784000294</sessionid> </sam:logout> </soapenv:Body>标签中的<sessionid>21974891784000294</sessionid>就是这个接口需要添加的参数。4.3 SampleServiceSoapBinding服务中的其他接口 SampleServiceSoapBinding服务还有search，buy，return三个接口，截图如下他们的标签在sample-soapui-pro-project.xml文件中和login，logout差不多，在这里就不过多做介绍

41、。5 详解Sample expanded TestSuite在打开的文件中找到<con:testSuite name="Sample expanded TestSuite"> . .</con:testSuite>这个标签，testSuite表示类型，name="Sample expanded TestSuite"表示名字，它包含在工程标签内部，和服务标签并列。在SoapUI中双击左侧的加号，出现如图界面在它的里面含有四个TestCase，这里只讲述第三个(Groovy DataSource)。6 Groovy DataSourc

42、e详解在打开的文件中，找到<con:testCase failOnError="true" failTestCaseOnErrors="true" keepSession="true" name="Groovy DataSource" . . . </ con:testCase > 这个标签，testCase表示类型，name="Groovy DataSource"表示名字，这个标签在Sample expanded TestSuite的标签内，截图如下：6.1 Properti

43、es: Username and Password组件在TestCase下新建一个叫做Properties: Username and Password的Properties组件 截图如下： 对应的标签为： <con:testStep type="properties" name="Properties: Username and Password"> . .</con:testStep> 标签里注明了新增组件的类型和名字：type="properties" name="Properties: Use

44、rname and Password"，这个标签在Groovy DataSource的标签内，双击这个组件，右边截图如下： 对应的标签为： <con:properties><con:property><con:name>Username</con:name><con:value>Loginn</con:value></con:property><con:property><con:name>Password</con:name><con:value>Lo

45、ginn123</con:value></con:property></con:properties>里面有个<con:interface>SampleServiceSoapBinding</con:interface>的标签，表示是继承了上面的SampleServiceSoapBinding服务6.2 Test Request: login组件在TestCase下新建一个叫做Test Request: login的Test Request组件，截图如下： 对应的标签是： <con:testStep type="req

46、uest" name="Test Request: login"> . .</con:testStep> 标签里注明了新增组件的类型和名字：type="request" name="Test Request: login" 这个标签在Groovy DataSource标签内，与Properties: Username and Password 并列。 双击新建的组件 右侧截图如下：对应的标签为： <con:request><!CDATA<soapenv:Envelopexmlns:s

47、oapenv=/soap/envelope/ xmlns:sam="/sample/"> <soapenv:Body> <sam:loginRequest> <username>$Properties: Username and Password#Username</username> <password>$Properties: Username and Password#Password</password&g

48、t; </sam:loginRequest> </soapenv:Body></soapenv:Envelope>></con:request>标签中的<username> <password>中的内容就是上图中添加的内容Test Request: login是含有断言的，加上断言：对应的标签是：<con:assertion type="SOAP Response"/><con:assertion type="Schema Compliance"><

49、;con:configuration/></con:assertion><con:assertion type="SOAP Fault Assertion"/>其中type="SOAP Response"是断言的类型，断言的名字默认和类型一样。在Test Request: login标签内。里面有个<con:interface>SampleServiceSoapBinding</con:interface>的标签，表示是继承了上面的SampleServiceSoapBinding服务这个组件的下面还有

50、一个叫做Test Request: search的组件，它们2个基本差不多，就不多做介绍了。6.3 DataSource: Item DataSource组件 在TestCase下新建一个叫做DataSource: Item DataSource的DataSource组件，截图如下： 对应的标签为：<con:testStep type="datasource" name="DataSource: Item DataSource"> . . </con:testStep> 标签中注明了新增组件的类型和名字：type="da

51、tasource" name="DataSource: Item DataSource"，标签与Test Request: login并列。 双击左侧的DataSource: Item DataSource，右侧的截图如下： 里面有一段groovy的代码，标签如下： <con:dataSource type="Groovy"><con:configuration><script>def list = context.myListif( list = null ) list = "Item 1&quo

52、t;,"Item 2","Item 3","Item 4", "Item 5" context.myList = list; if( !list.empty ) result.Items = "" + list0; list.remove( 0 ) </script></con:configuration></con:dataSource><con:property>Items</con:property>标签里的内容包含截图中里面的代

53、码里面有个<con:interface>SampleServiceSoapBinding</con:interface>的标签，表示是继承了上面的SampleServiceSoapBinding服务6.4 Search String PropertyTransfer组件在TestCase下新建一个叫做Search String PropertyTransfer的Property Transfer组件，截图如下对应的标签为：<con:testStep type="transfer" name="Search String Propert

54、yTransfer">.</con:testStep> 标签里注明了新增组件的类型和名字： type="transfer" name="Search String PropertyTransfer"标签与Test Request: login并列。双击Search String PropertyTransfer，右侧的截图如下： 对应的标签为: <con:name>searchstring</con:name><con:sourceType>Items</con:sourceType&

55、gt;<con:sourceStep>DataSource:ItemDataSource</con:sourceStep><con:targetType>Request</con:targetType><con:targetStep>TestRequest:buy</con:targetStep><con:targetPath>declare namespace sam='/sample/'/sam:buyRequest/buystring</con

56、:targetPath>里面有个<con:interface>SampleServiceSoapBinding</con:interface>的标签，表示是继承了上面的SampleServiceSoapBinding服务 6.5 Groovy Script: showInfoMessage组件在TestCase下新建一个叫做Groovy Script: showInfoMessage的Groovy Script组件，截图如下 对应的标签为：<con:testStep type="groovy" name="Groovy Scri

57、pt: showInfoMessage"></con:testStep> 标签里注明了新增组件的类型和名字：type="groovy" name="Groovy Script: showInfoMessage"标签与Test Request: login并列。双击Groovy Script: showInfoMessage，右侧截图如下： 对应的标签为：<con:config><script>def groovyUtils = new com.eviware.soapui.support.GroovyU

58、tils( context )def holder = groovyUtils.getXmlHolder ("Test Request: buy#Response")/ ("Value: " + holder.getPropertyValue ("Items") )com.eviware.soapui.support.UISupport.showInfoMessage ("Item: -" + holder.getNodeValue("/sam:buyResponse/purchasestatus/id") + "-" +" In Stock: -" + holder.getNodeValue("/sam:buyResponse/purchasestatus/stockStatus") +"-" +" Ex