《2022年软件性能测试过程详解与案例剖析学习笔记》由会员分享，可在线阅读，更多相关《2022年软件性能测试过程详解与案例剖析学习笔记（8页珍藏版）》请在金锄头文库上搜索。
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、的性能测试过程包括计划测试、测试设计、创建VU(virtual user)脚本、创建测试场景、运行测试场景、分析结果。5、Segue提供的性能测试过程先确定性能基线， 然后设定可接受的性能目标，用不同的并发用户数等重复测试。适合性能调优和性能优化，通过不断的try-check过程，逐渐找到可能导致性能瓶颈的地方并对其优化。6、PTGM 模型 performance testing general model。分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析。第 2 章 性能测试的应用领域2.1 性能测试的方法1、性能测试 (performance testi
5、ng) 模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能的要求。2、负载测试 (load testing) 通过在系统上不断增加压力，直到性能指标超过预定或某种资源的使用达到饱和。找到系统的处理极限。3、压力测试 (stress testing) 测试系统在一定饱和状态下，系统能够处理的会话能力，以及系统是否会出现错误。常用于测试系统的稳定性。4、配置测试 (configuration testing) 通过对被测软件的软/ 硬件环境的调整，了解各种不同环境对系统性能的影响的程度，从而找到系统各项资源的最优分配原则。5、并发测试 (concurrency testing)
6、 模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。关注内存是否有太多临时对象、超过设计生命周期的对象、数据库死锁、经常出现长事务、是否出现线程/进程同步失败、资源争用导致死锁、未处理异常导致死锁。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,failover testing 4、缺陷发现 concurrency t
8、esting,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,work set,private bytes Processor:%processo
9、r time,%user time,%privileged time,%dpc time Physical Disk:%disk time,average disk queue length,average disk read/write queue length,disk reads(writes)/sec,average disk sec/read,average disk sec/transfer Network Interface:bytes total/sec System:%total processor time,file data operation/sec,processor
10、 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 数；然后与processorprivileged time合并分析；最后根据disk
11、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 connection pool:waiting for connecti
12、on 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 章 性能测试工具原理4.1 性能测试工具模型性能测试工具只能帮助您实施性能
13、测试，并不能帮助您完成性能测试的需求；性能测试工具能够根据您的要求以各种方式提供报表，这些报表是分析的基础。性能测试工具一般包括虚拟用户脚本产生器；压力产生器；用户代理；压力调度和控制系统；压力结果分析工具。4.2 性能测试脚本录制时的协议类型对于 j2ee, 建议选择 http/https协议。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 2 页，共 8 页学习必备欢迎下载4.3 性能测试工具的选择与评估工具支持被测系统运行的平台吗？支持被测系统使用的协议吗？能够支持我们的特殊要求？能够提供对我们关心的服务器、应用服务器或是数据库类型计数器的监
14、控吗？工具使用的脚本语言功能完善吗？常用的包括Loadrunner 和 silk performer。第 5 章 性能测试的组织5.1 人员构成经理、测试设计、测试开发、测试执行、测试分析、支持5.2 过程模型基于 ATLM 和 TMap模型。1、前期准备保证系统稳定、建立合适的测试团队、测试工具需求确认。2、测试工具引入选择；培训；应用过程。3、测试计划测试目的（应用领域，测试目标）；用户活动剖析与业务建模（系统日志与用户调查分析）；确定性能目标；制定计划。4、测试设计与开发测试环境设计；测试场景设计；测试用例设计；脚本和辅助工具开发活动。5、测试执行与管理建立测试环境；部署测试脚本和测试场
15、景；执行测试和记录结果。6、测试分析根据测试的目的和目标给出测试结论。第 8 章 案例三某通信企业的web业务系统性能测试8.1 背景该系统用于管理企业的备品和备件，包括网络设备的库存管理、库存流转、备品备件的查询统计。测试的主要目的是验证系统的性能是否达到用户要求。8.2 项目特点采用 J2ee,tomcat,struts+ejb+hibernate。一台 unix 服务器用作数据库服务器，一台unix 服务器用作应用服务器。性能体现主要是响应时间。协议为http/https。8.3 测试过程1、前期准备 5 人：一个数据库工程师、一个性能测试设计和分析人员、三名性能测试开发和实施人员。工具
16、需要支持Http/https协议，监控 unix/windows服务器的主要性能计数器值，支持 oracle数据库计数器值监控，支持 tomcat应用服务器的jvm 内存使用状况监控。2、测试工具引入选择 LoadRunnder；tomacat 的 jvm 自行开发工具来实现。3、测试计划（1）测试目的：验证系统是否达到预期性能指标（2）用户活动剖析与业务建模：得到典型用户活动分析表，并发用户数和吞吐量用户活动分析表 - 业务名称实际使用用户数量业务发生数（笔 / 天） - 备件信息 200 1500 - 库存流转 -申请单 200 4000 - 库存流转 -审批 100 4000 - 库存流
17、转 -借用 150 3000 - 库存流转 -还库 150 3000 - 库存流转 -报废 100 200 - 查询统计 -备件查询 200 5000 - 查询统计 -申请单查询 100 2000 - 导入备件 Excel 文件 20 80 - 精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 3 页，共 8 页学习必备欢迎下载平均每天该系统的用户为600；平均每个用户每天使用4 小时；平均每个用户进行500 个业务操作；所以并发用户数：600*4/8=300 吞吐量： 300*500/(4*60*60)=10,浏览数 / 秒（3）确定性能目标：得到
18、性能需求描述详细描述 - 在典型数据量，页面响数据规模备件500000 条记录，应时间不超过10 秒半年流转数据750000 条记录 - 系统能够稳定运行压力条件：高于实际系统运行压力1 倍系统稳定判定条件：测试中，各进程内存没有明显变化测试中，响应时间和业务能力没有明显变化持续测试时间72 小时 - 典型规模的excel 备文件规模 20M ，包含记录50000 条件文件导入时间性能 - 在 10秒的响应时间下，以响应时间 10 秒作为负载测试的结束条件，能承受的用户数获得系统能承受的最大用户数量 - 在典型用户数量下，cpu 平均使用率不高于75% ，内存使用率不高于75% ；在稳定性测试
19、的压力条件下，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 测试结果
20、记录测试结果分析和报告编写 2005.3.21-2005.3.23 测试报告- 4、测试设计与开发 (1) 测试环境设计由于本测试主要与于验证系统在实际环境中的性能能力，因此尽可能选择接近实际环境的配置。测试环境 - 设备硬件配置软件配置 - 数据库服务器 SUN V880 服务器（ 1 台） Solaris 8 4CPU 8GB内存磁盘阵列 Oracle 9.2.0.1 服务器性能计数器脚本 - 应用服务器 SUN V880 服务器（ 1 台） Solaris 8 4CPU 8GB内存磁盘阵列 Tomcat 5 服务器端应用服务器性能计数器脚本 - 性能测试 Console PC 机（ 1
21、台） WindowsXP+SP1 CPU2.4GHZ 512MB内存 LoadRunner Controller 40GB 硬盘 LoadRunner Analysis Microsoft Office - 负载产生设备 PC 机（ 5 台） WindowsXP+SP1 CPU2.4GHZ 512MB内存 LoadRunner Agent 40GB硬盘 - 基础数据量在需求中已有描述 (2) 测试场景设计设计并发用户数300，每个 VU操作之间的时间间隔为30 秒精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 4 页，共 8 页学习必备欢迎下载典型
22、测试场景- 场景名称场景业务及分配比例测试指标性能计数器- 系统用户分配：页面数据库服务器常用性能计数器应用备件信息100 响应应用服务器cpu 使用率典型申请单 100 时间应用服务器内存使用率场景 1 备件查询 100 小于应用服务器JVM可用内存用户增长模式： 10 秒响应时间 ramp up, 每 15 秒增加 4 个迭代时间间隔30 秒运行时间30 分钟- 系统用户分配：页面数据库服务器常用性能计数器应用申请单 100 响应应用服务器cpu 使用率典型审批 100 时间应用服务器内存使用率场景 2 还库 50 小于应用服务器JVM可用内存报废 10 10 秒响应时间用户增长模式： r
23、amp up, 每 15 秒增加 4 个迭代时间间隔30 秒运行时间30 分钟- 系统用户分配：页面数据库服务器常用性能计数器应用申请单 100 响应应用服务器cpu 使用率典型审批 100 时间应用服务器内存使用率场景 3 备件查询 100 小于应用服务器JVM可用内存报废 10 10 秒响应时间用户增长模式： ramp up, 每 15 秒增加 4 个迭代时间间隔30 秒运行时间30 分钟- 稳定用户分配：页面数据库服务器常用性能计数器性测典型场景3 用户数响应应用服务器cpu 使用率试场的两倍时间应用服务器内存使用率景备件查询 100 小于应用服务器JVM可用内存运行时间72 小时 10
24、 秒响应时间- 数据用户分配：页面数据库服务器常用性能计数器导入导入 Excel 文件 10 响应应用服务器cpu 使用率场景申请单 100 时间应用服务器内存使用率审批 100 小于应用服务器JVM可用内存用户增长模式： 10 秒响应时间 ramp up, 每 15 秒增加 4 个迭代时间间隔30 秒运行时间30 分钟- (3) 测试用例设计将用户业务操作形成更详细的用例步骤。审批业务：用例编号： TC_xxxx_xxx-1 用例条件：用户已经登录，具有审批的权限用户步骤和验证方法： 1 、用户单击“库存流转”链接，进入库存流转页面验证：页面出现库存流转提示字符串 2 、用户在页面左侧树试图
25、上单击“审批”链接，进入审批页面验证：页面上出现审批单：列表提示字符串 3 、用户在页面给出的等待审批的申请单列表中选择最上方的一个，单击审批按钮，进入审批页面验证：给出选中审批单信息，页面上出现被选中审批单的编号 4 、用户输入审批信息，单击通过按钮验证：页面上出现审批通过提示字符串 (4) 脚本和辅助工具开发活动。5、测试执行与管理建立测试环境；部署测试脚本和测试场景；执行测试和记录结果。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 5 页，共 8 页学习必备欢迎下载6、测试分析根据测试的目的和目标给出测试结论。软件性能测试过程详解与案例剖析
26、学习笔记1 20XX年 10 月 20 日 星期二 13:39 1. RBI (Rapid Bottleneck Identify) 方法是一种用于快速识别系统性能瓶颈的方法。该方法基于以下一些事实：a. 发现的 80% 系统的性能瓶颈都由吞吐量制约；b. 并发用户数和吞吐量瓶颈之间存在一定的关联；c. 采用吞吐量测试可以更快速定位问题。RBI 方法首先访问服务器上的“小页面”和“简单应用”，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。在确定具体的性能瓶颈时，
27、RBI 将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4 个环节确定系统性能具体的瓶颈。RBI 方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。PS:可以通过 RBI 测试，可以顺便发现当前系统所能承受的最大并发用户数和最佳并发用户数。2. SEI负载测试计划过程SEI 负载测试计划过程（SEI Load Testing Planning Process）是一个关注于负载测试计划的方法，其目标是产生 “清晰、 易理解、 可验证的负载测
28、试计划”。SEI 负载测试计划过程包括6 个关注的区域 （Area）：目标、用户、用例、生产环境、测试环境和测试场景。SEI 负载测试计划过程将以上述6 个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容：a. 生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。b. 用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。c. 用例
29、：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。从 SEI 负载测试计划过程的描述中可以看到，SEI 负载测试计划过程给出了负载测试需要关注的重点区域，但严格来说，其并不能被称为具体的方法论，因为其仅仅给出了对测试计划过程的一些关注内容，而没有能够形成实际的可操作的过程。同功能测试一样，性能测试也必须经历测试需求、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特殊性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程。SEI 负载测试计划
30、过程在负载测试需要关注的具体内容上提供了参考，但其并不是一个完整的测试过程。PS:SEI 主要关注的是业务模型、用户比例。建立相对真实的业务模型可以通过系统日志或者用户调查来获得。3. 性能下降曲线分析方法：四个区域a. 单用户区域 baseline b. 性能平坦区 benchmark c. 压力区域d. 性能拐点精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 6 页，共 8 页学习必备欢迎下载4. 常用理论公式思考时间 Rrequest rate = Tsession length / Tthink timePS:在压力测试的时候，一般不需要思
31、考时间，测试系统满负荷的情况下所能支撑的用户数。在负载测试的时候，需要一定的思考时间，来模拟真实的用户体验。方法一：并发数 Cconcurrent user = Nuser number * Tsession length / Ttotal time最大并发数： Cmax concurrent user Cconcurrent user + 3 * sqrt(C concurrent user) 方法二：根据 2.8 原则，计算并发用户数。最大并发数 = 并发数 * r (r, 23) 方法三：根据经验，始终有10 %用户一直作用于应用系统。吞吐量 F = Uaverage request n
32、umber * Cconcurrent user F = Nnumber user * Rrequest rate / Ttotal time PS: 相同的吞吐量下，并发用户数不同可以得到不同的结果。软件性能测试过程详解与案例剖析学习笔记2 20XX年 10 月 20 日 星期二 13:40 5. 性能调优常见的错误 a. 数据库记录，每次做测试前后要保证数据量的一致。 b.java和.net应用在使用前需要预热。6. 调优标准过程7. 稳定性测试 MTBF 平均无故障时间，如果在CPU 处于较大压力下运行一段时间，则“等同”于让系统在压力较小的情况下较长时间的运行，因此通过在压力测试环境下
33、进行测试，可以看成是一种“压缩时间的测试方法”。 a. 这种性能测试方法的主要目的是验证系统是否支持长期稳定的运用，在大的压力下进行一个较长的时间的测试，如果系统不出现问题或是不好的征兆，基本上可以确定系统具备长期稳定运行的条件。 b. 这种性能测试方法需要在压力下持续一段时间的运行，对于一般的非关键的大型应用来说，一般让系统处于可能的峰值压力下，进行23 天的稳定性测试基本就够了。 c. 测试过程中需要观察系统运行状况，随着时间的推移，响应时间有明显变化或者资源使用率有明显的波动，都可能是系统部稳定的征兆，需要重点观察。8.PTGM 模型 a. 测试前期准备a.a. 保证系统的稳定a.b.
34、建立核实的测试团队 b. 测试工具的引入 c. 测试计划 d. 测试设计与开发d.a. 测试环境设计d.b. 场景设计 e. 测试执行和管理 e.a.建立测试环境部署测试脚本和场景 e.b.执行测试和记录结果 f.测试分析 PS: 测试执行完后，即分析，同时记录结构和场景，维护和管理测试场景精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 7 页，共 8 页学习必备欢迎下载测试计划中的步骤： 1. 测试目的，明确性能测试领域测试领域性能测试目标性能目标能力验证验证系统在给定环境中的性能重点关注的关键业务响应时间、吞吐量规划能力验证系统的性能能力，找出
35、系统能力扩充的关键点，给出改善其性能扩展能力的建议业务的性能瓶颈性能调优提高系统的性能表现重点关注的关键业务响应时间、吞吐量发现缺陷发现系统中的缺陷无 2. 用户活的剖析于业务建模 2.1.用户活动的剖析2.1.1.通过系统日志，了解用户的活动，业务路径，分型出用户关注，常用业务模块2.1.2.通过用户调查 2.2.业务建模， 采用流程图方式绘出个进程之间的交互关系和数据流向，业务建模是对业务系统中的行为及其实现方式和发件的建模 3. 性能目标 4. 制定测试时间计划 PS: 1. 多台服务器和pc 机进行性能测试的时候需要时间同步 2. 用户数是用户数，业务数是业务数，1 个用户可以进行多次同样的业务。 3.基础数据量，需要我们来核实数据是否足够，因此在测试前了解数据库中将用到的表，以及表维护的的周期。 a.用到表，需要确认。 b.表维护，（清理周期）。 c.按周期和业务量估算基础数据。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 8 页，共 8 页
