性能测试相关概念

目录

1.当我们谈及软件性能的时候，我们到底谈的是什么？

2.衡量软件性能的三个最常用的指标是什么？

3.并发用户数、响应时间、系统吞吐量之间的关系

4.常用的七种性能测试方法

5.性能测试的四大应用领域

1.当我们谈及软件性能的时候，我们到底谈的是什么？

目前，对软件性能最普遍的理解就是软件处理的及时性。但其实，从不同的系统类型，以及不同的视角去讨论软件性能，都会有所区别。

同样地，对同一个系统来说，不同的对象群体对软件性能的关注点和期望也不完全相同，甚至很多时候是对立的。这里，不同的对象群体可以分为四大类：终端用户、系统运维人员、软件设计开发人员和性能测试人员。

2.衡量软件性能的三个最常用的指标是什么？

并发用户数、响应时间，以及系统吞吐量。

• 并发用户数

并发用户数，是性能需求与测试最常用，也是最重要的指标之一。它包含了业务层面和后端服务端层面的两层含义。

• 业务层面的并发用户数，指的是实际使用系统的用户总数。但是，单靠这个指标并不能反映系统实际承载的压力，我们还要结合用户行为模型才能得到系统实际承载的压力。
• 后端服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。

举个栗子，一个已经投入运行的 ERP 系统，该系统所在企业共有 5000 名员工并都拥有账号，也就是说这个系统有 5000 个潜在用户。

根据系统日志分析得知，该系统最大在线用户数是 2500 人，那么从宏观角度来看，2500 就是这个系统的最大并发用户数。但是，2500 这个数据仅仅是说在最高峰时段有 2500 个用户登录了系统，而服务器所承受的压力取决于登录用户的行为，所以它并不能准确表现服务器此时此刻正在承受的压力。

假设在某一时间点上，这 2500 个用户中，30% 用户处于页面浏览状态（对服务器没有发起请求），20% 用户在填写订单（也没有对服务器发起请求），5% 用户在递交订单，15% 用户在查询订单，而另外的 30% 用户没有进行任何操作。那么此时，这 2500 个“并发用户”中真正对服务器产生压力的只有 500 个用户（（5%+15%）*2500=500）。

在这个例子中，5000 是最大的“系统潜在用户数”，2500 是最大的“业务并发用户数”，500 则是某个时间点上的“实际并发用户数”。而此时这 500 个用户同时执行业务操作所实际触发的服务器端的所有调用，叫作“服务器并发请求数”。

从这个例子可以看出，在系统运行期间的某个时间点上，有一个指标叫作“同时向服务器发送请求的数量”，这个“同时向服务器发送请求的数量”就是服务器层面的并发用户数，这个指标同时取决于业务并发用户数和用户行为模式，而且用户行为模式占的比重较大。

因此，分析得到准确的用户行为模式，是性能测试中的关键一环。但，获得精准的用户行为模式，是除了获取性能需求外，最困难的工作。

目前，获取用户行为模式的方法，主要分为两种：

（1）对于已经上线的系统来说，往往采用系统日志分析法获取用户行为统计和峰值并发量等重要信息；

（2）而对于未上线的全新系统来说，通常的做法是参考行业中类似系统的统计信息来建模，然后分析。

• 响应时间

通俗来讲，响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”，是用户视角软件性能的主要体现。

响应时间，分为前端展现时间和系统响应时间两部分。其中，前端时间，又称呈现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间；而系统响应时间，又可以进一步划分为 Web 服务器时间、应用服务器时间、数据库时间，以及各服务器间通信的网络时间。

除非是针对前端的性能测试与调优，软件的性能测试一般更关注服务器端。但是，服务器端响应时间的概念非常清晰、直接，就是指从发出请求起到处理完成的时间，没有二义性；而前端时间的定义，在我看来存在些歧义。所以，接下来我会和你详细聊聊前端时间这个话题。

虽然前端时间一定程度上取决于客户端的处理能力，但是前端开发人员现在还会使用一些编程技巧在数据尚未完全接收完成时呈现数据，以减少用户实际感受到的主观响应时间。也就是说，我们现在会普遍采用提前渲染技术，使得用户实际感受到的响应时间通常要小于标准定义的响应时间。鉴于此，我认为响应时间的标准定义就不尽合理了，尤其是对于“接收到最后一个字节”。

