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.一旦分析完毕，可以将结果导出到网页作为测试报告