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

《2022年软件性能测试过程详解与案例剖析学习笔记.docx》由会员分享，可在线阅读，更多相关《2022年软件性能测试过程详解与案例剖析学习笔记.docx（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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、下降曲线分析法 描述性能随用户数量增长而显现下降趋势的曲线；4、LoadRunner 的性能测试过程包括方案测试、测试设计、创建VUvirtual user脚本、创建测试场景、运行测试场景、分析结果；5、Segue供应的性能测试过程先确定性能基线, 然后设定可接受的性能目标,用不同的并发用户数等重复测试；适合性能调优和性能优化,通过不断的try-check过程,逐步找到可能导致性能瓶颈的地方并对其优化；6、PTGM模型 performance testing general model；分为测试前期预备、测试工具引入、测试方案、测试设计与开发、测试执行和治理以及测 试分析；第 2 章 性能测试

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

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

7、够连续使用系统,假如这种情形发生,用户将受多大 程度影响；名师归纳总结 - - - - - - -第 1 页,共 8 页精选学习资料 - - - - - - - - - 学习必备 欢迎下载2.2 应用领域分析 1、才能验证 performance testing,reliability testing,stress testing,failover testing 2、才能规划 load testing,configuration testing,stress testing 3、性能调优 configurationg testing,load testing,stress testing,f

8、ailover testing 4、缺陷发觉 concurrency testing,stress testing,failover testing 第 3 章 性能计数器及性能分析方法 用来衡量被测系统当前的状况和进行性能测试结果分析；可在操作系统级、应用服务器级和数据库级别上查看和记录性能计数器 的数值；3.1 操作系统计数器及分析 1、Windows Memory:available mbytes,pages/sec,pages read/sec,page faults/sec,cache bytes Process:%processor time,page faults/sec,wor

9、k set,private bytes Processor:%processor time,%user time,%privileged time,%dpc time Physical Disk:%disk time,average disk queue length,average disk read/write queue length,disk readswrites/sec,average disk sec/read,average disk sec/transfer Network Interface:bytes total/sec System:%total processor t

10、ime,file data operation/sec,processor queue length 2、unix 3、内存分析方法 用于分析系统有无遇到内存瓶颈,是否需要通过增加内存等手段提高系统性能表现；第一查看 memory/available mbytes ；留意 pages/sec,pages read/sec,page faults/sec反映进行磁盘交换的频率 ；依据 physical disk 分析；4、处理器分析方法先看 system%Total processor time,然后看每个cpu 的指标,最终分析；5、磁盘 I/O 分析方法运算每个磁盘的I/O 数；然后与pro

11、cessorprivileged time合并分析；最终依据disk sec/transfer分析；6、进程分析方法 观看 %processor time ,反映进程消耗的处理其时间；然后查看每个进程产生的页面失效,对于产生最多页面失效的进程要重点分析；明白进程的process/private bytes,看是否存在内存泄露；7、网络分析方法 network interfacebytes total/sec 为发送和接收字节的速率,与当前带宽进行比较；3.2 应用服务器计数器 1、IIS 2、J2EE应用服务器计数器 weblogic： JVM:heap size;heap free JDBC

12、 connection pool:waiting for connection current count;connection total count;max capacity;active connections current count execute queue:execute thread current idle count;pending request oldest time;serviced request oldest time;serviced request total count;pending request current count; 3、数据库计数器第 4

13、章 性能测试工具原理 4.1 性能测试工具模型 性能测试工具只能帮忙您实施性能测试,并不能帮忙您完成性能测试的需求；性能测试工具能够依据您的要求以各种方式供应报表,这些报表是分析的基础；性能测试工具一般包括虚拟用户脚本产生器；压力产生器；用户代理；压力调度和掌握系统；压力结果分析工具；4.2 性能测试脚本录制时的协议类型名师归纳总结 对于 j2ee, 建议挑选 http/https协议；第 2 页,共 8 页- - - - - - -精选学习资料 - - - - - - - - - 学习必备 欢迎下载 4.3 性能测试工具的挑选与评估 工具支持被测系统运行的平台吗？支持被测系统使用的协议吗？能

