LoadRunner

LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。

LoadRunner进行各种测试的入口，包括三大模块：

.Create /Edit Scipts：进入Mercury Vitrual User Generator 模块，用于创建和编辑脚本。

.Run load Tests：进入Mercury LoadRunner controller模块，用于创建运行和监视场景。

.Analyze load Tests：进入Mercury LoadRunner Analysis模块，用于分析测试结果。

LoadRunner进行测试的过程：

1）制定性能测试计划，测试计划中应该包括实际的设计，场景的设计。

2）录制测试脚本

3）创建运行场景

4）运行测试

5）监视场景

6）分析测试结果

LoadRunner 的脚本录制：

一）进入Vvitrual User Generator模块 创建脚本选择协议
二）录制脚本

1）选择菜单Vuser /start Recording或从工具栏上直接点击Record按钮，弹出录制对话框。

URL：输入测试网站首页（http：//mail.163.com)

Recording into action ：将脚本录制到哪个action中（默认不变）（Vuser Init，Vuser End，Action，其中Vuser Init，Vuser End一般用于存放应用程序初始化和关闭时的脚本，这两处脚本只能执行一遍，Action中存放的是实际的主体脚本，可以多次运行，测试人员可以多次创建Action脚本。）

2）点击ok按钮开始录制，这时LoadRunner 会自动打开mail.163.com网站，并弹出录制工具栏，所做的任何操作都会被录制下来。

3）在mail.163.com网站上输入用户名和密码，点击登录按钮，直到登录后的界面完全显示后再点击工具栏上的停止按钮。这时主界面上会显示自动生成的脚本。

LoadRunner 脚本是类C语言，一般不需要测试人员从头到尾编写， 只需要在录制的脚本上写该就可以。

录制成功后点击工具栏上的运行按钮，就可以运行一遍脚本，运行完毕会自动生成一个报告。

三）编辑脚本

一般情况下编辑脚本包括插入事务、插入集合点、插入注释、插入检查点、插入函数、插入脚本参数化、关联等。

1）插入事务

事务（Transaction）就是一系列相关联操作的集合。上面录制163 邮箱等脚本，虽然能够记录整个过程时间，但不是登录的准确时间，而是多个事务的时间总和，包括登录网页载入到浏览器的时间，输入用户名和密码的时间，以及在操作过程中的思考时间。而登录的准确时间应该从点击“登录”按钮那一瞬间开始计时，到登录后的页面完全显示出来的时间间隔。若要将这一段时间分离出来就需要为登录操作单独创建一个事务。具体方法如下：

在输入完用户名和密码后，点击登录按钮之前，点击工具栏上的“插入事务开始点”按钮，或选择Insert /Start Transation菜单命令。系统会弹出一个事务对话框，在对话框中 输入事务名（事务名最好要有意义）。插入事务开始点后，需要在操作结束之后点击“插入事务结束点”

2）插入集合点

什么是集合点，为什么要插入集合点？ 还是以163邮箱为例，LoadRunner 可以创建多个虚拟用户同时访问系统，比如创建20个用户并发登录163 邮箱，但并发的意思是20个 用户同时访问mail.163.com网页，而不是整个登录过程都是同时进行的，也就是说并发仅仅只体现在开始执行的一瞬间，随着时间的推移和系统环境的限制，20个用户操作就不同步了。那么如果想测试20个用户同时点击“登录”按钮，方法就是插入一个集合点。

具体方法:就是在输入完用户名和密码之后，点击登录按钮之前，点击工具栏上的插入集合点按钮或选择Insert /Rendezvous菜单命令，系统就会自动 弹出插入集合点对话框，在name文本框中输入集合点名称（集合点名称也要有意义）

关于集合点的两点注意事项：

.可以同时插入事务开始点和集合点，无顺序要求

.集合点只能插入到action部分。

3）插入注释

插入注释最好在录制过程中进行。具体方法：在需要插入注释的前面，点击“插入注释按钮”或选择Insert/comment菜单命令。注释在脚本中以/* */来标识，我们也可以在脚本中直接添加注释。

4）插入检查点

检查点功能：主要是验证网页上是否存在指定的text或者image。具体方法：

.找到检查页面（最好切换到Treeview视图）

