软件性能测试

1软件性能定义性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来度量。性能的及时性用响应时间或者吞吐量来衡量。而响应时间是对请求做出响应所需要的时间。1.1用户角度比如一个典型的Web应用：用户关注的是软件对用户操作的响应时间。此响应时间=呈现时间+系统响应时间。1.2管理员角度关注系统的响应时间。对于系统管理员来说，用户客户端所消耗的时间是不考虑的。重点就考虑系统响应时间，包括网络耗时、各服务器耗时等。还会关注系统状态，比如资源利用率、系统可扩展性、系统容量、系统稳定性。1.3开发角度关注于如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现。和如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷。会从系统架构、数据库设计、代码质量等方面考虑性能。USERWEBUIWEBServerAPPServerDBServer呈现时间系统响应时间2软件性能的主要术语2.1响应时间对请求做出响应所需要的时间。响应时间=呈现时间+系统响应时间。呈现时间：取决于数据在被客户端收到响应数据后呈现页面所消耗的时间。系统响应时间：应用系统从请求发出开始到客户端接收到数据所消耗的时间。从设计角度考虑，更好的用户体验是，前端在等待数据结果时，提供进度条或逐步显示数据。进一步分解响应时间：网络传输时间+应用延迟时间（Web服务器延迟时间+DB延迟时间）。对于响应时间，其标准不一。一般页面的响应时间，2秒是非常有吸引力，5秒是比较不错的，10秒则是忍受的极限。视具体情况具体设置。2.2并发用户数系统并发用户数：同一时间内访问系统的用户数。针对的是服务器最大承载量。关注的是瞬间最大访问量。业务并发用户数：从用户角度来说，在相当长的一段时间内，都会有基本固定数量的用户访问系统。系统用户数：使用该系统的用户总数。在线用户数：同时在线的用户数。在做并发测试的时候，一般会采取两种方法：一是在并发数一定的情况下，按业务不同进行测试（业务一，多少人一起使用，什么时候开始使用，使用多长时间）。这种方式更多的是业务并发测试。二是在并发数一定的情况下，只做单纯一样的操作（查询、修改、添加、删除）。这种方式更多的是系统并发测试。估算并发用户的公式：C=nL/T其中：C为平均并发用户数；n为loginsession的数量；L为loginsession的平均时间长度；T为考察的时间段长度。峰值并发数：Cm=C+3*√C假设loginsession符合泊松分布。比如：OA系统，共3000个用户，每天大约有400个用户访问，对一个用户来说，每天在线时间为4小时，而每天工作时间为8小时。则平均的并发用户为C=400*4/8=200，并发用户峰值为242。实际应用过程中，要考虑时间的细粒度或结合业务峰值和谷值来更精确的估算并发用户。更一般的公式是：C=n/10，即以每天访问系统用户数的10%作为平均的并发用户数Cm=r*Cr为调整因子，取值一般为2~3对web服务器的日志分析，能得到更为精确的最大并发用户访问数。2.3吞吐量单位时间内系统处理的客户请求的数量。体现软件系统的性能承载能力。一般描述：请求数/秒或页面数/秒。业务角度来说，访问人数/天或处理的业务数/小时。网络角度：字节数/天==网络流量。作用：1、用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标；2、用于协助分析性能瓶颈。比如以字节数/秒主要反映受网络基础设施、服务器架构、应用服务器制约；以单击数/秒表示主要受应用服务器和应用代码的制约。在未遇到性能瓶颈时，计算公式：F=Nvu*R/T。Nvu表示虚拟用户的个数(VirtualUsers)；R表示每个VU发出的请求(单击)数量；T表示测试时间。2.4性能计数器Counter。描述服务器或操作系统性能的一些数据指标。资源利用率：系统各种资源的使用状况。2.5思考时间ThinkTime：从业务角度来说，指用户在进行操作时，每个请求之间的间隔时间。思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关系。计算公式：R=T/TtR：每个用户发出的请求数；T为测试时间；Tt为思考时间。计算思考时间的一般步骤：1、首先计算出系统的并发用户数；2、统计出系统平均的吞吐量3、统计出平均每个用户发出的请求数量4、根据上面公式计算出思考时间。如果测试目的是为了验证应用系统具有预期的能力，即能力验证，则尽量模拟用户真实的思考时间；如果是更一般的研究，了解系统在压力下的性能水平或了解系统承受压力的能力，即规划能力，则可考虑0思考时间。3软件性能测试方法论3.1SEI负载测试计划过程关注于负责测试计划，目标产生“清晰、易理解、可验证的负载测试计划”。关注：目标、用户、用例、生产环境、测试环境和测试场景。3.2RBI方法RapidBottleneckIdenfity.快速识别系统性能瓶颈的方法。基于：发现80%系统的性能瓶颈都由吞吐量制约；并发数和吞吐量瓶颈之间存在一定的关联；采用吞吐量测试可以更快速定位问题。首先访问“小页面”或“简单应用”，从应用服务其、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，并通过不断增加并发用户数和吞吐量，观察系统的性能表现。3.3性能下降曲线分析法性能下降曲线分析法：通过性能曲线上的单用户区，性能平坦区，压力区域以及性能拐点几个关键因素来分析性能瓶颈问题。从上图可以看到，发布博文事务曲线非常平滑，最大响应时间为0.999秒，是属于非常好的现象，其它事务随着负载用户数量的增大，出现相应的波动，从而可以分析性能问题所在。从图中可以看到，一条曲线可以分为以下几个部分：（1）性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。（2）压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域的开始。（3）性能拐点——性能开始“急剧下降”的点。这几个区域实际上明确标识了系统性能最优秀的区间，系统性能开始变坏的区间，以及系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方。因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。3.4Loadrunner性能测试过程负载测试一般包括5个阶段：规划、创建脚本、定义场景、执行场景和分析结果。➤规划负载测试。定义性能测试要求，例如并发用户数量、典型业务流程和要求的响应时间。➤创建Vuser脚本。在自动化脚本中录制最终用户活动。➤定义场景。使用LoadRunnerController设置负载测试环境。➤运行场景。使用LoadRunnerController驱动、管理并监控负载测试。➤分析结果。使用LoadRunnerAnalysis创建图和报告并评估性能。3.5Segue性能测试过程Silkperformer在Segue中提供的性能测试过程，是一个try-check过程，即：评估需求→开发测试→建立基线→执行测试→分析结果→回归测试→测试结束。3.6PTGM模型PerformanceTestingGeneralModel。该性能测试模型将性能测试分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤。3.7GAME(A)性能测试过程模型G：Goal，目标A：Analysis，分析M：Metrics，度量E：Execution，执行（A）：Adjust，调整。E执行失败后才进入A阶段，并且涉及的大多是有关开发和系统管理工作，因此A设为隐式。性能测试过程模型如图1-5所示。注：方法论颇多，视具体情况而定。软件性能测试可视为一个工程或项目，亦可谓一个子过程或验证项。4性能测试方法4.1性能测试PerformanceTesting模拟生产运行压力量和使用场景组合，测试系统的性能是否满足生产性能要求。在特定的运行条件下验证系统的能力状况。确定用户场景、给出需要关注的性能指标、测试执行和测试分析。性能目标描述：系统在100个并发用户下进行某种业务操作，响应时间不超过5秒。4.2负载测试LoadTesting通过在被测系统上不断增加压力，直到性能指标。找到系统的处理极限，为系统调优提供数据。亦称为可量性测试(ScalabilityTesting)。极限描述：在给定条件下最多允许120个并发用户访问或在给定条件下最多在1小时内处理2100笔业务。预期的性能指标：响应时间不超过10S或服务器平均CPU利用率低于65%。4.3压力测试StressTesting测试系统在一定饱和状态下，如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。1）主要目的是检察系统处于压力情况下时，应用的表现。通过增加访问压力，如增加并发用户，使应用系统的资源使用保持在一定的水平。检测此时的表现，有无错误信息，响应时间等。2）通过模拟负载等方法，使系统的资源使用达到较高的水平。比如设定为“CPU75%，内存70%”情况下，有无错误、系统响应时间。其他，如JVM内存、DB连接数、DB的CPU等。3）测试系统的稳定性。如果一个系统能够在压力环境下稳定运行一段时间，那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度。4.4配置测试ConfigurationTesting对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。1）了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。2）规划领域内评估该如何调整才能实现系统的扩展性。4.5并发测试ConcurrencyTesting通过模拟用户的并发访问，测试多用户并发访问同一个应用、模块或者数据记录时是否存在死锁或者其他性能问题。1）发现系统中可能隐藏的并发访问时的问题。2）关注某些性能指标，如内存泄露、死锁、长事务、线程/进程同步失败等。并发测试可验证某种架构或设计的合理性，可作代码级别的检查和定位。如Jprofile、JProbe工具。4.6可靠性测试ReliablityTesting通过给系统加载一定的业务压力(如资源在70-90%的使用率)的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。1）验证系统是否能够支持长期稳定的运行2）需要在压力下持续一段时间的运行。3）关注系统的运行状况。关注内存、CPU、系统响应时间有无明显变化。4.7失效恢复测试（FailoverTesting）针对有冗余备份和负载均衡的系统设计的。用来检验如果系统局部发生故障，用户能否继续使用系统；以及如果发生，用户将受到多大程度的影响。还关注问题发生时，能支持多少用户访问和采取何种应急措施。一般说来，只有对系统持续运行指标有明确要求的系统才需要进行此类测试。5性能测试领域5.1能力验证在给定条件下，系统能否具有预期的能力表现。问题描述方式：“某系统能否在A条件下具有B能力”在已确定的环境下运行，根据典型场景设计测试方案和用例，确定相应的性能目标。一般采用性能测试。可靠性验证、压力测试、失效恢复测试也可归入。5.2规划能力应该如何才能使系统具有我们要求的性能能力或在某种可能发生的条件下，系统具有如何的性能能力。问题描述方式：“某系统能否支持未来一段时间内的用户增长”或“应该如何调整系统配置，使系统能够满足增长的用户数的需要”。负载测试、配置测试和压力测试。5.3性能调优在开发和测试阶段都可能涉及到。确定基准环境、负载和性能指标-〉调整系统运行环境和实现方法，执行测试-〉记录测试结果，分析-〉回到第二步重复继续，直到发现最优配置。调整包括：硬件环境（CPU、内存、硬盘、网络环境等）、系统设置（系统核心参数、DB内存池、应用服务器内存、jvm等）、应用级别（新架构、新数据访问方式、修改业务逻辑等）配置测试、负载测试