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 | 网关超时 |
1.4 Loadrunner 12.55安装
1.4.1 安装教程
安装包：
下载链接: 百度网盘 请输入提取码
提取码: a3pi
安装注意事项：
- 安装前，把所有的杀毒软件和防火墙关闭；
- 若以前安装过LoadRunner，需将其卸载；
- 安装路径不要带中文字符；
- LoadRunner 12已经不再支持XP系统，浏览器建议使用IE10以上版本。；同时win 11的小朋友们请注意，Loadrunner需要有IE支持
启动安装包
鼠标右键点击HPE LoadRunner 12.55 Community Edition.exe安装程序，选择“以管理员身份运行”，弹出窗口，选择文件存放地址，可选择默认路径，点击“Install”。
若安装过程中被电脑安装的杀毒软件拦截时，均选择允许操作。
安装向导会验证电脑是否含有软件安装运行的必备组件，缺少组件时，会弹出窗口显示需安装的组件。点击“确定”按钮将自动安装所需组件，必须先安装这些必备程序才能安装HPE LoadRunner。
必备组件安装完成后，会弹出HPE LoadRunner安装向导窗口，选择要安装的产品，这里选择LoadRunner，点击“下一步”。
最终用户许可协议，勾选“我接受许可协议中的条款”，点击“下一步”。
目标文件夹，选择安装路径，安装路径不能含有中文字符，点击“下一步”。
已准备好安装HPE LoadRunner，点击“安装”将进行程序的安装。
正在安装HPE LoadRunner。
LoadRunner安装完成，点击“完成”，关闭安装弹窗。
安装完成，我们桌面上会出现三个软件，我们一一介绍一下：
使用顺序：Virtual User Generator -> Controller -> Analysis
1.4.2 Virtual User Generator介绍
Virtual User Generator（用户脚本）录制与编写脚本的地方，就是通过录制或编写脚本来模拟用户的行为，同时会打印出日志信息，方便调试脚本；VuGen也是一个集成开发调试环境，在这里完成脚本开发并调试通过后就可以放到Controller中创建场景。
简单说，就是我们将会用VuGen对我们需要测试的流程进行录制，然后对录制下来的流程进行一些配置调试。
1.4.3 Loadrunner中最核心模块——Controller介绍
场景（Scenario）是一种用来模拟大量用户操作的技术手段，通过配置和执行场景向服务器产生负载，验证系统各项性能指标是否达到用户要求，而Controller可以帮助我们对场景进行设计、执行以及监控进行管理。
从性能角度来说，场景一般可以分为两种类型即可：
- 单一场景：在一个场景中，只有一个脚本（业务）
- 理论基石：在任何系统中，如果单一业务单独执行，性能能够通过，则意味着每个业务本身其实是能够达到性能需求的。
- 混合场景：在一个场景中，一次执行多个脚本（业务）
目的：是为了测试不同业务之间是否存在并发（广义的并发，即在线即并发）冲突的现象
注意：
- 负载用户的数量：和一次执行N个脚本没有关系，应该就是最大负载用户数（在线用户数）。
- 负载用户分配比例：通过统计数据（业务量占比）来进行虚拟用户的分配。
LoadRunner中是通过Controller组件来进行场景的设计和执行的，Controller中的场景分为两种：目标场景（基本不适用）、手工场景。
1.4.4 Analysis介绍
是收集测试数据后生成图表报告的地方，帮助我们分析数据并产生图片，方便对负载生成后的相关数据进行整理分析。
