我们需要测试的webserivce 分两种情况：带有soapheader，需要进行并发性能测试；不带有soapheader，需要进行单线程的大数据量测试，一个请求接着一个请求的发送。

    现在的公司是做电信增值业务的。通过在客户端构建的用户对象，对所需的业务进行soapheader 的验证后，再由webserivce 传递到服务器端，服务器接收到数据后，在电信的后台服务器中进行业务处理，再将处理后的结果通过webserivce 返回给客户端。

 测试环境：

 测试PC（一台LoadRunner测试主控台+N台负载生成器）、WebService服务器、业务管理服务器、数据库服务器

  录制脚本：
1.打开“Virtual User Generator”。
2.New一个virtual user，选择“Web Services”，点击“ok”。

3。在弹出的脚本页面，选择“ ScanWSDL”，在URL 中输入要测试的webseri
vce URL，点击“下一步”。

4.点击“Open Validation Report”来验证URL的有效性，点击“下一步”

5.选择你要测试Methods，点击“下一步”

6.输入Specify argument values，点击“下一步”。

7.勾选“Run script. after generation”

8.设置“ run-time-settingwebserivceClient Emulation.Net”点击“完成”，
loadrunner 将会自动产生脚本。

9.soapheader 的添加
在script. View 模式中可以看到在刚才录制完后，脚本回放成功，但是这并不
代表你的webserivce 的功能正确，你需要查看所保存脚本文件夹目录下\result1\Iteration1\t1.xml 中的response 来判断request 是否成功。如果提示无效的验证错误，这是因为你未输入soapheader 造成的，那么我们需要自己编写一段脚本来添加soapheader：

即：SOAPHeader=<soap:Header xmlns=\"http://bell.ca/vas/getServiceStatus\"><
AuthenticationHeader><Username>user</Username><Password>pass</Password></
AuthenticationHeader></soap:Header>并保持在一行

再次回放，查看\result1\Iteration1\t1.xml 中的response 是否返回success。

（另外介绍一下不带有soapheader的在录制时需要注意的地方：

需要在run-time-settingwebserivceClient EmulationMS soap 进行设置。）

脚本的加强

在脚本中添加事务与集合点，参数化部分参数，并且屏蔽掉lr_think_time(3)，因为这会影响性能测试结果

（不带soapheader的不需要要设置事务和集合点，因为模拟的是单线程测试情况，只需要屏蔽掉lr_think_time(3)。）

运行场景

在run-time-settings 中

持续发送情况下：选择pacing As soon as the previous iteration ends

间隔相同时间发送情况下：选择pacing After the previous iteration endsFi
xed输入设置时间

间隔不同时间发送情况下：选择pacing AtRandom输入设置时间

 

 

 

   soapUI把工作组织成项目。每个项目主要由需要测试的接口来识别。在这里，接口是指另外一端的指向一个暴露了Web service方法的站点的URI（统一资源标识）。你可以很快地创建一个基本的项目结构；soapUI能接受一个文件的WSDL或者一个Web service终点传输的WSDL。

　　项目被有层次结构地组织，并且包含一个或多个TestSuite，TestSuite包含一个或多个TestCase，TestCase包含一个或多个测试步骤。真正的工作 – 发送请求、接受响应、分析结果、改变测试执行流程 – 发生在测试步骤这个层面。TestCase收集和组织需要执行某个对目标的特定操作的步骤。TestSuite汇总那些发生在某个特定区域的Web service的TestCase（例如订购一本书所需要的操作）。你可以通过右键点击项目树中的父节点并选择上下文菜菜单中的“New”菜单，来创建新的TestSuite、TestCase和测试步骤。

　　soapUI通过检查附加给测试响应的断言来判断测试是通过还是失败。有大量的断言可供选择，从“simple contains”测试 – 如果某个提供的字符串匹配则表示成功 – 到“XPath matching”，对响应信息执行复杂的XPath表达式匹配成功则表示测试通过。

　　测试步骤与程序代码很类似。目前，soapUI定义了6个测试步骤类型，最普遍的是请求（Request），发送一个HTTP请求给目标地址，并接收一个响应。可插入条件跳转测试步骤（Conditonal GoTo）来控制流程。一个或多个检查最近的响应的Xpath表达式是必不可少的。第一个表达式的成功会导致相关测试步骤分支的执行。

　　soapUI最强大的是Groovy测试步骤。Groovy是类Java的轻量级脚本语言。一个Groovy测试步骤可以是任何Groovy代码，也就是说基本上Groovy能做的事情，在测试步骤中也能做。测试步骤中的Groovy代码可以访问soapUI框架。例如，一个Groovy测试步骤可以通过JDBC读取数据库的信息，与前一个测试步骤的响应信息进行比较，并响应地修改执行的流程 – 甚至执行另外一个TestCase。

    除了功能测试外，soapUI还能对Web service进行压力测试。每个压力测试包含一个或多个TestCase的执行，并且可以调整用于模拟各种各样的场景。你可以指定测试执行一定量的时间长度，或者一定量的迭代周期，指定以并发的方式执行还是随时间线性变化的方式。

　　当压力测试完成后，一个压力测试编辑器会为每个TestCase提供大量的统计数据：执行的次数，最大、最小、平均执行时间等。还可以在统计图表页以图表的形式查看这些数据。