性能测试入门知识汇总

什么是性能测试

>在给定环境和场景中进行的测试活动
>根据测试结果评判是否存在性能问题
>如果存在性能问题，编辑定位性能瓶颈，并提出改进建议

性能不仅仅包括响应时间，还包括资源的占用。

性能测试的价值

关注一个性能测试项目在分析调优了之后，响应时间有多大的提升，TPS 有多大的提高，资源有多少的节省。

真正的性能工程师，可以把结果整理清楚之后，又可以下结论，提出解决方案：线上根据这个测试结果，做对应的配置，系统肯定可以稳定运行。又或者是这样的：当前测试说明了线上不能支持，后面应该如何优化。

我们努力的方向是性能的完整工程，这就是我在开头提到的，既要有前期的测试，还要有中间的分析，以及最后的调优，而不仅仅是做做脚本。

如果你想把性能测试做好，就不要局限自己的技术范围和认知范围。无论是系统、数据库、代码、中间件、存储、网络，你遇到什么问题，都要试着去分析下该如何判断，并考虑如何在后续的过程中进行调优。

性能领域要求的专业技能并不少，发展的宽度和深度完全取决于你自己的意愿。你可以选择只做一个写脚本的工程师，也可以选择成为一个性能调优的专家。从技术范围上说，测试工具、操作系统、开发语言、实现架构、数据库、网络、存储、部署架构等，都是你需要掌握的内容。

性能测试的价值在哪里？

性能测试分析优化之前，如果 TPS 是 100，你做完了之后 TPS 是 10000，这就是价值。

在性能测试分析优化之前，如果响应时间是 0.1ms，你做完了之后是 0.01ms，这就是有价值。

在性能测试分析优化之前，如果 CPU 使用率是 100%，你做完了之后是 50%，这就是有价值。
 

性能测试的概念

压力测试，容量测试，负载测试，太多混乱的概念。这里高楼老师给出一个概念：

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

性能测试需要有指标：，应该有的指标是：时间指标、容量指标和资源利用率指标。

性能测试需要有模型：模型是什么？它是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来

性能测试要有方案？方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险

性能测试中要有监控。这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力。监控是为了取证。

性能测试要有预定的条件：这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等

性能测试中要有场景。性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

性能测试要有结果报告 测试报告是需要汇报或者归档的。大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图。

性能测试基本流程

(1)性能测试需求分析(项目经理，业务/架构专家，产品经理，开发经理，测试工程)
(2)性能测试计划（测试经理，产品经理）
(3)性能测试准备（性能测试工程师，外部支持）
(4)开发脚本/执行测试（性能测试工程师）
(5)测试结果分析（测试经理，外部支持）
(6)系统调优（架构师，产品经理，测试经理，外部支持）
(7)编写测试报告(性能测试工程师)

 

 什么系统需要做性能测试

>任何系统都需要做性能测试，我们关键考虑的是应该做
性能测试到什么程度。
>系统分类：
>单机系统
>C/S:更关注于系统资源使用情况、数据库性能以及运行的配置要求。
>B/S:会关注web服务器的相关指标

C/S更多关注系统资源，B/S更关注服务器资源，单机程序只关注本地。

性能测试应用领域

性能测试的目的主要有以下几点：

1）评估系统的能力：性能测试主要考查系统的能力，其中系统的负荷和响应时间是相当重要的，也是验证系统能力的依据之一。能力验证这个领域最常使用的测试方法，包括后端性能测试、压力测试和可靠性测试。

2）识别系统的缺陷：性能测试考查系统受控的负荷还存在哪些缺陷，并为解决这些缺陷提供路径。缺陷发现，是一个比较直接的应用领域，通过性能测试的各种方法来发现诸如内存泄露、资源竞争、不合理的线程锁和死锁等问题。缺陷发现，最常用的测试方法主要有并发测试、压力测试、后端性能测试和代码级性能测试。

