性能测试参阅手册

1、性能测试简介

1.1 什么是性能测试

软件性能测试，性能首先是一种指标，表明软件系统或构件对及时性的要求的符合程度；再是作为产品的一种特性，可以用时间来度量。

性能指标不妨划分为两个类型：服务型和效率型。

服务型指标有：可用性和响应时间。它们所衡量的是应用程序为用户服务效果的好坏。效率型指标有：吞吐量和利用率。

通常，对软件性能的关注是多个层面的，不同的角色处在不同视角关注的“性能”具体内容不完全相同，而对于测试工程师来说，这些都是需要去关注的，下面从四个层面来阐述软件性能。

1.1.1 用户视角

对用户来说，软件性能就是软件对用户操作的响应时间。

明确来说，比如听写业务中lalr的时间。

1.1.2 管理员视角

管理员作为一个特殊的用户，除了会关注一般的用户体验外，还会关心和系统状态相关的信息。

比如说已知并发用户数为100时，A业务的响应时间为2s，那么此时的系统状态（cpu，内存，io 等）；另外对于系统的可扩展性、处理并发能力、最大容量，性能瓶颈等因素。

1.1.3 研发视角

研发人员对性能的关注更加深入，对于他们来说，如何通过调整设计、代码实现和系统设置等方法提高软件的性能表现，以及如何发现并解决软件设计和开发过程中由于多用户访问引起的缺陷。

对于开发来说，单纯的获知好与坏的评价往往意义不大，测试还需要进一步分工作在于指出引起性能不好表现的根源或可能。

1.1.4 web前端性能

这部分指web交互，主要为前端响应时间即浏览器的页面加载时间。

暂时和现有业务关系不大，这里主要是提高浏览器下载和执行资源的并发性，如何让让浏览器尽快开始渲染页面，如何充分地利用缓存等是性能关注的问题。

1.2 为什么要做性能测试

1.2.1 IT商业价值曲线

性能问题有个极大的热点，那就是等到发现它们时，往往已经是太迟了，而且越晚发现它们，解决它们的成本就越高。

性能发现周期与解决成本

实线（计划）表示在开发一个应用程序的计划阶段，如期完成的预期结果（黑色方块）。应用程序按计划表成功部署，并在系统部署后不出现或少出现问题，从而立即开始为企业带来效益。

虚线（实际）表示在实际的产品研发过程中，非常频繁地发生实际部署和部署目标的不吻合（条纹方块），是由于在解决性能问题时花费大量的时间和金钱。对于企业来说，这可不是个好消息，因为这个应用程序未能实现预期的效益。

以价值利益体现作为唯一指标简单粗暴却直接有效。

1.2.2 明确测试价值，体现测试价值

测试有许多利益相关者。测试之美令这些利益相关者满意。测试人员了解利益相关者及其对测试的目标和期望。测试人员与利益相关者合作，以确保目标和期望切合实际，并确定指标来衡量有效性和高效性。

通过协力一致持之以恒地改进测试服务和测试方法，测试工作有效、高效、优雅。不仅对自己的工作感到高兴，其他利益相关者也为之高兴。这样的测试工作堪称美丽。

通常完成这样的工作我们可以按照下面四步进行全面彻底的评估：

1.了解你的利益相关者。

2.了解他们对测试的目标和期望。

3.为利益相关者的目标期望建立指标和目标（外在美）。

4.为测试的目标期望建立指标和目标（内在美）。

1.3 性能测试术语

1.3.1 响应时间

响应时间：即从用户端发出请求到接收到应用程序给出完整响应所经过的时间。

响应时间分解

一般响应时间分为呈现时间和服务端响应时间两部分。呈现时间取决于数据在被客户端收到后呈现给用户所消耗的时间；服务端响应时间又分为网络传输时间（N1+N2+N3+N4）和应用延迟时间（A1+A2+A3），应用延迟时间又分为数据库延迟时间（A2）和应用服务器延迟时间（A1+A3）。

之所以要对响应时间进行这些分解，主要目的是能够更容易地定位性能瓶颈。通常这些时间都会在日志中埋点记录并最终呈现。

