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 sample
  requests for all operations?（为每个接口创建一个请求的例子）
• Creates a
  TestSuite for the imported WSDL or WADL （为WSDL或者WADL创建一个测试包）
• 点击 OK 按钮后，页面弹出保存工程的提示，以 project 名称+“- soapui-project.xml”的形式进行命名，因此上述工程在保存时页面给出默认命名为PeiZhiTest-soapui-project.xml，直接点击保存即可。

4）  保存成功后，页面继续弹出“GenerateTestSuite”TAB页：

选择：

• Single TestCase
  with one Request for each Operation（为每个接口的请求都创建一个测试用例）
• Create new empty
  requests创（建一个空的请求）
• Operations 中选择要测试的 WS 接口方法，如果一个 WS 有多个方法， Operations 中会列出所有方法，只须选择要测试的方法即可。
• 最后勾选上 Generates a default
  LoadTest 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 秒。设置完毕后，点击左上方的绿色箭头，程序开始进行负载测试。

参数说明：

limit：表示我们负载测试要持续执行的时间，单位为秒。

Threads：配置负载测试所用的线程数，即一般性能测试中所说的并发数。

Test Delay:设置测试时线程的休眠时间，即在完成一次完整的用例执行后，开始下一次执行时，线程的休眠时间，单位为毫秒。

Random:该值的设置是与“Test Delay”的设置结合在一起的，如下图，它表示休眠的时间会在（1-0.5）*1000=500 和（1+0.5）*1000=1500秒之间波动。如果设置为0，则表示test delay不会随意变化，直接是初始设置的毫秒数。

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);

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);

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 这种形式的接口也可支持。