我来举个实际案例吧。加载一个网页时，如果 10 秒后还是白屏，那你一定会感觉很慢、性能无法接受。但是，回想一下你曾经上新浪网的经历，当加载新浪首页时，你应该不会感觉速度很慢吧。其实，实际情况是，新浪首页的加载时间要远大于 10 秒，只是新浪采用了数据尚未完全接收完成时进行呈现的技术，大大缩短了用户主观感受到的时间，提升了用户体验。

所以，严格来讲，响应时间应该包含两层含义：技术层面的标准定义和基于用户主观感受时间的定义。而在性能测试过程中，我们应该使用哪个层面的含义将取决于性能测试的类型。显然，对于软件服务器端的性能测试肯定要采用标准定义，而对于前端性能评估，则应该采用用户主观感受时间的定义。当然，我们在前端性能测试中，会利用一些事件的触发（比如 DOM-Load、Page-load 等）来客观地衡量“主观的前端性能”。这部分内容我会在后面介绍前端性能测试时，和你详细讨论。

• 系统吞吐量

系统吞吐量，是最能直接体现软件系统负载承受能力的指标。

这里需要注意的是，所有对吞吐量的讨论都必须以“单位时间”作为基本前提。其实，我认为把“Throughput”翻译成吞吐率更贴切，因为我们可以这样理解：吞吐率 = 吞吐量 / 单位时间。

对性能测试而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”来衡量吞吐量。当然，从业务的角度来讲，吞吐量也可以用单位时间的业务处理数量来衡量。以不同方式表达的吞吐量可以说明不同层次的问题。比如：“Bytes/Second”和“Pages/Second”表示的吞吐量，主要受网络设置、服务器架构、应用服务器制约；“Requests/Second”表示的吞吐量，主要受应用服务器和应用本身实现的制约。

这里需要特别注意的是：虽说吞吐量可以反映服务器承受负载的情况，但在不同并发用户数的场景下，即使系统具有相近的吞吐量，但是得到的系统性能瓶颈也会相差甚远。

比如，某个测试场景中采用 100 个并发用户，每个用户每隔 1 秒发出一个 Request，另外一个测试场景采用 1000 个并发用户，每个用户每隔 10 秒发出一个 Request。显然这两个场景具有相同的吞吐量, 都是 100 Requests/second，但是两种场景下的系统性能拐点肯定不同。因为，两个场景所占用的资源是不同的。这就要求性能测试场景的指标，必然不是单个，需要根据实际情况组合并发用户数、响应时间这两个指标。

3.并发用户数、响应时间、系统吞吐量之间的关系

可以以去体检中心体检为例进行类比，分为4个阶段。

• 当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往把这个阶段称为 “空闲区间“。
• 当系统整体负载并不是很大时，随着系统并发用户数的增长，系统的吞吐量也会随之呈线性增长，我们往往把这个阶段称为 “线性增长区间”。
• 随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时间会逐渐变长。相应地，系统的整体吞吐量并不会随着并发用户数的增长而继续呈线性增长。我们往往把这个阶段称为系统的“拐点”。
• 随着系统并发用户数的增长，系统处理能力达到过饱和状态。此时，如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为零，系统处于被压垮的状态。我们往往把这个阶段称为“过饱和区间”。

只有理解了这些主要性能指标之间的约束关系，我们才能在实际的性能测试实践中设计有的放矢的性能测试场景。比如，后端性能测试的测试负载，我们一般只会把它设计在“线性增长区间”内；而压力测试的测试负载，我们则会将它设计在系统“拐点”上下，甚至是“过饱和区间”。

4.常用的七种性能测试方法

常用的性能测试方法可以分为七大类：后端性能测试（Back-end Performance Test）、前端性能测试（Front-end Performance Test）、代码级性能测试（Code-level Performance Test）、压力测试（Load/Stress Test）、配置测试（Configuration Test）、并发测试（Concurrence Test），以及可靠性测试（Reliability Test）。

第一，后端性能测试（服务器端性能测试）

后端性能测试，是通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试手段。

根据应用领域的不同，后端性能测试的场景设计主要包括以下两种方式：

• 基于性能需求目标的测试验证
• 探索系统的容量，并验证系统容量的可扩展性

第二，前端性能测试
前端性能测试并没有一个严格的定义和标准。

