SoapUI中文教程Word文件下载.docx
《SoapUI中文教程Word文件下载.docx》由会员分享,可在线阅读,更多相关《SoapUI中文教程Word文件下载.docx(14页珍藏版)》请在冰豆网上搜索。
![SoapUI中文教程Word文件下载.docx](https://file1.bdocx.com/fileroot1/2022-12/30/2ebc75c9-f86f-482a-bd6d-472624a7ef2b/2ebc75c9-f86f-482a-bd6d-472624a7ef2b1.gif)
右击左侧导航面板中的工作空间节点“Projects”,选择“NewSoapUIProject”。
图表2-1
页面弹出“NewSoapUIProject”TAB页,填入ProjectName,InitialWSDL/WADL可填入URL地址或直接导入WSDL文件,导入文件后,
如下图所示:
图表2-2
默认选上:
Createsamplerequestsforalloperations?
(说明:
为每个接口创建一个请求的例子)CreatesaTestSuitefortheimportedWSDLorWADL(说明:
为WSDL或WADL创建一个测试包)
点击OK按钮后,页面弹出保存工程的提示,以project名称+“-soapui-project.xml”的形式进行命名,因此上述工程在保存时页面给出默认命名为test1_file-soapui-project.xml,直接点击保存即可。
保存成功后,页面继续弹出“GenerateTestSuite”TAB页:
图表2-3
选择:
SingleTestCasewithoneRequestforeachOperation(说明:
为每个接口的请求都创建一个测试用例)
Createnewemptyrequests(说明:
创建一个空的请求)
Operations中选择要测试的WS接口方法,如果一个WS有多个方法,
Operations中会列出所有方法,只须选择要测试的方法即可,上图,去掉了test10、test2等接口的测试。
最后勾选上GeneratesadefaultLoadTestforeachcreatedTestCase(说明:
为每个创建好的测试用例生成一个默认的负载测试)
选择完毕后,点击OK按钮,进入测试用例命名页面,命名完毕后,确定。
图表2-4
在测试用例编写完毕后,可使用ctrl+s键,保存当前的工程。
如果要导入其他人的工程,可通过选择“ImportProject”,找到test-soapui-project.xml,选中后即可导入工程。
2.2创建测试用例
上面操作已经增加了test1的Web服务,接下来可以执行请求了。
在上面增加接口的时候,已经根据WSDL的Schema定义为每一个操作创建了默认请求。
图表2-5
在RequestServiceSoapBinding节点下展开了WS服务中所有的方法,而我们的测试包test1_file_TestSuite中根据“创建、导入工程”的第4步,而仅创建了我们要测试的方法的测试用例。
现在将以测试test1方法为例,来介绍用例的创建过程。
按照下图所示,打下测试包下的“test1TestCase”,在展开的“TestSteps”下选择“test1”,双击打开。
图表2-6
双击“test1”后,在SoapUI的右侧会出现请求编辑器:
图表2-7
请求编辑器分为三部分:
1.顶部的工具栏,包含一组请求相关的动作、操作
2.左边是请求区域
3.右边是响应区域
SoapUI默认生成的请求中,”?
”表示需要被替换的内容。
根据需要,可以替换或者删除掉这些值。
本接口需要一个名为id的入参,可在请求区域找到如下内容:
<
idxsi:
type="
soapenc:
string"
xmlns:
soapenc="
http:
//schemas.xmlsoap.org/soap/encoding/"
>
?
/id>
“id”即为参数名,找到上面的“?
”,替换为abcd任意字符串。
通过按下工具栏最左边的按钮(绿色箭头)来发送本次请求,请求会在后台执行,响应内容会出现在编辑器的右边,test1方法没有任何逻辑,任意的入参均不会影响到输出结果,出参为一个一维数组,第一个值为123,第二个值为456。
根据上述返回的结果报文后,可看到接口已被正确的调用,为在测试中不用人为地进行接口功能是否正确的判断,因此加入断言Assertions,可由程序直接对返回结果进行判断。
点击下图左上角的增加断言按钮:
图表2-8
会弹出“SelectAssertion”对话框,通过下拉框选择“Contains”的断言,确定后弹出如下对话框,在Content中填入内容,此处是表示返回的结果报文里应该包含的字段,根据我们test1接口的返回值,填写如下,点击“OK”,插入断言完毕,程序会在运行用例时,自动帮我们校验返回的结果报文是否包含“123”内容。
图表2-9
说明:
“TestSteps”中可创建多个测试用例,组成一个测试用例集,在运行该teststeps时,会根据用例的顺序从上到下将用例进行一次测试,将上一用例的输出作为下一用例的输入再组织相应的用例,此处待进一步研究。
2.3创建负载测试
性能测试一般使用loadrunner,或者自己写的调用客户端进行测试。
loadrunner是全面的性能测试工具,对一般开发人员来说太重,并且需要license。
自己写调用的客户端则测试的统计数据也需要写程序处理,比较麻烦。
这里推荐使用SoapUI,SOAPUI可以直接根据WSDL生成SOAP数据包,手工填入参数后可以直接进行性能测试。
在创建完测试用例后,本工程的负载脚本也由在最初创建好工程时,已经默认创建完毕,在此可直接打开使用,如下,可直接点开LoadTests节点,节点下包含名称为“LoadTest1”的负载脚本,双击打开。
图表2-10
双击打开后,页面如下显示,设置过程参考如下,场景为100用户并发,持续运行10分钟,没有思考时间。
相应的SoapUI可设置Threads=100,TestDelay=0,Limit=600,后面的下拉框选择Seconds,表示600秒。
设置完毕后,点击左上方的绿色箭头,程序开始进行负载测试。
图表2-11
负载测试过程中,右上方会有进度条显示测试的进度情况,SoapUI提供了2个图表和一个简要列表的形式列出了测试过程中相关数据的监控,如下图,下图为简要列表形式提供的数据:
图表2-12
点击上方红色方框框住的按钮,会弹出下方的监控图表,图中只有曲线,没有任何数据说明,只能看到变化的情况,由于无相应的刻度,而无法直观地看出数据大小:
图表2-13
SoapUI还提供了另一个图表,此图表与上与图表类似,不过仅能显示线程数与另一统计内容的曲线变化情况,另一统计内容可通过下图红色方框里的“selectstatistic”进行选择,如下:
图表2-14
3与LoadRunner的比较
使用LoadRunner提供的Webservice协议进行相同接口的测试。
不加校验的脚本(脚本名称:
LR_1)如下:
//@oolong2/2/2010
Action()
{
lr_start_transaction("
here_start"
);
web_service_call("
StepName=test1_101"
"
SOAPMethod=RequestJaxRPCService.RequestJaxRPC.test1"
"
ResponseParam=response"
WSDL=C:
/DocumentsandSettings/Owner/桌面
/RequestService.wsdl"
UseWSDLCopy=1"
Snapshot=t1264818214.inf"
BEGIN_ARGUMENTS,
xml:
sss=<
sss>
string>
/string>
/sss>
id=aff"
END_ARGUMENTS,
BEGIN_RESULT,
END_RESULT,
LAST);
lr_end_transaction("
LR_AUTO);
return0;
}
加了校验的脚本(脚本名称:
LR_2)如下,下面的脚本提供了对返回结果的一个校验,类似SoapUI里提供的断言:
charcom[]="
123"
;
test1Return[1]=Param_result"
if(strcmp(lr_eval_string("
{Param_result}"
),com)==0)
{
lr_vuser_status_message("
成功"
}
else
LR_FAIL);
lr_error_message(lr_eval_string("
));
}
场景与SoapUI的场景一致:
100用户并发,持续运行10分钟,没有思考时间。
对LR_2脚本进行性能测试后,发现响应时间比使用SoapUI进行测试的响应时间来的大,因此把校验过程注释掉,使用LR_1,又进行了一次负载测试。
从LR可以得到的结果图表较多,以下列出几个示意图:
图表3-1
TPS图如下:
图表3-2
平均事务响应时间如下:
图表3-3
可以看到由LR得到的结果,图表丰富,数据完整,提供了更好、更直观的说明作用。
性能测试结果数据比较
脚本名称
平均响应时间
总事务数
TPS
SoapUI脚本
291.45MS
205856
339.04
LR_1
0.491S
120646
194.898
LR_2
0.606S
96636
159.464
由上表及上面的分析得出以下结论:
SoapUI是专门针对ws接口的测试工具,在实现对相同接口测试时,SoapUI表现出来的性能更优越。
SoapUI在发送请求时,是直接以组装好的soap报文进行发送,而LR是使用web_service_call方法,从方法传入相应的参数,再由LR组装为soap报文后,再发往接口进行调用,因此LR在组装报文时,会有相应时间的耗费。
LR脚本中创建的事务,就包含了这段组装报文的时间,因此响应时间会比SoapUI的响应时间更大。
LR与SoapUI的差别应该还有更多,在此我尚未研究的更深入。
对于LR,在测试中若增加对返回结果的校验,也会耗费一定的时间,从上面的数据可以看出,时间差大约0.12s左右,这也与校验中使用的方法有关系,如果方法高效的话,这个时间差也将更少。
全SoapUI提供的结果数据的分析不如LR那么详细与全面,但对于接口级的测试已足够,且速度更优。
目前WS接口有多种语言可以实现,除了JAVA、C++,当前还有遇到WCF,生成的WSDL文件无法直接读到接口的入参与出参,此种接口生成的WSDL,LoadRunner读取时直接失败,暂找不到解决方法。
而使用SoapUI,本人已测试过,可支持java、c++,且wcf这种形式的接口也可支持。