首页 > 代码库 > SoapUI测试WS接口实战

SoapUI测试WS接口实战

引文:

本文讨论以下问题:

视频播放功能如何进行压力测试?

进行webservices接口测试时,用LR和soapui哪个工具更好?

1 测试需求

前几天接到一项压力测试的任务:视频播放功能的并发压力测试,也就是客户想知道我们系统的视频播放功能能支撑多少并发。

视频播放的大概流程是客户端发起请求,系统对请求进行权限验证,权限验证通过以后进行配置下载,最后视频流返回客户端。——由于视频流回传是受网络影响较大的,所以针对客户的这个需求我分成两个工作,一是计算客户当前宽带能支撑多少路视频播放;二是对鉴权和配置下载接口进行测试,验证其瓶颈。

以下以配置下载接口为例说明本次测试过程:

让开发提供鉴权接口的信息,如下图所示。

接口名

getData

接口地址

http://IP:PORT /PeiZhi/services/IPzService?wsdl

输入参数名

xtlb

jkid

queryXml

输入参数值

1010

0002

<?xml version="1.0" encoding="utf-8" ?>
<root>
<QueryCondition>
<szUser>wangchengyi</szUser>
<szPass>wangcyadmin</szPass>
<szUserType>0</szUserType>
</QueryCondition>
</root>
(szUserType:0表示视频监控普通用户,1表示数字矩阵,2表示高清调度,3表示DVR调度,5表示车载调度)

 

好了,有了接口信息以后,就该选择测试工具了。对于WS接口的测试,特别是入参为XML格式的,我比较钟情于用SoapUI进行测试(下文也有原因说明)。下面介绍一下详细测试过程,为了方便第一次接触SoapUI的童鞋理解,下文描述较详细,如已了解可以跳过。

2 SoapUI 下载地址

链接:http://pan.baidu.com/s/1dFkJVLR 密码:z1jo

3 SoapUI介绍

开源的 Web  服务测试工具,可以测试基于 SOAP 的 Web  服务,以及REST 风格的 Web 服务。支持多样的测试,例如功能测试,性能测试,回归测试等。

4 SoapUI使用过程

4.1 创建/导入工程

1)  安装并运行SoapUI之后,你就可以创建第一个SoapUI工程了。程序第一次打开时,左侧导航面板上,自动有一个空的 Projects 工程。

2)  右击左侧导航面板中的工作空间节点“Projects”,选择 “New  SoapProject”。

 技术分享

3)  页面弹出“NewSoapUI Project”,填入Project Name,Initial WSDL/WADL 可填入URL 地址或直接导入WSDL 导文入件文,件后,如下图所示:

 技术分享

 

默认选上:

  • Create samplerequests for all operations?(为每个接口创建一个请求的例子)
  • Creates aTestSuite for the imported WSDL or WADL (为WSDL或者WADL创建一个测试包)
  • 点击 OK 按钮后,页面弹出保存工程的提示,以 project 名称+“- soapui-project.xml”的形式进行命名,因此上述工程在保存时页面给出默认命名为PeiZhiTest-soapui-project.xml,直接点击保存即可。

4)  保存成功后,页面继续弹出“GenerateTestSuite”TAB页:

技术分享

选择:

  • Single TestCasewith one Request for each Operation(为每个接口的请求都创建一个测试用例)
  • Create new emptyrequests创(建一个空的请求)
  • Operations 中选择要测试的 WS 接口方法,如果一个 WS 有多个方法, Operations 中会列出所有方法,只须选择要测试的方法即可。
  • 最后勾选上 Generates a defaultLoadTest for each created TestCase(为每个创建好的测试用例生成一个默认的负载测试)

5)  选择完毕后,点击 OK 按钮,进入测试用例命名页面,命名完毕后,确定。

技术分享 

6)  在测试用例编写完毕后,可使用 ctrl+s 键,保存当前的工程。

7)  如果要导入其他的工程,可通过选择“Import Project”,找到XXX- soapui-project.xml,选中后即可导入工程。

 

4.2 创建测试用例

1)  上面操作已经增加了PeiZhiTest的Web 服务,接下来可以执行请求了。在上面增加接口的时候,已经根据 WSDL 的 Schema 定义为每一个操作创建了默认请求。

 技术分享

 

2)  现在将以测试getData方法为例,来介绍用例的创建过程。按照下图所示,打下测试包下的“getData  TestCase”,在展开的“Test Steps”下选择“getData”,双击打开。

技术分享

双击“getData”后,在 SoapUI 的右侧会出现请求编辑器:

技术分享

请求编辑器分为三部分:

  • 顶部的工具栏,包含一组请求相关的动作、操作
  • 左边是请求区域
  • 右边是响应区域

SoapUI 默认生成的请求中,“?”表示需要被替换的内容。根据开发提供的参数信息替换这些值。

 

3)  通过按下工具栏最左边的按钮(绿色箭头)来发送本次请求,请求会在后台执行,响应内容会出现在编辑器的右边。

技术分享 

4)  根据上述返回的结果报文后,可看到接口已被正确的调用,为在测试中不用人为地进行接口功能是否正确的判断,因此加入断言 Assertions,可由程序直接对返回结果进行判断。点击下图左上角的增加断言按钮:

技术分享 

会弹出“Add Assertion”对话框,选择“Contains”的断言,确定后弹出如下对话框,在Content 中填入内容,此处是表示返回的结果报文里应该包含的字段,根据我们 PeiZhiTest接口的返回值,填写如下,点击“OK”,插入断言完毕,程序会在运行用例时,自动帮我们校验返回的结果报文是否包含断言内容。

 技术分享 

