性能测试方法及分析报告方法

标准文案标准文案大全大全性能测试方法及分析方法一、性能测试简介什么是软件性能性能是软件产品的一种特性，可以用时间来进展度量。性能的准时性用响应时间或者吞吐量来衡量。响应时间是对恳求作出响应所需要的时间。OK按钮后2应时间。〔Web述系统的性能，而对非交互式应用〔嵌入式系统或是银行等的业务处理系统〕而言，响应时间是指系统对大事产生响应所需要的时间。品的开发人员也关注软件性能，下面将从3用户视角的软件性能Web开头到应用系统把本次操作的结果以用户能觉察的方式呈现出来1.1以一个Web发出恳求 恳求应用效劳器 DB效劳器用户用户感受到响应

应用界面呈现

返回数据呈现时间 系统响应时间1.1Web必需要说明的是，用户所体会到的“响应时间”既有客观的成分，也有主观的成分。例〔顺便说一下，这种技巧是在C/S。1.2.1节对“响应时间”的解释。治理员视角的软件性能外，他还会关心和系统状态相关的信息。例如，治理员已经知道，在并发用户数为100时，A8CPU了最大值？是否还有可用的内存？应用效劳器的状态如何？我们设置的JVM可用内存是否足够？数据库的状况如何？是否还需要进展一些调整？这些问题一般的用户并不关心不在他们的体验范围之内；但对治理员来说，要保证系统的稳定运行和持续的良好性能，就必需关心这些问题。况制定治理措施，在系统消灭打算之外的用户增长等紧急状况的时候能够马上制定相应措施，进展快速的处理；此外，治理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不连续地供给业务效劳等。题。1-1治理员关心的问题软件性能描述效劳器的资源使用状况合理吗治理员关心的问题软件性能描述效劳器的资源使用状况合理吗资源利用率应用效劳器和数据库的资源使用状况合理吗资源利用率系统是否能够实现扩展系统可扩展性系统最多能支持多少用户的访问？系统最大的业务处理系统容量量是多少系统性能可能的瓶颈在哪里系统可扩展性更换哪些设备能够提高系统性能系统可扩展性7×24系统稳定性开发视角的软件性能等治理员关心的内容，由于这些也是产品需要面对的用户〔特别的用户。但对开发人员来的性能表现到底是由于系统架构选择的不合理还是由于代码实现的问题引起？由于数据库设计的问题引起？抑或是由于系统的运行环境引发？是否存在由于内存处理等问题引起的系统故障？因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并没有太大的意1-21-2开发人员关注的性能问题开发人员关心的问题开发人员关心的问题问题所属层次架构设计是否合理系统架构数据库设计是否存在问题数据库设计代码是否存在性能方面的问题代码系统中是否有不合理的内存使用方式代码系统中是否存在不合理的线程同步方式设计与代码系统中是否存在不合理的资源竞争设计与代码总结以上我们描述了3用户对性能的理解属于“用户视角〔包括设计人员〕自然就是从“开发视角”来关注软件性能了。用户的角度来说，表现为软件系统对用户操作的响应时间；在系统或是治理员的关注层面，和引起性能问题的关键缘由。软件性能的几个术语性能计数器，在使用性能测试工具进展测试时，还会接触到“思考时间ThinkTim”的概念，那么，这些术语的精准含义到底是什么呢？本节重点介绍以上的各个术语。响应时间1.11.1.1图1.1〔响应时间Web性能测试中，我们并不关注“呈现时间表现，例如，一台内存缺乏的客户端机器在处理简洁页面的时候，其呈现时间可能就很长，应时间”和“响应时间1.2描述了一个Web中可以看到，页面的响应时间可被分解为“网络传输时间〔N1+N2+N3+N〕A1+A2+A，而“应用延迟时间”又可以分解为“数据库延迟时间〔A〕和“应用效劳A1+A。之所以要对响应时间进展这些分解，主要目的是为了能更好定位能问题的定位。1.2Web用户主观颜色，也就是说，响应时间的“长”和“短”没有确定的区分。例如，对一个电子商务网站来说，在美国和欧洲，一个普遍被承受的响应时间标准为2/5/10秒，也就是说，在2秒之内给客户响应被用户认为是“格外有吸引力的5内响应客户被认为是“比较不错的10秒是客户能承受的响应的上限。2小时以上进行数据的录入，当用户单击“提交”按钮后，即使系统在20分钟后才给出“处理成功”的操作来说，20因此，在进展性能测试时试人员自己的设想来打算。并发用户数在阐述这个术语之前，先来看看为什么在性能测试中需要关注这个“并发用户数弄清楚会有多少用户会在同一个时间段内访问被测试的系统就是我们说的并发用户数的一个概念，这种并发的概念通常在性能测试〔PerformanceTesting〕C/S或是B/S应用来说，系统的性能表现毫无疑问地主要由“效劳端”打算。在什么时候“效劳端”会承受最大的压力，或者说，在什么时候“效劳端”表现为最差的性能呢？毫无疑问，确定是在大量用户同时对这个系统进展访问的时候。为了说明这个“同时1.。1.3用排球击打墙面图1.3用“排球击打墙面”说明这种“同时描述的是同时向客户端发出恳求的客户，该概念一般结合并发测试〔ConcurrencyTesting〕使用，表达的是效劳端承受的最大并发访问数。下面我们用一个更接近实际的例子来说明这两个并发概念之间的不同。1.4应用界面效劳器VU应用界面效劳器VUVU2

