【性能测试基础】三个最常用的指标
作者：互联网
响应时间
定义
- 响应时间划分为呈现时间和服务器响应时间两个方面
- 呈现时间：数据被客户端收到收到后呈现给用户所消耗的时间。列如，对于一个WEB应用，呈现时间就是浏览器接收到响应数据后呈现和执行页面上的脚本所需要消耗的时间。所以，主要构成是前端响应时间，这部分时间取决于客户端而非服务端。
- 服务器响应时间：应用系统从请求发出到客户端接收到数据所消耗的时间。或应用系统从请求发出到客户端接收到最后一个字节数据所消耗的时间。
图解
如图，就是用户所能感受到的响应时间，包含呈现时间 和服务端响应时间。
虽然前端时间一定程度上取决于客户端的处理能力，但是前端开发人员现在还会使用一些编程技巧在数据尚未完全接收完成时呈现数据，以减少用户实际感受到的主观响应时间。也就是说，我们现在会普遍采用提前渲染技术，使得用户实际感受到的响应时间通常要小于标准定义的响应时间。
举个实际案例，加载一个网页时，如果 10 秒后还是白屏，那你一定会感觉很慢、性能无法接受。但是，部分网页采用了数据尚未完全接收完成就进行呈现的技术，大大缩短了用户主观感受到的时间，提升了用户体验。
所以，严格来讲，响应时间应该包含两层含义：技术层面的标准定义和基于用户主观感受时间的定义。而在性能测试过程中，我们应该使用哪个层面的含义将取决于性能测试的类型。显然，对于软件服务器端的性能测试肯定要采用标准定义，而对于前端性能评估，则应该采用用户主观感受时间的定义。
除非是针对前端的性能测试与调优，软件的性能测试一般更关注服务器端。
常用的系统操作响应时间
要求
- 在进行性能测试时，合理的响应时间取决于实际的用户需求，而不能依据测试人员的设想来决定。
- 对客户来说响应时间能否被接受带有一的用户主观色彩。列如，对于一个电子商务网站来说，在美国和欧洲，一个普遍被接受的响应时间标准为2/5/10秒。
并发用户数
定义
- 业务并发用户数：用户在同一时间段内访问被测试的系统，从业务角度模拟真实的用户访问。
- 最大并发访问数：服务器能承受的最大并发访问数
- 系统用户数：注册系统的用户人数
- 同时在线用户人数：当前登录系统的人数
- 服务器并发请求数：同时向服务器发送请求的数量
来看一个实例：一个已经投入运行的 ERP 系统，该系统所在企业共有 5000 名员工并都拥有账号，也就是说这个系统有 5000 个潜在用户。
根据系统日志分析得知，该系统最大在线用户数是 2500 人，那么从宏观角度来看，2500 就是这个系统的最大并发用户数。但是，2500 这个数据仅仅是说在最高峰时段有 2500 个用户登录了系统，而服务器所承受的压力取决于登录用户的行为，所以它并不能准确表现服务器此时此刻正在承受的压力。
假设在某一时间点上，这 2500 个用户中，30% 用户处于页面浏览状态（对服务器没有发起请求），20% 用户在填写订单（也没有对服务器发起请求），5% 用户在递交订单，15% 用户在查询订单，而另外的 30% 用户没有进行任何操作。那么此时，这 2500 个“并发用户”中真正对服务器产生压力的只有 500 个用户（（5%+15%）*2500=500）。
在这个例子中，5000 是最大的“系统用户数”，2500 是最大的“业务并发用户数”，500 则是某个时间点上的“实际并发用户数”。而此时这 500 个用户同时执行业务操作所实际触发的服务器端的所有调用，叫作“服务器并发请求数”。
从这个例子可以看出，在系统运行期间的某个时间点上，有一个指标叫作“同时向服务器发送请求的数量”，这个“同时向服务器发送请求的数量”就是服务器层面的并发用户数，这个指标同时取决于业务并发用户数和用户行为模式，而且用户行为模式占的比重较大。
注意：
- 服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。结合用户行为模型才能得到系统实际承载的压力。
- 分析得到准确的用户行为模式，是性能测试中的关键一环。但获得精准的用户行为模式，是除了获取性能需求外，最困难的工作。
吞吐量
定义
- 单位时间内系统处理的客户请求数量。是最能直接体现软件系统负载承受能力的指标。
- 一般来说，吞吐量用请求数/秒或页面数/秒来衡量
- 从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。
- 从网络的角度，用字节数/天来考察网络流量
吞吐量指标在Web系统的性能测试中发挥的作用
- 用于协助设计性能测试场景（根据估算的吞吐量数据，可以对应到测试场景的事务发生率、事务发生次数等），以及衡量性能测试场景是否达到预期的设计目标。
- 用于协助分析性能瓶颈。吞吐量的限制是性能瓶颈的一种重要表现形式。因此有针对性的对吞吐量设计测试有助于尽快定位到性能瓶颈所在位置。
注意
- 这里需要特别注意的是：虽说吞吐量可以反映服务器承受负载的情况，但在不同并发用户数的场景下，即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也会相差甚远。
比如，某个测试场景中采用 100 个并发用户，每个用户每隔 1 秒发出一个 Request，另外一个测试场景采用 1000 个并发用户，每个用户每隔 10 秒发出一个 Request。显然这两个场景具有相同的吞吐量, 都是 100 Requests/second，但是两种场景下的系统性能拐点肯定不同。因为，两个场景所占用的资源是不同的。
这就要求性能测试场景的指标，必然不是单个，需要根据实际情况组合并发用户数、响应时间这两个指标。
- 两个不同系统可能具有不同的用户数和用户使用模式，但如果具有基本一致的吞吐量，则可以说，他们具有基本相同的平均处理能力
并发用户数、响应时间、吞吐量之间的关系
通过一个我们日常生活中的体检为例，再来解释一下它们到底是什么，以及它们之间的关系和约束。
你先来想象这样一个场景：假设你找了一份新工作，入职前需要到体检中心完成入职体检。
在体检中心做检查的过程，通常是先到前台登记个人信息并领取体检单，然后根据体检单的检查项目依次完成不同科室的检查。
假设一共有 5 个科室，每个科室有 3 个候诊室，你发现体检中心有很多人都在做检查，那么你一般会选择先做排队人数较少的检查项目，直至完成 5 个科室的全部检查，最后离开体检中心。
现在，我们做个类比：把整个体检中心想象成一个软件系统，从你进入体检中心到完成全部检查离开所花费的时间就是响应时间，而同时在体检中心参加体检的总人数就是并发用户数，那么系统吞吐量就可以想象成是单位时间内完成体检的人数，比如每小时 100 人。
如果你到达体检中心的时间比较早，这时人还很少，5 个科室都不用排队，那么你就能以最短的时间完成体检。也就是说，当系统的并发用户数比较少时，响应时间就比较短；但是由于整体的并发用户数少，所以系统的吞吐量也很低。从中，我们可以得出这样的结论：
当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段称为 “空闲区间”。
如果你到达体检中心时，这里的人已经比较多了，只有部分科室不需要排队，但好在每个科室都有 3 个候诊室同时进行检查，所以排队时间不会很长，你还是可以在较短的时间完成体检。
也就是说，当系统的并发用户数比较多时，响应时间不会增加太多，因此系统的整体吞吐量也随着并发用户数的变大而变大的。从中，我们可以得出这样的结论：
当系统整体负载并不是很大时，随着系统并发用户数的增长，系统的吞吐量也会随之呈线性增长，我们往往把这个阶段称为 “线性增长区间”。
但是，当体检中心的人越来越多时，每个科室都需要排队，而且每个科室的队伍都很长，你每检查完一个项目都要花很长时间去排队进行下一个检查项目。这样一来，你完成体检的时间就会明显变长。
也就是说，系统的并发用户数达到一定规模时，每个用户的响应时间都会明显变长，所以系统的整体吞吐量并不会继续随着并发用户数的增长而增长。从中，我们可以得出这样的结论：
随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长。相应地，系统的整体吞吐量并不会随着并发用户数的增长而继续呈线性增长。我们往往把这个阶段称为系统的“拐点”。
最糟糕的情况来了，如果体检中心的人继续增加，你会发现连排队、站人的地方都没有了，所有人都被堵在了一起，候诊室中检查完的人出不来，排队的人又进不去。
也就是说，系统的并发用户数已经突破极限，每个用户的响应时间变得无限长，因此系统的整体吞吐量变成了零。换言之，此时的系统已经被压垮了。从中，我们可以得出这样的结论：
随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。
只有理解了这些主要性能指标之间的约束关系，我们才能在实际的性能测试实践中设计有的放矢的性能测试场景。比如，后端性能测试的测试负载，我们一般只会把它设计在“线性增长区间”内；而压力测试的测试负载，我们则会将它设计在系统“拐点”上下，甚至是“过饱和区间”。
标签：常用,响应,性能,系统,用户,并发,时间,测试,用户数 来源： https://www.cnblogs.com/sophia12138/p/15801366.html