SoapUI测试WS接口实战
Posted 软件测试杂谈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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" ?> |
好了，有了接口信息以后，就该选择测试工具了。对于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，又进行了一次负载测试。
根据测试结果分析得出以下结论：
- 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 这种形式的接口也可支持。
以上是关于SoapUI测试WS接口实战的主要内容，如果未能解决你的问题，请参考以下文章