SoapUI使用说明.docx

SoapUI使用说明.docx

《SoapUI使用说明.docx》由会员分享，可在线阅读，更多相关《SoapUI使用说明.docx（31页珍藏版）》请在冰豆网上搜索。

SoapUI使用说明

一soapUI基本概念

由于Web服务是被程序调用的，一般不会提供界面让最终用户或测试人员直接使用，soapUI是针对这种情况开发的一个工具，用户可以在soapUI中通过简单的操作完成复杂的测试。

目前我们系统中电子渠道接口、充值卡接口都是用WebService实现的，因此需要用到SoapUI进行测试。

SoapUI不仅可以简单地执行测试，而且可以自动运行已经准备好的测试用例，另外它也有性能测试的功能，虽然不及Loadrunner强大，但相对比较简单易用。

下文中主要介绍它的基本功能，不包括性能测试的部分。

　　在创建测试用例之前，我们先来看一看在soapUI中的基本概念，soapUI把REST服务、资源及其操作组织为一个层次结构。

如图1所示，主要包括如下层次：

　　●项目定义：

位于最上层（BookStoreTest），项目可以包含多个服务的定义。

　　●REST服务定义：

服务其实是对多个REST资源的一个分组，在我们的例子中只有一个服务BookStoreServie

　　●REST资源定义：

具体描述该资源的名称，URI,参数等属性

　　●REST方法定义：

针对每个资源的方法（GET,POST,PUT,DELETE等），图1中的方法名就是GetBookList

　　●REST操作请求定义：

基于每个方法，可以有一个或多个请求操作，如GetBookListRequest，这些请求操作才是真正被soapUI所调用执行的。

每个请求可以设置非常丰富的信息，例如Accept类型，请求的Header信息，运行了该请求以后，就能以各种方式查看运行结果。

但是这里还不能加入断言来验证结果-必须在建立测试用例以后才能使用。

　　对于测试用例来讲，同样是一个层次结构：

　　●TestSuite：

类似于Junit中的测试套件，其中可以加入多个TestCase

　　●TestCase：

可以包含多个TestStep

　　●TestStep：

一个TestCase可以包含多个TestStep,TestStep有多种类型，它可以是上面提到一个REST操作请求，也可以是一个Groovy的脚本，还可以试一个设置属性的操作。

TestStep甚至支持分支跳转操作：

根据特定的条件，从一个step可以跳转到其他step，而不必顺序执行。

　　soapUI实际上是一个平台，它支持强大的编程能力，开发或者测试人员可以利用groovy脚本来访问soapUI中的对象，在运行时修改RESTrequest/response，这就提供了极大的灵活性。

二怎样用soapUI测试Webservice接口

安装过程比较简单，大家从ftp:

//180.200.3.233/SoapUI/上下载安装程序安装就可以了。

先从创建项目开始，菜单——文件——创建项目：

说明：

Createsamplerequestsforalloperations?

：

为每个接口创建一个请求的例子

CreatesaTestSuitefortheimportedWSDLorWADL：

为WSDL或WADL创建一个测试包

CreateaWebServiceSimulationoftheimportedWSDL：

为WSDL创建一个模拟的服务端

InitialWSDL/WADL：

指定一个WSDL/WADL的路径，可以是本地或网络URL。

这里我们填写232的充值卡接口路径：

http:

//180.200.3.232:

8080/interf/services/ServiceForRMP?

wsdl

然后点击[OK]到下一步生成初始的测试用例：

说明：

OneTestCaseforeachOperation：

每个接口创建一个用例

SingleTestCasewithoneRequestforeachOperation：

创建一个用例包含每个接口对应的请求

UseexistingRequestsinInterface：

使用已有的请求

Createnewemptyrequests：

创建一个空的请求

GeneratesadefaultLoadTestforeachcreatedTeseCase：

每个用例生成一个负责测试

确定后进入下一步，生成MockService。

Path是生成的本地服务路径，Port是端口。

StartstheMockServiceimmediately选项可选可不选。

完成之后会在左边的树形结构中生成3部分：

1ServiceForRMPSoapBinding服务的集合

创建项目的时候我们选择了Createsamplerequestsforalloperations，所以每个接口都会自动创建一个请求，双击它就可以打开编辑面板，左边是请求内容，右边是响应内容。

把每个节点的“？

”替换成需要的内容，点击绿色的箭头发送就可以了。

右边的内容就是服务器返回的结果，同时可以看到系统后台有相同的日志显示。

发送后返回的内容：

