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

1、学习必备欢迎下载第一章 性能测试基本概念1.1 软件性能从用户的角度，软件性能就是软件对用户操作的响应时间；从治理员的角度，软件性能第一表现在响应时间上；仍包括资源利用率、可扩展性、系统容量（并发等）和系统稳固性等；为了保证系统的稳固运行和连续的良好性能；对于开发人员而言，最想知道“如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现”和“如何发觉并解决软件设计和开发过程中产生的由于过多用户拜访引起的缺陷”，也就是性能瓶颈和大量用户拜访时的缺陷；关注的是系统架构、数据库设计、代码和设计；所以在性能测试时，既要关注响应时间，仍要关注软件可扩展性、并发才能等指标，仍要为性能

2、问题定位；1.2 术语1、响应时间系统响应时间为应用系统从发出恳求开头到客户端接收到响应所消耗的时间；合理的响应时间取决于实际用户的需求；2、并发用户数有两种懂得，一种是同一时间段拜访系统的用户数量，一种是服务器所能承担的压力（同时发出恳求的客户）；在性能测试中我们更关注前者，业务并发用户数；公式 c=nl/t, 运算平均并发用户数，仍可用c=n/10 仍做简洁的估量； n 为每天拜访系统的用户数；仍可以通过分析服务器的日志来明白用户的使用状态；3、吞吐量单位时间内系统处理的客户恳求的数量，恳求数/ 秒，页面数 / 秒，拜访数 / 天，业务数 / 小时，字节数 / 天；可用于衡量是否达到了预期

3、设计目标，帮助分析性能瓶颈；4、性能计数器描述服务器或操作系统性能的一些数据指标；例如，内存数、进程时间；用于监控和分析；常与资源利用率进行横向对比，例如cpu 占用率 68%；5、摸索时间（休眠时间）用户在进行操作时，每个恳求之间的间隔时间；1.3 方法1、sei 负载测试方案过程关注于负载测试方案的方法，目标是产生清楚、易懂得、可验证的负载测试方案；关注目标、用户、用例、生产环境、测试环境和测试场景；2、rbi 方法rapid bootleneck identify,用于快速识别系统性能瓶颈的方法；3、性能下降曲线分析法描述性能随用户数量增长而显现下降趋势的曲线；4、loadrunner

4、的性能测试过程包括方案测试、测试设计、创建vuvirtual user脚本、创建测试场景、运行测试场景、分析结果；5、segue供应的性能测试过程先确定性能基线， 然后设定可接受的性能目标， 用不同的并发用户数等重复测试；适合性能调优和性能优化， 通过不断的 try-check过程，逐步找到可能导致性能瓶颈的地方并对其优化；6、ptgm模型performance testing general model；分为测试前期预备、测试工具引入、测试方案、测试设计与开发、测试执行和治理以及测试分析；第 2 章 性能测试的应用领域2.1 性能测试的方法1、性能测试 performance testing

5、模拟生产运行的业务压力气和使用场景组合，测试系统的性能是否满意生产性能的要求；2、负载测试 load testing通过在系统上不断增加压力，直到性能指标超过预定或某种资源的使用达到饱和；找到系统的处理极限；3、压力测试 stress testing测试系统在肯定饱和状态下，系统能够处理的会话才能，以及系统是否会显现错误；常用于测试系统的稳固性；4、配置测试 configuration testing通过对被测软件的软 / 硬件环境的调整，明白各种不同环境对系统性能的影响的程度，从而找到系统各项资源的最优安排原就；5、并发测试 concurrency testing模拟用户的并发拜访，测试多用

6、户并发拜访同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题；关注内存是否有太多暂时对象、超过设计生命周期的对象、数据库死锁、常常显现长事务、是否显现线程/ 进程同步失败、资源争用导致死锁、未处理反常导致死锁；6、牢靠性测试 reliability testing通过给系统加载肯定的业务压力的情形下，让应用系统连续运行一段时间，测试系统在这种条件下能否稳固运行；7、实效复原测试 failover testing针对冗余备份和负载均衡的系统；检验假如系统局部发生故障，用户是否能够连续使用系统，假如这种情形发生，用户将受多大程度影响；2.2 应用领域分析1、才能验证performan

7、ce testing,reliability testing,stress testing,failover testing 2、才能规划load testing,configuration testing,stress testing 3、性能调优configurationg testing,load testing,stress testing,failover testing 4、缺陷发觉concurrency testing,stress testing,failover testing第 3 章 性能计数器及性能分析方法用来衡量被测系统当前的状况和进行性能测试结果分析；可在操作系统级

