LoadRunner运行设置及关联.doc

LoadRunner运行设置(Run-Time Settings)Run LogicPacingLogThink TimeMiscellaneousBrowser Emulation其它设置选择默认值关联LoadRunner脚本关联动态数据的最简单方法百度或Google一下“如何在 LoadRunner 脚本中做关联 (Correlation)”，你会搜索到在网上相互转载的很经典的一篇文章。洋洋洒洒近6000汉字，像个小百科全书。对于关联Correlation的概念，对web_reg_save_param（）方法的参数的解释，你还可以参考那篇文章学习一下。对于如何手动关联动态数据，如果按那篇文档做，你可能需要2小时才能完成一个复杂测试场景的动态数据关联，使用本文档下面介绍的方法，不管多么复杂只需2分钟就能完成关联动态数据。为什么要关联动态数据呢？举个例子，在对我们平台的工作流性能测试时，在待办任务里面选择一条记录执行发送操作，LoadRunner VuGen会详细记录下来流程发送操作的细节，但在回放脚本的时候会有问题。待办任务里面找不到那条记录了，已经发送到下一个环节了。另一个更易理解的例子，在初始化查询页面，选择一条记录进行删除，录下脚本进行回放的时候会出错，记录已经删除了，回放脚本的时候服务器返回的记录不再包含那条记录，再向服务器发送删除那条记录的请求，就报错了。关联动态数据需要我们在脚本中设置一个变量，保存从服务器返回的起标识作用的数据，发送请求的时候使用该变量代替动态数据，这样再回放、反复测试就不会报错了。需要关联的标识性数据一般是各种主键，工作流的发送的例子很复杂，需要对流程编码、环节编码、参与者编码、表单编码等进行关联，下面使用复杂的工作流发送的例子进行演示。手动关联动态数据的复杂做法是，回放脚本，在Execution Log和Recoding Log打出的信息中找需要关联的动态数据及动态数据的左右边界。甚是麻烦，我没怎么看明白。其实每次回放脚本，Recoding Log打印的信息都是一样的，也和录制脚本的时候生成的dataRecordingLog.txt文件的内容一样。下面直接使用dataRecordingLog.txt文件，关联动态数据的时候不再需要回放脚本，减少了关联动态数据的工作时间。执行同样的操作，先后录制两次脚本保存，比较一下生成的Action.c，注意动态数据不能放在vuser_init.c文件中。自带的WinDiff工具不好使用，推荐使用Beyond Compare工具。不是所有的差异处都要关联的，WEB_URL()等方法的参数列表的先后顺序是没关系的，思考时间当然也可以不同。下图中右边的脚本已经关联过动态数据了，如果是刚录制的两份脚本，右边的id、processId等也是32位的主键，左右两份脚本的差异一目了然，记下这些动态数据的值。转载请保留：本文出自lobster的51Testing软件测试博客：/?194329以左图id的值：40287ae91c4b7dbb011c4b85e17204da为例，在脚本dataRecordingLog.txt中查找该值。找其第一次出现的地方，一般在该值的上方会有这样的字样：* tid=2258Action145 Receiving response from host 05:7001 ( 10/9/2008 17:40:37 )。如下图，记下40287ae91c4b7dbb011c4b85e17204da的左边界：。注意看一下这样的左右边界是否唯一。在刚才的脚本的文件dataRecordingLog.txt中小心向上翻动，可以找到这样的字样： * tid=2258Action145 Recording Function ( 10/9/2008 17:40:37 )该字样的下面紧接着是方法web_submit_data(jspformtaskdeal.cmd,)，这个方法在Action.c中是同样存在的，通过这个方法我们可以知道在Action.c的什么地方插入web_reg_save_param()方法。现在我们需要做的就是在脚本Action.c中，方法web_submit_data(jspformtaskdeal.cmd,)的前面，紧挨着这个方法写上web_reg_save_param()方法用于保存动态数据，其中LB、RB分别是刚才记录下的左右边界值，primary是我们起的变量名字。完整的方法如下：转载请保留：本文出自lobster的51T