2ServiceForRMPSoapBindingTestSuite测试用例的集合

TestSuite是测试用例的集合，且里面每个测试用例包含测试步骤和负载测试。

负载测试可以测试响应时间，统计测试结果。

这里不讨论。

在创建时已经自动给每个接口生成了一个发送请求的测试步骤，如图，同样，初始的节点内容是“？

”，要修改。

除了这个步骤，还可以加入其它步骤，它提供了几种用例步骤，包括：

简单说明一下其中几种步骤：

TestRequest：

发送一个soap请求

GroovyScript：

用Groovy脚本定义的步骤。

Groovy是一种脚本语言，语法跟java类似。

Properties：

定义变量/属性

PropertyTransfer：

传值。

可以把指定的属性的值传给另一个属性，也可以给请求中节点赋值。

ConditionalGoto：

跳转，符合一定条件就跳到第N步

Delay：

延迟，可以调整用例执行时间，模拟人工思考时间。

RunTestCase：

在用例中执行另一个用例。

下面举一个简单的例子来说明：

（这个用例包含9个步骤，但只看这前3个）

用例中第一步：

Properties

（2）。

这里定义了两个变量，CAID和SerialNo。

第二步：

PropertyTransfer，把上面定义的变量值传给下一步的recharge请求的相应节点。

图中所示的是设置PropertyTransfer的面板。

上面是值的来源，选择上一步定义的变量，下面是目标，选择下一步的recharge请求，property属性为Request。

因为整段请求XML是作为一个属性保存在这个步骤的。

下面的空白框要指明传给哪个节点，这里默认用的是Xpath语言。

Xpath是一种对XML格式文档操作的语言，功能很多，大家可以自行研究。

这里的“//customerId”意思是在全文中寻找这个名称的节点。

这样就可以把CAID传到充值请求中的customerId字段，设置好之后可以点击上方的绿色箭头（第一个）执行这个步骤，然后可以看到下一步的recharge请求中对应字段已经改变。

第三步：

recharge。

这一步是发送请求。

这里要说明是添加断言，也就是检查点。

如图所示，这个步骤包含2个检查点。

点击下面的Assertions或上方的

按钮可以添加断言。

soapUI定义了多种断言类型：

简单说明其中几种：

NotSOAPFault：

不是“失败响应”。

SOAPResponse：

是一个SOAP响应。

Contains：

响应内容包含的文本。

XPathMatch：

指定XML节点的内容。

SOAPFault：

是一个“失败响应”。

NotContains：

响应内容不包括哪些文本。

例子中用了Contains和XPathMatch。

Contains比较简单，只要指定包含的文本内容即可，介绍一下XPathMatch：

这里上面的部分指明了要检查哪个节点，//multiRef[@id]的意思是：

在全文中寻找名称为multiRef，并且有一个属性名称是id的节点。

这个节点是返回结果编码。

下面的“0”是这个节点的期望值。

0表示充值成功。

运行用例

先设置一下运行属性。

右键点击一个用例——options：

AbortonError选项，发生错误时终止运行，如果不希望这样，就取消它。

FailTestCaseonError选项，发生错误时把用例fail。

大家运行时可以按需要来决定。

然后可以运行用例。

双击TestSuite会弹出运行面板。

这里列出了TestSuite里面的全部用例，点击绿色箭头就会顺序执行。

点击下面的[TestSuiteLog]按钮可以查看执行日志，可以看到每一步骤的执行情况。

如下图。

这样我们就可以对Webservice接口进行简单的自动化测试。

3ServiceForRMPSoapBindingMockService设置虚拟的服务端

这部分是设置虚拟的服务端，它会在本机启动一个虚拟的服务，返回指定的响应内容。

当服务端还没开发完，或者条件不允许与其他系统一起调试时，这个功能便于在开发完成前就可以把测试用例准备好。

下图所示，recharge接口下面建了3个response。

右键单击对应的接口，新建一个response。

右边的内容是自动生成的，只要节点的“？

”替换成实际需要的内容即可。

也可以创建一个“失败响应”，点击这个按钮

，就会生成一个默认格式的失败响应，与实际系统返回的格式不一样，我们把已有的失败响应内容复制上去即可。

内容填写好之后，可以把响应与请求关联起来。

点击

，选择一个已有请求或新建一个，如下图。

然后启动MockService，运行一下请求，就会返回刚刚设置的response。

但要注意，要把请求响应的服务地址改为本机的虚拟地址，如下图

要选择图中的灰色的那个，前面部分是本机名称。

启动MockService：