14、够支持我们的特别要求？能够供应对我们关怀的服务器、应用服务器或是数据库类型计数器的监控吗？工具使用的脚本语言功能完善吗？常用的包括Loadrunner 和 silk performer；第 5 章 性能测试的组织 5.1 人员构成 经理、测试设计、测试开发、测试执行、测试分析、支持5.2 过程模型 基于 ATLM和 TMap模型；1、前期预备 保证系统稳固、建立合适的测试团队、测试工具需求确认；2、测试工具引入 挑选；培训；应用过程；3、测试方案 测试目的（应用领域,测试目标）；用户活动剖析与业务建模（系统日志与用户调查分析）；确定性能目标；制定方案；4、测试设计与开发 测试环境设计；测试场景

15、设计；测试用例设计；脚本和帮助工具开发活动；5、测试执行与治理 建立测试环境；部署测试脚本和测试场景；执行测试和记录结果；6、测试分析 依据测试的目的和目标给出测试结论；第 8 章 案例三某通信企业的 web业务系统性能测试 8.1 背景 该系统用于治理企业的备品和备件,包括网络设备的库存治理、库存流转、备品备件的查询统计；测试的主要目的是验证系统的性能是否达到用户要求；8.2 项目特点采纳 J2ee,tomcat,struts+ejb+hibernate；一台 unix 服务器用作数据库服务器,一台unix 服务器用作应用服务器；性能表达主要是响应时间；协议为http/https；8.3 测

16、试过程 1、前期预备 5 人：一个数据库工程师、一个性能测试设计和分析人员、三名性能测试开发和实施人员；工具需要支持Http/https协议, 监控 unix/windows服务器的主要性能计数器值,支持 oracle数据库计数器值监控,支持 tomcat应用服务器的jvm 内存使用状况监控；2、测试工具引入 挑选 LoadRunnder； tomacat 的 jvm 自行开发工具来实现；3、测试方案（1）测试目的：验证系统是否达到预期性能指标（2）用户活动剖析与业务建模：得到典型用户活动分析表,并发用户数和吞吐量 用户活动分析表 - 业务名称实际使用用户数量业务发生数（笔 / 天） - 备件

17、信息 200 1500 - 库存流转 -申请单 200 4000 - 库存流转 -审批 100 4000 - 库存流转 -借用 150 3000 - 库存流转 -仍库 150 3000 - 库存流转 -报废 100 200 - 查询统计 -备件查询 200 5000 - 查询统计 -申请单查询 100 2000 - 导入备件 Excel 文件 20 80 - 名师归纳总结 - - - - - - -第 3 页,共 8 页精选学习资料 - - - - - - - - - 学习必备 欢迎下载平均每天该系统的用户为 600；平均每个用户每天使用 4 小时；平均每个用户进行 500 个业务操作；所以并

18、发用户数：600*4/8=300 吞吐量： 300*500/4*60*60=10, 浏览数 / 秒（3）确定性能目标：得到性能需求描述具体描述 - 在典型数据量,页面响 数据规模备件 500000 条记录,应时间不超过 10 秒 半年流转数据 750000 条记录 - 系统能够稳固运行压力条件：高于实际系统运行压力1 倍系统稳固判定条件：测试中,各进程内存没有明显变化测试中,响应时间和业务才能没有明显变化连续测试时间 72 小时 - 典型规模的excel 备文件规模 20M,包含记录50000 条件文件导入时间性能 - 在 10 秒的响应时间下,以响应时间 10 秒作为负载测试的终止条件,能承

19、担的用户数 获得系统能承担的最大用户数量 - 在典型用户数量下,cpu 平均使用率不高于75%,内存使用率不高于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 测试工具部署说明、场景部署说明执

20、行性能测试 2005.3.13-2005.3.15 测试结果记录稳固性测试 2005.3.16-2005.3.20 测试结果记录测试结果分析和报告编写 2005.3.21-2005.3.23 测试报告- 4、测试设计与开发 1 测试环境设计由于本测试主要与于验证系统在实际环境中的性能才能,因此尽可能挑选接近实际环境的配置；测试环境 - 设备硬件配置软件配置 - 数据库服务器 SUN V880 服务器（ 1 台） Solaris 8 Oracle 9.2.0.1 4CPU 8GB 内存磁盘阵列服务器性能计数器脚本 - 应用服务器 SUN V880 服务器（ 1 台）磁盘阵列 Solaris 8

