工具介绍

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

10字真言：虚拟的用户，真实的负载

VuGen: 脚本录制工具

Controller:场景控制器

Analysis: 结果分析工具

经验总结

1.测试需求及目标

a.性能测试的第一步工作就是要“明确客户的需求“，这一阶段我称之为命题作文。作文如果跑题了即使长篇大论也无济于事。

b.这一阶段的参与者包括需求提出人员和测试人员，由于性能测试一般没有需求变更的情况，要求需求人员一定是比较权威。

c.一般来说，项目级性能测试客户自身会根据系统使用者范围（总用户数或在线用户数），系统使用环境（集中或分布），高峰作业量（并发用户）提出明确的要求，测试人员也可以提出一些供参考的经验值作为预期的目标。

d.如果系统测试属于产品测试，那么除了经验值目标外还应包含产品比对，这也是很多产品性能测试采用的一般模式。

e.性能测试的需求的大致分为两种：

一种是压力需求，要求××场景××并发用户下平均响应时间小于可接受值；

另一种是负载需求，要求××场景响应时间在××内支持××用户数。

二种测试的方法略有不同，但都能够通过测试工具简单操作完成切换。

2.测试设计

a.测试设计的原则：从简单到复杂

b.测试设计主要是测试人员根据测试目标准备测试方案和选取案例。

c.对于项目级测试，在测试需求中一般都会进行相关的说明，大多数情况下是将系统中关键业务处理场景作为性能测试案例，

d. 考虑到减少测试的复杂性，可以对业务场景中的测试案例进行进一步加工,比如实际场景中可能在一次请求中包含多次子操作（既查询，又修改），那么可以将这些操作拆分，这样更有利于分析结果数据，同时可以抛开业务操作功能之外的消耗（比如有些复杂页面包含很多查询结果，可以拆开分别进行测试，或者页面中包含较多的图片或flash也可以剥离出去，当然也可以利用测试工具中功能达到类似效果）

3.测试环境

a.测试环境＝硬件环境＋软件环境

b.测试环境在整个性能测试中是一个非常重要的工作。因为在测试报告中测试环境是最客观的指标，同时也是整个性能测试结果的基础

c.测试环境包括网络环境、硬件环境和软件环境。测试的服务器最好在同一个网段，硬软件最好和真实环境一致。说起来简单做起来难，在搭建环境的过程中一定要自己检查，尤其是软件环境涉及操作系统、应用服务器、数据服务器，更要做到完全一致，因为性能测试的数据都是上万级，结果数据往往相差都是毫秒级，一个小小的索引都会导致极大的差异。

4.脚本录制和测试工具

a.环境搭建好之后，可以开始录制脚本，录制脚本使用LoadRunner Virtual User Genorator工具，具体使用的方法网上有很多介绍，我的体会还是很容易上手，下面介绍一些经验和体会

b.事务设置

由于实际业务可能包括多个子操作，新增、查询、修改、删除。可以考虑使用事务分别进行监控，事务的使用也很简单，loadrunner的菜单栏提供加入事务功能。

c.参数变量和函数的使用

在测试中，我们可能需要录入一个随机数据或者一个枚举的顺序数据，比如业务场景中的数据主键可能一个日期＋唯一序列码，同时业务场景中主键是由系统程序（java代码）而不是数据库生成，这时候可以使用LoadRunner提供的参数来实现，参数被定义来自一个文件、一个随机数或者是一个顺序枚举，我仅尝试了后两种。（实际操作中定义参数后可以使用函数将参数和日期拼接成主键值）

d.Loadrunner提供一系列脚本函数，我使用其中的一部分，感觉还是很好用的。包括日志输出、数据转换、页面交互（以 Web_***开头的），尤其是在作删除事务的时候，由于需要取得新增数据的主键，可以考虑在新增数据后把主键值保存在页面，loadrunner会在请求的时候从返回数据中得到这个主键值并保存在脚本变量中，删除的时候可以使用这个变量来进行删除工作。使用 web_reg_save_param可以达到这个目的，比如 web_reg_save_param（”userid”,”LB=ABC”,”RB=EFG”,LAST）就是把返回页面中的正则匹配 ABC***EFG中的***保存在userid变量中，”LB”标志数据的左边界，同时”RB”标志数据的右边界，使用时同时要注意，这个函数相当于一个过滤器filter，所以一定要把它放在发出请求的事务前面。如果页面返回的数据比较多可以设置buffer值来增大返回数据的容量。

e.所有函数的用法都可以在工具提供的帮助文件中找到，个人体会比使用Google要好。

f.即使是测试本地系统，录制脚本的目标URL不要设置为http://localhost:7073/*.do或者http: //127.0.0.1:7073/*.do,而应该使用真实的本地ip。

g.运行结束后，LoadRunner会弹出一个测试结果窗口,同时运行时的页面还可以通过在LoadRimmer User Generator中切换察看树形视图进行检查。

h.通过检查数据库可以确认脚本是否按照预期进行了正确的数据操作。

i.在做关联的时候，应该从数据第一次出现的位置之前做关联，否则就会出现找不到数据的情况

5.测试计划及测试工具

a.脚本调试完毕，我们进入正式的测试工作，开始使用LoadRunner的控制台进行详细的测试计划编排和设置

b.关于如何使用控制台大家可以找到很多参考，我这里仅列出几点体会：

i.运行测试之前一定要先进行脚本验证，保证在无并发用户的情况下脚本能正确执行。

ii .运行测试一般设置测试运行的duration即可，但是为了对测试所执行的数据监控，也可以采取设置运行次数RunLogic来达到目的，比如并发用户 10个，每个用户运行10次，那么如果每个用户执行一次插入数据动作，最终应该产生100条数据。

iii.取消浏览器模拟browser emulation可以阻止测试中页面非测试数据的下载进而让测试结果更干净。

iv .no thinktime模式服务器压力比较大，如果是稳定性测试可以在事务间加入适当的thinktime，因为稳定性测试并不是压力测试。

v.并发用户较大时应该采用逐步增加用户的方式来执行计划（比如每隔15秒增加10个用户），执行计划时间一定要达到足够产生稳定的数据。（通过测试监控观察,可以在测试运行中随时增加新的用户来延长测试时间）

6.测试结果分析

a.测试分析是性能测试的最后一关，如果前面的工作没有失误的话，应该是水到渠成，可是大多数情况下我们还是需要对结果进行进一步分析，并调整我们的测试策略（包括环境、案例及脚本）

b.Loadrunner提供强大的测试分析工具－analysis，可以将测试数据提取出来进行事后分析。

c. 其中最重要的是响应时间response time和吞吐量(hps)，顾名思义，响应时间越小越好，吞吐量越高越好。当然资源消耗（CPU,MEMORY）越少越好。但是其实并不完全，对于一个系统来说，也要讲和谐，也既是所有的资源使用应该使用率应该保持一致。如果测试显示应用服务器CPU特别高,数据服务器特别低,那么系统运行肯定不正常，这时候需要检查是否网络正常，数据服务器是否有死锁等。

d.一般我们可以对测试结果做一点处理让数据更准确，比如设置过滤器去除不稳定数据，可以设置时间段截取稳定运行时间内的数据作为标本数据。

e.一旦分析完毕，可以将结果导出到网页作为测试报告。