【性能测试】loadrunner12.55--知识准备

1.0. 前言

在性能测试中，牵扯到了许多比较杂的知识点，这里将给大家说一下，loadrunner性能测试前需要做的一些准备，本节中我们将先从性能测试的一些术语入手，再到HTTP的一些知识，最后导我们loadrunner12.55的环境配置。

1.1 性能测试术语介绍

1.1.1 响应时间（Response time）

响应时间就是用户感受软件系统为其服务所耗费的时间

1.1.2 并发用户数

用来度量服务器并发容量和同步协调能力，在客户端指一批用户同时执行一个操作

C=nLTC=nLT

^C≈C+3√CC^≈C+3C

C是平均并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度；

^CC^

是并发用户数；

（实际上，这个公式我们基本上不用）

举个例子：一架电梯同时能够搭载的乘客数就可以看作是他的用户并发数

1.1.3 吞吐量（Throughput）

吞吐量是指单位时间内系统能够完成的工作量,它衡量的是软件系统服务器的处理能力,就是在一秒中统计所完成的工作量。是指在一次性能测试过程中网络上传输的数据量的总和。、

通常是不需要用吞吐量这个概念的。因为它在不同人的脑子里会存在一些误解。

用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出 10 吨水；10 个水龙头开 1 秒钟，流出 0.1 吨水。当然是一个水龙头的吞吐量大。你能说 1 个水龙头的出水能力是 10 个水龙头的强？所以，我们要加单位时间，看谁 1 秒钟的出水量大。这就是吞吐率。

比如说，有些人说吞吐量就是在说TPS。有些人说吞吐量是说的每秒字节数。所以不建议用这个概念来承载性能指标，「有TPS就够了」。

1.1.4 吞吐率（Throughout）

指一个业务系统在单位时间内提供的产量（或服务量）。

1.1.5 TPS（Transaction Per Second）

那么我们就来看看TPS

TPS是指每秒事务处理量。每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标

TPS = 并发数/平均响应时间

TPS是由并发数和平均响应时间计算得到，是否可以认为TPS是通过并发数和平均响应时间计算得到的一秒所处理的事务数，而吞吐量就是一秒内完成的事务数量。

举个例子：博尔特1秒跑10米，就计算得一小时能跑：10*3600=36000m，其实博尔特就跑了10s，而36000m这个数的大小，是我们计算出认为如果博尔特跑3600s可以跑36000m。
但是实际上让博尔特真的跑上一个小时，可能就跑了20000s（吞吐量），因为他全程不一定都是保持1秒10米，后面就累了，可能1s也就跑7m，
也就是TPS强调时刻，但是吞吐量强调时间。

1.1.6 QPS(Query Per Second)

每秒查询数，即控制服务器每秒处理的指定请求的数量。

1.1.7 点击率（Hit Per Second）

指每秒发送的HTTP请求的数量。点击率越大对server造成的压力就越大。

点击率可以看做是 TPS 的一种特定情况。点击率更能体现用户端对服务器的压力。TPS 更能体现服务器对客户请求的处理能力。

每秒钟用户向 web 服务器提交的 HTTP 请求数。这个指标是 web 应用特有的一个指标；web 应用是 “请求 - 响应” 模式，用户发一个申请，服务器就要处理一次，所以点击是 web 应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和 TPS 就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不是指鼠标的一次 “单击” 操作，因为一次 “单击” 操作中，客户端可能向服务器发现多个 HTTP 请求。

1.1.8 性能计数器（Counter)

描述服务器或操作系统性能的一些数据指标

1.1.9 思考时间（Think Time）

也称“休眠时间”。指用户在操作时，每个请求之间的时间间隔。

R=TTSR=TTS

R是请求数；T是时间；Ts是思考时间；

1.1.10 资源利用率

指服务器系统中不同硬件资源被使用的程度，资源利用率=资源实际使用量/总的可用资源量

常见资源指标

CPU使用率：不高于75%-85%

内存大小使用率：不高于80%

磁盘IO（速率）：不高于90%

网路（速率）：不高于80%

1.1.11 事务

前面我们提到了事务，那么这里就给大家也顺带讲下事务

用户自定义的一个标识，用来度量服务器响应时间的任务或操作集，事务时间反映的是一个操作过程的响应时间。

事务的处理过程可以理解为：发送请求-->网络传输-->收到响应

关注某个业务的响应时间，可以将该业务定义为事务

1.1.12 集合点

模拟系统上较重用户负载时，配置多个用户同时执行操作，当用户到达集合点时将进行等待，直到指定数量的虚拟用户到达后再进行用户并发操作。

见文知意，集合点就是集合的地方，比如我们需要对登录进行压力测试，那么我们就需要用户在集合点集合，再同时进行登录操作

模拟多个用户同一时间发出请求，可以在脚本中设置集合点。

1.1.13 检查点

一般与事务相配合使用，作用为在编译录制脚本、replay脚本的时候用来检查脚本执行情况，检查特定的文本字符串或图片。

1.1.14 平均响应时间

处理一个事务所需要的时间。平均响应时间越小、响应时间平均值越小，说明处理速度越快，软件的效率就越好。

1.2 性能测试分类

1.2.1 性能测试

性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

1.2.2 负载测试（Load Testing）

指的是最常见的验证一般性需求进行的性能测试，考察软件系统在既定负载下的性能表现

1.2.3 压力测试（Stress Testing）

考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数

1.2.4 配置测试（Configuration Testing）

指通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

1.2.5 并发测试（Concurrency Testing）

指当测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题，如内存泄漏、线程锁、资源争用问题，几乎所有的性能测试都会涉及并发测试。

1.2.6 可靠性测试（Reliability Testing）

为了评估产品在规定的寿命期间内，在预期的使用、运输或储存等所有环境下，保持功能可靠性而进行的活动。

1.2.7 容量测试（Volume Testing）

通过测试预先分析出反映软件系统应用特征的某项指标的极限值，系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。

1.2.8 基准测试

指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。

1.2.9 稳定性测试

测试系统在一定负载下运行长时间后是否会发生问题

1.2.10 可恢复测试

主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。

1.3 HTTP我们需要知道的

1.1.1 客户端向服务器请求的HTTP方法

GET

获取资源

POST

传输实体主体

PUT

传输文件

HEAD

获得报文首部

DELETE:

删除文件

OPTIONS

询问支持的方法,客户端用来询问服务器端支持哪一些方法

1.1.2 HTTP响应状态码

状态码	含义
100	请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
200	服务器已成功处理了请求
302	重写向，会自动将请求者转到不同的位置
400	服务器不理解请求的语法。
401	请求要求身份验证。对于登录后请求的网页，服务器可能返回此响应。
404	服务器找不到网页
500	服务器内部错误
502	网关错误
504	网关超时