1.3.2 用户并发数

用户并发数：在某一时间点，与被测目标系统同时进行交互的客户端用户的数量。

如果性能测试目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在同一时间访问被测系统，如果使用性能测试工具模拟出与系统的访问相同的用户数，那测试结果即能够真实反映实际用户访问时系统性能表现。

• 狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业务场景，比如1000个用户同时登陆系统；

• 广义上的并发：多个用户与系统发生了交互，这些业务场景可以是相同的也可以是不同的，交叉请求和处理较多；

以当前业务为例，并发主要由内核授权路数控制，通常使用路数与分钟交互次数比例为1:1000。

1.3.3 吞吐量（QPS/TPS）

吞吐量：指在一次性能测试过程中网络上传输的数据量的总和，也可以这样说在单次业务中，客户端与服务器端进行的数据交互总量。

吞吐率：吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。

一般来说，吞吐量用请求数/秒或页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。当然，从网络的角度来说，也可以用字节数/天来考察网络流量。

对交互式应用来说，吞吐量指标反映服务器承受的压力，容量规划的测试中，吞吐量是重点关注的指标，它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。

TPS：Transaction Per Second，每秒事务数，指服务器在单位时间内（秒）可以处理的事务数量。

QPS：每秒查询率，指服务器在单位时间内（秒）处理的查询请求速率。

QPS是查询，而TPS是事务，事务是查询的入口，也包含其他类型的业务场景，因此QPS应该是TPS的子集。

负载：对被测系统不断施加压力，直到性能指标超过预期或某项资源使用达到饱和，以验证系统的处理极限，为系统性能调优提供依据。

吞吐量与负载之间的关系：

吞吐量与负载的关系

• 上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比；

• 平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动；

• 下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比；

RT/ART：Response Time/average Response Time：响应时间/平均响应时间，指一个事务花费多长时间完成。

1.3.4 性能计数器（资源利用率）

性能计数器：Counter，是描述服务器或操作系统性能的一些数据指标。

资源利用率：系统各种资源的使用状况。

计数器在性能测试中发挥着监控和分析的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。但必须说明的是，单一的性能计数器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。

资源指标与硬件资源消耗直接相关，而系统指标则与用户场景相关。

资源指标与系统指标

A：资源指标：

CPU使用率：指用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%。

内存利用率：使用内存占总内存大小的百分比，内存可接受上限不超过85%。

磁盘IO：存取数据对应其IO写读操作，一般使用Disk Time 磁盘用于读写操作占用时间百分比来度量磁盘读写性能。

网络带宽：一般使用计数器Bytes Total/sec来度量，表示发送和接收字节的速率。

B：系统指标：

用户并发数：单位时间内与系统发生交互的用户数。

平均响应时间：系统处理事务的响应时间的平均值；事务的响应时间是从客户端提交访问请求到客户端接收到服务端响应所消耗的时间。

事务成功率：定于事务用于度量一个或多个业务流程的性能指标。一般为单位时间内可完成多少个定义的事务。

1.3.5 思考时间

思考时间：Thinking Time，在性能测试中，模拟用户的真实操作场景。用户操作的事务与事务之间是有一定间隔的，引入这个概念是为了并发测试（有交叉业务场景）时，业务场景比率更符合真实业务场景。

1.3.6 连接池

连接池是一个进程，多个连接在一个进程中存储，它是共享、可复用的。

当客户端发起请求，先检查连接池中是否有空闲连接，有则分配给其使用，没有则进行入请求队列或新建一个连接对象供其使用（取决连接池有多少连接及最大允许的连接数）。

每次客户端端发起请求，如果都新建连接，会消耗很多资源，连接池的存在及其特性，减少了连接建立所消耗的资源及节省了很多连接创建时间，给系统提供了更好的伸缩性，也有助于性能提升。

1.4 性能测试方法论

1.4.1 性能下降曲线分析法