.在Treeview视图左边的列表中选择一个页面，鼠标右击，选择右键insert before或insert after，弹出插入检查点的对话框

.如果想测试 web网页的图像，就选择image check命令，如果想测试web网页的文本，就选择text check命令，点击ok，弹出设置检查点对话框

.在search for中输入要搜索的字符串

.点击“确定”按钮后在step name中给该操作起个名字

如果想让系统运行时检查点起作用，还需要设置一个选项，方法是选择“Vuser/Runtime settings/preferences”菜单命令，在弹出的对话框中勾选Enable Image and text check复选框。

5）插入控制语句和函数

6）参数化输入

参数化输入是LoadRunner 高级使用技巧

我们在登录系统的时候，需要输入用户名和密码，如5个虚拟用户同时登录系统，则这5和用户都用这一组用户名和密码同时登录，这与实际是不相符的，如果禁止同一用户重复登录则系统就无法测试了。所有需要构造不同的用户名和密码，也就是实现用户名和密码的参数化。

   说明：

       1、集合点：插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据，从而达到测试计划中的需求。

　
　　2、事务（Transaction）：为了衡量服务器的性能，我们需要定义事务。比如：我们在脚本中有一个数据查询操作，为了衡量服务器执行查询操作的性能，我们把这个操作定义为一个事务，这样在运行测试脚本时，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时，直到运行到该事务的结束点，计时结束。这个事务的运行时间在结果中会有反映。插入事务操作可以在录制过程中进行，也可以在录制结束后进行。LoadRunner 运行在脚本中插入不限数量的事务。问题：事务的start_transaction与end_transaction是否可以嵌套？
　
　　3、参数化输入如果用户在录制脚本过程中，填写提交了一些数据，比如要增加数据库记录。这些操作都被记录到了脚本中。当多个虚拟用户运行脚本时，都会提交相同的记录，这样不符合实际的运行情况，而且有可能引起冲突。为了更加真实的模拟实际环境，需要各种各样的输入。参数化输入是一种不错的方法。
　
　　4、参数化包含以下两项任务：

　　① 在脚本中用参数取代常量值。

　　② 设置参数的属性以及数据源。（注：不是所有的函数都可以参数化的。）
　
　　5\参数的类型。

　　DateTime：很简单，在需要输入日期/时间的地方，可以用DateTime 类型来替代。其属性设置也很简单，选择一种格式即可。当然也可以定制格式。

　　Group Name：暂时不知道何处能用到，但设置比较简单。在实际运行中，LoadRunner使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name将会是None.  

　　Load Generator Name：在实际运行中，LoadRunner 使用该虚拟用户所在Load Generator 的机器名来代替。

　　Iteration Number：在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来替。
　
　　Random Number：随机数。很简单。在属性设置中可以设置产生随机数的范围

　　Unique Number：唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。

　　（注意：使用该参数类型必须注意可以接受的最大数。例如：某个文本框能接受的最大数为99.当使用该参数类型时，设置第一个数为1，递增的数为1，但100 个虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。注意：这里说的递增意思是各个用户取第一个值的递增数，每个用户相邻的两次循环之间的差值为1.举例说明：假如起始数为1，递增为5，那么第一个用户第一次循环取值1，第二次循环取值2；第二个用户第一次循环取值为6，第二次为7；依次类推。）

　　Vuser ID：设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是 –1.

　　File：需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据

　　User Defined Function：从用户开发的dll 文件提取数据。就目前我认为，这种方式没有必要。VuGen 支持C 语言的语法，在VuGen 中重新编写类似的函数应该不难。问题：是否可以对参数化File类型时，只建一个连接，就是说用select * from tableName 后得到一个表，而这个表中的许多列都可能在参数化过程中用到，如用户名\密码两列，是否可先用select * from userTabel 得到数据库中的全部数据，然后将不同的参数进行参数化就方便多了，而且可用相同的设置。
　
　　（注意：在参数数据显示区，最多只能看到100 行，如果数据超过100 行，只能点“Edit”按钮，进入记事本看。）

　　Sequential：按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取

　　Random：在每次循环里随机的读取一个，但是在循环中一直保持不变

　　Unique ：唯一的数。

