2023年软件性能测试过程详解与案例剖析学习笔记

第一章性能测试基本概念01软件性能

从用户的角度，软件性能就是软件对用户操作的响应时间。

从管理员的角度,软件性能一方面表现在响应时间上0还涉及资源运用率、可扩展性、系统容量（并发等）和系统稳定性等。为了

保证系统的稳定运营和连续的良好性能。A对于开发人员而言,最想知道“如何通过调整设计和代码实现,或是如何通过调整系统设

立等方法提高软件的性能表现”和“如何发现并解决软件设计和开发过程中产生的由于过多用户访问引起的缺陷”，也就是性能瓶颈和

大量用户访问时的缺陷。关注的是系统架构、数据库设计、代码和设计。*所以在性能测试时，既要关注响应时间，还要关注软件

可扩展性、并发能力等指标,还要为性能问题定位。

1.2术语1A、响应时间A系统响应时间为应用系统从发出请求开始到客户端接受到响应所消耗的时间。

合理的响应时间取决于实际用户的需求。

2、并发用户数上有两种理解，一种是同一时间段访问系统的用户数量，•种是服务器所能承受的压力（同时发出请求的客户）。

在性能测试中我们更关注前者，业务并发用户数。

公式c=nL/T,计算平均并发用户数，还可用c=n/10还做简朴的估计。n为天天访问系统的用户数。

还可以通过度析服务器的日记来了解用户的使用状态。

3、吞吐量A单位时间内系统解决的客户请求的数量，请求数/秒，页面数/秒，访问数/天，业务数/小时，字节数/天。可用于衡

量是否达成了预期设计目的,协助分析性能瓶颈。A4、性能计数部描述服务器或操作系统性能的一些数据指标。例如，内存数、

进程时间。用于监控和分析。常与资源运用率进行横向对比，例如cpu占用率68%。X、思考时间（休眠时间”用户在进行操

作时，每个请求之间的间隔时间。八

1.3方法L、SEI负载测试计划过程

关注于负载测试计划的方法，目的是产生清楚、易理解、可验证的负载测试计划。关注目的、用户、用例、生产环境、测试环境和

测试场景。

2、RBI方法人rapidbootieneckidentify,用于快速辨认系统性能瓶颈的方法。34、性能下降曲线分析法■»描述性

能随用户数量增长而出现下降趋势的曲线。仙、LoadRunner的性能测试过程A涉及计划测试、测试设计、创建VU（virtualu

ser）脚本、创建测试场景、运营测试场景、分析结果。y、Segue提供的性能测试过科先拟定性能基线,然后设定可接受的性

能目的，用不同的并发用户数等反复测试。适合性能调优和性能优化，通过不断的try-check过程，逐渐找到也许导致性能瓶颈的地

方并对其优化。

6、PTGM模型

performancetestinggenera1mode1«分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和

管理以及测试分析。

第2章性能测试的应用领域

2.1性能测试的方法

1、性能测试(performancetesting)A模拟生产运营的业务压力量和使用场景组合，测试系统的性能是否满足生产性能的规

定。%、负载测试(loadtesting)^通过在系统上不断增长压力，直到性能指标超过预定或某种资源的使用达成饱和。找到系