3）系统调优：性能测试的系统调优就是重复运行测试，验证系统的活动是否得到了预期的结果，从而改进系统性能。长时间的测试执行可导致程序发生由于内存泄漏引起的失败，系统调优可揭示程序中隐含的问题或冲突。性能调优：最常用的测试方法，涵盖了上面分享的七大类测试方法，即后端性能测试、前端性能测试、代码级性能测试、压力测试、配置测试、并发测试和可靠性测试。

4）验证稳定性及可靠性：在一个生产负荷下执行一定时间的测试，是评估系统稳定性和可靠性是否满足要求的唯一方法。

5）预测未来的性能，进行容量规划。能力规划最常使用的测试方法，主要有后端性能测试、压力测试、配置测试和可靠性测试。

 性能测试相关术语

响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始到这个页面安全在浏览器里展现计时结束的这一段时间间隔
WEB系统响应图：

 我们要关注的是整个响应时间

(1)响应时间
>响应时间：2-5-8原则
>当用户在2-5秒之间得响应时，会感觉系统的响应速度还可；
>当用户在5-8秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；
>当用户在超过8秒后仍然无法得到响应时，会感觉网站很慢

响应时间总结公式：
>响应时间=网络传输（请求）时间+服务器处理（一层或多层)时间+网络传输（响应）时间+页面前端解析渲染时间
(2)并发数
系统用户数：简单地说就是该系统的注册用户数
在线用户数：即登录系统的用户
并发用户数：是对服务器产生压力的用户。
(3)吞吐量
>吞吐量是指单位时间内系统处理的请求数量，能直接反映服务器承受的压力
是需要重点关注的指标。单位B/s
>当系统没有遇到性能瓶颈时，可以采用下面的公式来计算：

F为吞吐量，Nu是虚拟用户的个数，R是在T时间内每个VU发
出的请求字节数，T为性能测试所用的时间 如5个并发，每个并发4个，RT为1s，则F为20。

 (4)每秒通过事务数(TPS)
>是指每秒通过事务数，是直接反映系统性能的指标，该值大时，系统性能会比较好，当然每个系统都有它的上限，不可能无限大。将它与平均事务响应时间进行以对比，可以分析事务数量对响应时间的影响。
(5)每秒点击数
代表用户每秒向web服务器提交的HTTP请求数。

(6)思考时间
>思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。
>系统因为要满足业务特定需求就需要加上思考时间了。
(7)资源利用率
>是指服务器系统中不同硬件资源被使用的程度。
>资源利用率=资源实际使用量/总的可用资源量。
>资源利用率是分析系统性能指标进而改善性能的主要依据，在配置调优测试的过程中，通过比较配置调优前后系统资源的利用率来判断调优的效果。

 (8)性能计数器
>是描述服务器或操作系统性能的一些数据指标。
(9)QPS
>每秒查询率，是对一个特定查询服务器在规定时间内所
处理浏览多少的衡量标准。一般情况下会做为域名服务器的性能经常用用每秒查询率来衡量。只是应对于特定场景的吞吐量。

 性能测试分类

(1)基准测试
基准最简单的理解就是有基础的标准，这样能通过对比发现
系统的不同点与变化。一般情况下，基准测试有以下三种应用场景。
>可以在特定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。系统进行基准测试可以在较早的阶段发现性能问题。某系统从来没有进行过任何性能测试，需要对访系统做一次性能评估作为后开发调优的参考。

(2)并发测试
>并发测试可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否出现并发问题，如：内存泄露、线程锁、资源争用等。

(2)并发测试
>1)并发数=PV/PV Time*页面连接次数HTTP响应时间*因数/web服务器数量。
>PV:页面浏览量。
>PV Time:PV的统计时间，换算成秒。
>1页面连接次数：包括外部的JS1CSS\图片等，一般为10
>HTTP响应时间：一般可以为1s或者更少
>因数：一般为5
>假设，有一个网站每天有6万PV,其余参数保持默认，那么
推算出来的并发数大致公式如下：
60000/86400*10*1*5/1=35个并发数。