　　（注意：使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行5 次循环，那么编号为1 的虚拟用户取前5个数，编号为2 的虚拟用户取6-10 的数，依次类推，这样数据表中至少要有100个数据，否则Controller 运行过程中会返回一个错误。）

　　Same Line As 某个参数（比如Name）：和前面定义的参数Name 取同行的记录。通常用在有关联性的数据上面。　
　　6、检查点为了检查Web 服务器返回的网页是否正确，VuGen 允许我们插入Text/Imag 检查点，这些检查点验证网页上是否存在指定的Text 或者Imag，还可以测试在比较大的压力测试环境中，被测的网站功能是否保持正确。推荐最好能在录制过程中添加Text/Imag 检查点。（注意：这里要搜索的字符串可以使用正则表达式。）
　
　　7、可以调试脚本，比如在脚本中加断点等，操作和在VC 中完全一样

　　8、运行场景描述在测试活动中发生的各种事件。一个运行场景包括一个运行虚拟用户活动的Load Generator 机器列表，一个测试脚本的列表以及大量的虚拟用户和虚拟用户组。创建运行场景使用Controller.

　　9、优化Controller 和Load Generators 计算机如果控制机（Controller machine）和Load Generators 计算机运行的都是Windows2000，那么下面两个简单的技巧可以提高性能1）在Load Generators 计算机上，依次进入“控制面板”——“系统”——选择“高级”标签页，点“性能选项”按钮，选择优化“后台服务”选项，这样可以提高性能，从而可以在每个Load Generators 上运行更多的虚拟用户2）在Controller 计算机上，按照以上的步骤，进入“性能选项”窗口，不过这里选择优化“应用程序”
　
　　10、用于运行 Vuser 脚本的 C 解释器仅支持 ANSI C 语言。它不支持 Microsoft对 ANSI C 的任何扩展。
　
　　11、常用方法lr_set_transaction_status 设置打开事务的状态lr_set_transaction_status_by_name 设置事务的状态
　
　　lr_stop_transaction 停止事务数据的收集lr_stop_transaction_instance 停止事务（由它的句柄指定）数据的收集
　
　　lr_get_host_name 返回执行 Vuser 脚本的主机名lr_get_master_host_name 返回运行 LoadRunner Controller 的计算机名
　
　　lr_save_datetime 将当前日期和时间保存到参数中
　
　　lr_eval_string_ext 检索指向包含参数数据的缓冲区的指针lr_eval_string_ext_free 释放由 lr_eval_string_ext 分配的指针
　
　　lr_debug_message 将调试信息发送到输出窗口lr_error_message 将错误消息发送到输出窗口

　　lr_get_debug_message 检索当前消息类lr_log_message 将消息发送到日志文件lr_output_message 将消息发送到输出窗口lr_set_debug_message 设置调试消息类lr_vuser_status_message 生成带格式的输出，并将其写到 ControllerVuser 状态区域lr_message 将消息发送到 Vuser 日志和输出窗口
　
　　lr_peek_events 指明可以暂停 Vuser 脚本执行的位置lr_think_time 暂停脚本的执行，以模拟思考时间（实际用户在操作之间暂停以进行思考的时间）lr_continue_on_error 指定处理错误的方法lr_rendezvous 在 Vuser 脚本中设置集合点

lr关联: 手工关联和自动关联

简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。
VuGen提供二种方式帮助您找出需要做关联（correlation）的值：
自动关联
手动关联

一 手工关联
lr8.0之前的实现原理是: 在客户端和服务端之间设置一个proxy,拦截client和server之间的数据,产生脚本,当然是根据所选定的协议和端口.正因为如此,写在脚本中的,我们模拟客户端对服务端的通信数据是死的,有些情况下会失效,所以需要关联.
所以说,关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。举个例子,有些服务器和客户端对话的流程是这样的,首先,客户端首先发送一个消息,服务端分配一个sessionid,以后,每次客户端发送消息时,都需要带上这个sessionid.
关联可以讲 是一个特殊的参数化,只是数据来源不同,普通的参数化数据来源于文件\数据库等,关联的数据来源于服务器动态产生.
要对付这种服务器，我们必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到Session ID的部分，这样就可以成功骗过服务器.