统的解决极限。A3、压力测试(stresstesting”测试系统在一定饱和状态下，系统可以解决的会话能力，以及系统是否会出

现错误。常用于测试系统的稳定性。抽、配置测试(configurationtesting)

通过对被测软件的软/硬件环境的调整，了解各种不同环境对系统性能的影响的限度，从而找到系统各项资源的最优分派原则。

5、并发测试(concurrencytesting)^模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否

存在死锁或者其他性能问题。

关注内存是否有太多临时对象、超过设计生命周期的对象、数据库死锁、经常出现长事务、是否出现线程/进程同步失败、资源争

用导致死锁、未解决异常导致死锁。佻、可靠性测试(re1iabilitytesting)

通过给系统加载一定的业务压力的情况下,让应用系统连续运营一段时间,测试系统在这种条件下能否稳定运营。7乐实效恢复测试

(fai1overtesting)^针对冗余备份和负载均衡的系统。检查假如系统局部发生故障，用户是否可以继续使用系统，假如这种

情况发生，用户将受多大限度影响。

2.2应用领域分析1A、能力验证Aperformancetesting,re1iabilitytesting,stresstesting,fai1overtestin

g%、能力规戈Mloadtesting,configurationtesting,stresstesting3A、性能调优

configurationgtesting,1oadtesting,stresstesting,failovertestingA4、缺陷发现

concurrencytesting,stresstesting,failovertesting

第3章性能计数器及性能分析方法

用来衡量被测系统当前的状况和进行性能测试结果分析。可在操作系统级、应用服务器级和数据库级别上查看和记录性能计数器

的数值。

3.1操作系记录数器及分析1A、WindoWSAMemory:availablembytes,pages/sec,pagesread/sec,pag

efaults/sec,cachebytesAProcess:/^processortime,pagefaults/sec,workset,privateb

ytesAProcessor：%processortime,%usertime,%privilegedtime»%dpctime

Physica1Disk:%disktime,averagediskqueuelength,averagediskread/writequeue1ength,d

iskreads(writes)/sec,averagedisksec/read,averagedisksec/transfePANetworkInterface：bytes

total/secASystem：%totaiprocessortime,fi1edataoperation/sec,processorqueuelength

2、unix

3、内存分析方法4用于分析系统有无碰到内存瓶颈，是否需要通过增长内存等手段提高系统性能表现。A一方面查看me

mory/availablembytes；注意pages/sec,pagesread/sec,pagefaults/sec（反映进行磁盘互换的频率）；根据physicald

isk分析。

4、解决器分析方法A先看system\%Totaiprocessortime,然后看每个cpu的指标，最后分析。

5、磁盘I/O分析方法

计算每个磁盘的I/O数;然后与processor\privilegedtime合并分析;最后根据disksec/transfer分析。

6、进程分析方法A察看%processortime,反映进程消耗的解决其时间：然后查看每个进程产生的页面失效，对于产生最多页

面失效的进程要重点分析；了解进程的process/privatebytes,看是否存在内存泄露。④

7、网络分析方法会networkinterface\bytestotal/sec为发送和接受字节的速率，与当前带宽进行比较。

3.2应用服务器计数器

1、IIS%、J2EE应用服务器计数器Aweblogic：AJVM:heapsize；heapfree

JDBCconnectionpool:waitingforconnectioncurrentcount;connectiontota1count;max

capacity;activeconnectionscurrentcount

executequeue:executethreadcurrentidlecount；pendingrequestoldesttime；servicedreqnest

oldesttime;servicedrequesttota1count;pendingrequestcurrentcount;以、数据库计数器

第4章性能测试工具原理A4.1性能测试工具模型

性能测试工具只能帮助您实行性能测试，并不能帮助您完毕性能测试的需求；a性能测试工具可以根据您的规定以各种方

式提供报表，这些报表是分析的基础。A性能测试工具一般涉及虚拟用户脚本产生器；压力产生器;用户代理；压力调度和控制

系统；压力结果分析工具。

4.2性能测试脚本录制时的协议类型A对于j2ee,建议选择http/https协议。

4.3性能测试工具的选择与评估

工具支持被测系统运营的平台吗？

支持被测系统使用的协议吗？A可以支持我们的特殊规定？会可以提供对我们关心的服务器、应用服务器或是数据库

类型计数器的监控吗？④工具使用的脚本语言功能完善吗？会常用的涉及Loadrunner和silkperformer。

第5章性能测试的组织5.。人员构成经理、测试设计、测试开发、测试执行、测试分析、支持

5.2过程模型

基于ATLM和TMap模型。口、前期准备

保证系统稳定、建立合适的测试团队、测试工具需求确认。％、测试工具引入

选择;培训；应用过程。劣3、测试计划A测试目的（应用领域,测试目的）；用户活动剖析与业务建模（系统日记与用户调查分

析）；拟定性能目的；制定计划。小、测试设计与开发“测试环境设计;测试场景设计;测试用例设计；脚本和辅助工具开发活动。

5、测试执行与管理A建立测试环境；部署测试脚本和测试场景;执行测试和记录结果。外、测试分析

根据测试的目的和目的给出测试结论。

第8章案例三某通信公司的web业务系统性能测试84.1背景

该系统用于管理公司的备品和备件，涉及网络设备的库存管理、库存流转、备品备件的查询记录。

测试的重要目的是验证系统的性能是否达成用户规定。

8.2项目特点

采用J2ee,tomcat,struts+ejb+hibernate«-台unix服务器用作数据库服务器，一台unix服务器用作应用服务器。

性能体现重要是响应时间。协议为http/https。

8.3测试过程

1、前期准备

5人:一个数据库工程师、一个性能测试设计和分析人员、三名性能测试开发和实行人员。

工具需要支持Http/https协议，监控unix/windows服务器的重要性能计数器值，支持oracle数据库计数器值监控，支持tomca

t应用服务器的jvm内存使用状况监控。

2、测试工具引入

选择LoadRunnder;tomacat的jvm自行开发工具来实现。

3、测试计划

（1）测试目的:脸证系统是否达成预期性能指标

（2）用户活动剖析与业务建模：得到典型用户活动分析表,并发用户数和吞吐量

用户活动分析表

业务名称实际使用用户数量业务发生数（笔/天）A

K备件信息200150

单2004000■*

-A库存流转-审批1004000

库存流转-借用1503000

库存流转-还库1503000

库存流转-报废100200

查询记录-备件查询2005000A

查询记录一申请单查询1002023A

导入备件Exce1文献2080

平均天天该系统的用户为600;平均每个用户天天使用4小时；平均每个用户进行500个业务操作;

所以并发用户数：600*4/8=30(U吞吐量:300*500/(4*60*60)=10,浏览数/秒

(3)拟定性能目的：得到性能需求描述z具体描迹

4在典型数据量，页面响数据规模备件5000

00条记录，

应时间不超过10秒半年流转数据750000条记录A

A系统可以稳定运营压力条

件>高于实际系统运营压力1倍

系统稳定鉴定条件：

测试中，各进程内存没有明显变化

A测试中，响应时间和业务能力没有明显变化

a连续测试时间72小时

典型规模的excel备文献规模20M,包含记录50000条

件文献导入时间性能

下，以响应时间)10秒作为负载测试的结束条件,A能承受的用户数获得系统能承受的

最大用户数量4

-A在典型用户数量下，CPU平均使用率不高于75览内存使用率不高于75%；在稳定性测试的压力条件下，CPU

使用率不高于95%,内存使用率不高于90%。4（A）制定期间计划。

A「项目名

称子项目起止时间里程碑成果参与者

测试环境和场景设计2023.3.1-2023.3.2测试环境文档、测试场景文档④测试用例设计和脚本开

发2023.3.3-2023.3.10测试用例文档、测试脚本A测试环境构建2023.3.3-202

3.3.5测试环境、测试环境描述文档

测试工具和场景部署2023.3.11-2023.3.12测试工具部署说明、场景部署说明

执行性能测试2023.3.13-2023.3.15测试结果记录A稳定性测试202

3.3.16-2023.3.20测试结果记录A测试结果分析和报告编写2023.3.21-2023.3.23测试报告

4、测试设计与开发

（D测试环境设计

由于本测试重要与于验证系统在实际环境中的性能能力，因此尽也许选择接近实际环境的配置。

测试环境

备硬件配置软件配置A

A数据库服务器SUNV880月艮务器（1

台）So1aris84“PU8GB内存磁盘阵列Oracle

9.2.0.1

服务器性能计数器脚本

器SUNV880服务器（1台）Solaris8A4CPU8GB

内存磁盘阵列Tomeat5

服务器端应用

A服务器性能计数器脚本

A性能测试Consol

ePC机（1台）WindowsXP+SP1

CPU2.4GHz512MB内存LoadRunnerContro1ler

40GB硬盘LoadRunnerAnalysis

N&crcroftOffic^

负载产生设备PC机(5台)WindowsXP+SPl

CPU2.4GHZ512MB内存LoadRunnerAg

entA40GB硬

盘

基础数据量在需求中已有描述

(2)测试场景设计A设计并发用户数300,每个VU操作之间的时间间隔为30秒A典型测试场景A-

场景名称场景业务及分派比例测试指标性能计数器

4户

派：页面数据库服务器常用性能计数器“应用备件信息100响

应应用服务器cpu使用率

典型申请单100时间应用服务器内存使用率入场景1备件查询

100小于应用服务器JVM可用内存

用户增长模式：10秒响应时间

rampup,每15秒增长4个

迭代时间间隔30秒

运营时间30分钟A

系统用户分派：页面数据库服务器常用性能计数器A应用申请单10

0响应应用服务器cpu使用率A典型审批100时

间应用服务器内存使用蔡场景2还库50小于应用服务器JVM可用内存

A报废1010秒响应时间

用户增长模式：

rampup,每15秒增长4个

迭代时间间隔30秒A运营时间30分钟A

A系统用户分派:页面数据库服务器常用

性能计数器

应用申请单100响应应用服务器CPU使用率

典型审批100时间应用服务器内存使用率

场景3备件查询100小于应用服务器JVM可用内存4报废1

010秒响应时间A用户增长模式：

rampup,每15秒增长4个

—

迭代时间间隔30秒A运营时间30分钟A

稳定用户分派：页面数据库服务器常用性能计数器“性测典型场景3用户

数响应应用服务器cpu使用驷试场的两倍时间应用服

务器内存使用率

景备件查询100小于应用服务器JVM可用内存A运营时间72小

时10秒响应时间

数据用户分派：页面数据库服务器常用性能计数龈导入导入Excel文献

10响应应用服务器cpu使用率

场景申请单100时间应用服务器内存使用率A审批10

0小于应用服务器JVM可用内科用户增长模式：1

0秒响应时间Arampup,每15秒增长4个A迭代时间间隔30秒

4运营时间30分钟

(3)测试用例设计“将用户业务操作形成更具体的用例环节。、审批业务：

用例编号：TC_xxxx_xxx-1

用例条件:用户已经登录，具有审批的权限

用户环节和验证方法：1乐用户单击“库存流转”链接，进入库存流转页面4验证：页面出现库存流转提醒字符串A2、

用户在页面左侧树试图上单击“审批”链接，进入审批页面A验证：页面上出现审批单：列表提醒字符串

3、用户在页面给出的等待审批的申请单列表中选择最上方的一个，单击审批按钮，进入审批页面

验证：给出选中审批单信息,页面上出现被选中审批单的编号

4、用户输入审批信息,单击通过按钮4验证:页面上出现审批通过提醒字符串

(4)脚本和辅助工具开发活动。A

5、测试执行与管理A建立测试环境；部署测试脚本和测试场景;执行测试和记录结果。外、测试分析A根据测试的目的和目的

给出测试结论。

《软件性能测试过程详解与案例剖析》学习笔记1

2023年10月20日星期二13:39

1.RBI(RapidBottleneckIdentify)方法是一种用于快速辨认系统

性能瓶颈的方法。该方法基于以下一些事实：

a.发现的80%系统的性能瓶颈都由吞吐量制约；

b.并发用户数和吞吐量瓶颈之间存在一定的关联；

c.采用吞吐量测试可以更快速定位问题。

RBI方法一方面访问服务器上的“小页面”和“简朴应用”，从应用服务器、网络等基础的层次上了解系

统吞吐量表现；另一方面选择不同的场景,设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，

通过不断增长并发用户数和吞吐量，观测系统的性能表现。

在拟定具体的性能瓶颈时，RBI将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，一方面拟

定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码自身4个环节拟

定系统性能具体的瓶颈。

RB1方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不

是完整的性能测试过程。

PS：可以通过RBI测试，可以顺便发现当前系统所能承受的最大并发用户数和最佳并发用户数。

2.SEI负载测试计划过程

SEI负载测试计划过程(SEILoadTestingPlanningProcess)是一个关注于负载测试计划

的方法，其目的是产生“清楚、易理解、可验证的负载测试计划”。SEI负载测试计划过程涉及6个关注

的区域(Area)：目的、用户、用例、生产环境、测试环境和测试场景。

SEI负载测试计划过程将以上述6个区域作为负载测试计划需要重点关注和考虑的内容,其重点关注以下

几个方面的内容：

a.生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此,在测试环境上

相应用系统进行的负载测试结果很也许不能准确反映该应用系统在生产环境上的实际性能表现，为了规避

这个风险,必须仔细设计测试环境。

b.用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象,因此,必须通过对用户行为进行

分析，依据用户行为模型建立用例和场景。

c.用例:用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用

重要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。

从SEI负载测试计划过程的描述中可以看•到,SEI负载测试计划过程给出了负载测试需要关注的重点区域，

但严格来说，其并不能被称为具体的方法论，由于其仅仅给出了对测试计划过程的一些关注内容，而没有可

以形成实际的可操作的过程。同功能测试同样，性能测试也必须经历测试需求、测试设计、测试执行、测

试分析等阶段，但由于性能测试自身的特殊性(例如，需要引入工具，分析阶段相对重要)，性能测试过程

又不能完全套用功能测试过程。

SEI负载测试计划过程在负载测试需要关注的具体内容上提供了参考,但其并不是一个完整的测试过程。

PS:SEI重要关注的是业务模型、用户比例。建立相对真实的业务模型可以通过系统日记或者用户调查

来获得。

3.性能下降曲线分析方法:四个区域

a.单用户区域baseline

b.性能平坦区benehmark

c.压力区域

d.性能拐点

4.常用理论公式

思考时间RreWslr.t.

PS:在压力测试的时候，一般不需要思考时间，测试系统满负荷的情况下所能支撑的用户数。

在负载测试的时候，需要一定的思考时间，来模拟真实的用户体验。

方法一：

并发数Cconcurreniuser-Nusnualx'r*T^esslonlens111/TtOtaIlimo

最I大并数;CmaxconcurrentuserCanovrrentuser+3*Sqrt(C。。ncuTrentus«

方法二：

根据2.8原则，计算并发用户数。

最大并发数=并发数*r(r,2~3)

方法三：

根据经验，始终有10%用户一直作用于应用系统。

吞吐量

F-UavrrAgerequestminber*CroncurrentvXer

F-Nnunh*rus«r*R>©questrate/Ttoia1ijw

PS:相同的吞吐量下，并发用户数不同可以得到不同的