通常来讲，前端性能关注的是浏览器端的页面渲染时间、资源加载顺序、请求数量、前端缓存使用情况、资源压缩等内容，希望借此找到页面加载过程中比较耗时的操作和资源，然后进行有针对性的优化，最终达到优化终端用户在浏览器端使用体验的目的。

目前，业界普遍采用的前端测试方法，是雅虎（Yahoo）前端团队总结的 7 大类 35 条前端优化规则，你可以通过雅虎网站查看这些规则，以及对各规则的详细解读。

这里列出了其中几个最典型也是最重要的规则，来帮助你理解前端性能测试优化的关注范围。

• 减少 http 请求次数：http 请求数量越多，执行过程耗时就越长，所以可以采用合并多个图片到一个图片文件的方法来减少 http 请求次数，也可以采用将多个脚本文件合并成单一文件的方式减少 http 请求次数；
• 减少 DNS 查询次数：DNS 的作用是将 URL 转化为实际服务器主机 IP 地址，实现原理是分级查找，查找过程需要花费 20~100ms 的时间，所以一方面我们要加快单次查找的时间，另一方面也要减少一个页面中资源使用了多个不同域的情况；
• 避免页面跳转：页面跳转相当于又打开一个新的页面，耗费的时间就会比较长，所以要尽量避免使用页面跳转；
• 使用内容分发网络（CDN）：使用 CDN 相当于对静态内容做了缓存，并把缓存内容放在网络供应商（ISP）的机房，用户根据就近原则到 ISP 机房获取这些被缓存了的静态资源，因此可以大幅提高性能；
• Gzip 压缩传输文件：压缩可以帮助减小传输文件的大小，进而可以从网络传输时间的层面来减少响应时间；

第三，代码级性能测试

代码级性能测试，是指在单元测试阶段就对代码的时间性能和空间性能进行必要的测试和评估，以防止底层代码的效率问题在项目后期才被发现的尴尬。

如果你从事过性能测试相关的工作，一定遇到过这样的场景：系统级别的性能测试发现一个操作的响应时间很长，然后你要花费很多时间去逐级排查，最后却发现罪魁祸首是代码中某个实现低效的底层算法。这种自上而下的逐级排查定位的方法，效率通常都很低，代价也很高。

所以，我们就需要在项目早期，对一些关键算法进行代码级别的性能测试，以防止此类在代码层面就可以被发现的性能问题，遗留到最后的系统性能测试阶段才被发现。但是，从实际执行的层面来讲，代码级性能测试并不存在严格意义上的测试工具，通常的做法是：改造现有的单元测试框架。

最常使用的改造方法是：

1.将原本只会执行一次的单元测试用例连续执行 n 次，这个 n 的取值范围通常是 2000~5000；

2.统计执行 n 次的平均时间。如果这个平均时间比较长（也就是单次函数调用时间比较长）的话，比如已经达到了秒级，那么通常情况下这个被测函数的实现逻辑一定需要优化。

这里之所以采用执行 n 次的方式，是因为函数执行时间往往是毫秒级的，单次执行的误差会比较大，所以采用多次执行取平均值的做法。

第四，压力测试

压力测试，通常指的是后端压力测试，一般采用后端性能测试的方法，不断对系统施加压力，并验证系统化处于或长期处于临界饱和阶段的稳定性以及性能指标，并试图找到系统处于临界状态时的主要瓶颈点。所以，压力测试往往被用于系统容量规划的测试。还有些情况，在执行压力测试时，我们还会故意在临界饱和状态的基础上继续施加压力，直至系统完全瘫痪，观察这个期间系统的行为；然后，逐渐减小压力，观察瘫痪的系统是否可以自愈。

第五，配置测试

配置测试，主要用于观察系统在不同配置下的性能表现，通常使用后端性能测试的方法：

1.通过性能基准测试（Performance Benchmark）建立性能基线（Performance Baseline）；

2.在此基础上，调整配置；

3.基于同样的性能基准测试，观察不同配置条件下系统性能的差异，根本目的是要找到特定压力模式下的最佳配置。

这里需要注意的是，“配置”是一个广义配置的概念，包含了以下多个层面的配置：

• 宿主操作系统的配置；
• 应用服务器的配置；
• 数据库的配置；
• JVM 的配置；
• 网络环境的配置；
• …

第六，并发测试

并发测试，指的是在同一时间，同时调用后端服务，期间观察被调用服务在并发情况下的行为表现，旨在发现诸如资源竞争、资源死锁之类的问题。