8、、应用服务器级和数据库级别上查看和记录性能计数器的数值；3.1 操作系统计数器及分析1、windowsmemory:available mbytes,pages/sec,pages read/sec,page faults/sec,cache bytes process:%processor time,page faults/sec,work set,private bytes processor:%processor time,%user time,%privileged time,%dpc timephysical disk:%disk time,average disk queue le

9、ngth,average disk read/write queue length,disk readswrites/sec,average disk sec/read,average disk sec/transfernetwork interface:bytes total/secsystem:%total processor time,file data operation/sec,processor queue length2、unix3、内存分析方法用于分析系统有无遇到内存瓶颈，是否需要通过增加内存等手段提高系统性能表现；第一查看 memory/availablembytes ；留意

10、 pages/sec,pagesread/sec,pagefaults/sec反映进行磁盘交换的频率 ；依据 physical disk 分析；4、处理器分析方法先看 system%total processor time,然后看每个 cpu 的指标，最终分析；5、磁盘 i/o 分析方法运算每个磁盘的 i/o 数；然后与 processorprivileged time合并分析；最终依据disk sec/transfer分析；6、进程分析方法观看 %processor time ，反映进程消耗的处理其时间；然后查看每个进程产生的页面失效，对于产生最多页面失效的进程要重点分析；明白进程的 pro

11、cess/private bytes,看是否存在内存泄露；7、网络分析方法network interfacebytes total/sec为发送和接收字节的速率，与当前带宽进行比较；3.2 应用服务器计数器1、iis2、j2ee 应用服务器计数器weblogic： jvm:heap size;heap freejdbc connection pool:waiting for connection current count;connection total count;max capacity;active connections current countexecute queue:exec

12、ute thread current idle count;pending request oldest time;serviced request oldest time;serviced request total count;pending request current count;3、数据库计数器第 4 章 性能测试工具原理4.1 性能测试工具模型性能测试工具只能帮忙您实施性能测试，并不能帮忙您完成性能测试的需求； 性能测试工具能够依据您的要求以各种方式供应报表，这些报表是分析的基础；性能测试工具一般包括虚拟用户脚本产生器；压力产生器；用户代理；压力调度和掌握系统；压力结果分析工具；

13、4.2 性能测试脚本录制时的协议类型对于 j2ee, 建议挑选 http/https协议；4.3 性能测试工具的挑选与评估工具支持被测系统运行的平台吗？ 支持被测系统使用的协议吗？能够支持我们的特别要求？能够供应对我们关怀的服务器、应用服务器或是数据库类型计数器的监控吗？ 工具使用的脚本语言功能完善吗？常用的包括 loadrunner 和 silk performer；第 5 章 性能测试的组织5.1 人员构成经理、测试设计、测试开发、测试执行、测试分析、支持5.2 过程模型基于 atlm和 tmap模型；1、前期预备保证系统稳固、建立合适的测试团队、测试工具需求确认；2、测试工具引入挑选；培

14、训；应用过程；3、测试方案测试目的（应用领域，测试目标）；用户活动剖析与业务建模（系统日志与用户调查分析）；确定性能目标；制定方案；4、测试设计与开发测试环境设计；测试场景设计；测试用例设计；脚本和帮助工具开发活动；5、测试执行与治理建立测试环境；部署测试脚本和测试场景；执行测试和记录结果；6、测试分析依据测试的目的和目标给出测试结论；第 8 章 案例三某通信企业的web业务系统性能测试8.1 背景该系统用于治理企业的备品和备件，包括网络设备的库存治理、库存流转、备品备件的查询统计；测试的主要目的是验证系统的性能是否达到用户要求；8.2 项目特点采纳 j2ee,tomcat,struts+ej

15、b+hibernate；一台 unix 服务器用作数据库服务器，一台unix 服务器用作应用服务器；性能表达主要是响应时间；协议为http/https；8.3 测试过程1、前期预备5 人：一个数据库工程师、一个性能测试设计和分析人员、三名性能测试开发和实施人员；工具需要支持 http/https协议， 监控 unix/windows服务器的主要性能计数器值，支持 oracle数据库计数器值监控，支持 tomcat应用服务器的 jvm 内存使用状况监控；2、测试工具引入挑选 loadrunnder； tomacat 的 jvm 自行开发工具来实现；3、测试方案（1） 测试目的：验证系统是否达到预

