LoadRunner测试Word文件下载.docx

1、1、 创建测试脚本2、 设计场景，测试负载均衡 初始化每个vuser 每过15秒，同时登录15个vuser，一共100个vuser 事务持续时间为10分钟 事务结束后，没30秒结束5个用户3、 分析测试结果三、 操作过程1、开始录制 测试网站选用单协议中的web协议Program to record这边输入IE的 绝对路径URL Address输入菜菜网的网址Working directory输入测试软件的bin文件夹绝对路径Record into Action选择vuser_init此处会员登录，会员名：jojo，密码:123456选择action，开始事务录制。选择物品加入购物车。确认订单

2、：选择vuser_end，然后点击退出。回放脚本，用于对事务整个过程的检测。录制成功保存脚本进行负载测试添加测试脚本：设置虚拟场景：启动负载测试：测试结束：注：一般是在访问应用服务器时出现，大用户量和小用户量均会出现error 27791；来自网上的解释：1 应用访问死掉小用户时：程序上的问题。程序上存在数据库的问题2 应用服务没有死应用服务参数设置问题例如：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，

3、每次增加25Java连接池的大小设置，或JVM的设置等3 数据库的连接在应用服务的性能参数可能太小了数据库启动的最大连接数（跟硬件的内存有关）以上信息有一定的参考价值，实际情况可以参考此类调试。如果是以上所说的小用户时：程序上存在数据库的问题，那就必须采用更加专业的工具来抓取出现问题的程序，主要是程序中执行效率很低的sql语句，weblogic可以采用introscope定位，期间可以注意观察一下jvm的垃圾回收情况看是否正常，在实践中并发500用户和600用户时曾出现过jvm锯齿型的变化，上升下降都很快，这应该是不太正常的；出现26374和26377这两个error时，如果初期或脚本单独回放

4、时即出现此错误，则可能是关联问题：1.首先看下脚本中有没有使用了自动关联（web_reg_save_param） 2.在Virtual的脚本里查询下web_reg_save_param的参数使用位置,然后把这个参数化给还原回来。 如果初期没这个错误，或脚本单独回放时没有问题，而是压力越大错误率越高的话，怀疑是服务器反馈不及时，或反馈信息错误，或丢包了。导致LR没有从反馈信息中得到这个值。3. 把web_set_max_html_param_len（50000）值加大（此处确实是自动关联，）四、 测试结果上图为概要报告，是针对负载测试的结果描述： 整个负载测试时长7分22秒。 最大同时运行vus

5、er为4个；整个负载测试的吞吐量为68611987byte；平均吞吐量为154880byte；点击次数为4008次；平均点击率为9047次每秒；出现的error个数为224个； 事务行为中29次成功、8次失败、4次停止；vuser结束事务过程4次全通过；vuser登录过程中4次成功，96次失败。 HTTP响应的结果为：HTTP 200响应次数为2857次，每秒8.707次；HTTP 302响应次数为8次，每秒0.018次；HTTP 404响应次数为143次，每秒0.323次。上图为运行vuser的时间分布图，每秒平均登录1个，测试偏差1.549。上图为每秒点击次数的图形，平均为9.047次，偏

6、差为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优化配置： ThreadsPerChild 1900 MaxRequestsPerChild 10000，需要进一步加强服务器并行能力。