性能测试基础

1. 性能测试有哪些分类

1. 负载测试

   在这里，负载测试指的是最常见的验证一般性能需求而进行的性能测试，在上面我们提到了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。

   我们对负载测试可以有如下理解：

   1. 负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
   2. 负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发 容量、资源使用率等。

2. 压力测试

   压力测试是为了考察系统在条件下的表现，条件可以是超负荷的交易量和并发用户数。注意，这个条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。

   例子：负载测试关心的是用户规则和需求，压力测试关心的是软件系统本身。

3. 并发测试

   验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程 / 多线程协调同步可能带来的问题。这是要特别注意，必须测试的。

4. 基准测试

   当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。 按照基准测试的方法，需要打开 / 关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。

5. 稳定性测试

   “路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行 长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累 才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个 星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存 泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务 器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。

6. 可恢复测试

   测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受 了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。

2. 你认为性能测试的目的是什么？做好性能测试的工作的关键是什么？

性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能，性能测试常常需要和强度 测试结合起来，并常常要求同时进行软件和硬件的检测。

性能测试主要的关注对象是响应时间，吞吐量，占用内存大小（辅助存储区），处理精度等。

3. 服务端性能分析都从哪些角度来进行？

从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标。业务性能指标可以直观地反映被测系统的实际性能状况，常用的指标项有：

1. 并发用户数
2. 事务吞吐率（TPS/RPS）
3. 事务平均响应时间
4. 事务成功率

系统资源性能指标，主要是反映整个系统环境的硬件资源使用情况，常用的指标包括：

1. 服务器：CPU 利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘 IO 状态、网卡带宽使用情况等；
2. 数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；
3. 网络：网络吞吐量、网络带宽、网络缓冲池大小；
4. 缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；
5. 测试设备（压力发生器）：CPU 利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘 IO 状态、网卡带宽使用情况等。

4. 如何理解压力测试，负载测试以及性能测试？

• 性能测试（Performance Test）：通常收集所有和测试有关的所有性能，被不同人在不同场合下进行使用。
• 压力测试 （Stress Test）：是在一定的『负荷条件』下，长时间连续运行系统给系统性能造成的影响。
• 负载测试 （Load Test）：在一定的工作负荷下，给系统造成的负荷及系统响应的时间。

5. 编写一个 http 接口性能测试方案，测试过程的关注点有哪些，流程等？

一、准备工作

1、系统基础功能验证

性能测试在什么阶段适合实施？切入点很重要！一般而言，只有在系统基础功能测试验证完成、系统 趋于稳定的情况下，才会进行性能测试，否则性能测试是无意义的。

2、测试团队组建

根据该项目的具体情况，组建一个几人的性能测试 team，其中 DBA 是必不可少的，然后需要一至几名系统开发人员（对应前端、后台等），还有性能测试设计和分析人员、脚本开发和执行人员；在正 式开始工作之前，应该对脚本开发和执行人员进行一些培训，或者应该由具有相关经验的人员担任。

3、工具的选择

综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足一下几点： 支持对 web（这里以 web 系统为例）系统的性能测试，支持 http 和 https 协议；工具运行在 Windows 平台上； 支持对 webserver、前端、数据库的性能计数器进行监控；

4、预先的业务场景分析

为了对系统性能建立直观上的认识和分析，应对系统较重要和常用的业务场景模块进行分析，针对性 的进行分析，以对接下来的测试计划设计进行准备。

二、测试计划

测试计划阶段最重要的是分析用户场景，确定系统性能目标。

1、性能测试领域分析

根据对项目背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满足实际运行时的需要，还是目前的系统在哪些方面制约系统性能的表现，或者，哪些系统因素导致系统无法跟上业务发展？确定测试领域，然后具体问题具体分析。

2、用户场景剖析和业务建模

根据对系统业务、用户活跃时间、访问频率、场景交互等各方面的分析，整理一个业务场景表， 当然其中最好对用户操作场景、步骤进行详细的描述，为测试脚本开发提供依据。

3、确定性能目标

前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指 标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使用率等目标；比如：登录请求到登录成功的页面响应时间不能超过 2 秒；报表审核提交的页面响应时间不能超过 5 秒；文件的上传、下载页面响应时间不超过 8 秒；服务器的 CPU 平均使用率小于 70%，内存使用率小于 75%；各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；

4、制定测试计划的实施时间

预设本次性能测试各子模块的起止时间，产出，参与人员等等。

三、测试脚本设计与开发

性能测试中，测试脚本设计与开发占据了很大的时间比重。

1、测试环境设计

本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行分析，得出最优结果（最适合当前系统的配置）。

这里所说的配置大概是如下几类：数据库服务器；应用服务器；负载模拟器；软件运行环境，平台。

测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景，数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入，写入几条，需要多少的测试数据来使得测试环境的数据保持一致性等等。可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据， 保持一致性。

2、测试场景设计

通过和业务部门沟通以及以往用户操作习惯，确定用户操作习惯模式，以及不同的场景用户数量， 操作次数，确定测试指标，以及性能监控等。

3、测试用例设计

确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述，用例 大概内容如下：

用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可） 用例条件：用户已登录、具有对应权限等

操作步骤：系统业务场景描述

4、脚本和辅助工具的开发及使用

按照用例描述，可利用工具进行录制，然后在录制的脚本中进行修改；比如参数化、关联、检查 点等等， 最后的结果使得测试脚本可用，能达到测试要求即可；建议尽量自己写脚本来实现业务操作场景，这样对个人技能提升较大；一句话：能写就绝不录制！！！

四、测试执行与管理

在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试用例脚本，部署环境，执行测试并记录结果即可。

1、建立测试环境

按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，

同时保持测试环境的干净和稳定，不受外来因素影响。

2、执行测试脚本

这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本。

3、测试结果记录

根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。

五、测试分析

1、测试环境的系统性能分析

根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定 是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，进行具体 情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）。

2、硬件设备对系统性能表现的影响分析

由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确 定瓶颈是在数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作。

3、其他影响因素分析

影响系统性能的因素很多，可以从用户能感受到的场景分析，哪里比较慢，哪里速度尚可，这里可以根据 2\3\5 原则对其进行分析；至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素，具体问题具体分析，这里就不一一表述了。

4、测试中发现的问题

在性能测试执行过程中，可能会发现某些功能上的不足或存在的缺陷，以及需要优化的地方，这也是执行多次测试的优点。

6. 描述软件产生内存泄露的原因以及检查方式。（可以结合一种开发语言进行描述）

内存泄露的原因，主要是由于开发过程当中申请了计算机资源（例如对象、内存等），但是使用资源完成以后没有及时释放资源导致的。例如在 C 语言当中使用了 malloc 申请了内存，但是未使用 free 来释放内存。

7. 什么是系统瓶颈？

瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的特定业务要 求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。

严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的，例如 CPU 使用率刚好达到 100% 时，内存也正好耗尽的系统不是很多见。因此我们讨论系统瓶颈要从应用的角度讨论：关键是看系统能否满足用户需求。在用户极限使用系统的情况下，系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。

因此我们测试系统瓶颈主要是实现下面两个目的：

• 发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然后解决瓶颈，这是性能测试的基本目标。
• 发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统就可以适应新的变化。