LoadRunner常见问题总结

1、在average Transaction Response Time图中，曲线上下波动越小，说明服务器性能越稳定。如果波动很小，响应时间却偏大，这是需要分析程序算法是否存在缺陷或服务器参数的配置是否合理

2、通用性能测试分析流程

1）从分析summary的事务执行情况入手

2）查看负载发生器和服务器的系统资源情况

3）查看虚拟用户与事务的详细执行情况

4）查看错误发生情况

5）查看web资源与细分网页

LR中设置场景运行时间根据什么？

3、为什么在场景中响应时间很长，但是实际操作没那么长？

该问题常常是因为没有对具体操作添加事务函数导致，场景中的事务响应时间是整个Action的响应时间，另外一种可能性是在事务函数中存在lr_think_time()函数，在Analysis中过滤即可。

4、 loadrunner场景设计时间与实际运行时间相差很大，是为什么？

vuser的初始化、运行、消亡都不会按照你理想化的进行的。在整个过程中，随时会受到网络、硬件的干扰，比如，你设计的没10秒stop100个用户。理想情况下是这样，但是没准当时就是内存、cpu、网络导致没这么多的用户stop，那么就需要等待，等待的过程中就需要计时，这么一来二去的等到所有vuser都stop了，可能无形中时间就延长了，所以这个情况是正常的

注： 那么，网络、硬件怎么具体影响的呢？

5、理解思考时间

思考时间，顾名思义，在使用LR录制脚本过程中，模拟用户在访问和操作业务这个过程的停顿时间。

其实对于LR工具里面设置的思考时间（lr_think_time），有的人设置默认录制的值，有的人觉得在压力测试时要去掉思考时间，这样服务器的压力才大，我个人认为，如果真实地模拟用户的操作的话，加入思考时间是必要的，至于在测试时，应该使用LR工具适当的设置该值，如取某段范围内取随机值，或者在每个操作事务前设置3～5秒左右等。

思考时间，可以认为是一个事务要开始时思考的时间，一般在脚本中思考时间在一个事务的结束点、另一个事务 的起始点之间。

6、脚本调试准则

1）删除cookie，因为我们访问一个网站的时候，对这个网站都不会有cookie信息，所以不需要cookie，可以使用web_cleanup_cookies()函数清楚当前cookie信息

2）乱码情况，我们使用的中文操作系统默认编码是GB2312方式，但是几乎所有的中文网站都是utf-8，可以使用lr_convert_string_encoding()函数来处理

3）EXTRARES段是一种扩展验证机制，验证这些对象是否存在，如果 EXTRARES中的请求并不在请求返回中，那么回放改脚本会比真实情况略微增加带宽的使用。

注：在普通脚本开发中为了更好地模拟用户请求最好不要删txtrares，多了也没什么坏处，只是多了一点数据流量，删了会导致某些主请求请求不到的内容不会被请求。至于rxtrares中的内容是不是也需要参数化或者关联，个人觉得不用做那么多了，差别不大。

7、常用函数

web_link()

web_url()

web_submit_form()

web_submit_data()

web_custom_request() 自定义http请求 当请求比较特别，VuGen无法简单使用以上4个函数进行表述，那么录制后便会出现web_custom_requesta()函数，这个函数的作用是 自定义HTTP请求规则

web_convert_param() 完成HTML、URL、Plain三种格式的互转

lr_output_message() 输出函数

lr_set_debug_message() 日志操作

lr_set_debug_message(16|4,1) 强制设置日志为启用

lr_set_debug_message(0,1) 强制设置日志关闭

lr_set_debug_message(1|2,1) 强制设置日志启用，只查看基本内容

lr_get_attrib_string() 获取这些参数名对应的值

lr_error_message() 该函数的作用与lr_output_message()有些类似，都可以将函数中的字符串输出到日志，但是lr_error_message()函数会产生错误信息，这个错误会在后面影响错误计数器（尽量避免使用）

lr_eval_string() 可以从参数中取得相应的值，并且转化成一个字符串

lr_save_string() 将一个字符串保存为一个参数

8、什么情况下应该用HTML-based script？什么时候应选择URL-based script？

一般来说如果是标准使用IE访问的B/S架构，应该使用HTML-based script 下的A script containing explicit URLs only方式来录制脚本，这种脚本基于URL请求完成，不会带有任何前后依赖的内容。而如果是一个非HTML标准的C/S架构，建议使用URL-base script来录制脚本，这样可以确保不会遗漏任何HTTP请求。

9、脚本的return 0命令表示什么？

说明函数正常结束，直接跳到函数末尾。而使用Return-1则说明该函数错误结束

10、以lr开头的函数是LoadRunner自带的基础函数，而以web开头的函数是指Web Vuser script函数，用来模拟用户行为

11、一般think time时间设置为多少好呢？

通常的做法是在录制时按照普通用户的方式进行操作，得到常见用户的响应时间。例如在注册时正常输入注册信息，那么录制后的脚本在进入注册页面和提交注册请求之间就会自动生成think time。如果对录制出来的时间存在疑问，一般推荐把这个时间设置得小一点，这样性能测试对服务器负载大，得到的结果比较悲观，便于评估系统在超出需求情况下的处理能力。

12、在负载过程中建议不要同时打开Continute on error和Generate snapshot on error支持，这样会大幅降低负载效率。

13、一般来说响应时间由网络时间、服务器处理时间、网络延迟三大部分组成

14、 First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

15、 思考时间无论加在事务中还是事务外 都会导致脚本的运行时间加长

相当于请求的密度下降了 吞吐量就会下降

但是这个下降 并不是系统处理能力恶化 而是负载小了

16、 【receive time】 显示从服务器收到最后一个字节并完成下载之前经过的时间。 接收度量是很好的网络质量指示器（查看用来计算接收速率的时间/大小比率）。   好像你的下载带宽不够，导致这个时间太长。

17、 LR 的Vugen 和 controller 中迭代是这样的：

当场景的持续时间为“具体的几分钟”时，忽略Vugen中的迭代次数，脚步的action重复迭代，直到时间结束为止，按退出策略，执行退出操作

1. 当场景执行结束时，迭代次数还未完成，直接结束场景，结束迭代；

2. 当迭代结束时，场景持续时间未运行结束时，忽略 场景中设置的迭代次数，脚本的action重复迭代，知道运行时间结束为止，按退出策略，执行退出操作；

18、 Loadrunner中吞吐量与带宽的换算：

楼主运行完测试之后，在summary report中应该能得到Average Throughput (bytes/second)这个数值，假设为T，然后并发用户数是U，这样所需的最小带宽应该用如下公式计算：

（T/U/1024*1024)*8

需要注意的是带宽的单位通常为Mbps（M bits per second），所以需要进行以上的换算， 1 bytes=8 bits

19、 在分析性能测试结果时，有时会发现controller 中的average response time 和 analysis transaction summary中的 response time不一致。

可能原因有2：

1. 在controller中运行场景时，选择了replay thinking time.在analysis transaction summary中默认是ignore thinking time的。

   Solution: controller->run time setting->think time-> ignore think time.

2. controller 中的采样时间间隔和analysis中的采样时间间隔不一致。

   查看controller的采样时间间隔：right click graphc->configure->refresh rate (sec)

   查看analysis的采样时间间隔：analysis->view->set granularity

   solution: 将analysis的采样时间设置为controller一致