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

1、学习笔记软件性能测试过程详解与案例剖析软件性能测试过程详解与案例剖析学习笔记1看的顺序不是按照章节来的。so第4章 性能测试工具原理4.1 性能测试工具模型性能测试工具通常用来支持压力、负载测试，能够用来录制和生成脚本、设置和部署场景、产生并发用户、向系统施加持续压力1 性能测试不是就用性能测试工具进行测试。性能测试只能帮助测试工程师实施性能测试，并不能帮助您完成性能测试的需求、设计和分析工作2 性能测试工具无法自主进行性能分析，而是根据测试工程师的要求以各种方式提供报表，这些报表可以被用来分析系统性能状况3 性能测试工具的录制和回放 与 功能测试工具的录制和回放的区别 功能测试工具的录制和回

2、放是针对GUI的操作录制，脚本中记录的是用户对控件的操作，主要通过操作和数据来验证功能的正确性性能测试工具的录制和回放 着重强调并发的性能，GUI的许多界面操作对服务器都不构成压力。性能测试工具录制的是服务端和应用之间的通信数据，而不是GUI操作。所以录制的时候要先选择录制的协议4 如何选择协议 取决于应用和客户端的通信协议。对于WEB应用来说，采用HTTP/HTTPS协议4.2 性能测试工具架构1 虚拟用户脚本产生器 Virtual User Generator 通过Proxy代理服务器方式，截获并记录客户端和服务器之间的数据流。 截获数据流后对齐进行协议层上的处理，最终形成的是容易看懂的H

3、TTP业务交互过程脚本。自带IDE环境，用户可以通过IDE对脚本进行修改和调试。2 压力产生器 Player 用于根据脚本内容，产生实际的负载。 例如，如果一个测试场景要求产生100个虚拟用户，则压力产生器会生成100个进程或线程，每个线程都对指定的脚本进行解释执行3 用户代理 Agent4 压力调度和监控系统 Conductor 调度工具：可以根据用户的场景要求，设置各种不同脚本的VU数量，设置同步点等 监控系统：可以对各种数据库、应用服务器、服务器的主要性能计数器进行监控5 压力结果分析工具Analysis 辅助进行测试结果的分析4.2 性能测试脚本录制时的协议类型 取决于应用和客户端的通

4、信协议，而不是根据开发语言等选取协议4.3 性能测试工具的选择与评估1 罗列需要的工具功能列表 是否支持被测系统运行的平台 软硬件 数据库环境 是否支持被测系统使用的协议 是否支持特殊要求，例如防火墙等 是否提供对我们关心的服务器、应用服务器或是数据库类型计数器的监控 工具使用的脚本语言功能是否完善2 工具比较3 成本分析 价格和License方式第5章 性能测试的组织5.1 性能测试团队的人员构成1 项目测试经理 确定测试目标 制定测试计划 监控计划执行 处理项目干系人的交互 发现和处理测试中的风险2 测试设计 根据用户需求和软件需求，从业务的角度分析和整理典型场景， 识别出性能需求 制定合

5、理可行的测试方案和用例3 测试开发 实现测试方案和用例，测试脚本的编写和维护 确定测试过程中需要监控的性能指标4 测试执行 按照测试方案和用例，使用测试工具执行脚本 监控相关的性能指标，记录测试结果5 测试分析 查看测试结果，对照测试目标分析测试数据和测试过程中获取的性能指标 得出测试结论6 支持角色 系统支持 网络支持 数据库支持5.2 性能测试的过程模型性能测试过程通用模型PTGM Performance Test General Model (基于自动化测试生命周期方法ATLM和TMap模型)1 测试前期准备 验证系统基础功能，确保当前应用系统具备性能测试的条件 组建测试团队，根据项目情

6、况，确定人员所需技能 （测试设计、开发、执行、分析等。但大部分情况是一个人完成，脚本可能是开发人员提供） 测试工具需求确认被测系统环境测试工具功能需求操作系统环境测试工具是否能运行在本操作系统上测试工具是否支持对本操作系统的监控应用服务器环境测试工具能否支持对本应用服务器的监控数据库环境测试工具能否支持本数据库的监控应用使用的协议本系统使用了哪些协议哪些协议需要在性能测试中通过工具进行录制和产生负载测试工具能否支持需要进行录制和产生负载的协议网络环境是否需要测试工具支持防火墙是否需要测试工具支持负载均衡测试管理支持测试工具是否能够提供方便的测试结果分析和管理 性能预备测试2 测试工具引入 工具

