LoadRunner_测试Tuxedo.doc

用LoadRunner测试Tuxedo中间件系统河北移动BOSS1.5公司： 作者：张 翼日期：2005年6月22日修订纪录日期修订版本修改描述 作者2005-7-141.00初稿完成 张翼1概述随着软件行业的发展，测试作为软件生命周期中特别重要的一个步骤，已经被越来越多的软件开发单位所重视。随着客户对软件认识的不断深入，对测试的要求也越来越高。客户已经不再仅仅满足于软件功能的完成。而更注重的是软件的性能和能够承受的压力。很多人容易把软件性能测试和软件压力测试混淆，甚至包括一些已经从事软件测试工作多年的专业人员。其实，二者之间确有关联，但也有比较明显的区别。按照我个人的理解，软件性能测试主要关注的是软件在规定正常的条件下，其处理能力的体现。比如对软件响应速度的测试和对服务器资源占用情况的检测；而压力测试，顾名思义，既是对软件的运行环境施加压力，来观测软件的运行情况。它关注的不是软件的响应速度或占用了多少系统资源。而是以高出正常负载20%30%的情况下，观测系统是否能够成功正确的响应请求。其失败率是多少。在做软件性能测试的时候如何去检测系统的响应速度？又如何去观测系统资源占用的情况呢？在做软件压力测试的时候，如何构造一个高于正常负载的一个测试环境呢？又如何统计业务的失败率呢？目前，业界中有不少能够做性能和压力测试的工具，Mercury Interactive公司的LoadRunner是其中的佼佼者，也已经成为了行业的规范。它完全能够帮助完成以上所需要的工作。2编写目的河北移动BOSS1.5是以Tuxedo为中间件的C/S三层结构系统。作为测试员，我被安排做账务这个模块的性能和压力测试。由于以前从来没有使用过LoadRunner，这次工作遇到了很大的困难。疯狂K书的结果是发现LoadRunner对B/S系统的性能和压力测试支持得如此之好。凡是网上有的资料十之八九的都是介绍如何用LR对B/S系统的测试。此外就是一些喜欢玩底层的高手，弄一大堆英文资料来介绍Winsock的测试。我只能说，对不起，Winsock的英文资料我看不懂，B/S的资料我暂时不需要。还有一篇网上流传的文章，介绍的是用LR对BEA（Tuxedo、Weblogic）的测试，只简单描述了LoadRunner测试步骤，其介绍太留于表面，扫盲尚可，作为使用的说明，那就差的太远了。对于我们的系统来说，很明显应该使用Tuxedo协议去录制测试脚本。由于不能找到相关的介绍文档。我在著名的51testing论坛上和深圳测试协会的论坛上都发帖求助。居然5天过去了，看的人不少，回复的人一个也没有。气愤之余，决心要在这次测试搞定以后一定记录下步骤和心得，亦是本文形成的缘由。3本文讨论的范围本文是针对LoadRunner对Tuxedo中间件系统测试的一个专题文档。通过实例描述的方式介绍LR对Tux中间件系统进行测试的方法，主要介绍对脚本的处理，顺带介绍一下LoadRunner基本功能和测试步骤，但是不会以此为主。本文不会对Tuxedo中间件的详细配置进行介绍。4测试脚本的准备我打算以缴费的性能测试作为例子，通过我是怎样一步步实现这个测试脚本的，来介绍这个过程。4.1脚本的录制万事开头难？当接到测试缴费性能的任务时，我已经看过了一些关于用LR测试B/S的文章。所以毫不犹豫的开始了用Tuxedo协议录制脚本的工作。4.1.1协议的选择打开VuGen，选择单协议录制方式，采用Tuxedo6协议:图表 1 协议选择由于系统的服务端采用的Tuxedo8.0服务，所以刚开始的时候我使用Tuxedo7协议进行录制。在录制到第8个事件的时候报错（如图2）。后来考虑到录制的客户端是tuxedo6.5的，可能不包含Tuxedo7的部分dll文件，所以改用Tuxedo6协议，就能够成功录制了。图表 2 协议选错了4.1.2开始录制选单设置当打开Tuxedo6协议开始录制以后，系统弹出一个开始录制对话框。由于测试对象是C/S结构的，所以我选择“Win32应用程序”为应用程序类型。然后在要录制的程序里面通过选择按钮选到要运行的客户端程序。将“录制到操作”定位到vuser_init中。详细的信息如图。图表 3 开始录制对话框 注意：1、 LR的脚本基本上分成三个结构，vuser_init、action、vuser_end。对于Web协议的脚本来说action可以是多个的。对于选用的Tuxedo6协议，经过观察，好像不能添加多个action。通常vuser_init是用来放置登录脚本的，vuser_end是用来放置退出脚本的，这两部分的脚本不参与迭代和循环，也不需要定义事务。如果需要在登录的时候添加集合点，验证多用户登录的压力测试方案，则需要将登录脚本放在action中，让vuser_init留空。因为在vuser_init区域内是不允许添加集合点的。2、 “工作目录”通常是根据“要录制的程序”的选择而自动填充的，不需要做修改。4.1.3录制登录“开始录制”对话框设置完成，点击OK键，录制正式开始。LR会根据设置的“要录制的程序”打开对应的客户端程序（如图4）。按照正常步骤登录即可。图表 4 正常登录输入工号和口令点击确定，成功登录系统。LR的录制控制条会显示录制过程中发生的事件，比如在登录窗口打开过程中共做了24个事件（如图4），登录成功后共做了112个事件（如图5）。4.1.4插入集合点登录完成后，将要做缴费操作，所以需要更换录制脚本的区域。直接在录制控制条上将vuser_init换成action即可(如图5)。图表 5 更换录制区域 然后继续脚本的录制。打开缴费的界面，输入一个要缴费的服务号码（电话号码）。输入完成后添加集合点。添加集合点的方式为点击录制控制条上的添加集合点按钮（如图6）。然后弹出“插入集合点”对话框，输入集合点的名字，就成功了。图表 6 添加集合点 注意：1、集合点：当通过controller虚拟多个用户执行该脚本时。用户的启动或运行步骤不一定都是同步的。集合点是在脚本的某处设置一个标记。当有虚拟用户运行到这个标记处时，停下等待，直到所有的用户都达到这个标记处时，再一同进行下面的步骤，这样能够用最大的用户并发去做下面的操作，就像集合再前进一样。集合点之名由此而得。集合点主要用于对关键步骤的加压。所以常用在事务定义之前。4.1.5插入事务点集合点插入完毕，点击录制控制条上的“事务开始定义”按钮定义事务。“开始事务”对话框弹出，输入事务名称，点击确定就完成了开始事务的标记。（如图7）图表 7 插入事务开始点 注意：1、事务：对于一个录制好的脚本，在回放的时候怎么去关注它的具体性能呢？当然不是全局的去观察。测试需要注意的其实是脚本中的关键点。比如图书馆的新书入库，其实测试人员关注的只是在图书入库的那个步骤的性能值，通常都不会去研究填写这些入库图书信息的那些过程。所以LR的事务添加操作就是把测试所需要关注的操作定义成事务告诉LR，这个是我想要重点检测性能的操作。LR就会在运行过程中记录事务内操作的响应事件等性能数据。并在Analysis中以报告的形式给出统计结果。4.1.6插入事务结束点事务开始点插入完成后，点击Enter键，对输入的服务号码进行查询。查询出号码对应的账户信息。当查询完成后，点击录制控制条中的插入事务结束点按钮。弹出“结束事务”对话框，点击OK结束定义的事务。（如图8）图表 8 插入事务结束点现在来回顾一下4.1.4到4.1.6做了什么。其实我的目的是让LR关注查询输入的电话号码对应的账户信息这个步骤，因为它是一个要和数据库交互的动作，并且会被客户经常使用。所以应该把查询账户信息的操作定义成一个事务。在做这个事务之前，为了给这个事务正常加压。所以定义了集合点。4.1.7完成脚本录制账户信息查询的过程完成后，在“实交”区域内输入实际要交的金额。然后效仿前面的步骤为缴费提交的操作添加集合点、事务开始点。然后点击确定按钮。等提交完成后加入事务结束点。事务结束点加入过后，需要的基本操作就完成了。最后录入退出脚本。此时需要将脚本录制区域修改为Vuser_end（如图9）图表 9 更换脚本录制区域然后点击关闭客户端的按钮。在系统提示确认过后，成功退出客户端。然后点击录制控制条上的结束控制按钮，就能够成功生成录制的脚本。至此我的缴费性能测试脚本就制作完成了。谁说万事开头难？就录脚本来说，我认为是LoadRunner操作中最简单也最容易上手的。 注意：在录制脚本的过程中，需要选择数据。建议最好能够选择比较有代表性的数据。比如我的脚本中，选择的服务号码。该号码对应的账号和用户号码最好不要相同。因为这两个号码在后面动态关联或参数替换的地方需要用到。如果不能区别的话，到时候从Reply CARRY buffer中找到的数据就不知道哪些应该替换成账号，哪些应该替换成用户号码了。后面会对参数替换和动态数据的关联详细介绍。4.2脚本的修改增强脚本功能关于Tuxedo6协议的LoadRunner录制脚本的增强，费了我不少功夫。主要是到处都找不到资料。上网求助也无门。后来发现高手就在身边，通过不断的请教，终于顺利完成了这次的工作任务。再次特别的感谢这位高手。脚本录制完成了，我在Vugen中回放了两边，都能够顺利通过。但是如果就用这个脚本去做性能测试显然是不能测试到真正的性能的。4.2.1录制的原始脚本不能直接用做性能测试为什么录制的原始脚本不能直接用做性能测试呢？这里先简单讲述一下controller的用途。LoadRunner8.0以前的版本主要包含了3个应用VUGenerator、Controller和Analysis。VUGenerator用于对测试脚本的录制、编译和调试；Analysis用于对性能测试结果的分析和给出报表结果；LoadRunner8.0还包含一个叫做Tuning Console的应用，是用作系统优化方案的（我没有用过，连相关资料都没看过，就不吹这个了）；Controller是用于虚拟场景的构建、提供虚拟用户方案的模拟，对测试脚本的分配，以及提供监视器实时监控系统资源。简单点讲，就是用VuGen录制完脚本了，用Controller去生成一个场景，然后产生大量的虚拟用户，把脚本分配给这些虚拟用户在场景中去执行，对服务器来说就好像同时有很多用户都在访问自己，实际上都是一台或数台机器虚拟出来的。现在来讨论一下为什么原始脚本不行。拿我录制的脚本来说，首先，登录系统以后，要用一个电话号码查询账户信息，然后给这个账户缴费。当虚拟了大量用户以后，每个用户都同时去执行这个脚本，就会造成所有的虚拟用户同时在为同一个账户缴费。由于系统有concurrence constraint机制，是不允许两个操作员同时操作同一条数据的。所以用原始脚本运行是肯定会报错的。所以，为了避免这个问题，就需要对当前的脚本增强，使其更加通用化。能够让不同的虚拟用户为不同的账号缴费。具体的实施主要有参数化替换和动态数据关联两个操作。要做这两个操作，就一定要熟悉录制出来的脚本的结构。4.2.2 Tuxedo协议录制生成的脚本结构简介在VuGen中可以发现录制完成的脚本中，除了包括3个脚本区域外还有1个Replay.vdf文件。如图：图表 10 Replay.vdf这个Replay.vdf是用来做什么的呢？首先从录制脚本的结构说起。在vuser_init、action、vuser_end中脚本的结构都十分类似。结构大概为多个request carry buffer和对应的reply carry buffer。图表 11 脚本实例图11是从录制脚本的action区域中截取的一段。从注释信息中可以看出，它包含了一个/* Request CARRY buffer 12 */和一个/* Reply CARRAY buffer 12 */。现在具体介绍一下各个语句，先从图中红框内/* Request CARRY buffer 12 */以前的语句开始。l lr_rendezvous(queryCustInfo);该语句是我在录制过程中定义的第一个集合点。l lr_start_transaction(queryCustInfo);该语句是我在录制过程中定义的第一个事务开始点。l lrt_tpfree(data_1);该语句是将data_1内的数据清空。l lrt_tpfree(data_0);该语句是将data_0内的数据清空。l lr_think_time(24);设置思考事件，当脚本运行到此处，暂停24秒。l data_0 = lrt_tpalloc(CARRAY, , 253);给data_0分配一个新的缓存空间，类型为CARRAY，子类型为空，长度为253个字节。/* Request CARRY buffer 12 */l lrt_memcpy(data_0, sbuf_12, 252);从sbuf_12中拷贝252个字节到data_0。l lrt_display_buffer(sbuf_12, data_0, 252, 252);该命令是将data_0指向的sbuf_12缓存中的数据拷贝到一个.out文件当中。第1个252是“在回放中将使用的实际数据长度”。第2个252是“期望的长度和在录制过程中观测到的一样”。l data_1 = lrt_tpalloc(CARRAY, , 2); 给data_1分配一个新的缓存空间，类型为CARRAY，子类型为空，长度为2个字节。l tpresult_int = lrt_tpcall(DISPATCHER,data_0,252,&data_1,&olen,0);lrt_tpcall函数的作用是发送一个服务请求但后等待回复。上面语句是向DISPATCHER发送请求，data_0是请求的数据部分，252是指data_0的长度，&data_1是返回的数据，&olen是返回数据的长度，0是有效性标记。/* Reply CARRY buffer 12 */l lrt_display_buffer(rbuf_12, data_1, olen, 11594);该命令是将data_1指向的rbuf_12缓存中的数据拷贝到一个.out文件当中。olen是“在回放中将使用的实际数据长度”。11594是“期望的长度和在录制过程中观测到的一样”。l lrt_abort_on_error();如果上一步tuxedo功能遇到错误，就中止当前正进行的事务。现在再来看Replay.vdf。打开Replay.vdf,可以发现下面的语句写在开头处：/*This file is generated by LoadRunner. You may edit it carefully!*/#ifndef TUXVDF_H#define TUXVDF_Hchar* data_0;char* data_1;现在终于知道data_0和data_1是从哪里来的了。再往下看，可以发现原来Replay.vdf 中的结构也大体是多个request carry buffer和对应的reply carry buffer。并且注意，所有的reply carry buffer都是被注释的。在这里可以找到action中被使用的sbuf_12和rbuf_12。其实Replay.vdf就是一个大的数据仓库。在和服务器交互的过程中，所有缓存中的数据最终都会按照格式写进Replay.vdf。拿我录制的脚本举例，登录用的txjhs，查询账户用的服务号码都能够在Replay.vdf中对应的sbuf中找到；而输入服务号码后获取的账户信息（账号、流水号等等）信息也能从Replay.vdf中对应的rbuf中找到。如此以来就可以对这些数据进行参数化和动态绑定了。 注意：1、脚本中各个函数的具体含义其实不必深究。对于测试员来讲，如果不是打算用手工方式编写完整的脚本，那么知道函数的大意已经足够了。不会影响性能测试的进行。2、有没有发现Replay.vdf里面有很多乱码？这是因为数据被加密了。比如我第一次录制完成后，发现了大段的乱码。而且有类似下面的语句：图表 12 Replay.vdf乱码有compress做标记，表示该段代码被加密。从脚本中看，因为加密是发生在Request段中，所以应该是客户端向服务器端发送的请求被加密，请开发的同事提供了解密版本的客户端解决了这个问题。在软件中，如果重要的数据或请求需要在网络上传输，为了避免被破坏性的截取，往往会将这些数据或请求加密以后再放在网上传输，接收方接到加密数据后经过解密程序解密再做后续响应。4.2.3参数化替换关于为什么要做参数化替换已经在本节的前面部分有较详细的描述，这里就不再赘叙了。直接进入如何参数化的部分。同样拿我录制的脚本开刀。首先回想一下脚本录制过程。录制的脚本中，主要包含下面几个流程。1、 首先用txjhs用户登录系统。2、 然后输入服务号去获取账号等信息。3、 对账号进行缴费操作。4、 退出。可以观察到在整个流程中需要参数化的是用户（包括对应密码）和服务号码。因为它们是操作员向服务器发出请求的数据。在Replay.vdf中找到用户和服务号码第一次出现的地方。选中这个字段，点击右键，弹出右键菜单。（如图13）图表 13 参数替换右键菜单选择“替换为新参数”打开“选择或创建参数”对话框。（对于英文版LR应该是选择“Replace with new parameter”）。图表 14 选择或创建参数参数名可以任意命名，最好和实际参数的意义匹配，便于以后维护。参数类型这里选择File，意为从文件中读取。然后点击“属性”按钮打开“参数属性”页面，如图15。页面中参数类型和选择或创建参数页面中的参数类型等效。文件路径为文件保存路径。点击“创建表”按钮。确认后，能够创建一个一行一列的数据表，数据为“txjhs”，就是登录用户（该用户没有设置密码，所以没有参数化密码），然后可以通过点击添加行和添加列按钮，添加记录，并输入新的登录用户名，最后LR会将这些数据形成一个文件保存在指定的路径中。图表 15 参数属性页面点击数据向导按钮，能够打开数据库查询向导页面，如图16。图表 16 数据库查询向导建议在查询定义中选择“手动指定SQL语句”，点击下一步，可以打开指定SQL语句页面。如图17图表 17 手动指定SQL语句点击创建，打开Select Data Sourc页面，开始创建连接字符串。如图18图表 18 Select Data Sourc页面点击“New”按钮，打开“Create New Data Source”页面，选择Oracle ODBC Driver数据源类型（因为我的后台数据库是Oracle），点击“下一步”图表 19 Create New Data Source页面新页面中要求输入数据源的名称，可以随意键入，如图20。然后点击下一步。图表 20 输入数据源名称 确认信息页面弹出，并列出目前该数据源的设置，直接点击完成即可，会弹出一个连接窗口，输入数据库连接的服务名，用户名和密码，点击OK，如图21：图表 21 数据库连接窗口如果连接通过，ODBC数据源就被成功创建，可以在“手动指定SQl语句”的窗口中看到连接串。然后在SQL语句窗口输入自己定义的SQL语句，点击完成后，就能够成功按照提供的数据源和SQL语句在指定的数据库中查询到指定的数据存放于数据文件中。如图22：图表 22 填入SQL通过创建表方式和数据向导方式都可以成功创建数据文件，操作员可以随意选择自己习惯的方式。总之，能坚守数据文件放数据的原则，就不会出问题了。当回到“参数属性页面”中后，发现数据已经准备好了，而且原来灰色的区域目前也可以选择了。如图23。选择列中的内容，不再赘述。主要介绍一下“选择下一行”和“更新值的时间”的几个选项。图表 23 参数属性页面2“选择下一行”共有下面几个选项：u Sequential： 按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取。u Random： 任意选择。但是在每一次迭代中，将不发生变化。u Unique：唯一的数。当使用该选项时，需要保证准备的数据文件中有足够的数据。比如要做20个虚拟用户，每个用户要进行5次迭代，第一个用户在5次迭代中分别使用数据文件中的数据1数据5，第二个用户在5次迭代中分别使用数据文件中的数据6数据10，类推以后20个用户将使用到100个数据。那么必须保证准备的数据文件中有100个以上的数据，否则运行时会出错。u Same line as 某个参数：和前面定义的参数取同行的记录。通常用在有关联性的数据上面。比如当我做登录密码的参数化时，由于它和UserID是有关联的，所以会用到这种选择方式。“更新值的时间”共有下面几个选项：u Each iteration：每次迭代更新一个新的值。u Each occurrence：每次出现时该参数时更新一个新的值。u Once不管迭代多少次该参数的值一直保持不变。考虑到我录制脚本的实际情况，这里我将“选择下一行”设为“Unique”，将“更新值的时间”设为“Each iteration”。既是说，每次迭代的时候读取一次数据文件中的数据且文件中的数据不会被多用户重复使用。这样参数的定义就完成了，可以发现Replay.vdf中原来选中的“txjhs”变成了“UserID”。如图24。说明该数据已经被参数替换了。接着将Replay.vdf文件中所有在Request CARRY buffer里出现的“txjhs”全部替换为“UserID”。参数替换的工作就完成了。可以参照本次操作的步骤同样替换服务号码。图表 24 参数化替换成功 注意：1、 参数类型：在创建参数的时候，我选择了参数类型为File。参数类型共有9种，现在来简单介绍一下所有的参数类型以及意义。1.1、 DateTime：在需要输入日期/时间的地方，可以用DateTime 类型来替代。其属性设置也很简单，选择一种格式即可。当然也可以定制格式。1.2、 Group Name：很少用到。在实际运行中，LoadRunner使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name将会是None。1.3、 Load Generator Name：在实际运行中，LoadRunner 使用该虚拟用户所在LoadGenerator 的机器名来代替。1.4、 Iteration Number：在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来代替。1.5、 Random Number：随机数。很简单。在属性设置中可以设置产生随机数的范围。1.6、 Unique Number：唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。注意：使用该参数类型必须注意可以接受的最大数。例如：某个文本框能接受的最大数为99。当使用该参数类型时，设置第一个数为1，递增的数为1，但100 个虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。这里说的递增意思是各个用户取第一个值的递增数，每个用户相邻的两次循环之间的差值为1。举例说明：假如起始数为1，递增为5，那么第一个用户第一次循环取值1，第二次循环取值2；第二个用户第一次循环取值为6，第二次为7；依次类推。1.7、 Vuser ID：设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是 1。1.8、 File：需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（就是我用到的那种类型）。1.9、 User Defined Function：从用户开发的dll 文件提取数据。有关各种参数类型属性的详细设置这里就不多介绍了，到用到的时候大家可以多看看帮助文档。4.2.4动态数据关联什么是动态数据关联？哪些是动态数据？怎么关联？什么是动态数据关联动态数据可以理解为从服务器返回给客户端的数据。比如当你向服务器发送了一个请求 (Request CARRY buffer)，在服务器的响应（Reply CARRY buffer）中会给出一些数据。并且在后续的程序中，这些被服务器返回的数据将被频繁的使用。对于不同的请求数据来说，服务器处理后会返回不同的响应数据。操作员在得到这些数据返回之前无法预测到这些数据，所以无法用参数化的方式去处理这些数据。比如当我输入服务号码查询账户信息。输入的服务号码是我可以控制的，这个是发送的信息。发送这个信息以后，服务端会处理我发送的服务号码，然后返回给我这个服务号码对应的账户信息，这个是处理在Reply CARRY buffer中的。而且后面的程序会对这个账户号码进行缴费操作。输入不同的服务号码，其返回的账号信息都不想同。像这样的数据就需要用到关联了。关联的做法是预先定义一个变量，当从服务器截获到Reply CARRY buffer时，把其中相关的值保存在这个变量中，当系统中有用到这个返回值的时候就用这个变量去替换。这样以来，不管输入什么样的服务号码，那个变量中保存的值永远是对应的账号信息。确定需要关联的值怎样去确定要关联的值？有两种方式。一个很有经验的操作员，根据他对系统业务的了解，可以很清楚的知道哪些请求操作会让服务器返回一些将在后面操作中用到的数据。以及这些数据包括哪些内容。然后就可以轻松的写脚本关联这些返回的数据；另外一种方式是用不同的请求输入录制两份相同操作的脚本。然后用VUGen自带的WDIFF工具比较两次脚本的不同之处，以得到需要关联的地方。比如我分别录制两次缴费业务的脚本，两次使用的服务号码不同，在返回的buffer里面就可以看出这两次脚本返回的不相同的地方，就可以做这些数据的关联了。但是并不是所有的不同之处都需要关联。比如某些指明执行时间的Reply CARRY buffer中的数据就不必关联。第二种方式比第一种要麻烦，但是操作条理比较清楚，而且不容易遗漏需要关联的数据，很适合初学者。我是按照第二种方法来做的。首先我录制了两个缴费的脚本（Fee1和Fee2）。操作步骤完全一样，仅仅是登录的用户和输入的服务号码不同。当Fee2录制完成后，选中左边导航栏中的Replay.vdf，点击“工具”“与Vuser比较”，如图25：图表 25 与Vuser比较在对话框中选择刚才录制的脚本Fee1，然后点击确定。打开如图26：图表 26 打开WDIFF如图中所示，两个Replay.vdf脚本中的差异用黄色高亮显示（在页面中双击可以在查看全文和查看差异模式间切换）。然后关注其中一个文件，统计出除了执行日期和16进制代码段以外的所有差异数据。比如我统计的是Fee2的Replay.vdf中的差异数据，包括txjhs等。接着回到Fee2的脚本，研究Replay.vdf。在Replay.vdf文件中查找刚才统计出来的差异数据。其规则是看这些数据的第一次出现是否在Reply CARRY buffer区域内，并且该数据是否在后面的Request Request CARRY buffer中有用到。如果两个条件都满足，则说明该数据需要关联。 注意：1、 差异分两种，一种是两个文件的相同的行中，有不一样的数据；另一种是在相同的行中，一个文件有数据，另一个文件没有数据。我们的研究对象不考虑后者。关联数据下面以accountoid的关联来说明关联的具体步骤。在我的差异数据统计中，我找到的需要关联的数据其中一个是3180800249409，它第一次出现在Reply CARRY buffer 14中（如图27），然后在Request CARRY buffer15，19，23，24中都有用到。图表 27 Reply CARRY buffer 14然后开始计算它的offset数值。offset数值是指，从Reply CARRY buffer14开始，到出现3180800249409总共有多少个字节。16进制按分段，算一个字节，双引号和段的标题不算在内，因此，这个数据的offset值应该是68，长度是13。接下来在录制的脚本中（vuser_init，Action，vuser_end）找到Reply CARRY buffer14的段，插入关联语句段。如图28：图表 28 插入关联语句图中所示lrt_save_parm()函数就是LR中tuxedo协议脚本专用的关联函数。data_1表示Reply CARRY buffer 14中的数据是从data_1中的来的，68是offset值，13是需关联数据的长度。accountoid是定义的变量名称。这个函数的意思是，从data_1中68位以后，取13位数据保存在变量accountoid中。关联定义完成以后，再修改Replay.vdf。把Request CARRY buffer 15，19，23，24中的3180800249409全部替换成accountoid。如图29：（Reply CARRY buffer中的不必替换了）图表 29 替换Request CARRY buffer至此，该数据的关联就已经完成了。其他数据的替换按照同样的操作进行。动态数据关联就可以成功的完成。录制过程中我对脚本的修改也止于此。像加入流程控制语句之类的其他修改方式在我的测试中并没有用到。请参阅其他资料。 注意： 按照文中描述的方法二去寻找需要关联的数据也不是绝对的。在我录制脚本的过程中就遇到了一个不能关联的数据。下面以此为例，加以说明。 在录制的过程中，依照方法二，我发现了一个需要关联的数据3180800158122。在数据库中，查询到这个号码其实是用户的oid。它在Reply CARRY buffer 14中第一次出现（如图30），并在Request CARRY buffer15和19中使用。按照前面的描述，这个数据是应该被关联的。 但是我们再注意看这个buffer段。在3180800158122出现以前，有一段数据德顺。有姓名字段的存在导致这个数据无法被关联。因为对于不同的服务号，会有不同的客户名称，有两个字的，三个字的，四个字的，甚至英文字串。这样以来通过这个“孟德顺”计算出来的offset值就不一定适用于其他服务号码的请求。因此这里不能用关联的方式。我在这里的处理方式是将这个值参数化，并且和另一个参数化的数据服务号码绑定在一起。当选择服务号码的时候，就能够准确绑定对应的用户ID。详细方法请参看前面的参数化替换。图表 30 oid的第一次出现4.3脚本的调试验证脚本的正确性脚本完成后可以在Generator中对脚本进行调试。选中某行，点击F9可以设置断点。点击F10可以在断点以后进行单步运行。F5是运行。操作和微软系的IDE工具类似，这里不再赘述。开始调试前需要对Run Time Setting进行一些简单的设置，下面简单介绍一下。4.3.1 Run Time Setting设置点击Generator页面中的“Runtime Setting”（中文版为“运行时设置”）按钮，可以打开运行时设置页面。它包括了步（Step）的设置，日志（Log）的设置，思考时间（ThinkingTime）设置，以及其他（Etc）设置。首先来看步的设置。步的设置如图31中所示即为运行时设置步的设置界面。它包括“迭代计数”的设置和“开始新迭代”的设置。通常我只设置了“迭代计数”，没有修改过“开始新迭代”的默认设置。“迭代计数”的设置其实就是脚本Action区域循环次数的设置。需要注意的是当设置了“迭代计数”后，脚本运行时只有Action区域的脚本会参与循环。还记得在参数化替换中设置参数属性的“更新值的时间”有一个“Each Iteration”选项。其中的Iteration就是在这里设置的。通常对于调试脚本来说，这里的迭代次数不需要设置得太大。其实在调试脚本的时候设置迭代次数的目的是为了检验迭代调试运行时，脚本中的参数以及关联函数是否会随着脚本的迭代而发生变换，以证明参数替换和动态关联是否成功。所以设置3到5次迭代，以保证能够看出规律来就可以了。那么如何才能看得出，每次迭代的过程中究竟参数被替换成什么值了呢？下面简单说一说日志的设置，就明白了。图表 31 运行时设置步日志的设置图表 32 运行时设置日志日志的设置包含了一个日志记录的开关。当开关打开时，LR会按日志选项的设置记录脚本运行日志。当日志选项为“仅在出错时发送消息”时，LR会自动记录出错日志。但是这种选项对脚本的调试来说不太适合，因为如果脚本中的参数替换或动态关联不成功时很有可能不会发生错误。也就不会记录日志。操作员也就无法从日志得知对脚本的修改是否成功。我一般都选择“始终发送消息”，并且采用“扩展日志”方式，打印出参数替换。方便检查。但是很少要求打印“服务器返回数据”和“高级跟踪”，除非遇到无法定位的脚本错误。因为当要求打印“服务器返回数据”或“高级跟踪”时 ，由于服务器返回的数据非常多，会导致调试花费时间过长。思考时间的设置图表 33 运行时设置思考时间在录制脚本的过程中，测试人员操作的时候多少会有一些停顿或者是延时。有些是无意的，有些可能是有目的的。这些延时在脚本中以lr_think_time()函数表示。括号中输入正整数，表示延时时长，以秒为单位。思考时间设置就是为了控制这些延时。在思考时间的设置中，可以设置忽略这些思考时间，即不需延时。也可以重播这些延时。并且提供了四种重播的方式：u “按录制时记录的时间”是完全按照录制时的延时来重播。u “将录制思考时间乘以”方式提供了一个让用户定义的系数，重播延时时长由录制的实际时间乘以这个系数来决定。u “使用录制思考时间的随机百分比”提供了Min和Max这两个下限和上限百分比设置，重播时Generator会从实际录制时间乘以下限百分比到实际录制时间乘以上限百分比这个区间内随机读取一个值来作为重播延时的时长。u “将思考时间限制为”直接让用户重新定义所有的延时时长，单位为秒。个人认为用得最多的，可能还是忽略思考时间。至少在我遇到的脚本中，大多数的思考时间都不具备什么特别意义的。其他设置其他设置包括了“错误处理”、“多线程”、“自动事务”。错误处理是只当有错误发生时怎样处理。我通常会要求出错后跳过错误继续往下执行。因为有些错误是不会影响事务成功通过的。所以没有必要遇到错误就停止运行。对Tuxedo6协议来说“多线程”只能选择“按进程运行Vuser”。在4.1.5 插入事务点里面，我解释了事务这个概念。这里的自动事务是LR自动对事务的创建。在默认情况下“自动事务”中的“将每个Action定义为一个事务”是被选中的。即是说LR默认将整个Action看作一个事务，在运行过程中会自动记录Action的响应时间。如果不需要关注Action，可以将此处的勾去掉。图表 34 运行时设置其他 注意：对于不同协议的脚本，其运行时设置包含的项或可选的项都会有所不同。因此本文中介绍的这方面的内容并不一定适用于其它协议的运行时设置。4.3.2调试脚本运行时设置完成，就可以开始从Generator中调试脚本了。点击运行开始的按钮或者F5，脚本会按照Runtime Setting的设置开始运行，并在输出窗口打印关键日志。当脚本运行完成，没有错误，并且从关键日志来看所有参数替换和动态关联都成功的话，证明脚本已经完全通过调试，可以使用了。至此对脚本的研究已经告一段落。 注意：在脚本调试的过程中，所执行的脚本都是有效的。比如录制的是一个增加用户信息的脚本。当调试脚本的时候，如果调试成功的话，新增用户信息的操作是会真正加入到数据库中的,请注意。5运行测试5.1添加虚拟场景让测试脚本在此运行脚本制作完成，数据文件准备妥当，需要添加一个虚拟场景，在场景中模拟负载，运行脚本。LR的Cotroller用来完成这个功能。5.1.1创建场景在Generator中，创建好脚本后，点击工具创建Controller方案，可以打开一个新的Controller。从开始菜单也可以打开Controller。图表 35 打开场景创建系统会弹出一个“新建方案”窗口，如图36。（从Generator打开和从开始菜单打开有些许不同，大体一样。这里主要介绍从开始菜单打开的。）可以选择两种创建方案的类型。一种是面向目标的方案，一种是手动方案。手动方案又分为按数量分配负载和按比例分配负载两种。如果选择了“使用百分比模式在脚本间分配Vuser”那么就会打开按比例分配的场景模式。其实各种模式的选择取决与测试的目的。手动方案，让测试人员决定需要加载的负载量，用于在标准负载下测试系统的性能。目标方案，让测试人员定义一个目标，和添加负载的最小值和最大值。运行时LR会按照用户给定的负载最小值开始添加，试探系统性能是否能够达到定义的目标。如果不能达到，就继续添加，直到达到目标或者设置的最大值。这种方案对于定位当前系统能够承受的最大负载量非常有用。图表 36 创建方案窗口现在来分别介绍两种方案的具体设置。手动方案在“新建方案”窗口中选择手动方案（按数量分配负载），从“可用脚本”中选中一个脚本添加到“方案中的脚本”或者通过“浏览”按钮选择可用的脚本。然后点击确定打开手动方案（按数量分配负载）页面，如图37：图表 37 手动方案（按数量分配负载）可以看见选择的可用脚本已经列在了方案组中，默认的“数量”是10个，默认的负载生成器是Localhost。数量是指负载数量，即是虚拟用户数。可以根据测试的设计而由操作员更改。负载生成器是指生成这些虚拟用户的机器。如果添加了多个负载生成器，在方案组中可以从下拉框中为每个组选择属于自己的负载生成器。在方案组的右侧，有一列控制按钮：u 开始方案：当所有场景设置完成后，点击该按钮可以开始运行。u 生成器：用于负载生成器的添加，点击后弹出窗口如图38：图表 38 负载生成器页面中所显示的，表示当前仅有一个负载生成器，是本机Localhost，其状态是向下（down，其实就是没有拉起的意思，这里中文包的翻译有点生硬），平台是Windows。若选中该负载生成器，点击右边的“连接”按钮，可以测试该负载生成器是否正常可用。若可用，在连接完成后，状态会改为“就绪”，否则显示为“连接失败”。点击添加可以新增负载生成器，点击删除，可以删除选定的负载生成器。当点击添加时，系统弹出添加窗口：图表 39 添加新的负载生成器在名称中填写指定负载生成器的IP地址，选择负载身成器的操作系统，点击确定就可以完成添加。默认情况下“使负载生成器参与方案”是选中的，表示当改生成器添加以后自动加到方案中。可以根据需要设置为空。“更多选项”这里不再一一介绍了。详细信息按钮可以查看某个负载生成器的具体设置。选中某个负载生成器，点击禁用按钮，可以禁用负载生成器。u Vuser：点击Vuser按钮，弹出Vuser的监控页面。如图40：图表 40 Vuser监控页面 该页面中可以监视各个Vuser的状态，所属的脚本，所属的负载生成器，和已用时间。并且能够控制某个或某些Vuser的运行，逐渐停止，停止。还可以在线添加新的虚拟用户。是在线监控虚拟用户的有效工具。u 添加组：可以理解为添加一个的脚本。点击该按钮能够弹出组添加页面，如图41图表 41 添加组 该页面中提供了，组命名、Vuser数量定义，负载生成器选择和脚本选择。设置完成后，会向方案组列表中增加一条新的记录。u 删除组：在方案组列表中选中一条组记录，点击删除组按钮，能够删除该选定组。u 运行时设置：在4.3.1Run Time Setting设置中，介绍过Generator中调试脚本的运行时设置。这里的运行时设置内容和前面介绍的完全一样。但不同的是，这里设置的运行时设置是控制场景中脚本运行的，而不是用于脚本调试的。u 详细信息：点击可查看某选中方案组的详细配置信息。u 查看脚本：点击可打开Generator查看某选中方案组所包含的测试脚本。在方案组的上方，有“编辑计划”的按钮，点击弹出编辑计划窗口，如图42：图表 42 计划生成器生成器中包含“按方案”和“按组”两种计划模式。但两种计划模式都包含“加压”，“持续时间”，“减压”三个Tab页。“加压”中的设置，是设置各虚拟用户运行的次序和方式。一种方式为同时加载所有Vuser；一种方式为指定时间和数量，表示在每隔指定的时间，加载指定的虚拟用户数。“持续时间”是所有的虚拟用户全部加压后的运行时长设置。其中“运行直到完成”是指当虚拟用户全部启动后，让虚拟用户运行方案组中脚本在运行时设置里定义好的“迭代次数”直到完成；“运行时间在加压完成后”是让测试员自己定义完全加压后脚本运行的时间，可以验证系统在完全负载的情况下运行指定时间的性能表；“无限期运行”是让员工手工控制脚本的停止，否则就一直运行下去。“减压”是指虚拟用户运行结束退出运行状态的方式设置。可以“同时停止”，也可以设置时间和数量，指定每隔多少时间停止多少用户。但是“减压”的所有设置项必须要“持续时间”选择