教程贴士：明确压力点，根据压力点设计多少种场景组合

第一步：计划测试

1、明确压力点，根据压力点设计多少种场景组合

2、把文档(包括多少种场景组合、场景与场景组合条件的对应表)写好

3、如果监测UNIX机器，在被监测的机器需要安装监测Unix的进程

4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据

5、让开发人员做一个恢复数据的脚本，以便于我们每次测试的时候都能够有一个相同的环境

6、针对每一个模块包括四个子文件夹：如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹，每个子文件夹储存对应的文件，如下表所示

其中：结果名“1场景”是在场景中的“Results Setting”中设置的，具体的设置见“建立场景”部分，这里也可以有另外一种方法：在打开模板设置，如下：

选中“Automatically save the session as:”并且在“%ResultDir%”后面填写你想保存的文件名，当你打开某个lrr文件时，系统自动在当前目录中生成一个文件保存分析图表，如下图所示：

第二步：生成测试脚本

1、 把登陆部分放到“vuser_init”部分,把需要测试的内容部分放到“Action”部分执行;但是如果是模拟多个用户登陆系统，则要把登陆部分放到Action部分来实现

2、 录制脚本后，想查询某个函数的原型，按“F1”键

3、 确认脚本中哪些参数是需要进行参数化的(最好能可以和开发人员一起确认)

4、 在脚本参数化时把函数web_submit_data()中的ITEMDATA后面的数据参数化，因为这些数据是传递给服务器的，当然也可以把一个函数中的所有相同变量都替换掉

5、 脚本中无用的部分用“/*”“*/”“//”注释掉，但最好不要删除

6、 调试脚本遵循以下原则：

确认在VU里SUSI(单用户单循环次数single user & single iteration)

确认在VU里SUMI(单用户多循环次数single user & multi iteration)

确认在controller中MUSI(多用户单循环次数multi user & single iteration) 确认在controller中MUMI(多用户多循环次数 multi user & multi iteration)

7、 事务的名称取的有意义便于事务之间的区分，把所有的事务名都记录在一起，便于在测试结果概要中区分它们，这要写成一个表：某次测试有哪些模块，每个模块中有哪些事务(见对应的“关系表”)

8、 在 “Parameter List”中可以选择参数类型“Random Number”，使某一个参数取设定的范围内的随机值

第三步：建立场景

1、 把场景名称编号，并制定出一份场景名称和场景条件组合的对应表。比如，场景m对应于“某一模块_xx个vu _分z台machine”(见“关系表”中的例子)

2、 根据上面的对应表把场景设置好，需要设置的要素如下：总体多少个用户、分多少个组、每个组有多少个用户、分几台机器运行、每个脚本迭代多少次、是否回放think time时间、检查Parameter List中每个参数设置是否正确、参数从表中取值间隔是否正确、是否选中“Initialize all Vusers before Run”

3、 测试结果应该保存为“m场景0，m场景1,…”

4、 把虚拟用户分散到几台机器上和在一台机器上面都要进行测试，因为有可以效果不同

5、 场景中如果有需要改动的地方，必须新建一个场景(建议使用“另存为”，然后再修改结果文件名，再选择相应的脚本)，并把场景按顺序编号，先维护好场景与场景组合条件的对应表，以便以后的查找，并且在结果 “Results Setting”中设置的结果名与场景名相同。建议在“Results Setting”中选中“Automatically create a results directory for each scenario executeon”让它每次自动累加，不建议选中“Automatically overwrite existing results directory without prompting for confirmation”，因为我们不要覆盖掉以前的测试结果，把它保存下来以便有个根据。

6、 需要注意的地方：当在“Parameter List”中的“Select next row”选中“Unique”时，如果再在“Edit Schedule\Schedule by Scenario\Duration”中选中第二项“Run for XX after the ramp up has been completed”时系统就会报错，提示“Unique”类型不相符。

第二篇：Oracle的性能测试经验总结

前段时间，在阿里妈妈新机房压力测试过程中用到了LR测试ORACLE，跟DBA一起在杭州网通新机房进行1000用户的压力模拟测试。整个压力测试耗时两天。以下是一些经验：

1）压力测试过程中发现一些SQL脚本执行非常慢，进行了优化。

2）最好并发测试，否则服务基本上没有什么压力。

3）先从100用户开始，再慢慢向上加，直到CPU的承载达到90%以上。查看系统的性能情况，包括TPS，响应时间，和内存等。

还包括oracle服务器的I/O流量和交易数。

这个方案是参考了淘宝的机房性能测试方案，下面是性能测试的具体步骤：

oracle的性能测试主要是模拟大量的sql语句操作，来对数据库服务器进行加压。在测试前，需要准备以下要模拟的sql语句，测试脚本，并将测试控制机、测试加压机、被测数据库服务器准备妥当。

脚本协议选择oracle（2-Tier），将所有要模拟的sql语句放在一个sql文件内，使用sql-plus来操作数据库载入，使用 loadrunner来录制。录制好之后就是修改脚本了，首先在vdf.h文件中定义变量（static void FAR * OraBind1;），定义参数(

static LRD_VAR_DESC UID =

{LRD_VAR_DESC_EYECAT, 1, 10, LRD_DBTYPE_ORACLE, {1, 1, 0},

DT_SF_STRIPPED_SPACES};)。

为什么要在这里定义而不直接只用参数化呢？因为那样会对加压机造成很大的压力，不利于测试。这里需要根据你的脚本来变化，你在脚本中使用了多少变量，多少参数，那么你就在要这里定义多少。接下来修改脚本的，将一次性的登陆登出放在init和end中，使用lrd_assign和 lrd_ora8_bind_placeholder命令替代参数，如

lrd_ora8_stmt(OraStm6, "SELECT COUNT(*) as counter FROM ***** WHERE ***_id=" ":U and ( status = 0 or "

"status is null)", 1, 0, 0);

lrd_assign(&UID , "{UID}", "", 0, 0);

lrd_ora8_bind_placeholder(OraStm6, &OraBind1, "U", &UID , 0, 0, 0);

这样，脚本就差不多大功告成了。编译一下，没有问题就通过了^o^

将脚本放在控制机上，就可以开始加压了，注意的是，被测数据库服务器的各个参数配置要记录下来，以便修改参数调优时能分析清晰。记录下数据库的iops，time，tps和响应时间，结果汇总出报告。