性能下降曲线实际上是描述性能随着用户数增加而出现下降趋势的曲线，这里所有的性能可以是响应时间，也可以是吞吐量等数据。一般来说，性能只要指响应时间。

典型的性能下降曲线

从上图可以看出几点：

1.单用户区域：系统对单用户的响应时间。可以以此作为基准参考值。

2.性能平坦区：在不进行更新性能调优的情况下所能期望达到的最佳性能。该区域可以作为基线或benchmark。

3.压力区域：应用轻微下降的区域。典型的，最大建议用户负载是在压力区域开始的。

4.拐点：性能急剧下降的点。

这几个区域实际明确标识了系统性能最优秀的区间、系统开始变坏的区间和性能急剧下降的点。对性能测试来说，找到这些区间和拐点，就可以找出性能瓶颈产生的地方。

1.4.2 SEI负载测试计划过程

SEI负载测试计划过程（SEI Load Testing Planing Process）是一个专注负载测试计划的方法，其目标是产生清晰、易理解、可验证的负载计划。

SEI负载测试计划过程包含6个关注的区域：目标、用户、用例、测试环境、生产环境和测试场景。它需要注意的有几个点：

1.生产环境和测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。

2.用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。

3.用例：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，
对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断
每个业务发生的频度、业务出现性能问题的风险等。

SEI负载测试计划过程只给出了负载测试需要关注的重点区域，但没有具体的操作流程，但是可以看出性能测试也是需要经历测试需求、测试设计、测试执行和测试分析等阶段。

1.4.3 性能测试基本准则

2、性能测试的应用领域

在实际的生产环境中，我们经常遇到一些场景如下：

• 我们的系统刚刚上线，正处在试运行阶段，用户要求我们必须提供符合当初提出的性能要求的报告才能通过验收，应该如何进行测试？
• 我们的系统已经稳定运行了一段时间，为了保证系统在运行过程中一直能够提供给用户良好的运行性能，应该怎么办？
• 明年，这个系统的用户数会大幅增加，届时肯定需要对系统进行调整，但怎样调整才是最有效的呢？增加应用服务器？提高数据库服务器的配置？还是需要对代码进行调整？
• 我们的系统存在性能问题，达不到预期的性能要求。这个问题究竟是什么原因造成的？该怎样对系统的性能进行调整？
• 在实验室测试中，我们的系统一直表现得很好，但产品发布到现场之后，在实际的用户使用环境下，总是会出现这样那样莫名其妙的问题，例如系统运行一段时间后速度变慢，某些应用自动退出，出现应用挂死等情况，导致用户对我们的产品非常不满。这些问题能在测试阶段发现吗？
• 在敏捷测试环境下，根本没有时间在每个迭代中计划和开展详细的性能测试，那应该怎样保证系统的性能？

仔细对上述场景进行分析，可以发现不同产品阶段产生不同的问题，那么测试关注的内容将会明显不同，即我们可以在测试中采用不同的测试方法。

性能测试的应用领域，下面通过该概念将性能测试应用的不同场合划分为几种不同的性能应用领域，然后根据总结的各种性能测试方法，给出一些在不同的性能测试应用领域内采用方法的建议。

2.1 性能测试的方法

不同的文献和资料对性能测试方法的分类方法以及每种方法的范围界定都不完全相同，我们提出本分类的目的仅仅是为了便于区别各种不同的测试方法并为不同应用领域的测试提供更好的参考。

2.1.1 验收性能测试（Acceptance Performance Testing）

验收性能测试（Acceptance Performance Testing）方法通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。

特点：

• 主要目的是验证系统是否具有系统所宣称的能力；
• 需要事先了解被测系统的典型场景，并具有确定的性能指标；
• 要求在已确定的环境下运行。

2.1.2 负载测试（Load Testing）

负载测试（Load Testing）方法在被测系统上不断增加压力，直到性能指标（如响应时间）超过预定指标或者某种资源使用已经达到饱和状态。

另外指一定的软件、硬件及网络环境下，运行一种或多种业务，在不同虚拟用户数量的情况下，测试服务器的性能指标是否在用户的要求范围内，以此确定系统所能承载的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率。

