性能测试指标：

vuser虚拟用户：模拟真实业务和逻辑的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。

Vuser脚本用于描述vuser的场景中执行的操作。

虚拟用户在性能场景中有以下12个状态：

 

transaction事务：要度量服务器性，需要定义事务

每个事务包含事务开始和事务结束标记，事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。

可以将事务开始放置在脚本 中某行或者多行代码的前面，将事务结束放置在该行或多行代码后面。在该脚本的虚拟用户运行时，这个事务将衡量该行或者多行代码的执行花费了多长时间。

就是标示，这个事务开始结束点

 

tps每秒事务数：

每秒种系统能够处理的交易或事务的数量

它是衡量系统处理能力的重要指标

TPS (transaction per second)代表每秒执行的事务数量，可基于测试周期内完成的事务数量计算得出。例如，用户每分钟执行6个事务，TPS为6 / 60s = 0.10 TPS。同时我们会知道事务的响应时间(或节拍)，以此例，60秒完成6个事务也同时代表每个事务的响应时间或节拍为10秒

例1：假定我们所开发的并发服务器，并发的访问速率是：1000客户/分钟，每个客户在该服务器上将花费平均0.5分钟，根据little's law规则，在任何时刻，服务器将承担1000×0.5＝500个客户量的业务处理。假定过了一段时间，由于客户群的增大，并发的访问速率提升为2000客户/分钟。在这样的情况下，我们该如何改进我们系统的性能？ 根据little's law规则，有两种方案：

 

第一：提高服务器并发处理的业务量，即提高到2000×0.5＝1000。 或者

第二：减少服务器平均处理客户请求的时间，即减少到：2000×0.25＝500。

 

例2：假设你排队参观某个风景点，该风景点固定的容纳人数是：60人。每个人在该风景点停留的平均时间是：3分钟。假设在你的前面还排有20个人，问：你估计你大概等多少时间才能进入该风景点。

答案：1小时（3×20=60），和该景点固定的容纳人数无关。

 

响应时间（Response time）和节拍（Pacing）。实际上节拍会超越响应时间对TPS的影响。

解两个因子：响应时间（Response time）和节拍（Pacing）。实际上节拍会超越响应时间对TPS的影响。

 

示例1：节拍0秒，思考时间0秒

用户执行5个事务并且每个事务的响应时间是10秒，需要花费50秒完成5个事务，即5/50=0.1 TPS (这里TPS是由响应时间控制)。

 

示例2：速率15秒，思考时间0秒

用户执行5个事务且每个事务的响应时间是10秒，但实际由于节拍大于响应时间，所以它优于响应时间控制了事务发生的频率。完成5个事务需要5*15 = 75秒，产生5/75=0.06667 TPS。

 

在第二个示例中，平均响应时间小于节拍15秒，需要75秒完成5个迭代，产生了0.06667 TPS。

 

上面两个例子中我们假设思考时间为0秒。如果思考时间为2秒，总时间仍是75秒完成5个迭代，产生0.06667 TPS。

 

节拍为0秒，则     用户数 = TPS * ( 响应时间 + 思考时间 )

节拍不为0秒且大于响应时间与思考时间的和，则     用户数 = TPS * (速率)

 

事实上TPS是事务在w.r.t时间的速率，所以也被称为吞吐量(throughput)。

所以利特尔法则在负载模型中解释为：系统内平均用户数 = 平均响应时间 * 吞吐量

N = ( R + Z ) * X

N, 用户数

R, 平均响应时间(也可能是速率)

Z, 思考时间

X, 吞吐量(如TPS)

 

如：N (用户数)=1500, R (平均响应时间)=10, Z (思考时间)=0，则X (吞吐量)=1500/10=150 TPS

 

 

pv page view:

Pv是page view的缩写，用户通过浏览器访问页面，对应用服务器产生的每一次请求，记为pv .在真实的性能环境下，需要对这个概念做了延伸，系统直实处理的一个请求，视为一个pv.pv的概念适用于接口。

peak pv 高峰page view:指一天中pv数达到的最高峰

concrrency并发：

并发分为狭义和广义两类

狭义的并发，即所有的用户在同一时刻做同一件事情或操作。这种操作一般针对同一类型 的业务。或者所用户进行完全一样的操作。目的是测试数据库对程序对并发操作的处理。

广义的并发，即多个用户对系统发出了请求或者进行了操作。但是这些请求，或操作可以是不同的，对整个系统，极然有很多用户同时进行操作。

狭义并发强调对系统的请求操作完全相同的。多适用于性能测试，负载测试压力测试，稳定 性测试场景 。广义并发不限于系统的请求操作。多适用于混合场景，稳定性测试场景 。

scenario场景：

性能测试过程中为了模拟真实用户的业务处理过程，在 LoadRunner 中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。 

Response time响应时间：

响应时间是指从客户端发一个请求开始计时，到客户接收到从服务端返回的响应结果结束所经历的时间，响应时间由请求发送时间，网络传输时间和服务器处理时间三部分组成。

在性能测试结果分析中，性能场景中事务的响应时间，事务响应时间分为事务最小响应时间，事务平均响应时间，事务最大响应时间。

 

think time思考时间：

模拟正式用户在实际操作时的停顿时间。

从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。

从测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔进间。

cpu资源：

Cpu资源是指性能测试场景运行的这个时间段内，应用服务系统cpu资源占用率。

Cpu资源是判断系统处理能力以及应用运行是否稳定的重要能数。应用系经可以包括应用服务器，web服务器，数据库服务器等。

性能测试过程中，对cpu的监控以及分析报告、图表有loadrunner自带监控分析，有liunx 系统输出及手工汇总，有第三方式工具监控分析等。

 

 

load负载：

系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中：
1. 它没有在等待 I/O 操作的结果。
2. 它没有主动进入等待状态（也就是没有调用“wait”）。
3. 没有被停止（例如：等待终止）。
性能测试结果分析 Load 分布如图 8 所示。

 

std.deviation标准差：

该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之，
标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差、TPS 标准差、Running Vuser
标准差、 Load 标准差、 CPU 资源利用率标准差、 Web Resources 标准差等。举例响应时间标
准差，如图 9 所示，事务 SellerSaveItem 的响应时间为 0.043 秒，响应时间标准差为 0.01，
如图红色圈住所示。 

性能测试模型：

pv计算模型

pv->tps转换模型

tps波动模型

共享中心性能测试工 模型

前端页面性能测试模型

性能测试策略：

性能测试评估：

关键业务

日pv量

逻辑复杂度

运营推广计划

其它

 

性能测试类型：

性能测试压力变化模型

性能测试

负载测试

压力测试

稳定性测试

 

性能测试执行方法

单场景

混合场景

性能监控

监控指标

监控工具

监控步骤

 

性能分析：

分析原则

分析信息来源

分析标准

分析工具

性能测试通过标准

性能测试流程 

性能测试流程图

性能测试流程主要活动

 

性能测试文件模板