16、期性能指标（2） 用户活动剖析与业务建模：得到典型用户活动分析表，并发用户数和吞吐量用户活动分析表业务名称实际使用用户数量业务发生数（笔 / 天）备件信息2001500库存流转- 申请单2004000库存流转- 审批1004000库存流转- 借用1503000库存流转- 仍库1503000库存流转- 报废100200查询统计- 备件查询2005000查询统计- 申请单查询1002000导入备件excel 文件2080平均每天该系统的用户为600；平均每个用户每天使用4 小时；平均每个用户进行500 个业务操作；所以并发用户数： 600*4/8=300吞吐量： 300*500/4*60*60=1

17、0,浏览数 / 秒（3） 确定性能目标：得到性能需求描述具体描述在典型数据量，页面响数据规模备件500000 条记录， 应时间不超过 10 秒半年流转数据750000 条记录系统能够稳固运行压力条件：高于实际系统运行压力1 倍系统稳固判定条件：测试中，各进程内存没有明显变化测试中，响应时间和业务才能没有明显变化连续测试时间 72 小时典型规模的 excel 备文件规模 20m，包含记录 50000 条件文件导入时间性能在 10 秒的响应时间下，以响应时间 10 秒作为负载测试的终止条件， 能承担的用户数获得系统能承担的最大用户数量在典型用户数量下， cpu 平均使用率不高于 75%，内存使用率

18、不高于75%；在稳固性测试的压力条件下，cpu使用率不高于 95%，内存使用率不高于 90%；4 制定时间方案；子项目名称子项目起止时间里程碑成果参加者测试环境和场景设计2005.3.1-2005.3.2测试环境文档、测试场景文档测试用例设计和脚本开发2005.3.3-2005.3.10测试用例文档、测试脚本测试环境构建2005.3.3-2005.3.5测试环境、测试环境描述文档测试工具和场景部署2005.3.11-2005.3.12测试工具部署说明、场景部署说明执行性能测试2005.3.13-2005.3.15测试结果记录稳固性测试2005.3.16-2005.3.20测试结果记录测试结果分

19、析和报告编写2005.3.21-2005.3.23测试报告4、测试设计与开发(1) 测试环境设计由于本测试主要与于验证系统在实际环境中的性能才能，因此尽可能挑选接近实际环境的配置；测试环境设备硬件配置软件配置数据库服务器sun v880 服务器（ 1 台）solaris 84cpu 8gb 内存磁盘阵列oracle 服务器性能计数器脚本应用服务器sun v880 服务器（ 1 台）solaris 84cpu 8gb 内存磁盘阵列tomcat 5服务器端应用服务器性能计数器脚本性能测试 consolepc 机（ 1 台）windowsxp+sp1cpu2.4ghz 512mb内存l

20、oadrunner controller40gb 硬盘loadrunner analysismicrosoft office负载产生设备pc 机（ 5 台）windowsxp+sp1 cpu2.4ghz 512mb内存loadrunner agent40gb硬盘基础数据量在需求中已有描述(2) 测试场景设计设计并发用户数 300，每个 vu操作之间的时间间隔为30 秒典型测试场景场景名称场景业务及安排比例测试指标性能计数器系统用户安排：页面数据库服务器常用性能计数器应用备件信息 100响应应用服务器 cpu 使用率典型场景1申请单 100备件查询 100时间小于应用服务器内存使用率应用服务器

21、jvm可用内存用户增长模式：ramp up,每 15 秒增加4 个10 秒响应时间迭代时间间隔 30 秒运行时间 30 分钟系统用户安排：页面数据库服务器常用性能计数器应用典型申请单 100审批 100响应时间应用服务器 cpu 使用率应用服务器内存使用率场景2仍库 50报废 10小于10应用服务器 jvm可用内存秒响应时间用户增长模式：ramp up,每 15 秒增加4 个迭代时间间隔 30 秒运行时间 30 分钟系统用户安排：页面数据库服务器常用性能计数器应用典型申请单 100审批 100响应时间应用服务器 cpu 使用率应用服务器内存使用率场景3备件查询 100小于应用服务器 jvm可用

22、内存报废 1010秒响应时间用户增长模式：ramp up,每 15 秒增加4 个迭代时间间隔 30 秒运行时间 30 分钟稳固用户安排：页面数据库服务器常用性能计数器性测典型场景 3 用户数响应应用服务器 cpu 使用率试场的两倍时间应用服务器内存使用率景备件查询 100运行时间 72 小时小于应用服务器 jvm可用内存10 秒响应时间数据用户安排：页面数据库服务器常用性能计数器导入导入 excel文件10响应应用服务器 cpu 使用率场景申请单 100时间应用服务器内存使用率审批 100用户增长模式：10 秒小于应用服务器 jvm可用内存响应时间ramp up,每 15 秒增加4 个迭代时间