2.1.3 压力测试（Stress Testing）

压力测试（Stress Testing）是指在一定的软件、硬件及网络环境下，模拟大量的虚拟用户向服务器产生负载，是服务器的资源处于极限状态（CPU、内存等）下并长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作。与负载测试获得峰值性能数据不同 ，压力测试强调在极端情况下系统的稳定性，这个时候处理能力已经不重要了。

2.1.4 配置测试（Configuration Testing）

配置测试（Configuration Testing）方法通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

配置测试是指在不同的软件、硬件以及网络环境配置下，运行一种或多种业务，在一定的虚拟用户数量下，获得不同配置的性能指标，用于选择最佳的设备及参数配置。通过产生不同的配置，来得到系统性能的变化情况。

特点：

• 为了了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
• 一般在对系统性能状况有初步了解后进行，主要用于性能调优和规划能力。

2.1.5 并发测试（Concurrency Testing）

并发测试（Concurrency Testing）是指通过模拟多个用户并发访问同一个应用、存储或数据记录及其他并发操作，测试是否存在死锁、数据错误等障碍。为了避免你数据库或函数方法在并发下的错误，需要专门针对每个模块进行并发测试。

特点：

• 为了发现系统中可能隐藏的并发访问时的问题（内存泄漏，数据库死锁，资源竞争死锁，异常等）。
• 为了关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
• 在开发的各个阶段使用，需要相关的测试工具的配合和支持。

2.1.5 可靠性测试（Reliability Testing）

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

特点：

• 目的是验证系统是否支持长期稳定的运行。
• 需要在压力下持续一段时间的运行。
• 测试过程中需要关注系统的运行状况。

2.1.6 失效恢复测试（Failover Testing）

失效恢复测试（Failover Testing）方法是针对有冗余备份和负载均衡的系统设计的。这种测试方法可以用来检验如果系统局部发生故障，用户是否能够继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。

• 主要目的是验证在局部故障情况下，系统能否继续使用。
• 这种方法需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。
• 只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。

2.2 性能测试应用领域分析

概括来说，性能测试的应用领域划分为5个领域，下面将不同的性能测试方法与应用领域进行对应。

2.2.1 能力验证

一个典型的能力验证问题是某系统在A条件下能否具有B能力，即期望的条件下是否有预期的能力。总体来说有以下特点：

1.要求在确定的环境下进行：能力验证要求运行环境必须是确定的，因为无法或很难根据系统在一个环境中的表现去推断其在另一个不同环境中的表现。

2.需要根据典型场景设计测试方案和用例：一个典型场景包括操作序列和并发用户数量条件。在设计用例时，需要确定相应的性能目标。

在这个领域，一般采用的测试方法包括性能测试、可靠性测试、压力测试和失效恢复测试方法。

2.2.2 规划能力

规划能力验证的问题是如何使系统具有我们要求的性能表现，这个在实际中可能被描述为某系统能否支持未来一段时间内用户增长或如何调整系统配置，可以使系统能够满足增长用户数的需求。它的特点如下：

1.它是一种探索性测试，即测试不依赖于预先设定的用于比较的目标，而是要求在测试过程中了解系统本身的能力。
2.可被用于了解系统的性能及获得扩展性能的方法，除了要通过负载测试等方法获知系统性能的表现，还需要通过更换设备、调整参数等方法获知系统性能可扩展的元素。

tp：所谓非探索性测试，指系统测试过程中已建立了明确的测试预期，得到测试结论的方法时用实际的结果于预期的结果进行不比较，一直则通过。而探索性测试没有在测试过程中建立明确的测试预期，测试要求得到的结论是非确定的，一般结论是在某种条件下，系统性能表现如何等。

对于规划能力领域的问题，一般的测试方法包括负载测试，配置测试和压力测试方法。

2.2.3 性能调优

性能调优活动一般会和其他性能测试应用领域活动参杂在一起。由于性能调优可以调整的对象众多，故可以在系统实现阶段就可以进行。

