性能测试基础知识（一）

性能测试的分类

性能测试的类型通常包括如下几类：

• 性能测试：寻求系统在正常负载下的各项性能指标，或者通过调整并发用户数，使系统资源的利用率处于正常水平时获取到系统的各项性能指标。

• 负载测试：系统在不同负载下的性能表现，通过该项测试可以寻求到系统在不同负载下的性能变化曲线，从而寻求性能的拐点。例如负载测试时，在只不断递增并发用户数时，观察各项指标的变化规律，找到系统能达到的最大TPS，并且观察此时系统处理的平均响应时间、各项系统资源和硬件资源的消耗情况。

• 压力测试：系统在高负载下的性能表现，该项测试主要是为了寻求系统能够承受的最大负载以及此时系统的吞吐率，通过该测试也可以发现系统在超高负载下是否会出现崩溃而无法访问，以及在系统负载减小后，系统性能能否自动恢复。

• 基准测试：针对待测系统开发中的版本执行测试，采集各项性能指标作为火气版本性能的对比。

• 稳定性测试：以正常的负载或者略高于正常负载对系统进行长时间的测试，检测系统是否可以长久稳定运行，以及系统的各项性能指标会不会随着时间发生明显变化。

• 扩展性测试：通常用于新上线的系统或者新搭建的系统环境，通过先测试单台服务器的处理能力，然后慢慢增加服务器的数量，测试集群环境下单台服务器处理能力是否有损耗，集群环境的性能处理能力是否可以呈现稳定增加。

性能测试场景

性能测试的场景类型通常包括如下几种：

• 业务场景：通常指的是系统的业务处理流程，描述具体的用户行为，通过对用户行为进行分析，以划分出不同的业务场景，是性能测试时测试场景设计的重要来源。

• 测试场景：测试场景是对业务场景的真实模拟，测试场景的设计应该尽可能贴近真实的业务场景。

• 单场景：指的是指涉及单个业务流程的测试场景，目的是测试系统的单个业务处理能力是否达到预期，并且得到系统资源利用正常情况下的最大TPS、平均响应时间等性能指标。

• 混合场景：测试场景中涉及多个业务流程，并且每个业务流程在混合的业务流程中占用的比重会不同，该比重一般根据实际的业务流程来设定。尽可能符合实际的业务需要。该测试场景的目的是为了测试系统的混合业务处理能力是否满足预期要求，并且评估该系统的混合业务处理容量最大能达到多少。

常见的性能测试指标

• 响应时间

  请求或者某个操作从发出的时间到收到服务器响应时间的差值就是响应时间。一个完整的响应时间=后台处理时间+网络传输时间+客户端呈现时间。

• TPS/QPS

  事务是自定义的某个操作或者一组操作。例如在一个系统的登陆页面，输入用户名/密码，从单击“登陆”按钮开始到登陆完成跳转到页面，并且新的页面完全加载完成，这一个操作我们就可以定义为一个事务。

  TPS是Transaction Per Second 的缩写，即系统每秒能够处理的事务数量，一般统计的是每秒处理的事务数。

  QPS是每秒查询率（Query Per Second）的缩写，是对一个特定的查询服务器在规定的时间内所处理请求数量。和TPS的区别在于，假定一次登录事务会产生2个请求，每秒完成1次登录事务，那么TPS就是1，QPS就是2。

• 并发用户

  在真实的用户操作汇总，用户的每个相邻操作之间都会有一定的间隔时间（在性能测试中，我们称之为思考时间），所以，并发用户一般都有绝对并发和相对并发之分。绝对并发是指某个时间点同时一起想服务器发出请求的并发用户数；相对并发是指一段时间内向服务器发出请求的并发用户总数。就单性能指标而言，系统并发用户数指系统可以同时承载的、正常使用系统功能的用户总数量。

  针对并发用户我们举例说明。双11在某宝网站购买某司摇头机的流程包括登陆、浏览商品、把商品加入购物车、去购物车结算、确认商品清单、确认收货地址、最后支付。如果用200人同时按照这个流程购买摇头机，因为每个人购买商品的步骤有快有慢，所以在同一时间点向服务器请求的人数不会有200人，会远小于200。如果我们假设同时请求的人数为20，那么上面说的200个用户就是相对并发用户数，而20个用户则是绝对并发用户。

• PV/UV

  PV：Page View的简写，即页面的浏览量或点击量，用户每次对系统或者网站中的任何页面访问均会被记录一次，用户如果对同一页面进行多次访问，那么访问量就会累加。PV一般是衡量电子商务网站性能容量的重要指标。PV的统计可以分为全天PV、每小时PV以及峰值PV。

  UV：Unique Visitor的简写，即指系统的独立访客，访问系统网站的一台电脑客户端会被称为一个访客，每天00:00点到次日00:00点相同的客户端指被计算一次。同样的UV的统计也分为全天UV、每小时UV以及峰值UV。

• 吞吐量

  吞吐量是指系统在单位时间内处理客户端请求的数量。从不同的角度来看，吞吐量的计算方式可以不一样。

  1. 从业务角度：吞吐量可以用请求数/s、页面数/s等进行衡量计算；

  2. 从网络角度：吞吐量可以用字节/s来进行衡量计算；

  3. 从应用角度：吞吐量可以反映的是服务器承受的压力，即系统的负载能力

  一个系统的吞吐量一般与一个请求处理对CPU的消耗、带宽消耗、IO、内存资源的消耗等紧密相连。

• 资源开销

  每个请求或事务对系统资源的消耗，用来衡量请求或者事务对资源的消耗程度。例如，对CPU的消耗可以用占用CPU的秒数或者核数来衡量，对内存的消耗可以用内存使用率来衡量，对IO的消耗可以用每秒读写磁盘的字节数来衡量。在性能测试中，资源开销是一个可以量化的概念，资源开始情况对性能指标有着重要的影响。

各性能指标间的关系

下面是一个标准的软件性能模型，纵坐标为Utilization（资源利用率）、Throuthput（吞吐量）、Response Time（响应时间），横坐标为负载（并发用户数）。该模型描述对一个系统不断加压的过程，系统的吞吐量、响应时间、资源利用率是如何变化的，主要分为3个阶段：

• Light Load（低压力）：在这个阶段，资源充足，随着用户并发增长，资源占用率和吞吐量基本呈线性增长，并且响应时间基本不变，表示系统在此压力下能较轻松地处理请求；

• Heavy Load（大压力）：在这个阶段，资源已基本达到饱和，因此随着用户并发数的增长，吞吐量增长缓慢甚至停止增长，响应时间开始变长，此时系统的处理性能已基本达到极限；

• Buckle Zone（响应超时区域）：在这个阶段，系统资源已饱和，但并发用户数仍不断提升，导致系统的处理能力下降，吞吐量急剧下降，响应时间呈指数级增加，此时系统已经在超负荷运行。

 

从图中可以看出，系统的吞吐量与资源（包括硬件、软件资源）、响应时间、用户并发数都有很大关联。这里存在两个概念：最佳用户数和最大用户数。

• 最佳用户数：Light Load与Heavy Load交界处，此并发用户数是系统可承载的最佳用户数，因为此时资源利用率和吞吐量都可以达到最大，并且对用户来说满意度也是最高的（响应时间不变）。

• 最大用户数：Heavy Load与Buckle Zone交界处，此并发用户数是系统可承受的最大用户数，虽然此时资源利用率和吞吐量仍为最大，但用户已存在不满意即将离开的风险（响应时间开始上升）。