性能测试入门基础知识总结

性能测试基础

---

进行性能测试，我们需要关注性能测试的哪些方面，如果能回答出以下几个问题（5W），我们就基本入门性能测试了，然后就需要我们通过实践，运用这些性能知识理论去为实践服务，帮助我们更好的检查和定位系统的性能问题，从而改善我们的系统软件。

• WHY：为什么要进行性能测试
• WHAT：关注的性能测试内容是什么
• WHO：哪些人员需要关注性能问题
• WHERE：性能测试的关注领域
• WHEN：何时进行性能测试

以下分别回答上面的5个问题。

WHY（为什么进行性能测试）

当我们使用一个软件的时候，可能在某些高峰期时段，我们发现软件使用起来特别的卡，特别是我们提交一个表单信息，或进行其他的操作，半天才会响应。在这种高并发的场景下，极慢的响应时间就会使用户在使用软件的时候特别愤怒。而对于我们的系统而言，在用户量特别大的情况下，如果我们不去测试这个并发用户量的极限值，可能就会导致系统崩溃，进而引发更严重的事情。因此，进行性能测试非常重要，它是衡量我们的软件在压力负载情况下的承受能力。所以，我们可以从以下几个方面思考软件的性能问题：

• 应用程序是否能够很快的响应用户的要求
• 应用程序是否能够处理预期的用户负载并由盈余能力
• 应用程序是否能够处理业务所需要的事务数量
• 在预期和非预期的用户负载下，应用程序是否稳定
• 是否确保用户在真正使用软件时获得舒适的体验

WAHT（关注什么）

我们的性能测试需要关注哪些内容呢？可以从以下几个方面入手：

• 并发用户数/吞吐量
• 平均响应时间
• 服务器资源占用情况
• 可靠性、可扩展性
• 发现引起系统问题的原因，关注采用何种技术提高系统性能
• 软硬件配置是否合理（容量规划/硬件选型）

WHO（谁关注）

• 开发人员

开发人员需要关注系统的架构是否合理；数据库设计是否存在问题；代码是否存在性能问题，会不会有内存泄漏；系统中是否存在不合理的线程同步方式和不合理的资源竞争。

• 系统管理员

系统管理员（包括操作系统管理人员、网络管理人员、服务器管理人员等），他们需要关注：

资源利用率：应用服务器和数据库资源使用状况是否合理。

系统容量：系统最多能支持多少用户的访问，系统最大的业务处理量是多少。

系统稳定性：系统是否能支持7*24小时的业务访问。

系统的可扩展性：系统是否能实现扩展，系统性能可能的瓶颈在哪里，更换哪些设备能够提高系统性能。

• 用户

用户最关心的是系统的响应时间，过长时间的等待会使用户烦躁，甚至放弃使用该软件系统。

对于一般的web网站来说，普遍的标准原则是3/5/8(2/5/10)

3：3秒用户会觉得是一个很好的体验。

5：5秒用户会觉得差了一点，还好，一般用户能够接受。

8：8秒是用户所能承受的最大极限。

• 业务人员

业务人员关注的是如何向用户提供参数，例如支持多少用户使用，响应时间是多少。

• 测试人员

测试人员需要关注以上所有层面，是否能够发现系统中存在的瓶颈，是否真实有效的评估系统性能能力。

WHERE（关注领域）

• 能力验证

性能测试中最简单也是最常用的一个领域，主要关心的是“在给定的条件下，系统能否具有预期的表现”。

• 规划能力

规划能力领域主要关心的是“如何才能是系统具有我们要求的性能能力，或在某种可能发生的条件下，系统具有如何的性能能力”。

• 性能调优

主要应用于对系统性能进行调优。一般来说，性能调优活动会和其他领域的活动交杂一起，是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域。

• 发现缺陷

该领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷。

需要注意的是：性能测试并不独立于功能测试，它是在满足功能的情况下进一步的调优。性能测试并不只是并发用户的测试。

WHEN（何时测试）

• 功能测试中后期

性能测试并不是简单的在其他测试完成后测试一下就行了，它在我们的测试过程中占有不容忽视的比重。

性能测试中的常见术语

---

性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件对系统的各项指标进行测试。系统的性能是一个广泛的概念，对一个软件系统而言包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。

一般我们主要针对系统法性能指标指定性能测试方案，执行测试用，得出测试结果来验证系统的性能指标是否满足既定值。性能指标可能包括系统各方面的能力，如系统并发处理能力，系统响应时间，批量业务处理能力等等。性能测试主要用来保证产品上线或发布之后系统的性能满足用户的需求。性能测试在软件质量保证中起重要作用。

并发数

系统用户数：简单的说是该系统的注册用户数，这些用户可以是活跃的，也可以是僵尸的。

在线用户数：即登录系统法用户，例如，其中500个用户的状态为在线状态，但在线用户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。

并发用户数：是对服务器产生压力的用户。例如，在线的500个用户中，只有20%的用户对服务器产生压力，这20%的用户就是并发数。严格上讲，并发用户数是同一时间进行同一操作的用户数。

响应时间（Reponse Time）

又叫请求响应时间：TTLB（time to last byte），对请求作出响应所需要的时间
网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。

事务响应时间 （Transaction Reponse Time）

事务是指一组密切相关的操作组合。例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求。

每秒事务通过数（Transaction Per Second）

TPS 是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变。

地铁检票口例子：

只有十台进站检票的机器，一台机器一秒能进一个人
并发用户数为5，则TPS为5
并发用户数为10，则TPS为10
并发用户数为100，则TPS仍为10

点击率（Hit Per Second）

每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大，服务器压力越大。这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。

吞吐量（Throughput）

单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络的角度来说，也可以用字节数/天来衡量。

思考时间（Think Time）

思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。

资源利用率

不同系统资源的使用情况。CPU,Memory，磁盘，网络。

通过了解性能测试中的常见术语，我们对性能测试的理解更加深入，接下来，我们需要继续深入理解性能测试模型。

性能测试模型

---

曲线拐点模型

• X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
• 随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。
• 接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
• 同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
• 最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是统的最佳并发用户数，因为各种资源都利用充分响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

地铁模型

某地铁站进站只有3个刷卡机。人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

• 场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。
• 场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。
• 场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。
• 场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。
• 场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。
• 场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽）。
• 场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。
• 场景八：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

性能测试分类

---

性能测试主要有以下分类：

• 基准测试
• 性能测试
• 负载测试
• 压力测试
• 并发测试
• 配置测试
• 可靠性测试
• 失效恢复测试
• 大数据量测试

基准测试

有基础的标准，这样能通过对比发现系统的不同点与变化。

1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。
2）系统进行基准测试可以在较早的阶段发现性能问题。
3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。

性能测试（Performance Testing）

是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求。

负载测试（Load Testing）

负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据。

压力测试（StressTesting）

压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。

注意：负载测试和压力测试两者可以结合进行。

负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

并发测试（Concurrency Testing）

并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁
或者其他性能问题。

配置测试（ConfigurationTesting）

配置测试方法是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资
源的最优分配原则
例如在测试执行时更换、扩充硬件设备，调整网络环境、调整应用服务器和数据库服务器的参数设置，比较每次测
试结果，从而确定各个因素对系统性能的影响。

可靠性测试（Reliability Testing）

可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

失效恢复测试（Failover Testing）

1.失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。
2.一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用。
3.不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统。

大数据量测试

大数据量测试的两种类型：
1.独立的数据量测试
针对某些系统存储、传输、统计、查询等业务进行大数据量测试
2.综合数据量测试
和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案