关联（correlation）函数
关联（correlation）会用到下列的函数：
web_reg_save_param：这是最新版，也是最常用来做关联（correlation）的函数。
语法：
web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );
web_create_html_param、web_create_html_param_ex：这二个函数主要是保留作为向前兼容的目的的。建议使用 web_reg_save_param 函数。

手动关联的执行过程大致如下：
使用相同的业务流程与数据，录制二份脚本
使用WinDiff工具协助找出需要关联的数据
使用web_reg_save_param函数手动建立关联
将脚本中有用到关联的数据，以参数取代

检查脚本哪些地方的错误是因为关联引起的,run time setting 中设置data returned by server
确定哪些数据需要关联
找出动态数据的左右边界值和出现位置
脚本中添加web_reg_save_param函数
在脚本中参数化脚本中的动态值
校检动态数据

找位置
检查脚本哪些地方的错误是因为关联引起的,run time setting 中设置data returned by server,运行,肯定出错,查看出错函数,如request form. was not fount错误信息,有可能是因为关联引起的.找到这个函数,我的一次实践是在web_submit_data()函数.
因为这个sessionid是不同的,所以我们使用相同的操作和数据录制两个脚本,使用tools中的compair with user,比较两个不同的脚本,注意,这个工具是按照action来比较的,同时注意：请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间.保存的文件名太长或者有中文的情况下,会出错.
找出所有不同的地方,再做分析.

使用web_reg_save_param函数手动建立关联
web_reg_save_param要放在提交数据的函数之前,是最近的位置.
在树形图的server中找到 web_reg_save_param中要用到的边界
web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串，来辨识要撷取的动态数据的，所以我们还需要找出动态数据的边界字符串。这里要注意的是"要用\做转义字符.

将脚本中有用到关联的数据，以参数取代
当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的（hard-coded）资料。
将
“Name=userSession”, “Value=123456879”, ENDITEM,
换成
“Name=userSession”, “Value={UserSession}”, ENDITEM,
语法
int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
参数说明
ParamName:存放动态数据的参数名称
list of Attributes:其它属性，包含 Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及 SaveLen。属性值不分大小写，例如 Search=all。以下将详细说明每个属性值的意义:
Notfound:指定当找不到要找的动态数据时该怎么处置。
Notfound=error:当找不到动态数据时，发出一个错误讯息。假如没设定此属性，此为LoadRunner的默认值。
Notfound=warning:当找不到动态数据时，不发出错误讯息，只发出警告，脚本也会继续执行下去不会中断。在对脚本除错时，可以使用此属性值。
LB:动态数据的左边界字符串。此属性质是必须要有的，而且区分大小写。
RB:动态数据的右边界字符串。此属性质是必须要有的，而且区分大小写。
RelFrameID:相对于URL而言，欲搜寻的网页的Frame。此属性质可以是All或是数字，而且可有可无。
Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分，不搜寻header)、Noresource(只搜寻body部分，不搜寻header与resource)或是All(搜寻全部范围，此为默认值)。此属性质可有可无。
ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无，默认值是1。假如值为All，则所有找到符合的数据会储存在数组中。
SaveOffset:当找到符合的动态数据时，从第几个字符开始才开始储存到参数中。此属性质不可为负数，其默认值为0。
Convert:可能的值有二种:
HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式
HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式
SaveLen:从offect开始算起，到指定的长度内的字符串，才储存到参数中。此参数可有可无，默认值是-1，表示储存到结尾整个字符串。

  看一个男人的品味，要看他的袜子。
　看一个女人是否养尊处优，要看她的手。
　看一个人的气血，要看他的头发。
　看一个人的心术，要看他的眼神。
　看一个人的身价，要看他的对手。
　看一个人的底牌．要看他身边的好友。
　看一个人的性格，要看他的字写得怎样。
　看一个人是否快乐，不要看笑容，要看清晨梦醒时的一刹那表情。
　看一个人的胸襟，要看他如何面对失败及被人出卖。
　看两个人的关系，要看发生意外时，另一方的紧张程度。

测试工程师最开心的事:发现了一个很严重的bug,特别是那种隐藏很深,逻辑性的错误.偶第一次发现这种问题的时候,听到上司和开发人员的表扬时,高兴的就想扭pp.不过现在慢慢矜持些了,呵呵.