VUG1.4实际应用系统用户的恳求执行某些操作，然后将结果返回给用户。从用户的角度来看，在一个相当长的时间段内〔例如1天念就是前面争论的业务并发用户数。的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向效劳压力最大，资源承受的压力也最大，在这种状态下，可以考虑通过并发测试〔ConcurrencyTesting〕觉察系统中存在的并发引起的资源争用等问题。在实际的性能测试中，常常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户人数假设有一个OA2023OA用户总数是2023名，这个概念就是“系统用户数〔用一个全局变量计数全部已登录的用户，从在线统计功能中可以得到，最顶峰时有500人在线〔这个500就是一般所说的“同时在线人数，那么，系统的并发用户数是多少呢？依据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。固然，500500器承受的压力。由于效劳器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在饶有兴致地看系统公告〔，20〔对用户填写的表格来说，只有在“提交”的时刻才会向效劳端发送恳求，填写过程是不对效劳端构成压力的，20〔也就是什么也没有做，剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%不只取决于业务并发用户数，还取决于用户的业务场景。业务场景，一般可以通过对效劳器日志的分析得到。并发用户数进展争论，而且，为了便利，直接将业务并发用户数称为并发用户数。那么，到底应当如何获得测试人员关心的并发用户数的具体数值呢？下面给出了一些用于估算并发用户数的公式。nLCT 〔1〕CC3C

〔2〕loginsession的平均长度；TOA应用，考察的时间段长度应当8公式2〕则给出了并发用户数峰值的计算方式，其中，ˆC就是公式〔1〕中得到的平均的并发用户数。该公式的得出是假设用户的loginsession符合泊松分布而估算得到的。下面依据上述给出的方法进展实例计算。OA30004004小时，在8则依据公式〕和公式2，可以得到：C=400×4/8=200200200+3×200

=242loginsession算这两个值并不简洁。另外，考虑到用户的业务操作存在确定的时间集中〔也就是说，用户对系统业务的访问往往不是平均分布在整个考察时间段内时间段内，承受公式〕和公式〕进展计算照旧存在确定的偏差。我们给出对该公式使用的一些建议1个小时为考察时间的粒度，对一个OA8在的时间集中性的问题。301日前夕会有大量用户的访问……因此多考虑一些可能发生的场景，基于这些场景进展估算。Web〔固然精度更差〕阅历公式是：Cn10 〔3〕rC 〔4〕也就是说，用每天访问系统用户数的10%作为平均的并发用户数，并发用户数的最大值由并发用户数乘上一个调整因子r得到，r2～3。公式〔3〕和公式〔4〕可以在要求不太严格的性能测试，或是只有很少数据支持分析的性能测试中使用。在本节的前面局部提到了“日志分析”方法。所谓“日志分析”方法是指通过对应用效劳并发用户访问数”数据。这种方式得到的数据准确度和可信度都比较高，对于Internet用等无法估量用户数量和用户行为模式的应用，这种方式最为可信。吞吐量吞吐量是指“单位时间内系统处理的客户恳求的数量/秒或是页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/节数/天来考察网络流量。例如，对一个Web应用系统来说，从系统的处理力气考虑，可以以页面数/秒作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的业务数/小时作为吞吐量的标准。在本章的开头局部，已经争论过，对于交互式应用，用户直接的体验是“响应时间吐量”来描述我们对系统性能的期望可能更加合理。对于交互式应用来说，吞吐量指标反映的是效劳器承受的压力。在容量规划的测试中，过程中，吞吐量指标也有重要的价值，例如，Empirix80%是由于吞吐量的限制导致的。在对Web系统的性能测试过程中，吞吐量主要以恳求数〔单击数/字节数/秒来表达，吞吐量指标可以在两个方面发挥作用：用于帮助设计性能测试场景，以及衡量性能测试场景是否到达了预期的设计目标：在设计性能测试场景时，吞吐量可被用于帮助设计性能测试场景，依据估算的吞吐量数据，吞吐量可以衡量测试是否到达了预期的目标。用于帮助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以帮助尽快定位到性能瓶颈所在位置。例如，RBI〔RapidBottleneckIdentify〕方法就主要通过吞吐量测试觉察性能瓶颈。以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络根底设施、效劳器架构、应用效劳器制约；以单击数/秒方式表示的吞吐量主要受应用效劳器和应用代码的制约。到性能瓶颈的时候，吞吐量可以承受如下公式计算：FN其中，F表示吞吐量；N