21、Tomcat 5 4CPU 8GB 内存服务器端应用服务器性能计数器脚本 - 性能测试 Console PC 机（ 1 台） CPU2.4GHZ 512MB内存 WindowsXP+SP1 LoadRunner Controller 40GB 硬盘 LoadRunner Analysis Microsoft Office - 负载产生设备 PC 机（ 5 台） CPU2.4GHZ 512MB内存 WindowsXP+SP1 硬 LoadRunner Agent 40GB盘 - 基础数据量在需求中已有描述 2 测试场景设计名师归纳总结 设计并发用户数300,每个 VU操作之间的时间间隔为30 秒

22、第 4 页,共 8 页- - - - - - -精选学习资料 - - - - - - - - - 学习必备 欢迎下载典型测试场景- 场景名称场景业务及安排比例测试指标性能计数器- 系统用户安排：页面数据库服务器常用性能计数器应用备件信息100 响应应用服务器cpu 使用率典型申请单 100 时间应用服务器内存使用率场景 1 备件查询 100 小于应用服务器JVM可用内存用户增长模式： 10 秒响应时间 ramp up, 每 15 秒增加 4 个 迭代时间间隔 30 秒 运行时间 30 分钟- 系统用户安排：页面数据库服务器常用性能计数器应用申请单 100 响应应用服务器cpu 使用率典型审批

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

24、场景3 用户数应用服务器cpu 使用率试场的两倍时间应用服务器内存使用率景备件查询 100 小于应用服务器JVM可用内存运行时间72 小时 10 秒响应时间- 数据用户安排：页面数据库服务器常用性能计数器导入导入 Excel 文件 10 响应应用服务器cpu 使用率场景申请单 100 时间应用服务器内存使用率审批 100 10 秒小于应用服务器JVM可用内存用户增长模式：响应时间 ramp up, 每 15 秒增加 4 个 迭代时间间隔 30 秒 运行时间 30 分钟- 3 测试用例设计 将用户业务操作形成更具体的用例步骤；审批业务：用例编号： TC_xxxx_xxx-1 用例条件：用户已经登

25、录,具有审批的权限 用户步骤和验证方法： 1 、用户单击“ 库存流转” 链接,进入库存流转页面 验证：页面显现库存流转提示字符串 2 、用户在页面左侧树试图上单击“ 审批” 链接,进入审批页面 验证：页面上显现审批单：列表提示字符串 3 、用户在页面给出的等待审批的申请单列表中挑选最上方的一个,单击审批按钮,进入审批页面 验证：给出选中审批单信息,页面上显现被选中审批单的编号 4 、用户输入审批信息,单击通过按钮 验证：页面上显现审批通过提示字符串 4 脚本和帮助工具开发活动；5、测试执行与治理 建立测试环境；部署测试脚本和测试场景；执行测试和记录结果；名师归纳总结 - - - - - - -

26、第 5 页,共 8 页精选学习资料 - - - - - - - - - 学习必备 欢迎下载 6、测试分析 依据测试的目的和目标给出测试结论；软件性能测试过程详解与案例剖析学习笔记 1 20XX年 10 月 20 日 星期二 13:39 1. RBI Rapid Bottleneck Identify 方法是一种用于快速识别系统性能瓶颈的方法；该方法基于以下一些事实：a. 发觉的 80%系统的性能瓶颈都由吞吐量制约；b. 并发用户数和吞吐量瓶颈之间存在肯定的关联；c. 采纳吞吐量测试可以更快速定位问题；RBI 方法第一拜访服务器上的“ 小页面” 和“ 简洁应用” ,从应用服务器、网络等基础的层次

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

28、 负载测试方案过程 SEI 负载测试方案过程（SEI Load Testing Planning Process）是一个关注于负载测试方案的方法,其目 标是产生 “ 清楚、 易懂得、 可验证的负载测试方案”；SEI 负载测试方案过程包括 6 个关注的区域 （Area ）：目标、用户、用例、生产环境、测试环境和测试场景；SEI 负载测试方案过程将以上述 6 个区域作为负载测试方案需要重点关注和考虑的内容,其重点关注以下 几个方面的内容：a. 生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在肯定的差异,因此,在测试环境 上对应用系统进行的负载测试结果很可能不能精确反映该应用系统在生产

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

30、的过程；同功能测试一样,性能测试也必需经受测试需求、测试设计、测试执行、测试分析等阶段,但由于性能测试自身的特别性（例如,需要引入工具,分析阶段相对重要）,性能测试 过程又不能完全套用功能测试过程；SEI 负载测试方案过程在负载测试需要关注的具体内容上供应了参考,但其并不是一个完整的测试过程；PS:SEI 主要关注的是业务模型、用户比例；建立相对真实的业务模型可以通过系统日志或者用户调查来获 得；3. 性能下降曲线分析方法：四个区域 a. 单用户区域 baseline b. 性能平整区 benchmark c. 压力区域 d. 性能拐点名师归纳总结 - - - - - - -第 6 页,共 8