说明:

“Test Steps”中可创建多个测试用例,组成一个测试用例集,在运行该test steps时,会根据用例的顺序从上到下依次测试,将上一用例的输出作为下一用例的输入再组织相应的用例,此处待进一步研究。

 

4.3 创建负载测试

1)  在创建完测试用例后,本工程的负载脚本也由在最初创建好工程时,已经默认创建完毕,在此可直接打开使用,如下,可直接点开 Load Tests 节点下名称为“LoadPeiZhiTest”的负载脚本,双击打开。

 技术分享 

2)  双击打开后,页面如下显示,设置过程参考如下,场景为 100 用户并发,持续运行 10分钟,没有思考时间。相应的SoapUI 可设置 Threads=100,Test Delay=0,Limit=600,后面的下拉框选择Seconds,表示 600 秒。设置完毕后,点击左上方的绿色箭头,程序开始进行负载测试。

技术分享

3)  负载测试过程中,右上方会有进度条显示测试的进度情况,SoapUI提供了2 个图表和一个简要列表的形式列出了测试过程中相关数据的监控,如下图,下图为简要列表形式提供的数据:

 技术分享  

4)  点击上方红色方框框住的按钮,会弹出下方的监控图表,图中只有曲线,没有任何数据说明,只能看到变化的情况,由于无相应的刻度,而无法直观地看出数据大小:

技术分享

 

SoapUI 还提供了另一个图表,此图表与上图类似,不过仅能显示线程数与另一统计内容的曲线变化情况,另一统计内容可通过下图红色方框里的“select statistic”进行选择,如下:

技术分享

 

5 与 LoadRunner的比较

本章主要探讨用两个工具测试相同接口时的不同。

使用LoadRunner提供的Webservice协议进行相同接口的测试。

1)  不加校验的脚本(脚本名称:LR_1 )如下:

技术分享
lr_start_transaction("PeiZhi");    web_service_call( "StepName=getData_101",        "SOAPMethod=IPzService|IPzServiceHttpPort|getData",        "ResponseParam=response",        "Service=IPzService",        "ExpectedResponse=SoapResult",        "Snapshot=t1474862040.inf",        BEGIN_ARGUMENTS,        "in0=1010",        "in1=0002",        "in2=<?xml version=\"1.0\" encoding=\"utf-8\" ?><root><QueryCondition><szUser>wangchengyi</szUser><szPass>wangcyadmin</szPass><szUserType>0</szUserType></QueryCondition></root>",        END_ARGUMENTS,        BEGIN_RESULT,        "out=Param_out",        END_RESULT,        LAST);    lr_end_transaction("PeiZhi", LR_AUTO);
View Code

2)  加了检查点的脚本(脚本名称:LR_2  ): 

技术分享
lr_start_transaction("PeiZhi"); web_reg_find("Text=jqz",         LAST );    web_service_call( "StepName=getData_101",        "SOAPMethod=IPzService|IPzServiceHttpPort|getData",        "ResponseParam=response",        "Service=IPzService",        "ExpectedResponse=SoapResult",        "Snapshot=t1474862040.inf",        BEGIN_ARGUMENTS,        "in0=1010",        "in1=0002",        "in2=<?xml version=\"1.0\" encoding=\"utf-8\" ?><root><QueryCondition><szUser>wangchengyi</szUser><szPass>wangcyadmin</szPass><szUserType>0</szUserType></QueryCondition></root>",        END_ARGUMENTS,        BEGIN_RESULT,        "out=Param_out",        END_RESULT,        LAST);    lr_end_transaction("PeiZhi", LR_AUTO);
View Code

3)  场景与SoapUI的场景一致:100 用户并发,持续运行 10 分钟,没有思考时间。对 LR_2 脚本进行性能测试后,发现响应时间比使用 SoapUI 进行测试的响应时间来的大,因此把校验过程注释掉,使用 LR_1,又进行了一次负载测试。  

 

根据测试结果分析得出以下结论: 

  1. SoapUI是专门针对WS接口的测试工具,在对相同接口测试时,SoapUI表现出来的性能更优越。
  2. SoapUI在发送请求时,是直接以组装好的soap报文进行发送,而LR是使用web_service_call方法,从方法传入相应的参数,再由LR组装为 soap报发后,再发往接口进行调用,因此LR在组装报文时,会有相应时间的耗费。LR脚本中创建的事务,就包含了这段组装报文的时间,因此响应时间会比SoapUI的响应时间更大。LR与SoapUI的差别应该还有更多,在此我尚未研究的更深入。
  3. 对于LR,在测试中若增加对返回结果的校验,也会耗费一定的时间,从上面的数据可以看出,时间差大约 0.12s左右,这也与校验中使用的方法有关系,如果方法高效的话,这个时间差也将更少。
  4. SoapUI提供的结果数据的分析不如LR那么详细与全面,但对于接口级的测试已足够,且速度更优。

目前 WS 接口有多种语言可以实现,除了 JAVA、C++,当前还有遇到 WCF, 生成的 WSDL文件无法直接读到接口的入参与出参,此种接口生成的WSDL,LoadRunner读取时直接失败,暂找不到解决方法。而使用SoapUI,本人已测试过,可支持JAVA、C++,且 WCF 这种形式的接口也可支持。

SoapUI测试WS接口实战