23、间隔 30 秒运行时间 30 分钟(3) 测试用例设计将用户业务操作形成更具体的用例步骤；审批业务：用例编号： tc_xxxx_xxx-1用例条件：用户已经登录，具有审批的权限用户步骤和验证方法：1 、用户单击“库存流转”链接，进入库存流转页面验证：页面显现库存流转提示字符串2 、用户在页面左侧树试图上单击“审批”链接，进入审批页面验证：页面上显现审批单：列表提示字符串3 、用户在页面给出的等待审批的申请单列表中挑选最上方的一个，单击审批按钮，进入审批页面验证：给出选中审批单信息，页面上显现被选中审批单的编号4 、用户输入审批信息，单击通过按钮验证：页面上显现审批通过提示字符串(4) 脚本和帮

24、助工具开发活动；5、测试执行与治理建立测试环境；部署测试脚本和测试场景；执行测试和记录结果；6、测试分析依据测试的目的和目标给出测试结论；软件性能测试过程详解与案例剖析学习笔记120xx年 10 月 20 日 星期二 13:391. rbi rapid bottleneck identify方法是一种用于快速识别系统性能瓶颈的方法；该方法基于以下一些事实：a. 发觉的 80%系统的性能瓶颈都由吞吐量制约；b. 并发用户数和吞吐量瓶颈之间存在肯定的关联；c. 采纳吞吐量测试可以更快速定位问题；rbi 方法第一拜访服务器上的“小页面”和“简洁应用”，从应用服务器、网络等基础的层次上明白系统吞吐量表

25、现；其次挑选不同的场景，设定不同的并发用户数，使其吞吐量保持基本一样的增长趋势，通过不断增加并发用户数和吞吐量，观看系统的性能表现；在确定具体的性能瓶颈时，rbi 将性能瓶颈的定位依据一种“自上而下”的分析方式进行分析，第一确定是由并发仍是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4 个环节确定系统性能具体的瓶颈；rbi 方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程；ps:可以通过 rbi 测试，可以顺便发觉当前系统所能承担的最大并发用户数和正确并发用户数；2. sei负载测试方案过程sei 负载测试方

26、案过程（ sei load testing planning process）是一个关注于负载测试方案的方法，其目标是产生 “清楚、 易懂得、 可验证的负载测试方案” ；sei 负载测试方案过程包括6 个关注的区域 （area ）： 目标、用户、用例、生产环境、测试环境和测试场景；sei 负载测试方案过程将以上述6 个区域作为负载测试方案需要重点关注和考虑的内容，其重点关注以下几个方面的内容：a. 生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在肯定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能精确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必需

27、认真设计测试环境；b. 用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必需通过对用户行为进行分析，依据用户行为模型建立用例和场景；c. 用例：用例是用户使用某种次序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判定每个业务发生的频度、业务显现性能问题的风险等；从 sei 负载测试方案过程的描述中可以看到，sei 负载测试方案过程给出了负载测试需要关注的重点区域， 但严格来说，其并不能被称为具体的方法论，由于其仅仅给出了对测试方案过程的一些关注内容，而没有能够形成实际的可操作的过程；同功能测试一样，性能测试也必需经受测试需求

28、、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特别性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程；sei 负载测试方案过程在负载测试需要关注的具体内容上供应了参考，但其并不是一个完整的测试过程；ps:sei 主要关注的是业务模型、用户比例；建立相对真实的业务模型可以通过系统日志或者用户调查来获得；3. 性能下降曲线分析方法：四个区域a. 单用户区域 baselineb. 性能平整区 benchmarkc. 压力区域d. 性能拐点学习必备欢迎下载4. 常用理论公式摸索时间 r request rate= t session length/ t th

29、ink timeps:在压力测试的时候，一般不需要摸索时间，测试系统满负荷的情形下所能支撑的用户数；在负载测试的时候，需要肯定的摸索时间，来模拟真实的用户体验；方法一：并发数 c concurrent user= n user number * t session length/ ttotal time最大并发数： cmax concurrent user c concurrent user+ 3 * sqrtcconcurrent user方法二：依据 2.8 原就，运算并发用户数；最大并发数 =并发数 * r r, 23方法三：依据体会，始终有 10 %用户始终作用于应用系统；吞吐量f = u average request number* c concurrent userf = n number user * r request rate/ ttotal timeps: 相同的吞吐量下，并发用户数不同可以得到不同的结果；软件性能测试过程详解与案例剖析学习笔记220xx年 10 月 20 日 星期二 13:405. 性能调优常见的错误a. 数据库记录，每次做测试前后要保证数据量的一样；b.java和.net应用在使用前需要预热；6. 调优标准过程7. 稳固性测试mtb