R 〔5〕vuTvuVU〔VirtuaeUser，虚拟用户〕的个数；RVUvu发出的恳求〔单击〕数量；T表示性能测试所用的时间。但假设遇到了性能瓶颈，此时吞吐VU〔5〕给出的关系。常用于分析吞吐量的图形是“吞吐量——VU1.5给出了两个“吞吐量——VU从图中可以看到，吞吐量在VU数量增长到确定程度的时候产生了性能瓶颈。本文给出了一个例如。1.5“吞吐量——VU对同一个应用进展两次不同的性能测试，测试A100个并发，每个VU1出一个恳求；测试B1000VU10A，测试〔页/秒100×1/1=100B〔页/秒1000×1/10=100，100。但从测试结果来看，执行测试A50/秒消灭性能瓶颈，而测试B25/秒消灭性能瓶颈。性能计数器〔Counte是描述效劳器或操作系统性能的一些数据指标系统来说，使用内存数MemoryInUsag，进程时间TotalProcessTim〕的计数器。器只能表达系统性能的某一个方面，对性能测试结果的分析必需基于多个不同的计数器。与性能计数器相关的另一个术语是“资源利用率/总的资源可用量”形成资源利用率的数据，用以进展各种资源使用的比较。10000Web效劳器的CPU占用率为68%，平均的内存占用率为556855在性能测试中常用资源利用率进展横向的比照，例如，在进展测试时会觉察，资源A的使用率到达了接近100%的数值，而其他的资源利用率都处于比较低的水平，则可以很清楚A要结合响应时间变化曲线、系统负载曲线等各种指标进展分析。性能计数器是性能测试分析的主要参考值，本书的第3章对其进展了具体的解释说明，并说明白如何利用这些计数器分析系统性能瓶颈。思考时间思考时间ThinkTim，也被称为“休眠时间等待一段时间，再发出下一个恳求。各个操作之间等待一段时间，表达在脚本中，具体而言，就是在操作之间放置一个Think的函数，使得脚本在执行两个操作之间等待一段时间。在测试脚本中思考时间表达为脚本中两个恳求语句之间的间隔时间不同的测试工具供给了不同的函数或者方法来实现思考时间，本书附录A中对思考时间进展了的具体描述，另外，本书实践篇也有一些使用思考时间的实际 例子。实，思考时间与迭代次数、并发用户数和吞吐量之间存在确定的关系。公式〔5〕VUN、每个用户发出恳求数RT的函数，而其中vuR又可以用时间T和用户的思考时间T来计算：sTR 〔6〕Ts用公式〔5〕和公式〔6〕进展化简运算可得，吞吐量与N成正比，而与T成反比。vu s步骤：首先计算出系统的并发用户数；统计出系统平均的吞吐量；统计出平均每个用户发出的恳求数量；依据公式〔6〕计算出思考时间。4计算得出的思考时间为基准，让实际的思考时间在确定幅度内随机变动。LoadRunner和SegueSilkPerformer等工具都支持以这种方式设置思考时间。最终要说明的是“00”作为思考时间，以给要求。由于从业务的角度考虑，思考时间用于更真实地模拟用户操作，设置思考时间为0，根本上不具有实际的业务含义。但在非交互式应用的性能测试过程中，有时候确实会将思考时间设置为0，这时候是模拟一种尽可能大的压力，争论系统在巨大压力下的表现。可以说，假设测试的目的是为了“验证应用系统具有预期的力气〔也就是所说的“力气验证”的应用领域，就应当尽量模拟用户在使用业务时的真实思考时间；假设目的是进展更一般的争论，例如“了解系统在压力下的性能水平”或是“了解系统承受压力的力气”〔也就是所说的“规划力气”的应用领域，则可以承受0思考时间。二、性能测试方法论与方法简洁成为一种任凭的测试行为，而任凭进展的性能测试很难取得实际的作用和预期的效果，因此本章将简洁介绍几种常见的性能测试过程和方法，并着重介绍常用的性能测试方法。性能测试方法论SEISEI负载测试打算过程〔SEILoadTestingPlanningProcess〕是一个关注于负载测试打算的方法，其目标是产生“清楚、易理解、可验证的负载测试打算SEI负载测试打算过程包括6个关注的区域AreSEI负载测试打算过程将以上述6个区域作为负载测试打算需要重点关注和考虑的内容，其重点关注以下几个方面的内容：产环境上的实际性能表现，为了躲避这个风险，必需认真设计测试环境。用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必需通过对用户行为进展分析，依据用户行为模型建立用例和场景。用例：用例是用户使用某种挨次和操作方式对业务过程进展实现的过程，对负载测现性能问题的风险等。SEISEI打算过程的一些关注内容，而没有能够形成实际的可操作的过程。段，但由于性能测试自身的特别性〔例如，需要引入工具，分析阶段相对重要，性能测试过程又不能完全套用功能测试过程。SEI完整的测试过程。RBIRBI〔RapidBottleneckIdentify〕方法是Empirix性能瓶颈的方法。该方法基于以下一些事实：觉察的80%系统的性能瓶颈都由吞吐量制约；并发用户数和吞吐量瓶颈之间存在确定的关联；承受吞吐量测试可以更快速定位问题。RBI方法首先访问效劳器上的“小页面”和“简洁应用保持根本全都的增长趋势，通过不断增加并发用户数和吞吐量，观看系统的性能表现。在确定具体的性能瓶颈时，RBI将性能瓶颈的定位依据一种“自上而下”的分析方式进展分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库4RBI值得借鉴，但其也不是完整的性能测试过程。性能下降曲线分析法性能下降曲线实际上描述的是性能随用户数增长而消灭下降趋势的曲线/主要是指响应时间。1.61.6一条典型的响应时间性能下降曲线例如1.6单用户区域——对系统的一个单用户的响应时间域可被用作基线或是benchmark。压力区域——应用“略微下降”的地方。典型的、最大的建议用户负载是压力区域第三步第四步第三步第四步的开头。性能拐点——性能开头“急剧下降”的点。颈产生的地方。拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优供给依据。LoadRunner第一步打算测试测试设计VU脚本创立测试场景运行测试场景分析结果其次步1.7给出了LoadRunner第一步打算测试测试设计VU脚本创立测试场景运行测试场景分析结果其次步第五步第六步1.7LoadRunner第五步第六步用例的设计；创立VU脚本阶段主要依据设计的用例创立脚本；创立测试场景阶段主要进展执行，收集相应数据；分析结果阶段主要进展结果分析和报告工作。LoadRunner供给的这共性能测试过程已经涵盖了性能测试工作的大局部内容，但由于该过程过于严密地与LoadRunner工具集成，没有兼顾使用其他工具，或是用户自行设计工具的需求，也不能被称为是一个普适性的测试过程。另外，LoadRunner供给的该性能测试过程并未对打算测试阶段、测试设计阶段的具体行为、方法和目的进展具体描述，因此该方法最多只能被称为“使用LoadRunner进展测试Segue图1.8SegueSilkPerformerPerformanceTestingLifecycletry-checkSilkPerformer供给的性能测试过程从确定性能基线开头，通过单用户对应用的访问猎取性能取值的基线，然后设定可承受的性能目标〔响应时间，用不同的并发用户数等重复进展测试。Segue供给的这种性能测试方法格外适合性能调优和性能优化，通过不断重复的try-check过程，可以逐一找到可能导致性能瓶颈的地方并对其进展优化。EvaluateEvaluateDevelopTestAssetsDevelopExploratoryRe-BenchBaseLine&BenchmarkTuneSystemAnalyzeResultsTestsValidateReg’sCriteriaMetCompleteProject1.8SegueSilkPerformer但Segue供给的这共性能测试过程模型存在与LoadRunner的性能测试过程同样的问题，出具体的活动和目标。性能测试的方法此外还存在其他的一些类型的性能测试方法。依据大范围的性能测试的概念的界定，性能测试可包括如下几种方法：性能测试PerformanceTestin；负载测试LoadTestin；压力测试StressTestin；配置测试ConfigurationTestin；并发测试ConcurrencyTestin；牢靠性测试ReliabilityTestin；失效恢复测试FailoverTestin；性能测试〔PerformanceTesting〕性能测试〔PerformanceTesting〕方法是通过模拟生产运行的业务压力气和使用场景组合，测试系统的性能是否满足生产性能要求。PerformanceTesting是一种最常见的测试方法，通俗地说，这种测试方法就是要在特定的运行条件下验证系统的力气状况。这种方法的特点有：这种方法的主要目的是验证系统是否有系统宣称具有的力气。有的力气。这种方法需要事先了解被测试系统典型场景，并具有确定的性能目标。PerformanceTesting1005这种方法要求在已确定的环境下运行。PerformanceTesting〔硬件设备、软件环境、网络条件、根底数据等〕都已经确定。负载测试〔LoadTesting〕负载测试〔LoadTesting〕方法通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经到达饱和状态。这种测试放大可以找到系统的处理极限，为系统调优供给数据。在某些状况下，这种方法有时也被称为可量性测试ScalabilityTestin。该方法有这样一些特点：这种性能测试方法的主要目的是找到系统处理力气的极限。LoadTesting方法通过“检测-加压-直到性能指标超过预期”的手段，其主要目的是120个并发用户访问”12100的性能指标”一般会被定义为“响应时间不超过10CPU65%”等指标。这种性能测试方法需要在给定的测试环境下进展与唯物压力气和典型场景，使得测试结果具有业务上的意义。LoadTesting方法由于涉及到“预定的性能指标”等需要进展比较的数据，也必需在给定的测试环境下进展。另外，LoadTesting方法在“加压”的时候，必需选择典型场景，在增加压力时保证这种压力具有业务上的意义。用。