右键单击ServiceForRMPSoapBindingMockService，选择restart即可，会看到

这个绿色的小图标在闪，表示正在运行。

三使用变量

　　soapUI支持使用自定义变量（Property）在Project中存储和共享数据。

Property是一个命名的字符串可以被GroovyScript，PropertyTransfer或者Property-Expansion引用，目前所有的变量均被处理为字符串。

soapUI允许在项目的各个层次中定义变量，常用的层次包括：

Project，TestSuite，TestCase，Global等。

　　1.使用Property编辑器定义变量。

　　用户可以使用soapUI自带的PropertyEditor定义各个层次的变量。

以Project变量为例，点击BookStoreTest，在Properties面板中添加自定义变量，如下图所示：

图5.使用Property编辑器定义项目变量

　　2.使用命令行指定变量。

　　修改soapUI.bat文件中的Java参数如下：

　　清单x.使用命令行指定变量

setJAVA_OPTS=%JAVA_OPTS%-Xms128m-Xmx256m-Dsoapui.properties=properties.txt

　　其中，properties.txt为指定的全局变量文件名字，可以通过添加如下代码到全局变量文件来设置project/testsuite/testcase等层次的变量：

　　清单x.使用命令行指定变量

soapui.properties.=pathtopropertiesfile

　　为相应对象的名字。

　　3.使用变量

　　soapUI使用如下语法引用项目中定义的变量：

　　清单x.使用命令行指定变量