7、选择 功能符合度 工具应用技能培训 测试工作相关人员 确定工具应用过程 确定测试工具在测试中的具体应用范围工具使用过程中的问题解决方法 测试工具的脚本如何管理3 测试计划 性能测试领域分析 不同的性能测试应用领域，性能测试的目标定义会有区别应用领域性能测试目标性能目标能力验证验证系统在给定环境中的性能能力重点关注的关键业务响应时间、吞吐量规划能力验证系统的性能扩展能力，找出系统能力扩充的关键点，给出改善其性能扩展能力的建议业务的性能瓶颈性能调优提供系统的性能表现重点关注的关键业务响应时间、吞吐量发现缺陷发现系统中的缺陷无 用户活动剖析与业务建模目的：寻找用户的关键性能关注点，确定最贴近用户要求

8、的性能目标 用户活动剖析方法：系统日志分析和用户调查分析 业务建模是对业务系统的行为及其实现方式和方法的建模，一般采用流程图的方式描绘出各进程之间的交互关系和数据流向 确定性能目标性能测试目标根据性能测试需求和用户活动分析结果和业务建模来确定 制定测试时间计划4 测试设计与开发 测试环境设计性能测试的结果与测试环境之间的关联性非常大，必须先确定测试的环境。测试环境设计包括系统的软硬件环境、数据环境设计、环境的维护方法。 能力验证领域：明确是在特定的部署环境下进行 规划能力领域：测试环境不特定，但也需要设计基准环境 性能调优领域：调优过程是一个反复的过程，在调优过程中必须保证每次测试时的环境保持

9、不变 测试场景设计测试场景模拟的一般是实际业务运行的剖面，其包括业务、业务比例、测试指标的目标以及需要在测试过程中进行监控的性能计数器。剖面：对性能测试而言，剖面表示的是某个时刻用户使用该应用的典型模式，一般由“用户执行的操作”、“执行不同操作的用户比例”以及“用户使用系统的频率”进行描述。 测试用例设计把针对每个测试场景规划出相应的工具部署、应用部署、测试方法和步骤，这个过程就是测试用例设计活动。测试用例是对测试场景的进一步细化。细化内容包括场景中涉及业务的操作序列描述、场景需要的环境部署等内容。业务描述中一定会给出判断业务是否执行成功的准则。 测试脚本和辅助工具开发测试脚本的开发通常基于“

10、录制”，依靠工具提供的录制功能，可以将需要性能测试关注的业务在工具的录制下操作一遍，然后基于该录制后的脚本，对齐进行修改和调试，确保其可以在性能测试中顺利使用。最常用的脚本修改和调试技巧是参数化、关联、日志输出。5 测试执行和管理 建立测试环境 软硬件系统环境搭建数据库环境搭建应用系统的部署系统设置参数的调整数据环境（使用检查列表Checklist，检查环境的可用性） 部署测试脚本和测试场景通过测试工具部署测试脚本和测试场景。部署完成后，需要一个确认步骤，保证场景部署与设计一致。保证需要监控的计数器都已经部署好相应的监控手段。 执行测试和记录结果测试执行非常简单，一般只需要使用菜单或是按钮就可

11、以完成。记录结果也可以依靠测试工具完成，通过测试工具中的监控模块，可以获取并记录需要关注的性能计数器的值。 如果测试工具不提供，可以用脚本调用操作系统提供的工具，在脚本实现中讲各性能计数器值分析出来并按照一定格式记录在本地文件中。6 测试分析 测试分析过程用于对测试结果进行分析，根据测试的目的和目标给出测试结论。性能测试的分析需要借助各种图表，一般的性能测试工具提供了报表模块来生成不同的图表，报表模块同时还允许用户通过叠加、关联等方式处理和生成新的图表。 如果是自己编写的脚本获取性能计数器的值，则可以通过Excel生成图表。性能分析的通用方法之一：“拐点分析”方法是一种利用性能计数器曲线图上的

12、拐点进行性能分析的方法。基本思想是基于这个事实：性能产生瓶颈是由于某个资源的使用达到了极限，此时的表现是随着压力增大系统性能表现急剧下降，因此只要关注性能表现上的“拐点”，获取拐点附近的资源使用情况，就能够定位系统性能瓶颈。但只能定位到资源上的制约，无法直接定位引起制约的原因。第2章 性能测试的应用领域2.1 性能测试的方法1性能测试Performance Testing 通过模拟生成运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求。 一个典型的场景包括操作序列、并发用户数量条件。且要有确定的性能目标。性能目标的描述基本上是：要求系统在100个并发用户的条件下进行某业务操作，