31、 页精选学习资料 - - - - - - - - - 学习必备 欢迎下载4. 常用理论公式摸索时间 R request rate = Tsession length / Tthink timePS:在压力测试的时候,一般不需要摸索时间,测试系统满负荷的情形下所能支撑的用户数；在负载测试的时候,需要肯定的摸索时间,来模拟真实的用户体验；方法一：并发数 C concurrent user = N user number * Tsession length / Ttotal time concurrent user 最大并发数： Cmax concurrent user Cconcurrent us

32、er + 3 * sqrtC方法二：依据 2.8 原就,运算并发用户数；最大并发数 = 并发数 * r r, 23 方法三：依据体会,始终有 10 %用户始终作用于应用系统；吞吐量 F = Uaverage request number * Cconcurrent user F = Nnumber user * Rrequest rate / Ttotal time PS: 相同的吞吐量下,并发用户数不同可以得到不同的结果；软件性能测试过程详解与案例剖析学习笔记 2 20XX年 10 月 20 日 星期二 13:40 5. 性能调优常见的错误 a. 数据库记录,每次做测试前后要保证数据量的一样

33、； b.java和.net应用在使用前需要预热；6. 调优标准过程7. 稳固性测试 MTBF 平均无故障时间,假如在 CPU处于较大压力下运行一段时间,就“ 等同” 于让系统在压力较小的情形下较长时间的运行,因此通过在压力测试环境下进行测试,可以看成是一种“ 压缩时间的测试方法” ； a. 这种性能测试方法的主要目的是验证系统是否支持长期稳固的运用,在大的压力下进行一个较长的时间的测试,假如系统不显现问题或是不好的征兆,基本上可以确定系统具备长期稳固运行的条件； b. 这种性能测试方法需要在压力下连续一段时间的运行,对于一般的非关键的大型应用来说,一般让系统处于可能的峰值压力下,进行 23 天

34、的稳固性测试基本就够了； c. 测试过程中需要观看系统运行状况,随着时间的推移,响应时间有明显变化或者资源使用率有明显的波动,都可能是系统部稳固的征兆,需要重点观看；8.PTGM 模型 a. 测试前期预备a.a. 保证系统的稳固 a.b. 建立核实的测试团队 b. 测试工具的引入 c. 测试方案 d. 测试设计与开发 d.a. 测试环境设计 d.b. 场景设计 e. 测试执行和治理 e.a. 建立测试环境部署测试脚本和场景 e.b. 执行测试和记录结果 f. 测试分析 PS: 测试执行完后,即分析,同时记录结构和场景,保护和治理测试场景名师归纳总结 - - - - - - -第 7 页,共 8

35、 页精选学习资料 - - - - - - - - - 学习必备 欢迎下载测试方案中的步骤： 1. 测试目的,明确性能测试领域测试领域性能测试目标性能目标才能验证验证系统在给定环境中的性能重点关注的关键业务响应时间、吞吐量规划才能验证系统的性能才能,找出系统才能扩充的关键点,业务的性能瓶颈给出改善其性能扩展才能的建议性能调优提高系统的性能表现重点关注的关键业务响应时间、吞吐量发觉缺陷发觉系统中的缺陷无 2. 用户活的剖析于业务建模 2.1. 用户活动的剖析2.1.1. 通过系统日志,明白用户的活动,业务路径,分型出用户关注,常用业务模块2.1.2. 通过用户调查 2.2. 业务建模, 采纳流程图方式绘出个进程之间的交互关系和数据流向,业务建模是对业务系统中的行为及其实现方式和发件的建模 3. 性能目标 4. 制定测试时间方案 PS: 1. 多台服务器和 pc 机进行性能测试的时候需要时间同步 2. 用户数是用户数,业务数是业务数,1 个用户可以进行多次同样的业务； 3. 基础数据量,需要我们来核实数据是否足够,因此在测试前明白数据库中将用到的表,以及表保护的的周期；名师归纳总结 a.用到表,需要确认；第 8 页,共 8 页 b.表保护,（清理周期）； c.按周期和业务量估算基础数据；- - - - - - -