对已部署在实际生产环境中的应用系统，性能调优可能关注的是系统部署环境的调整，如服务器（参数）的调整，数据库参数的调整等；对研发环境来说性能调优可能更关注的是应用逻辑的实现方法，应用涉及的算法，数据库访问层设计等因素，此时并不要求测试环境即是实际的生产环境，只要调优过程总有个可比较的基准测试环境即可。一般过程如下：

性能调优是在产品实现的各个阶段都会涉及，可能我们已经在这个过程中有意识或无意识的参与了。但需要注意的是性能调优并不是一种自发的无意识的行为，它本身必须要遵守一定的原则和过程。

一个标准的性能调优过程的描述如下：

1.确定基准环境、基准负载和基准性能指标

基准负载指可以被衡量和比较性能调优测试结果的标准运行环境、测试操作脚本和可被用来衡量调优效果的性能指标。这里标准的应用运行环境指每次执行性能测试时的环境要严格保持一致。

常见的错误包含下面几种：

• 没有保证每次执行后的数据库有相同的数据环境，
• 在一些应用程序（J2EE或dotNet）需要重启时，没有在测试前进行一段时间的预热。

2.调整系统运行环境和实现方法，执行测试

这个性能调优的核心步骤，调优的目的是通过通过调整提高应用系统的性能。一般应用系统的调整一般经过以下3个方面：

• 硬件环境的调整：包括改变系统运行的服务器、主机设备环境（改用具有更高性能的机器，或是调整某些服务器的物理内存总量、CPU数量等）、调整网络环境（更换快速的网络设备，或是采用更高带宽的组网技术）等。
• 系统设置的调整：对系统运行的基础平台设置进行调整，如根据应用需要调整UNIX系统的核心参数，调整数据库的内存池大小，调整应用服务器使用的内存大小，或是采用更高版本的JVM环境等。
• 应用级别的调整：主要是对应用实现本身进行调整，包括选用新的架构、采用新的数据访问方式或修改业务逻辑的实现方式等。

在实际的调优过程中，具体调整哪个部分内容需要视情况而定。如果调优的对象是在一个应在实际生产环境上布署完成的系统，则调优的重点可能会放在硬件环境和系统设置上。但如果是正在或通过对硬件和系统设置不能达到期望的应用，则需要在应用级别进行调整，参数或其代码。

系统调整之后，必须存在一个可用于衡量调优是否取得效果的标准。另外还有一点即是不要一次调整过多参数或应用实现方法。经验来说，一次调整3 - 5次比较合适。

tp：必须为性能调优设定一个可接受的性能调优测试目标，否则这个过程会一直持续下去，因为系统始终都不会处于一个“最优”的状态。

3.记录测试结果并进行分析

2.2.4 缺陷发现

缺陷发现性能测试应用领域主要目的是通过性能测试的手段来发现系统存在的缺陷。常遇到的场景为应用在测试环境表现正常，但是交付用户则会出现一大堆莫名其妙的问题。当然生产环境的复杂性更高。

缺陷发现性能测试应用领域一般可以作为系统测试阶段的补充测试红素段，在测试过程中发现并发问题或是系统维护阶段问题定位手段，对系统运行过程中已出现的问题进行重现和定位。

该应用领域的主要目的是发现缺陷，并没有可以参照的性能指标或需要达到的要求，因此主要采用并发测试的方法。但同时我们若需要观察压力及失效恢复过程中出现的问题，可以采用压力测试和失效恢复测试方法。

2.2.5 性能基准比较

性能基准比价通常应用在敏捷开发过程中。敏捷软件开发具有小步快走、快速需求变化的特征。敏捷软件开发采用递增的开发方式，需要在每个迭代版本中保证应用性能不会因迭代变化而变坏。

性能基准比较，顾名思义，就是在不设定明确的性能目标的情况下，通过比较得到每次迭代中的性能表现的变化，根据这些变化决定迭代是否达到了预期的目标。

在实际的操作中，可以将性能测试形成固定的脚本，并在固定的环境中对模块进行相应的性能测试，测试结果通过工具直接写入数据库，并通过图形展现为折线图，可以直观反应每次迭代中的性能表现变化。

