LoadRunner测试.docx

LoadRunner测试.docx

《LoadRunner测试.docx》由会员分享，可在线阅读，更多相关《LoadRunner测试.docx（20页珍藏版）》请在冰豆网上搜索。

LoadRunner测试

网站测试报告

一、测试环境

测试网站：

菜菜网

系统环境：

windows_server_2008_r2_enterprise_with_sp1_x64

测试工具：

Loadrunner11.0+IE8.0

二、测试任务

1、创建测试脚本

2、设计场景，测试负载均衡

●初始化每个vuser

●每过15秒，同时登录15个vuser，一共100个vuser

●事务持续时间为10分钟

●事务结束后，没30秒结束5个用户

3、分析测试结果

三、操作过程

1、开始录制

测试网站选用单协议中的web协议

Programtorecord这边输入IE的绝对路径

URLAddress输入菜菜网的网址

Workingdirectory输入测试软件的bin文件夹绝对路径

RecordintoAction选择vuser_init

此处会员登录，会员名：

jojo，密码:

123456

选择action，开始事务录制。

选择物品加入购物车。

确认订单：

选择vuser_end，然后点击退出。

回放脚本，用于对事务整个过程的检测。

录制成功

保存脚本

进行负载测试

添加测试脚本：

设置虚拟场景：

启动负载测试：

测试结束：

注：

一般是在访问应用服务器时出现，大用户量和小用户量均会出现error27791；

　　来自网上的解释：

　　1>应用访问死掉

　　小用户时：

程序上的问题。

程序上存在数据库的问题

　　2>应用服务没有死

　　应用服务参数设置问题

　　例如：

　　在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。

如果连接时收到connectionrefused消息，说明应提高该值，每次增加25％

　　Java连接池的大小设置，或JVM的设置等

　　3>数据库的连接

　　在应用服务的性能参数可能太小了

　　数据库启动的最大连接数（跟硬件的内存有关）

　　以上信息有一定的参考价值，实际情况可以参考此类调试。

　　如果是以上所说的小用户时：

程序上的问题。

程序上存在数据库的问题，那就必须采用更加专业的工具来抓取出现问题的程序，主要是程序中执行效率很低的sql语句，weblogic可以采用introscope定位，期间可以注意观察一下jvm的垃圾回收情况看是否正常，在实践中并发500用户和600用户时曾出现过jvm锯齿型的变化，上升下降都很快，这应该是不太正常的；

注：

出现26374和26377这两个error时，如果初期或脚本单独回放时即出现此错误，则可能是关联问题：

1.首先看下脚本中有没有使用了自动关联（web_reg_save_param）

2.在Virtual的脚本里查询下web_reg_save_param的参数使用位置,然后把这个参数化给还原回来。

如果初期没这个错误，或脚本单独回放时没有问题，而是压力越大错误率越高的话，怀疑是服务器反馈不及时，或反馈信息错误，或丢包了。

导致LR没有从反馈信息中得到这个值。

3.把web_set_max_html_param_len（50000）值加大

（此处确实是自动关联，）

四、测试结果

注：

上图为概要报告，是针对负载测试的结果描述：

●整个负载测试时长7分22秒。

●最大同时运行vuser为4个；整个负载测试的吞吐量为68611987byte；平均吞吐量为154880byte；点击次数为4008次；平均点击率为9047次每秒；出现的error个数为224个；

●事务行为中29次成功、8次失败、4次停止；vuser结束事务过程4次全通过；vuser登录过程中4次成功，96次失败。

●HTTP响应的结果为：

HTTP200响应次数为2857次，每秒8.707次；HTTP302响应次数为8次，每秒0.018次；HTTP404响应次数为143次，每秒0.323次。

注：

上图为运行vuser的时间分布图，每秒平均登录1个，测试偏差1.549。

注：

上图为每秒点击次数的图形，平均为9.047次，偏差为14.426。

注：

上图为网站吞吐量的图形，平均吞吐154880.332byte，图形偏差值为286127.154。

注：

上图为事务摘要的图形，绿色方柱为pass，粉红为fail，橘红为stop。

注：

上图为平均事务响应时间的图形，行为过程平均时间为1.853s,偏差值为0.087；vuser结束过程平均时间为5.49s，偏差值为0；vuser登录过程平均时间为28.39s，偏差值为5.158。

五、总结

测试初期没有错误，脚本单独回放时也没有问题，而随着服务器压力越大错误率就越高，应该是服务器反馈不及时，或反馈信息错误，或丢包了，从而导致LR没有从反馈信息中得到某些参数。

对于虚拟用户大量丢失这情况，服务器还需要进一步优化，如tomcat优化配置：

maxThreads="500"minSpareThreads="400"maxSpareThreads="450"；如apache优化配置：

ThreadsPerChild1900MaxRequestsPerChild10000，需要进一步加强服务器并行能力。