一、明确性能测试的范围

例如：以iptv系统为例，是需要测试bss页面、中间件具体接口、boss/crm具体接口

二、明确性能测试的指标

例如：

1、支持最大并发用户数是多少？（压力测试）

2、每秒n个用户并发，能正常持续运行多久？（负载测试）

3、在系统用户为n个的情况下，每秒x个用户并发，持续运行y分钟，查看系统硬件io、cpu、内存；查看软件平均吞度量、tps、平均响应时间、事务成功率、事务失败率、错误率等（性能测试）、

响应时间：事务从开始到完成所花费时间

平均吞吐量：指单位时间内系统处理用户的请求数

TPS：transaction per second 服务器单位时间处理的事务数 （事务数/运行时间s）

事务：指访问并可能更新数据库中各种数据项的一个程序执行单元。例如订购操作，它含有多个请求

事务成功率：成功事务数占完成总事务数的比率

事务失败率：失败事务数占完成总事务数的比率

三、定义数据模型

1、目标系统用户数、目标每秒并发数、硬件系统配置情况，如下：模板

IPTV-BSS 性能指标.docx

四、设计性能测试方案

IPTV BSS四川电信版本性能

五、搭建性能测试环境

1、尽可能模拟现网的环境与组网结构

2、前台应用和后台数据库安装在独立干净的服务器上。

3、当前性能测试环境分别为：192.168.12.11（前台） 192.168.12.31（数据库）192.167.12.177（Loadrunner）

六、构造性能测试数据

1、使用LR 、QTP自动化工具构造（比较慢，不需要了解表结构，但是需要了解业务流）

2、编写存储过程构造用户、包月、订购数据（比较快，需要对相关表结构和数据库了解）

七、录制、调试测试脚本

1、中间件接口目前是web services协议，因当前测试指标均超过100个并发，故使用web（http/html）协议录制。中间件接口录制页面：

2、boss接口当前有两种协议，一种是web services协议，一种是sockets协议，因当前测试指标最大为100个并发，故可以使用web services协议或http/html协议录制。

3、bss页面基于ie运行，故使用web（http/html）协议录制。

注明：当前中间件接口，四川boss接口，浙江电信bss部分页面均有现成的脚本，如果其它局点需要测试可使用原有的脚本调试即可。

详细参考：LoadRunner性能测试_刘双林_20xx0115.doc 2.3/2.4章节 进行学习

八、执行性能测试场景

1、按照测试方案文档中的测试用例执行即可。

2、在执行性能测试过程中会具体使用到性能测试工具LR。 关于性能测试工具的使用方法网上有大把资料。请自行学习：场景设置、参数化等

详细参考：LoadRunner性能测试.doc 3章节 进行学习

九、监控并记录性能测试结果

1、硬件性能：bss应用服务器cpu、内存；数据库服务器cpu、内存、io

内存、cpu 不高于70% ；IO不高于80% 否则可能存在性能瓶颈

统计方式：

（1）通过命令在服务器上查询

内存 sar -r 5 120 （每5s刷新1次共刷新120次）

cpu sar -u 5 120

io iostat 5 120

（2）在服务器上安装rpc.rstatd工具，通过LR客户端窗口监控记录

2、软件性能：平均吞度量、tps、平均响应时间、事务成功率、事务失败率、错误率等（场景运行完毕可通过loadrunner工具导出性能测试结果），是否达标是要与性能测试指标进行比对。

详细参考：LoadRunner性能测试.doc 4章节 进行学习

十、分析性能测试结果输出总结报告

1、将实际测试结果和性能测试指标进行对比，总结出不达标测试对象及具体测试数据

2、测试与开发人员根据性能测试数据，从硬件环境和软件本身进行分析。例如：优化硬件配置、软件处理逻辑、数据库架构脚本等。

3、具体分析的方法：一般是具体问题具体分析，查找瓶颈时按以下顺序，由易到难。

（1）服务器硬件瓶颈

（2）网络瓶颈(对局域网，可以不考虑)