13、响应时间不超过5秒。2负载测试 Load Testing 通过在被测系统上不断增加压力，直到性能指标超过预定指标或某种资源使用已经达到饱和状态。 这种性能测试方法主要目的是找到系统处理能力的极限。这个极限一般会描述成：在给定条件下最多允许120个并发用户访问；在给定条件下最多能够在1小时内处理2100笔业务。预期的性能指标一般会定义为：响应时间不超过10秒、服务器平均CPU利用率低于65%。 负载测试一般用来了解系统的性能容量，或是配合性能调优来使用。（系统在保证一定响应时间的情况下能够允许多少并发用户的访问）3压力测试 Stress Testing 通过增加访问压力（例如增加并发用户数量）使

14、应用系统的资源使用保持在一定的水平。主要目的是检验此时应用表现，重点在于有无出错信息产生，系统对应用的响应时间。4配置测试 Configuration Testing 了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。5并发测试 Concurrency Testing 并发测试方法通过模拟用户的并发访问，测试多用户访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 并发测试主要关注的问题问题类别问题描述内存问题是否有内存泄漏（C/C+）是否有太多的临时对象（Java）是否有太多的超过设计生命周期的对象（Java）数据库问题是否有数据库死锁（Dead

15、Lock）是否经常出现长事务（Long Transaction）线程 进程问题是否出现线程 进程同步失败其他问题是否出现资源争用导致的死锁是否没有正确处理异常（例如超时）导致系统死锁6可靠性测试 Reliability Testing 通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。对于一般的非关键性大型应用来讲，让系统处于可能的峰值压力下，进行2-3天的稳定性测试基本上足够。 测试过程中需要关注系统的运行状况。关注系统内存使用状况，系统的其他资源使用有无明显的变化，以及系统响应时间有无明显变化。如果随着时间推移，响应时间有明显变化，或是系统

16、资源使用率有明显波动，都可能是系统不稳定的征兆，需重点关注。7失效恢复测试 Failover Testing 这种方法是针对有冗余备份和负载均衡的系统设计的。用来验证如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。2.2 性能测试应用领域分析1 能力验证 关注的是，在给定条件下，系统能否具有预期的能力表现。一般采用的测试方法包括性能测试 可靠性测试 压力测试 失效恢复测试2 能力规划 关注的是，在某种可能发生的条件下，系统具有如何的性能能力。一般会描述为：某系统能否支持未来一段时间内的用户增长，或是，应该如何调整系统配置，使系统能够满足增长的用户

17、数的需要。一般采用的测试方法包括负载测试 配置测试 压力测试3 性能调优性能调优的标准过程 确定基准环境、基准负载、基准性能指标 调整系统运行环境和实现方法，执行测试 记录测试结果，进行分析性能调优主要测试方法是配置测试 负载测试 压力测试 失效恢复测试4 缺陷发现主要目的是发现系统中存在的缺陷，并没有可以参照的性能指标或是需要达到的性能目标。一般采用的测试方法：并发测试 压力测试第3章 性能计数器及性能分析方法 性能计数器通常被用来衡量被测系统当前的状况和进行性能测试结果分析。可以在操作系统级别、应用服务器级别和数据库级别上查看和记录性能计数器的数值，在性能测试分析结果对这些数据进行分析。3

18、.1 操作系统计数器及分析1 Windows操作系统的主要计数器类别计数器名称计数器描述MemoryAvailable Mbytes可用物理内存数后续完善。2 UNIX操作系统的主要计数器3 内存分析方法4 处理器分析方法5 磁盘I/O分析方法6 进程分析方法7 网络分析方法3.2 应用服务器计数器1 IIS应用服务器计数器除此之外，还有如下几个需关注的 Active Server Page计数器 重点关注：超时的请求数、脚本运行时期的错误、队列中的请求数、请求等待时间、请求总数、失败的请求总数、送出的总字节数。其中，队列中的请求数和请求等待时间直接反映应用服务器的处理能力。如果队列中的请求数

19、 数值处于一个比较高的水平，同时请求等待时间是一个比较大的值，则应用服务器本身是瓶颈。 Web Service计数器重点关注：Bytes Total/Sec:显示Web服务器发送和接收的总字节数。数值低表明该IIS正在以较低的速度进行数据传输。Connection Refused:数值越低越好。数值高表明网络适配器或处理器存在瓶颈。Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）2 J2EE应用服务器计数器常用的包括WebLogic WebSphere Tomcat等。主要三类：JVM 、JDBC Connection Pool

