LoadRunner 性能测试心得

操作流程

第一次没用经验，直接就上马，没有执行性能测试操作流程。

应该采用“测试计划->设计测试用例->录制测试脚本->执行测试->分析测试结果”的流程。

测试计划

分析应用系统、定义性能测试目标（确定需求对应的度量指标）、计划LoadRunner执行过程。

设计测试用例

分析测试需求、确定测试负载、确定用例细节。下面这个表格形式是从网上摘抄来的，觉得可以借鉴。

测试序号			脚本名称
测试目的
测试数据及条件
脚本描述	描述
	录制步骤
	事务
	同步点
测试场景描述		场景1：2个用户并发、循环1次（测试报告文件名称） 场景2：7个用户并发、循环1次（测试报告文件名称） …
测试结果验证
测试环境恢复

录制测试脚本

在录制脚本时，要注意几点：

1、 录制虚拟用户脚本；

2、 优化脚本（针对当前测试用例）；

3、 在单击模式下运行测试脚本；

4、 将虚拟用户合并到场景中；

5、 关于LoadRunner调试：在需要设置参数或者关联的地方，可能因某些原因，不能正常获取，那么可以利用LoadRunner的打印函数+调试（F）来便于我们分析数据，eg：lr_log_message("parent dclass id:%s",lr_eval_string("{parentId}"));

6、 关于使用“手工关联”的几点注意：

A． 若关联的字符串较长（超过255个字符），则需要在Action后增加参数长度申明，eg：web_set_max_html_param_len("1024");

B． 若不了解关联的左右边界，可以通过“Tree View”方式浏览，选择“Server Response”，找到提交的字符，如图：

C． 关联函数一定要放在页面之前申明，

eg：web_reg_save_param( "dataStateModify", "LB=name=\"state:data/ModifyDClass\" value=\"", "RB=\"", "Ord=1", "Search=Body", "RelFrameId=1", LAST );

执行测试

执行脚本时，要注意几点：

1、 要运行一个完整的测试场景

2、 要设置Run-Time属性：包括每个虚拟用户执行迭代次数、Think time设置（默认是采用录制脚本时的时间。）

3、 针对虚拟用户执行步骤时间控制，可以在Controller的“tools”->“Options”，如图：

4、 对于浏览器缓存的配置，可以在“Run-time setting”的“Browser Emulation”里设置，如图：

5、 更多“Run-time setting”配置项，如HTTP请求连接超时时间（默认120s）等可以在“Perferences”->“Options…”如图：

6、 对于使用了参数的脚本，若参数分配是采用“Unique”+“Once”方式的（适用于按序分配参数记录，每个虚拟用户分配一次），则参数行数必须大于或等于虚拟用户个数，否则会报“insufficient records for param…”之类的异常；还有一个情况，是在执行测试中发现的，不知道算不算LoadRunner的bug。即第一次参数记录有2个，设置虚拟用户2个正常运行；再修改参数记录为5个，设置虚拟用户5个，不能执行，也是报上述错误。经不断尝试，发现为这个脚本创建一个新的场景就能正常运行了。

7、 在运行测试时候，发现LoadRunner会出现集合点失效的现象，即设置了集合点，但是并发用户并非等待到一起运行，先加载的虚拟用户就会先运行直至结束，唯一解决办法就是需要重新启动场景。

分析测试结果

1、 这个是本次性能测试的弱项，还需要进一步提高。

2、 由于资源记录情况，是针对整个脚本运行场景的，他没有与单个事务关联（或许是我还没有找到。。）所以事务的资源消耗情况，是采用整个场景完整运行的资源消耗数据的。（不够精确）

测试经验和教训

1、 前期测试计划和测试用例一定要做好，这样才有章可循，提高录制脚本和执行测试效率；

2、 测试计划一定要参照应用系统和实际运行情况来制订，做到有的放矢，不要拍脑袋；

3、 一定要科学合理的评估测试总工作量（按照测试流程制订测试计划来评估）；

4、 当脚本录制确认无误（通过回放来判断），运行场景却总是报莫名其妙的错时，可以尝试创建脚本的新场景来运行；

5、 录制的脚本、场景数据、分析报告等文件一定要有较好的命名规范，做到看文件名即明白这个文件是什么，便于管理；

6、 不要丢弃原来旧的测试结果；（这样，可以用于不同版本进行对比）