（3）服务器操作系统瓶颈(参数配置)

（4）中间件瓶颈(参数配置，数据库， web 服务器等)

（5）应用瓶颈( SQL 语句、数据库设计、业务逻辑、算法等)

注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对

一些要求低的，我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下，系统的硬件瓶颈在哪儿就够了。

十一、LoadRunner性能测试工具操作文档

LoadRunner性能测试.doc

loadrunner8.1教材.pdf

 

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

第一步：计划测试

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 execution”让它每次自动累加，不建议选中“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”类型不相符。

7、 在“Run-time Setting”设置中，“General”中的“Pacing”非常有用，可以设置每次迭代

之间相隔多少时间，也可以是随机的取值

8、 建议：把“Parameter List”和“Run-time Setting”中的所有设置都搞熟悉，这样便于以

后对脚本和场景进行设置

9、 设计“Parameter List”时的小技巧：即在“Allocate X values for each Vuser”时，尽量

把它的间隔在数据容许的范围内取大些，这样可以做从一次迭代到最大值迭代，而且对脚本没有什么影响

10、当一个脚本中有多个事务，在事务前面增加集合点时需要一点技巧。或者我们把脚本复

制几个，或者我这样做：测试前面的事务的压力时，把后面的事务前的集合点设置为不激活状态；在测试后面的事务的压力时，把前面的事务的集合点设置为不激活状态，另外最好不选中Initialize all Vusers before Run，具体参见Controller中的“Scenario/Rendezvous”，及用户手册(按F1)

11、把持续时间从最后60秒改为整个场景的时间，右键单击某个图，选择“Configue”，修 改Graph Time即可

12、每次从一个场景修改后保存为另一个场景时别忘记把结果保存文件名修改相对应的文件名。在设置结果保存文件名时有一个技巧：如果你打开这个窗口时，点击确定则系统会

默认以“4场景2”为基点向后加“4场景20”“4场景21”等等，但是如果你把结果文件名后面的数据去掉，改为“4场景”，点击确定后，系统会自动搜索是以“4场景”开头的文件名，并在它的后面继续增加，比如把它改为“4场景”时，下次结果保存在“4场景3”中。而且他在搜索的时候搜索以“4场景”开头的文件名，从0开始，有的话就不取代而跳过，没有的话就取代。

第四步：运行场景

1、 运行场景前需要注意的事项：每个组的虚拟用户数、迭代次数、think time、参数化时的

取值间隔、执行恢复数据的脚本、确认虚拟机的LoadRunner Agent Service打开

2、 如果监测Unix，运行场景前需要启动监测Unix进程，启动的命令“rpc.rstatd”、查看这

个进程是否启动的命令“rpcinfo –p”

3、 运行前使Generator机器处理Ready状态

4、 确认被监测的机器已经连接上去，并且添加自己所需要的计数器

5、 运行之前一定要确认系统中压力点的数据量是多少

6、 确认以上都正确时再运行测试场景

第五步：监视场景

1

、打开

Transactions”，可以随时观察到事务的运行状态 “Passed Transactions”或“Failed

第六步：分析测试结果

1、 打开Analysis后，把经过数据处理的结果图表保存到“图表”文件夹，并且文件名和场

景名、结果名相同，这样便于以后的查阅。也可以省去每次进行数据处理的时间。

2、 可以通过点击界面上的“View Run Time Setting”可以看到此场景运行时的一些场景

设置

3、 在关联图表时可以自动调节每个元素的比例，点击右键，选

择

即可

4、 每次测试结束后确认所做的操作是正确的，确认正确后再分析结果

5、 在结果文件夹中为每个场景建立一个文档，把每次运行时的情况记录下来以便于写测试

报告，尤其运行错误的原因记录下来，并把开发人员所做的修改也记录下来以便知道开发人员做了些什么修改

6、 在分析运行结果时可以把几个结果合在一起进行比较，打开如下“Cross with Result…”

即可，然后增加一个运行结果，这样就可以把你所需要的结果放到一起比较了