　　测试工程师最提心吊胆的事:版本release出去后,客户发现了很多或很严重的bug.经过紧张的系统测试之后,好不容易可以轻松一下了,却又陷入了每天担心正在做验收或使用的客户一封邮件或一个电话说产品有问题.碰到好些的老板还会比较乐观的看这样的问题,最惨的就是有些人一顿臭骂,之前的辛苦,加班全部都给抹杀了.

　　测试工程师最憎恨听到的话:"为什么这个bug没有在测试的发现呢?"这句话经常是客户发现bug后,老板对测试人员的质问.当然这里排除那种很明显的错误.其实谁都知道bug是不可能全部发现的,这句话其实也是客户对大头,大头对小兵一级一级问下来的.除了希望测试人员警惕之外,还有更多的是一种"踢猫"的行为.对于这句话,偶第一次听到这句话的反映是"我们怎么可能发现所有的bug呢",后来变成"制造bug的人不是我们,是开发",到现在的"让我查查我的日志,问问开发这个bug的原因,为什么我们会没有找到,下次我们会怎样"的回复.

　　测试工程师最郁闷的事:"刚才那个版本打包打错了,你们要重测".新版本来了,马上投入紧张的测试,希望能够多找些bug.没想到辛苦了可能大半天,开发人员说打包打错了,你重测吧.这种情况虽然可以通过规范流程之类的办法控制发生的机率,但人总会犯错,多少而已.碰到这样,你除了提醒开发部门下次注意,你除了重测没有太多办法.

　　测试工程师最不想面对的事:在测试晚期或最新的版本里发现了以前一直存在的问题,特别是当问题很严重时决定到底报不报bug.报吗,开发人员肯定会问以前有没有这个问题,不报吗,客户发现更惨.毕竟客户或老板的责备比开发部门或主管的责备轻许多,最后还是会报到bug库里的.

　　测试工程师最不想做的事:申请版本推迟发布.由于在版本发现了太多的问题,觉得产品不能达到发布的标准,建议公司推迟发布产品.这时虽然大家都知道产品有问题,尽管你自己也不希望这样,但谁都觉得你是一个制造麻烦的人,毕竟市场的压力很大呀.

　　测试工程师最丢人的事:辛苦的发现了一个bug,居然是该配的参数没有配等一些自己的失误造成的.有些该注意的地方居然测试时忘了,找出的问题给开发人员一顿臭扁,无比丢人啦.

　　测试工程师最怕的事:一天,甚至几天都没有发现一个bug!经过一段时间的bug高峰期后,有段时间会发现bug数量的减少,最可怕的就是一天都没有发现一个bug.偶有时会难过的吃饭都没心情.搞得偶的开发朋友说了一句最让人吐血的话:"要不要我在代码里放几个bug给你呀,hoho"

　　测试工程师最伤心的事:每年的调薪,发bonus或发股票时,测试工程师总比开发工程师少.偶有一同事在调薪的第二天就申请转开发,说测试太没前途了.

　　测试工程师最有力的保护方法:把你认为是bug的问题都提交到一个正式的,可以追踪的地方(一般来说是bug库).有时总会碰到一些很小的或是很难判断的问题,犹豫一定是否要报,特别是一些UI的问题.有时问开发人员,他们可能会轻描淡写的回复你导致你没有report它.但多年的经验一定要报,了解bug流程走向的人都知道,后面还有人verify,还有开发经理判断,如果不是bug,自然他们会回复,会写明原因.说白了,出了问题也不是你的事情.当然一开始经验不足时会收到一些白眼球,但慢慢经验多了,对系统熟悉了,自然这种情况会少些.人也可以从一些问题中发现自己的弱点.但如果不报,那天客户提出来,你除了懊悔还要面对指责,严重的炒鱿鱼.

　　测试工程师最任重道远的事:测试驱动开发.碰到这种开发模式的项目,既是测试扬眉吐气的机会,也是可能会陷你于深渊的恶潭.你就必须打起十二分的精神.等于你在引导开发,有什么问题一定要提出来,否则你就等着被盲目的牵着鼻子走了.

　　测试工程师最期待的事:测试能够越来越受重视,测试工程师的考核越来越合理.