2.2.6 总结

性能测试领域和测试方法的关联

3、性能计数器及性能分析方法

这阶段缺乏实践说明，后续修改补充。

3.1 操作系统计数器及分析

3.1.1 unix/linux操作系统主要计数器

UNIX/Linux操作系统的主要计数器

3.1.2 内存分析方法

内存分析判断系统有无遇到内存瓶颈，是否需要通过增加内存等手段来提高系统性能。

内存分析需要使用的计数器为3.1.1节memory和physical disk计数器。下面是内存分析的主要方法和步骤：

1.查看mempry - available memory：查看系统可用内存指标，有个初步印象。

2.注意Pages/sec、Pages Read/sec和Page Faults/sec的值。

• 操作系统经常会利用磁盘交换的方式提高系统可用的内存量或内存的使用效率，这3个指标直接反映了操作系统进行磁盘交换的频度。
• Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
• Page Faults/sec值表示每秒发生页面失效的次数，页面失效次数越多，说明操作系统向内存中读取的次数越多。
• Pages Read/sec的计数值，该计数器的阈值为5，如果计数值超过5，则可以判断存在内存方面的问题。

3.Physical Disk计数器的值分析性能瓶颈。

• 如果Pages Read/sec很低，同时Disk Time %和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时Pages Read/sec并未降低，则是由于内存不足。

3.1.3 处理器（cpu）分析方法

处理器（CPU）也可能是系统的瓶颈，下面来看如何针对处理器进行分析，步骤如下：

1.System - Total Processor Time % 性能计数器的计数值。

• 该计数值用于体现服务器整体的处理器利用率，对多处理器系统而言，该计数值体现的是所有CPU的平均利用率。如果该值的数值持续超过90%，则说明整个系统面临着处理器方面的瓶颈，需要通过增加处理器来提高性能。
• 由于操作系统本身的特性，在某些多CPU系统中，该数据本身并不大，但若CPU之间的负载状况极不均衡，也应该视作系统
  产生了处理器方面的瓶颈。

2.看每个CPU的Processor Processor Time % 和Processor User Time % 和Processor Privileged Time %。

• ProcessorUser Time %是指系统的非核心操作消耗的CPU时间，如果该值较大，可以考虑是否能通过算法优化等方法降低该值。如果该服务器是数据库服务器，Processor User Time %值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。

3.研究系统处理器瓶颈。

• 查看System Processor Queue Length计数器的值，当该计数器的值大于CPU数量的总数加1时，说明产生了处理器阻塞。在处理器的Process Time %值很高时一般都伴随着处理器阻塞，但产生处理器阻塞时，Processor Process Time %计数器的值并不一定很大，此时就必须查找处理器阻塞的原因。
• DPC Time %是另一个需要关注的内容，该计数值越低越好。在多处理器系统中，如果该值大于50%并且Processor Processor Time值非常高，则考虑加入一个网卡来提高性能。

3.1.4 磁盘IO分析方法

3.1.5 网络分析方法

4、测试流程

下面主要介绍性能测试的基本流程，性能测试从执行层面来看一般分为下面几个阶段。

测试流程

4.1 性能需求分析

性能需求分析是整个性能测试工作开展的基础，如果性能测试的需求都没弄清楚，那么执行是毫无意义的。

在需求分析阶段，测试人员需要与项目人员进行沟通，收集各种项目资料，对系统进行分析，建立性能测试数据模型，并将其转化为可衡量的具体性能指标。故而性能测试需求分析过程是繁杂的，需要测试人员有深厚的性能理论知识，除此之外还需要懂一些数学建模的知识来帮助我们建立性能测试模型。

4.1.1 需求分析关键点

通过分析性能需求分析我们需要得出那些结论或目标。

• 明确到底要不要进行性能测试，性能测试的目的是什么。
• 明确被测系统是什么？被测系统的相关技术信息：架构、平台、协议等。
• 明确被测系统的基本业务、观景业务、用户行为。
• 明确性能测试点是什么？哪些需要测试，哪些不需要，并给出原因。
• 明确被测系统未来的业务拓展规划及性能需求。
• 明确性能测试的指标，知道什么数据算测试通过。