这种性能测试方法是一般用来了解系统的性能容量，或是协作性能调优来使LoadTesting方法可以用来了解系统的性能容量〔系统在保证确定响应时间的状况下能够允很多少并发用户的访问差异。压力测试〔StressTesting〕压力测试〔StressTesting〕方法测试系统在确定饱和状态下，例如CPU、内存等在饱和使用状况下，系统能够处理的会话力气，以及系统是否会消灭错误。StressTesting这种性能测试方法的主要目的是检查系统处于压力状况下时，应用的表现。StressTesting方法通过增加访问压力〔例如，增加并发的用户数量等有无出错信息产生，系统对应用的响应时间等。一般状况下，会把压力设定为“CPU7570%以上”CPU和内存使用率JVMCPU作为压力的依据。这种性能测试方法一般用于测试系统的稳定性。用压力测试的方法考察系统的稳定性是出于这样的考虑题。配置测试〔ConfigurationTesting〕配置测试〔ConfigurationTesting〕方法通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优安排原则。这种方法具有以下的特定：这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度而推断出最值得进展的调优操作。的主要目的是了解各种因素对系统性能的影响程度，从而推断出对性能影响最大的因素。这种性能测试方法一般在对系统性能状况有初步了解后进展。ConfigurationTesting的因素。这种性能测试方法一般用于性能调优和规划力气。ConfigurationTesting续进展。另外，在“规划力气”领域内，该方法也常被用来评估“该如何调整才能实现系统并发测试〔ConcurrencyTesting〕并发测试〔ConcurrencyTesting〕方法通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。该方法具有以下特点：这种性能测试方法的主要目的是觉察系统中可能隐蔽的并发访问时的问题。ConcurrencyTesting后，就常常会消灭各种莫名其妙的问题。解决这类问题的方法是进展认真的并发模拟测试。这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄露、线程锁和资源争用方面的问题。ConcurrencyTesting2-1出了并发测试主要关注的问题。2-1并发测试主要关注的问题问题类别问题类别问题描述是否有内存泄露〔C/C++〕内存问题是否有太多的临时对象〔java〕是否有太多的超过设计生命周期的对象〔java〕是否有数据库死锁〔DeadLock〕数据库问题是否常常消灭长事务〔LongTransaction〕线程/进程问题是否消灭线程/进程同步失败是否消灭资源争用导致的死锁其他问题是否没有正常处理特别〔例如超时等〕导致系统死锁这种性能测试方法可以在开发的各个阶段使用支持。发负载的产生外，还需要一些其他工具进展代码级别的检查和定位。Compuware公司的DevPartnerdj-technologieJProfileQuestJProbe以在这方面发挥作用。牢靠性测试〔ReliabilityTesting〕这里说的“牢靠性测试”并不等同于“获得软件的牢靠性”，软件的牢靠性是一个很大的命题，这里指的牢靠性测试是通过给系统加载确定的业务压力〔例如：资源在70%~90%的使用率〕，让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要留意：在使用该测试前需要目的系统的资源使用率已经到达70%~90刻环境下运行该应用系统。90%。比方：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接到达27。要求MTBF〔平均无故障时间〕到达10000小时、那么我们可以认定该系统的运行时间至少需要到达三年重启动一次。超过这个数字我们就可以认为“不行靠”J2EE90%~1003可以认定该MTBF该方法具有以下特点：这种性能测试方法的主要目的是验证系统是否支持长期稳定的运行。ReliabilityTesting方法的目的是验证系统是否能够支持长期稳定的运行，其原理在行的条件。这种性能测试方法需要在压力下持续一段时间的运行。2～3测试过程中需要关注系统的运行状况。在运行过程中，一般需要关注系统的内存使用状况，系统的其他资源使用有无明显的变失效恢复测试〔FailoverTesting〕该方法是针对有HACMP等冗余备份和EdgeServerforLBJ2EE假设这种状况发生，用户将受到多大程度的影响。该方法有以下特点：这种性能测试方法的主要目的是验证在局部故障状况下，系统能否连续使用。有一台或几台效劳器消灭问题，应用系统照旧能够正常执行业务。FailoverTesting方法可以在测试中模拟一台或几台设备故障，验证预期的恢复技术是否能够发挥作用。这种性能测试方法还需要指出，当问题发生的时候“能支持多少用户访问”当一台或多台效劳器消灭问题后，系统确定会受到性甚至是功能上的局部损失。因此，些必要措施？”这种问题的明确答案。测试。的系统。三、性能测试分析方法前一章着重介绍了目前常用的性能测试方法，本章主要简洁介绍一下常用的各种性能测试分析方法。1、内存分析方法内存分析方法主要是用于推断系统有无遇到内存瓶颈高系统性能表现。主要计数器包括MemoryPhysicalDisk内存分析的主要步骤和方法如下：首先查看MemoryAvailableMbytes该值是用于描述系统可用内存的直接指标，在对系统进展操作系统级别的内存分析时，存可用。假设该指标的数据比较小，系统可能消灭了内存方面的问题，此时需要进一步分析。留意s/sec、sRead/secFaults/sec操作系统常常会使用磁盘交换的方式来提高系统可用的内存量或是提高内存的使用效率。这三个指标直接反映了操作系统进展磁盘交换的频度。假设s/sec表示内存有问题，而可能是运行使用内存映射文件的程序所致。Faults/sec说明白每秒发生页面失效的次数，页面失效次数越多，说明操作系统向内存中读取的次数越多。此时还需要查看sRead/sec计数器，该计数器阀值为5，假设超过5，则可以判定存在内存方面的问题。依据PhysicalDiskPhysicalDisksRead/sec%DiskTimeAverageDiskQueueLengthsRead/sec%DiskTimeAverageDiskQueueLength则可能有磁盘瓶颈。但是假设AverageDiskQueueLengthsRead/sec于内存缺乏。(备注：内存分析方法用到的计数器指标主要有：MemoryAvailableMbytes、Memorys/secsRead/sec和Faults/secPhysicalDisk%DiskTimeAverageDiskQueueLength)2、处理器分析方法处理器(CPU)也可能是系统的瓶颈，对处理器进展性能分析的步骤如下：首先查看System%TotalProcessorTimeCPU假设该值的数值持续超过90%，则说明整个系统面临这处理器方面的瓶颈，需要增加处理器来提高性能。留意：由于操作系统本身的特性，在某些多CPU系统中，该数据本身并不大，但此时CPU其次查看每个CPU的Processor%ProcessorTimeProcessor%UserTimeProcessor%PrivilegedTime。