单交易基准测试

（以登录为例）
假设登录支持10分钟300用户登录，并发数不少于20个，响应时间不超过5秒，业务成功率100%，服务器CPU及内存资源使用率不超过80%
分成两个业务测试类型：并发测试、业务量测试（交易量）
并发测试：并发数20，系统至少有20个已存在的可用账户
业务量测试：10分钟300个用户，系统至少存在300个可用账户，需测试出单次登录消耗时间，从而计算出所需的vuser数量。

**测试步骤如下：

1.先测出单次登录所需时间
打开之前调试好的脚本flightlogin,由于要计算时间，所以先添加事务，如下图


运行后统计时间是7.9548秒，四舍五入取8秒。
1060/8=75个，一个vuser10分钟可以登录75个用户；300/75=4，需要4个vuser；751.2=90,要为每个vuser准备90个用户；90*4=360，一共需要360个用户。如果希望模拟真实用户行为，用户名设置为参数化，则参数化类型选择unique number类型。
2.产生360个用户
打开register脚本注册用户，之前脚本已经调试成功，注册时可以把调试代码注释，如下图

username参数化设置如下，因为要产生360个用户，所以block设置为360

然后把用户名参数化，并在前边加上t，

设置迭代360次，然后运行

可以看到有360个用户注册成功

验证是否能成功登陆。打开页面输入账号密码t360,123，提示登录成功

另外一种产生数据的设置方法，在run time setting中设置block。

如图，把submit_login单独设置迭代360次，其他action迭代1次，这样运行比较快。这种方法要把参数取值方式设置成每次发生，而不是每次迭代，与第一种方法的取值方式不一样。

运行后也可以产生360个用户，这里就不再运行了。
3.设计20并发测试场景

打开run load test ，打开flightlogin脚本，选择manual scenario（手动场景）

a.打开后先确认脚本代码有没有问题，点击view script

查看脚本发现用户名需要参数化，密码需要修改

参数化方法还选择unique number，由于这次是运行20并发，查看瞬时值，所以设置block=1，


打开run time setting 检查设置是否正确，然后在design中点击details按钮，再点击refresh按钮更新脚本，因为修改脚本后不会自动更新到run and test。


b. 脚本更新后设置并发数，设置20个并发，如下图

设置运行直到完成

然后设置run time setting，执行压测时日志设置成只发送错误日志，遇到错误继续执行，把每个action设置成一个事务，具体设置如下图

注意，如果脚本没有添加事务，又没有勾选上图中最后一个框里的选项，执行完压测时会没有数据。

c. 接下来设置结果路径
点击results-results settings，然后修改名称和路径

d. 设置run选项卡里的设置项
点击run，如下图，本页主要设置监控（具体需要什么数据根据不同项目来分析，不一定都跟本例一致）

windows resourcses设置：选中图形，右键然后选择Add Measurements



注意：Name填服务器的域名或者IP地址

框中的资源度量都可以用，但一般用不了这么多，如果看不懂可以全删掉然后再添加自己需要的项


processor表示CPU,%Processor Time表示CPU的使用率，右侧0123表示机器是4核的，然后点击Add（点击后框里不会出现所选度量，关掉windows resources框后才会出现，所以点一下Add就行了，不用一直点）
接下来添加内存，在object框里输入M，出现Memory(内存)，选择Available MBytes（表示以兆为单位），然后点击添加


可以看到已经添加成功。
设置完成后点击start scenario（如果是并发跑，最后一般状态是passed，如果是运行时间，交易数量，最后的状态一般是stopped）


可以看到运行成功了。

4.业务量场景设计：4并发持续运行10分钟
a. 打开flightlogin脚本

b. 查看脚本设置，block设置为90（与之前20并发设置不同，因为这个要持续运行10分钟）

c. 查看run time setting，确保设置正确

更新脚本

d. 设置运行结果存放位置

e. 设置并发数4

设置运行10分钟

f. 设置run time setting
由于设置了持续时间，run logic没有用了，可以直接设置成1.



g. 查看有没有设置集合点
vuser以百分比形式运行时不能设置集合点，所以集合点灰化有三种情况：
（1）脚本没有添加集合点函数
（2）场景中设置以百分比模式执行，应该选择Vuser组模式
（3）如果选择的是 面向目标 的场景方法，集合点是不可用的；手动场景时选择百分比模式，集合点也不可用
本例不用设置集合点

h. 添加浏览器资源度量


I. 点击运行

运行结束，状态是stopped

j. 打开并保存结果

5. 场景结果分析
运行结果如下图
a. summary report

框中的是事务的数据，事务是loadrunner工具中衡量性能指标的最小单元。数据依次为最小值、平均值、最大值、标准方差、90%时间、通过的数量、失败的数量、暂停的数量。
其中标准方差越小说明越稳定。从数据来看已经达到了要求：成功率100%，响应时间不超过5秒（不包含think time）

此数据没有包含think time

修改是否包含think time以及事务百分比方法：单击红框右下角出现3个点，点击3个点

选择包含think time，把90改成80，点击OK

b. running vusers
下图中数据是正确的，如果发现数据是错误的，则应该是负载生成器的问题，此时压力测试结果不准确。

c. hits per second：每秒请求数（点击数）说明客户端向服务器发送的请求的数量，这个图如果有偏差或者不均衡也说明客户端产生的压力有问题。

补充：
在run load test 页面右键图形，点击configure，出现如下窗口，refresh rate可以设置图形更新频率，如图表示每5秒取一个值。

在analysize test results页面，右键图形，点击set granularity,可以设置图形粒度（同一维度下，数据统计的粗细程度），如下图

有时候run load test和analysize test results的同一个图数值会有一点差异，一般以analysize test results的图为准。

d. throughout:吞吐量：表示Vuser在任意给定的一秒内从服务器接收的数据量，是服务器的指标。

吞吐量和每秒请求数一般大致保持一致，即请求数越大，对应的服务器的吞吐量也越大，如果请求变大，吞吐量却没啥变化，可能有以下几种原因：（1）服务器响应慢（2）压力可能没到服务器（3）服务器可能设置了阈值（4）服务器的处理能力到达最大值，没办法处理更多的响应，也可能是其他的原因，需要具体分析

遇到需要关联分析的指标时，可以合并图形，右键选择merge graphs,然后选择需要关联的图


e. Average transaction response time（平均事务响应时间）：显示负载测试场景运行期间每秒内用于执行事务的平均时间。

右键graphs-add new item-add new graph添加新图

双击框中待添加的图


可以看到cpu和内存没有超过80%

f. 下图中框里的两个图可以查看组件的情况，具体可以参考LoadRunner analysis中文帮助文档。

g. 导出报告
reports-new report-generate

选择类型

选择Word文档

导出报告如下