呵呵，今天上班的时候心里面不住的打鼓，谁叫自己得了个宝呢。终于快到中午的时候忍不住，开始准备安装9.0。OK，从Mercury站点当下来的文件是一个单Exe自解压安装包。安装是不需要任何诀窍的，直接解压缩即可。

注意事项：
1、安装目录和安装文件目录都不要带中文，否则会出现拒绝访问的错误；
2、解压时如果遇到MolizzaFireFox插件拒绝访问的问题，请停止掉系统中的一些软件服务后再尝试，我遇到这个问题时最初是进入到安全模式下进行解压的。但是安装LoadRunner时仍然遇到这个问题，而安装LoadRunner是无法唉安全模式下完成的。所以我停止了McAfee、Oracle、无线网卡等相关软件的服务后，安装成功的。
3、使用破解文件，破解完成。

不过，没觉得比LoadRunner8.1多些什么东西，看来还要多试试才能了解，可怜我的8.1版本，才使用了5个月就被替代……

但是这桶水里面的容量总共只有9杯，倒完之后就要换水。所以第10个人等了20分钟才喝到水，因为他换水的时间比较长。（很象是JVM的垃圾收集）

这个例子里面，10个用户并发，并发同样的事务，分别需要1到20分钟。事务的最大响应时间和最小响应时间相差很大，那是什么原因呢？

可以从以下几个角度出发思考问题，发现原因所在。啥角度呢，就是问一下：有什么办法可以提高我的事务请求的时间呢？

1、增加饮水机；（类似于集群，效率提高是非常明显的）
2、增加饮水机容量；（类似于提高HeapSize了，在WebLogic中，提高HeapSize的另外一个代价就是GC的时间会变长，在GC这个时间段内，任务都是挂起的。废话，在换水的时候当然所有人只能等待了啊）
3、减少每个用户倒水的时间；（比如调整SQL语句，在历次的性能测试过程中，如果硬件条件不变的话，没有比这招更能带来效果的了）
4、减少每个用户请求的水资源；（比如优化业务逻辑，这需要测试人员对代码非常熟悉，目前能做到这点的恐怕还只有开发人员）
5、增加饮水机的出水率；（提高了单位时间内的ThroughOut，那TPS肯定是提高了）
等等；

性能测试场景：
每用户地址可开1000门电话，即1个用户地址下挂1000个号码资源；
并发用户数从400起，每5分钟增加10个用户直到满足以下三个条件时退出：
1、总体事务错误率在统计区间内的平均值首次大于1％；
2、服务器CPU负载在统计区间内的平均值首次大于80％；
3、被测系统任一服务器主机发生操作系统重启情况；

根据以上场景，和开发人员讨论、和预测试的经验，初步判断系统可并发用户为500左右，则系统运行时间为1小时左右，每装一门电话系统运行时间为10″钟左右，think_time设定为3*3＝9″钟，迭代次数预估计为180次，也不排除更多的可能性；
则计划需要20W条基础数据，数据建立规则如下：
号码段从99000001到992000000；
用户地址从“XX街道XX小区XX号13B000001”到“XX街道XX小区XX号13B002000”；
每分线盒下挂100个资源，分线盒资源编号从000001到000200；
用户端口、线对编号后六位从000001到200000；

由于参数量比较大，所需要参数化的内容也比较多，所以经过尝试后不打算使用参数文件或者从数据库读取参数的方式；
而是使用VUserID＋IterationNumber生成参数；
参数化的过程如下：
1、在系统参数中为脚本建立ParameteType为VUser ID 和IterationNumber的参数，分别使用％3S【NewParam_VUserID】和％3D【NewParam_ItrationNbr】；
2、将两个参数叠加，形成六位数字，作为基本参数；
3、当迭代数超过200时，VUserID＋500，IterationNumber－200，重新生成六位基本参数；
4、分线盒资源参数、地址资源参数通过基本参数的换算后得到；
所使用到的函数以及方法都是比较常用的，如下：
1、sprintf：合并两个参数，并将其保存为基本参数；
sprintf(ParamVI,"%s%s",lr_eval_string("{NewParam_ItrationNbr}"),lr_eval_string("{ParamVUID_Nbr}"));
2、lr_save_string：保存参数用；
lr_save_string(ParamVI,"ParamVI");
3、atoi：字符转数字；
4、itoa：数字转字符；
5、intlength：判断字符串长度；

当这样做了之后，会发现参数化的过程也变得非常简单，简单的将需要参数化的内容替换成{ParamVI}即可，为调试脚本和数据节约了大量的时间，也为测试结果打下了比较好的基础；

PS：总的来讲过程比较简单，但想法比较有意思，所以Blog出来希望给出指导建议。

>kill 254076（杀死进程）

>/usr/sbin/inetd（重启命令，其实就是上面ps命令查询出来的）

>ps -ef|grep inetd（验证一下是否启动）

这样子就可以直接在LR中监控了，选择UnixResource，Add Measurement，输入Unix机器的IP选择监控指标即可。

至于那些指标究竟表示的什么意思，其实很好理解了啊。不过还是不要以如下解释为准，先看一下LR的帮助手册里面的定义，然后再去专业网站上仔细看看吧。
CPU：CPU利用率；
AvLoad：最近一分钟内的系统平均负载；
PageRate：磁盘与内存交换数；

1、设置断点
    其实和很多开发工具一样，LR中也能设置断点，具体菜单在：Insert － Toggle BreakPoint；
    设置完断点后，当调试执行该脚本时，即会在该处停留，其后的步骤可以使用单步执行等。LR比较笨的是，断点是和行数绑定的，而不是和脚本。我经常在脚本的前面增加代码后，导致断点失位。我用的版本是8.0，不知道现在的新版本有没有改进这些问题。

2、增加Log
    一种办法就是手工打Log；
    我比较喜欢这样，但只是在需要调试参数的时候使用；在某一行写上类似于lr_log_message("getvalue:ParamVUID_Nbr %s", lr_eval_string("{ParamVUID_Nbr}"))这样，就可以了。执行到这一步骤时，会在日志中打出该参数的值，如getvalue:ParamVUID_Nbr 001001。
    另一个办法就是在RunTimeSetting中设置ExecuteLog了。
    分别有三种ExecuteLog。
    ParameterSubStitution：日志中显示每行脚本中执行时的参数；
    DataReturnByServer：日志中显示从服务端返回的值，这招在手工关联时非常管用；大家在手工关联需要动态获取服务端返回值的时候肯定都会去ViewTree的吧？但是有时候Tree不显示，告诉你：无法显示XML。这时候想要知道服务端究竟回给了哪些数据就可以使用这个ExecuteLog了。不过我现在也很懒，很少有耐心去打印这个日志，当我想知道服务端回给了哪些值的时候，我就直接去脚本目录查看data目录下的文件～～汗啊
    AdvancedTrace：日志中显示每行脚本中执行的函数以及参数；这个我用的时候觉得没啥意思。

3、被测系统日志
    有时候这样做需要有开发人员的协助；在VUGenerator模拟执行的过程中被测系统也可以在关键步骤中打印日志，这样可以更好的协助测试人员调试脚本。

不过大部分脚本调试起来都不会很麻烦，以上几个步骤完全是因为在广州做入网测试的时候，电信方要求过多，被逼出来的～