(3)负载测试
可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试。它的主要目的是验证业务或系统在给定的负载条件下的处理性能。
>负载手段：7*24小时不间断测试
(4)压力测试
>可以理解为没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此来确定系统的瓶颈或者不能接受的性能拐点，可以获得系统的最佳并发数，最大并发数。

 (5)稳定性测试
>要想知道系统稳定的情况，就需要长时间运行，在这段时间内观察系统的出错机率、性能变化趋势等。
>但稳定性测试也有和其他分类不一样的地方，这里需要强调两点：
>一般稳定性测试需要在系统成型后进行，并且没有严重的Bug存在。
>场景的设计以模拟真实用户的实际操作为佳
(6)失效恢复测试
>失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正常运行

按照场景设计分类

性能场景也要有分类，在我有限的工作经验中，性能场景从来都没有超出过这几个分类。

1.基准性能场景：这里要做的是单交易的容量，为混合容量故准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类)。

2.容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多。

3.稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人。
的心理安全感。

4.异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常

性能项目分类

对性能项目分为如下几类。
1.新系统性能测试类：这样的项目一般都会要求测试出系统的最大容量，不然上线心里没底。
2.旧系统新版本性能测试类：这样的项目一般都是和旧版本对比，只要性能不下降就可以根据历史数据推算容量，对调优要求一般都不大。
3.新系统性能测试优化类：这类的系统不仅要测试出最大容量，还要求调优到最好。

性能团队职责

1.性能验证：针对给定的指标，只做性能验证。第三方测试机构基本上都是这样做的。
2.性能测试：针对给定的系统，做全面的性能测试，可以得到系统最大容量，但不涉及到调优。
3.性能测试+分析调优：针对给定的系统，做全面的性能测试，同时将系统调优到最优状态。
 

性能测试分析方法

>指标达成法
>最优化分析法
>前后端性能测试分析
>前端性能分析：主要考虑链接数、页面大小、CSS缓存、Ajax是否缓存、JavaScript、是否启用外部脚本等
>后端性能分析：主要从引起性能的原因进行分析，包括计算机网络、数据库服务器、应用服务器以及应用程序本身，我们往往通过性能模型来表现 满足了指标，说明达标了

最优化分析法：会对系统进行优化，然后分析它。

理发师模型

性能测试分析模型 - huiyii - 博客园 (cnblogs.com)

性能测试--理发店模型 - Bronya天使 - 博客园 (cnblogs.com)

 当并发用户数小于最佳并发用户数时，随着用户的增加，响应时间并不会增加，只是系统资源利用率增加了

当并发用户超过最佳并发用户数，随着用户的增加，响应时间会变长

每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。

对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。

所以我们应该保证最佳并发用户数要大于系统的平均负载。

要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么。（每过一个小时来3个理发的，3个理发师会不停的剪发，而用户不需要等待。理发师处于这种状态很长时间后当然会崩溃）

对于一个系统来说，我们应该确保系统的最大并发用户数要大于系统需要承受的峰值负载。

TPS和响应时间关系

TPS和响应时间之间是什么关系？

 在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。

三条曲线：吞吐量的曲线（紫色）、利用率（绿色）、响应时间曲线（深蓝色）。

三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。

三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。

实际情况会与这个图有偏差。

实际：

负载区的资源饱和，和 TPS 达到最大值之间都不是在同样的并发用户数之下的。

响应时间的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。

吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平

最优并发数这个点，通常只是一种感觉，并没有绝对的数据用来证明。

最大并发数这个点，就完全没有道理了，性能都已经衰减了，最大并发数肯定是在更前的位置呀

这张图没有考虑到锁或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS 上不去，资源用不上。

简化出另一个图形，以说明更直接一点的关系。

蓝线表示 TPS，黄色表示响应时间。 

在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）
 

 测试工具的选择

工具的选择可以从如下3个维度考虑
>测试效果和工具价格是否在可接受的范围内？
>工具支持的网络协议、开发技术、中间件等是否包含公司的多数项目？
>工具的易学性和对项目进度的影响是否平衡？

本文来自王学丹、高楼老师。