4.1.2 需求分析方法

1、系统信息调研

系统信息调研

2、业务信息调研

指对被测业务进行分析，通过对业务的分析和了解，方便我们后续进行性能测试场景和指标的确定。

业务信息调研

3、性能需求评估

在实施性能测试之前，我们需要对被测系统做对应的评估，主要目的是明确是否需要进行性能测试，进而确定性能测试的测试点和指标。

a、业务角度

对内或外使用，预期使用量等。

b、系统角度

• 复用老框架，增加应用等场景，没必要进行性能测试。
• 数据库要求，性能测试主要是大数据的并发访问、修改数据库，而瓶颈在于连接数据库池的数量，而非数据本身的负载、吞吐能力。这时可以结合DNA的建议来估计是否进行性能测试。
• 系统特殊要求，如听写系统对响应时间有特殊要求，系统的快慢直接影响用户的体验等，则必须进行性能测试；大数据系统的及时性也需要性能测试。

上面几点中，简单分析了如何确定一个系统事都需要进行性能测试，继而我们要在此基础上确定被测系统的性能测试点。

4、确定性能测试点

a、关键业务：被测项目是否属于关键业务，有哪些关键的业务逻辑点，特别是分业务相关的功能点。

b、日请求量：被测系统各功能点的请求量。

c、逻辑复杂度：一个复杂的逻辑点可能引起系统的雪崩效应。

d、运营推广活动：配合业务进行推广及系统拓展等。

e、明确性能指标：吞吐量、成功率、稳定性、响应时间等。

4.1.3 性能测试准备

1、测试环境准备

• 被测系统环境，防止生产环境搞垮影响其它功能，可能需要单独进行环境布置。
• 测试机环境，负载机通常需要在物理机上面运行，每次需要准备好测试机器。

2、测试场景设计：根据性能需求来设计符合用户使用习惯的场景，场景设计的好坏直接影响性能执行的结果。

3、性能工具的准备

• 负载工具：根据需求分许和系统特点选择合适的负载工具，如LR、Jmeter或Locust等。
• 监控工具：准备性能测试后，被测系统资源使用的监控。

4、测试脚本准备：如果性能测试工具不能满足我们的需求，则需要自己准备测试工具。

5、测试数据准备：实际的测试用例需要不同的参数，测试数据对性能测试最终指标的影响尤为重要。

4.1.4 性能测试执行

1、人工值守

通常做性能测试需要人工执行并随时观察系统运行的情况，资源的使用率等。性能测试的吸引力在于它的不可预知性，当遇到不符合预期的情况很正常，需要相关人员进行冷静分析，这个过程漫长，需要不断调整系统参数或程序代码来定位，耗时耗力。特别是在当前敏捷开发模式比较流行的大环境下，版本发布非常频繁且版本周期短，没有那么长的时间来做性能测试。

2、无人值守

无人值守说的是尽可能将人工分析和执行过程分离，即在系统使用低峰期进行性能测试，其它时间人工进行数据分析，这需要我们能够自动化的收集各种运行数据、监控数据等便于后续分析。

4.1.5 结果分析

4.1.6 测试报告与总结

一般来说包含几个模块：测试背景、目的、范围、需求指标、策略、场景、阶段进度、测试风险等。

性能测试报告是性能测试的里程碑，通过报告能展示的性能测试的最终结果，展示系统是否符合预期，是否有隐患。

性能测试报告中需要阐明性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能调优说明、测试过程中遇到的问题和解决办法等。

性能测试工程师完成性能测试后，需要将测试结果进行备案，并作为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优方案。同时需要将测试过程中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题及解决办法或方案等记录，进行知识沉淀。

参考

性能测试二三谈系列

性能测试整理

测试的艺术专题

软件性能测试过程详解与案例剖析（第二版）- 2012.pdf

软件测试价值提升之路 - 2016.pdf