20、、Execute Queue3.3 数据库计数器数据库服务器常用计数器第1章 软件性能测试基本概念1.1 什么是软件性能 性能是一种指标，表明软件系统或构件对于其及时性要求的符合度；其次，性能是软件产品的一种特性，可以用时间来度量。性能的及时性用响应时间或者吞吐量来衡量。 对于软件性能的关注是多个层面的。1 用户视角的软件性能 从用户角度来说，软件性能就是软件对用户操作的响应时间。2 管理员视角的软件性能 从管理员角度来看，首先软件性能表现在系统的响应时间，同时还更关注和系统状态相关的信息。管理员关心的问题软件性能描述服务器的资源使用状况是否合理资源利用率应用服务器和数据库服务器使用状况是否合

21、理资源利用率系统是否能够实现扩展系统可扩展性系统最多能支持多少用户的访问？系统最大的业务处理量是多少系统容量系统性能可能的瓶颈在哪里系统可扩展性更换哪些设备能够提高系统性能系统可扩展性系统能否支持7*24小时的业务访问系统稳定性3 开发视角的软件性能 从开发角度，最想知道的是 如何通过调整设计和代码实现，或者如何通过调整系统设置等方法提高软件的性能表现；和如何发现和解决软件设计和开发过程中产品的由于多用户访问引起的缺陷；使性能表现不佳的因素，即“性能瓶颈”。开发人员关心的问题软件性能描述架构设计是否合理系统架构数据库设计是否存在问题数据库设计代码是否存在性能方面的问题代码系统中是否有不合理的内

22、存使用方式代码系统中是否存在不合理的线程同步方法设计与代码系统中是否存在不合理的资源竞争设计与代码1.2 软件性能的几个主要术语1 响应时间 呈现时间+系统响应时间 呈现时间是指数据在客户端收到响应数据后呈现页面所消耗的时间。 系统响应时间是指应用系统从请求发出开始到客户端接收到数据所消耗的时间。合理的响应时间取决于实际的用户需求。2 并发用户数并发用户数决定与具体的业务场景，一般会先对业务分解，分析出其中典型业务场景，然后基于场景采用某些方法获取其并发用户数。（业务并发用户数）3 吞吐量吞吐量是指单位时间内系统处理的客户请求的数量。4 性能计数器 性能计数器Counter是描述服务器或操作系

23、统性能的一些数据指标。5 思考时间 思考时间Think Time，从业务角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。对于交互式应用，一般模式是，用户在发出一个请求后，等待一段时间，再发出下一个请求。在脚本中，思考时间提醒为脚本中两个请求语句之间的间隔时间。如何计算思考时间：步骤如下： 首先计算出系统的并发用户数； 统计出系统平均的吞吐量； 统计出平均每个用户发出的请求数量； 根据公式6计算出思考时间。1.3 软件性能测试方法论1 SEI负载测试计划过程 SEI Load testing planning process 其目标是产生：清晰、易理解、可验证的负载测试计划SE

24、I负载此时计划过程包括6个关注的区域：目标、用户、用例、生产环境、测试环境、测试场景。缺点：只给出了负载测试需要关注的重点区域，但没有形成实际可以操作的过程。2 RBI方法 Rapid Bottleneck Identify 用于快速识别系统性能瓶颈的方法。该方法基于以下事实： 发现的80%的系统的性能瓶颈都是由吞吐量制约； 并发用户数和吞吐量之间存在一定的关联； 采用吞吐量测试可以更快速定位问题。3 性能下降曲线分析法 实际上描述的是性能随用户数增长而出现下降趋势的曲线。这里的性能可以是响应时间，也可以是吞吐量或单击数/秒的数据。 主要关注：系统性能最优秀的区间、系统性能开始变坏的区间、系统

25、性能急剧下降的拐点。 从而找到性能瓶颈的原因，和为性能调优提供依据。4 LoadRunner的性能测试过程 LR将性能测试过程分为6个步骤。 计划测试阶段：收集测试需求、确定典型场景； 测试设计阶段：设计测试用例； 创建VU脚本阶段：根据设计的用例创建脚本； 创建测试场景阶段：设计和设置测试场景，包括设定监控指标； 运行测试场景阶段：执行已经创建的测试场景，收集相应数据； 分析结果阶段：结果分析和报告工作。缺点：整个过程都紧密与LR工具集成，没有兼顾使用其他工具，没有普适性。5 Segue提供的性能测试过程 Silk Performer提供的性能测试过程从确定性能基线开始，通过单用户对应用的访问获取性能取值的基线，然后设定可接受的性能目标（响应时间），用不同的并发用户数等重复进行测试。适合性能调优和性能优化。缺点：过于和LR一样，过于依赖工具本身，同时缺乏对计划、设计阶段的明确划分。6 PTGM模型 性能测试过程通用模型PTGM 测试前期准备 测试工具引入 测试计划 测试设计与开发 测试执行和管理 测试分析