${[scope]propertyName[#xpath-expression]}

　　其中，scope可以为#Project#，#TestSuite#，#TestCase#，#Global#，#System#，#MockService#，#Env#，[TestStepname]#。

四验证结果

　　测试用例建好之后，需要向测试用例中添加Assertions以便验证结果的正确性。

soapUI支持ResponseSLA,ScriptAssertion,Contains,XQueryMatch,SchemaCompliance,XPathMatch以及NotContains等多种断言来对response进行判断来保证对Web服务高质量的测试。

本文以XPathMatch和ScriptAssertion为例来对在线书店服务返回的XML和JSON格式的response进行判断。

　　1.使用XPathMatch测试请求GetBookListRequest_XML返回的结果中，id为1234的book的price为29.0，response参见代码清单2。

　　点击TestCase的添加Assertions按钮，如图4所示。

在弹出的SelectAssertion窗口中选择XPathMatch断言，点击OK。

配置XPath如下图所示：

图6.使用XPATH测试XML格式的书籍列表

　　在XPathExpression面板中书写用于匹配Response的XPath表达式，ExpectedResult面板中填写期望的值。

soapUI将使用XPathExpression面板中填写的XPath表达式与Service调用结果匹配，将匹配结果与期望值比较，如果相同则测试通过，否则失败。

　　2.使用ScriptAssertion测试请求GetBookListRequest_JSON返回的结果，response参见代码清单1。

　　Assertion添加过程与XPathMatch类似，在SelectAssertion窗口中选择ScriptAssertion，并在之后弹出的ScriptAssertion窗口中书写如下代码：

　　清单5.使用ScriptAssertion测试JSON格式的书籍列表

 //asserttheresponseheader

assertmessageExchange.responseHeaders["Content-Type"]=="application/json;charset=UTF-8";

assertmessageExchange.responseHeaders["Cache-Control"]=="no-cache";

 //asserttherepsonsebody

 defbooksRoot=net.sf.json.JSONSerializer.toJSON（messageExchange.responseContent）;

 defbooks=booksRoot.get（"books"）;

 //assertbookdetail

 assertbooks[0].get（"book"）.get（"id"）=="1234";

 assertbooks[0].get（"book"）.get（"name"）=="book1";

 assertbooks[0].get（"book"）.get（"price"）==29;

3.使用Property测试请求GetBookRequest_JSON返回的结果，response参见代码清单3。

　　在ScriptAssertion窗口中写入如下代码：

　　清单6.使用Property测试JSON格式的书籍详情

 //getproperty

 defexpectedID=context.expand（'${#Project#book.id}'）;

 defexpectedName= context.expand（'${#Project#book.name}'）;

 //asserttheresponseheader

 assertmessageExchange.responseHeaders["Cache-Control"]=="no-cache";

 //asserttheresponsebody

 defbookRoot=net.sf.json.JSONSerializer.toJSON（messageExchange.responseContent）;

 assertbookRoot.get（"id"）==expectedID;

 assertbookRoot.get（"name"）==expectedName;

 assertbookRoot.get（"price"）==29.0;

　　上述使用GroovyScript对Service调用结果进行验证，可用的soapUI对象包括:

messageExchange，context以及log。

　　●messageExchange：

当前交互request/response的MessageExchange，可以用来直接访问messagecontent，HTTPHeaders，Attachment等对象。

　　●context：

运行当前TestCase的TestRunContext对象，具体使用方式请参见soapUIAPI文档。

　　●log：

一个标准的Log4jLogger对象，可以用来输出日志。

　　依照上述步骤定义好TestCase并添加适当的断言之后，就可以对在线书店REST服务进行测试。

双击BookStoreSerive_TestSuite,点击Run按钮来运行所有的TestCase，结果如下图所示：

图7.运行测试用例

五性能测试

　　性能测试在soapUI中称为LoadTest,针对一个soapUI的TestCase,可以建立一个或多个LoadTest,这些LoadTest会自动的把TestCase中的所有步骤都添加到其中，在运行的时候，soapUI会自动的使用多个线程来运行这些TestStep，同时也会监控它们的运行时间，例如最短时间，最长时间，平均时间等等。

这样用户能够很直观的看到REST服务的响应时间，从而对性能进行调优。

　　建立LoadTest非常简单，只需要在“LoadTests”上点击右键，选择"NewLoadTest",然后输入名称即可，下图是一个针对GetBookList的性能测试，可以看到有两个TestStep:

"GetBookList_xml"和"GetBookList_json",100个线程并发执行，时间限制是60秒。

最后的结果是，最短时间4毫秒，最长时间1204毫秒，平均时间20.54毫秒。

图8.性能测试

　　性能测试还支持断言，用户可以对一个TestStep或TestCase设置运行时间要求，例如平均时间大于2秒就认为失败，点击图8中中的“LoadTestAssertions”就可以设置。

当然根据需要，用户也可以编写脚本来做一些准备工作，或者清除工作。

参见图8中的"SetupScript"和“TearDownScript”。

六与BuildForge集成

　　测试可以有效的保证代码的质量，但是仅仅手工的、在本机上运行的REST服务测试时远远不够的。

实际上把测试作为软件构建的一部分，加入到持续集成中去是一个常见的敏捷开发实践，通过频繁的，自动化的测试，可以更有效的发现缺陷，保证代码质量。

　　IBMRationalBuildForge是一个管理软件构建和发布的平台,它提供了一个框架来自动化整个构建流程，不仅仅自动化单独的任务，可以集成多种用户现有的脚本和工具，最大限度的保护用户投资。

作为一个框架，BuildForge几乎可以调用操作系统上的任何脚本。

本文重点不在介绍BuildForge,假定读者对BuildForge已经比较熟悉，不熟悉的读者可以查看参考资料中的相关文章。

　　对于soapUI来说，最简单的一种集成方式就是提供命令行脚本让BuildForge调用。

在上文中我们已经展示了通过soapUI的GUI运行TestCase的功能，那么soapUI可不可以通过命令行完成类似的功能呢？

答案是肯定的。

　　soapUI提供了一个命令行工具testrunner.bat来运行一个项目中的TestSuite,可以在/bin下找到它，它的使用非常简单，只需要设置下面的几个常用参数即可：

　　-s指定要运行的TestSuite

　　-f指定运行结果的输出目录

　　-j生成junit风格的report

　　-r运行完成以后打印一个简单的summary

　　下面这行命令就是运行bookstore.xml这个soapUI项目中的BookstoreTestSuite,把结果输出到c:

\temp\reports中。

　　testrunner.bat-sBookstoreTestSuite-r-jC:

\developerWorks\soapui\bookstore.xml-fc:

\temp\reports

　　有了testrunner，把soapUI的测试集成到BuildForge中就很简单了，只需要在BuildForge的项目中添加一个步骤，参见下图：

图9.BuildForge中使用testrunner

七关于SoapUI的sample示例文件

1SoapUI的安装与启动

安装完SoapUI，我安装的目录是D盘，版本是3.6，则在D盘下会生成D:

\soapUI-Pro-3.6-beta1这个目录，进入D:

\soapUI-Pro-3.6-beta1\bin这个文件夹，双击soapUI-Pro-3.6-beta1，则启动了SoapUI软件。

2导入SoapUI示例的文件

在打开的SoapUI界面中，在Project上右键ImportProject导入文件的目录是：

D:

\soapUI-Pro-3.6-beta1\Tutorials\目录下的sample-soapui-pro-project.xml文件，这时工程里的界面如下图：

出