谈到并发测试，我就不得不和你说说“集合点并发”的概念了，它源于 HP 的 LoadRunner，目前已经被广泛使用了。那，到底什么是“集合点并发”呢？

简单来说：比如100个并发，需要让100个并发全部ready后一起向后端服务发送请求。

假设我们希望后端调用的并发数是 100，如果直接设定 100 个并发用户是无法达到这个目标的，因为这 100 个并发用户会各自执行各自的操作，你无法控制某一个确定的时间点上后端服务的并发数量。

为了达到准确控制后端服务并发数的目的，我们需要让某些并发用户到达该集合点时，先处于等待状态，直到参与该集合的全部并发用户都到达时，再一起向后端服务发起请求。简单地说，就是先到的并发用户要等着，等所有并发用户都到了以后，再集中向后端服务发起请求。

比如，当要求的集合点并发数是 100 时，那么前 99 个到达的用户都会等在那里，直到第 100 个用户到了，才集中向后端服务发起请求。当然，实际达到服务器的并发请求数，还会因为网络延迟等原因小于 100。

所以，在实际项目中，我建议在要求的并发数上进行适当放大，比如要求的并发数是 100，那我们集合点并发数可以设置为 120。

第七，可靠性测试（稳定性测试）

可靠性测试，是验证系统在常规负载模式下长期运行的稳定性。

虽然可靠性测试在不同公司的叫法不同，但其本质就是通过长时间模拟真实的系统负载来发现系统潜在的内存泄漏、链接池回收等问题。

由于真实环境下的实际负载，会有高峰和低谷的交替变化（比如，对于企业级应用，白天通常是高峰时段，而晚上则是低峰时段），所以为了尽可能地模拟出真实的负载情况，我们会每 12 小时模拟一个高峰负载，两个高峰负载中间会模拟一个低峰负载，依次循环 3-7 天，形成一个类似于“波浪形”的系统测试负载曲线。然后，用这个“波浪形”的测试负载模拟真实的系统负载，完成可靠性测试。同样地，可靠性测试也会持续 3-7 天。

5.性能测试的四大应用领域

不同的性能测试方法适用于不同的应用领域去解决不同的问题，这里“不同的应用领域”主要包括能力验证、能力规划、性能调优、缺陷发现这四大方面。每个应用领域可以根据自身特点，选择合适的测试方法。

第一，能力验证

能力验证是最常用，也是最容易理解的性能测试的应用领域，主要是验证“某系统能否在 A 条件下具有 B 能力”，通常要求在明确的软硬件环境下，根据明确的系统性能需求设计测试方案和用例。

能力验证这个领域最常使用的测试方法，包括后端性能测试、压力测试和可靠性测试。

第二，能力规划

能力规划关注的是，如何才能使系统达到要求的性能和容量。通常情况下，我们会采用探索性测试的方式来了解系统的能力。

能力规划解决的问题，主要包括以下几个方面：

• 能否支持未来一段时间内的用户增长；
• 应该如何调整系统配置，使系统能够满足不断增长的用户数需求；
• 应用集群的可扩展性验证，以及寻找集群扩展的瓶颈点；
• 数据库集群的可扩展性验证；
• 缓存集群的可扩展性验证；
• …

能力规划最常使用的测试方法，主要有后端性能测试、压力测试、配置测试和可靠性测试。

第三，性能调优

性能调优，其实是性能测试的延伸。在一些大型软件公司，会有专门的性能工程（Performance Engineering）团队，除了负责性能测试的工作外，还会负责性能调优。

性能调优主要解决性能测试过程中发现的性能瓶颈的问题，通常会涉及多个层面的调整，包括硬件设备选型、操作系统配置、应用系统配置、数据库配置和应用代码实现的优化等等。

这个领域最常用的测试方法，涵盖了我在上面分享的七大类测试方法，即后端性能测试、前端性能测试、代码级性能测试、压力测试、配置测试、并发测试和可靠性测试。

第四，缺陷发现

缺陷发现，是一个比较直接的应用领域，通过性能测试的各种方法来发现诸如内存泄露、资源竞争、不合理的线程锁和死锁等问题。

缺陷发现，最常用的测试方法主要有并发测试、压力测试、后端性能测试和代码级性能测试。

上面这些内容就是性能测试的常用方法和应用领域了，我用一张表汇总了各个应用领域需要用到的测试方法，希望可以帮助你记忆、理解。