2023年6月29日发(作者：)

性能测试基本概念与测试⽅法性能测试是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。负载测试和压⼒测试都属于性能测试，两者可以结合进⾏。通过负载测试，确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压⼒测试是通过确定⼀个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最⼤服务级别的测试。

⼀、概述 性能测试在软件的质量保证中起着重要的作⽤，它包括的测试内容丰富多样。中国软件评测中⼼将性能测试概括为三个⽅⾯：应⽤在客户端性能的测试、应⽤在⽹络上性能的测试和应⽤在服务器端性能的测试。通常情况下，三⽅⾯有效、合理的结合，可以达到对系统性能全⾯的分析和瓶颈的预测。 ·应⽤在客户端性能的测试　　应⽤在客户端性能测试的⽬的是考察客户端应⽤的性能，测试的⼊⼝是客户端。它主要包括并发性能测试、疲劳强度测试、⼤数据量测试和速度测试等，其中并发性能测试是重点。 并发性能测试是重点　　并发性能测试的过程是⼀个负载测试和压⼒测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执⾏指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使⽤等来决定系统的性能。负载测试是⼀个分析软件应⽤程序和⽀撑架构、模拟真实环境的使⽤，从⽽来确定能够接收的性能过程。压⼒测试（Stress Testing）是通过确定⼀个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最⼤服务级别的测试。　　并发性能测试的⽬的主要体现在三个⽅⾯：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应⽤程序的功能或者新的应⽤程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的⽤户负载，以预测系统的未来性能；通过模拟成百上千个⽤户，重复执⾏和运⾏测试，可以确认性能瓶颈并优化和调整应⽤，⽬的在于寻找到瓶颈问题。　　当⼀家企业⾃⼰组织⼒量或委托软件公司代为开发⼀套应⽤系统的时候,尤其是以后在⽣产环境中实际使⽤起来,⽤户往往会产⽣疑问,这套系统能不能承受⼤量的并发⽤户同时访问? 这类问题最常见于采⽤联机事务处理(OLTP)⽅式数据库应⽤、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试⼿段和先进的测试⼯具。 举例说明：电信计费软件　　众所周知,每⽉20⽇左右是市话交费的⾼峰期，全市⼏千个收费⽹点同时启动。收费过程⼀般分为两步,⾸先要根据⽤户提出的电话号码来查询出其当⽉产⽣费⽤,然后收取现⾦并将此⽤户修改为已交费状态。⼀个⽤户看起来简单的两个步骤,但当成百上千的终端，同时执⾏这样的操作时，情况就⼤不⼀样了,如此众多的交易同时发⽣,对应⽤程序本⾝、操作系统、中⼼数据库服务器、中间件服务器、⽹络设备的承受⼒都是⼀个严峻的考验。决策者不可能在发⽣问题后才考虑系统的承受⼒, 预见软件的并发承受⼒, 这是在软件测试阶段就应该解决的问题。　　⽬前，⼤多数公司企业需要⽀持成百上千名⽤户，各类应⽤环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的⽤户负载和愈来愈复杂的应⽤程序，使公司担忧会发⽣投放性能差、⽤户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。　　如何模拟实际情况呢? 找若⼲台电脑和同样数⽬的操作⼈员在同⼀时刻进⾏操作,然后拿秒表记录下反应时间？ 这样的⼿⼯作坊式的测试⽅法不切实际，且⽆法捕捉程序内部变化情况,这样就需要压⼒测试⼯具的辅助。　　测试的基本策略是⾃动负载测试，通过在⼀台或⼏台PC机上模拟成百或上千的虚拟⽤户同时执⾏业务的情景，对应⽤程序进⾏测试，同时记录下每⼀事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应⽤的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受⼒,就为最终⽤户规划整个运⾏环境的配置提供了有⼒的依据。 并发性能测试前的准备⼯作　　测试环境：配置测试环境是测试实施的⼀个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、⽹络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运⾏时的操作系统、数据库及其他应⽤软件构成的环境。　　⼀个充分准备好的测试环境有三个优点：⼀个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执⾏的技术需求；保证得到正确的、可重复的以及易理解的测试结果。　　测试⼯具：并发性能测试是在客户端执⾏的⿊盒测试，⼀般不采⽤⼿⼯⽅式，⽽是利⽤⼯具采⽤⾃动化⽅式进⾏。⽬前，成熟的并发性能测试⼯具有很多，选择的依据主要是测试需求和性能价格⽐。著名的并发性能测试⼯具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试⼯具都是⾃动化负载测试⼯具，通过可重复的、真实的测试，能够彻底地度量应⽤的可扩展性和性能，可以在整个开发⽣命周期、跨越多种平台、⾃动执⾏测试任务，可以模拟成百上千的⽤户并发执⾏关键业务⽽完成对应⽤程序的测试。　　测试数据：在初始的测试环境中需要输⼊⼀些适当的测试数据，⽬的是识别数据状态并且验证⽤于测试的测试案例，在正式的测试开始以前对测试案例进⾏调试，将正式测试开始时的错误降到最低。在测试进⾏到关键过程环节时，⾮常有必要进⾏数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了⼀个基线⽤来评估测试执⾏的结果。　　在测试正式执⾏时，还需要准备业务测试数据，⽐如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。　　模拟真实环境测试，有些软件，特别是⾯向⼤众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型⽂件的⽐例要尽量接近真实环境，这样测试出来的数据才有实际意义。

并发性能测试的种类与指标　　并发性能测试的种类取决于并发性能测试⼯具监控的对象，以QALoad⾃动化负载测试⼯具为例。软件针对各种测试⽬标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的监控对象，⽀持Windows和UNIX测试环境。　　最关键的仍然是测试过程中对监控对象的灵活应⽤，例如⽬前三层结构的运⾏模式⼴泛使⽤，对中间件的并发性能测试作为问题被提到议事⽇程上来，许多系统都采⽤了国产中间件，选择Java Script监控对象，⼿⼯编写脚本，可以达到测试⽬的。　　采⽤⾃动化负载测试⼯具执⾏的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执⾏跟踪，结果分析与定位问题所在，测试报告与测试评估。　　并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最⼩服务器响应时间；Mean：平均服务器响应时间；Max：最⼤服务器响应时间；StdDev：事务处理服务器响应的偏差，值越⼤，偏差越⼤；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发⽤户数。 应⽤实例：“新华社多媒体数据库 V1.0”性能测试　　中国软件评测中⼼（CSTC）根据新华社技术局提出的《多媒体数据库（⼀期）性能测试需求》和GB/T 17544《软件包质量要求和测试》的国家标准，使⽤⼯业标准级负载测试⼯具对新华社使⽤的“新华社多媒体数据库 V1.0”进⾏了性能测试。　　性能测试的⽬的是模拟多⽤户并发访问新华社多媒体数据库，执⾏关键检索业务，分析系统性能。　　性能测试的重点是针对系统并发压⼒负载较⼤的主要检索业务，进⾏并发测试和疲劳测试，系统采⽤B/S运⾏模式。并发测试设计了特定时间段内分别在中⽂库、英⽂库、图⽚库中进⾏单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中⽂库中并发⽤户数200，进⾏测试周期约8⼩时的单检索词检索。在进⾏并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及UNIX（Linux）、Oracle、Apache资源等。　　测试结论：在新华社机房测试环境和内⽹测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发⽤户数为200的负载压⼒，最⼤交易数/分钟达到78.73，运⾏基本稳定，但随着负载压⼒增⼤，系统性能有所衰减。　　系统能够承受200并发⽤户数持续周期约8⼩时的疲劳压⼒，基本能够稳定运⾏。　　通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满⾜上述并发和疲劳性能需求，且系统硬件资源尚有较⼤利⽤余地。　　当并发⽤户数超过200时，监控到HTTP 500、connect和超时错误，且Web服务器报内存溢出错误，系统应进⼀步提⾼性能，以⽀持更⼤并发⽤户数。　　建议进⼀步优化软件系统，充分利⽤硬件资源，缩短交易响应时间。 疲劳强度与⼤数据量测试　　疲劳测试是采⽤系统稳定运⾏情况下能够⽀持的最⼤并发⽤户数，持续执⾏⼀段时间业务，通过综合分析交易执⾏指标和资源监控指标来确定系统处理最⼤⼯作量强度性能的过程。　　疲劳强度测试可以采⽤⼯具⾃动化的⽅式进⾏测试，也可以⼿⼯编写程序测试，其中后者占的⽐例较⼤。　　⼀般情况下以服务器能够正常稳定响应请求的最⼤并发⽤户数进⾏⼀定时间的疲劳测试，获取交易执⾏指标数据和系统资源监控数据。如出现错误导致测试不能成功执⾏，则及时调整测试指标，例如降低⽤户数、缩短测试周期等。还有⼀种情况的疲劳测试是对当前系统性能的评估，⽤系统正常业务情况下并发⽤户数为基础，进⾏⼀定时间的疲劳测试。　　⼤数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进⾏⼤数据量的独⽴数据量测试；与压⼒性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试⽅案。⼤数据量测试的关键是测试数据的准备，可以依靠⼯具准备测试数据。　　速度测试⽬前主要是针对关键有速度要求的业务进⾏⼿⼯测速度，可以在多次测试的基础上求平均值，可以和⼯具测得的响应时间等指标做对⽐分析。 ·应⽤在⽹络上性能的测试　　应⽤在⽹络上性能的测试重点是利⽤成熟先进的⾃动化技术进⾏⽹络应⽤性能监控、⽹络应⽤性能分析和⽹络预测。

⽹络应⽤性能分析　　⽹络应⽤性能分析的⽬的是准确展⽰⽹络带宽、延迟、负载和TCP端⼝的变化是如何影响⽤户的响应时间的。利⽤⽹络应⽤性能分析⼯具，例如ApplicationExpert，能够发现应⽤的瓶颈，我们可知应⽤在⽹络上运⾏时在每个阶段发⽣的应⽤⾏为，在应⽤线程级分析应⽤的问题。可以解决多种问题：客户端是否对数据库服务器运⾏了不必要的请求？当服务器从客户端接受了⼀个查询，应⽤服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应⽤的响应时间；利⽤Application Expert调整应⽤在⼴域⽹上的性能；Application Expert能够让你快速、容易地仿真应⽤性能，根据最终⽤户在不同⽹络配置环境下的响应时间，⽤户可以根据⾃⼰的条件决定应⽤投产的⽹络环境。 ⽹络应⽤性能监控　　在系统试运⾏之后，需要及时准确地了解⽹络上正在发⽣什么事情；什么应⽤在运⾏，如何运⾏；多少PC正在访问LAN或WAN；哪些应⽤程序导致系统瓶颈或资源竞争，这时⽹络应⽤性能监控以及⽹络资源管理对系统的正常稳定运⾏是⾮常关键的。利⽤⽹络应⽤性能监控⼯具，可以达到事半功倍的效果，在这⽅⾯我们可以提供的⼯具是Network Vantage。通俗地讲，它主要⽤来分析关键应⽤程序的性能，定位问题的根源是在客户端、服务器、应⽤程序还是⽹络。在⼤多数情况下⽤户较关⼼的问题还有哪些应⽤程序占⽤⼤量带宽，哪些⽤户产⽣了最⼤的⽹络流量，这个⼯具同样能满⾜要求。 ⽹络预测　　考虑到系统未来发展的扩展性，预测⽹络流量的变化、⽹络结构的变化对⽤户系统的影响⾮常重要。根据规划数据进⾏预测并及时提供⽹络性能预测数据。我们利⽤⽹络预测分析容量规划⼯具PREDICTOR可以作到：设置服务⽔平、完成⽇⽹络容量规划、离线测试⽹络、⽹络失效和容量极限分析、完成⽇常故障诊断、预测⽹络设备迁移和⽹络设备升级对整个⽹络的影响。　　从⽹络管理软件获取⽹络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可⼈⼯⽣成流量数据），这样可以得到现有⽹络的基本结构。在基本结构的基础上，可根据⽹络结构的变化、⽹络流量的变化⽣成报告和图表，说明这些变化是如何影响⽹络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助⽤户及时升级⽹络，避免因关键设备超过利⽤阀值导致系统性能下降；哪个⽹络设备需要升级，这样可减少⽹络延迟、避免⽹络瓶颈；根据预测的结果避免不必要的⽹络升级。 ·应⽤在服务器上性能的测试　　对于应⽤在服务器上性能的测试，可以采⽤⼯具监控，也可以使⽤系统本⾝的监控命令，例如Tuxedo中可以使⽤Top命令监控资源使⽤情况。实施测试的⽬的是实现服务器设备、服务器操作系统、数据库系统、应⽤在服务器上性能的全⾯监控，测试原理如下图。UNIX资源监控指标和描述　　监控指标 描述　　平均负载 系统正常状态下，最后60秒同步进程的平均个数　　冲突率 在以太⽹上监测到的每秒冲突数　　进程/线程交换率 进程和线程之间每秒交换次数　　CPU利⽤率 CPU占⽤率（％）　　磁盘交换率 磁盘交换速率

　　接收包错误率 接收以太⽹数据包时每秒错误数　　包输⼊率 每秒输⼊的以太⽹数据包数⽬　　中断速率 CPU每秒处理的中断数　　输出包错误率 发送以太⽹数据包时每秒错误数　　包输⼊率 每秒输出的以太⽹数据包数⽬　　读⼊内存页速率 物理内存中每秒读⼊内存页的数⽬　　写出内存页速率 每秒从物理内存中写到页⽂件中的内存页数　　 ⽬或者从物理内存中删掉的内存页数⽬　　内存页交换速率 每秒写⼊内存页和从物理内存中读出页的个数　　进程⼊交换率 交换区输⼊的进程数⽬　　进程出交换率 交换区输出的进程数⽬　　系统CPU利⽤率 系统的CPU占⽤率（％）　　⽤户CPU利⽤率 ⽤户模式下的CPU占⽤率（％）　　磁盘阻塞 磁盘每秒阻塞的字节数⼆、为什么进⾏性能测试？ ⽬的是验证软件系统是否能够达到⽤户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的⽬的。 包括以下⼏个⽅⾯1．评估系统的能⼒，测试中得到的负荷和响应时间数据可以被⽤于验证所计划的模型的能⼒，并帮助作出决策。2．识别体系中的弱点：受控的负荷可以被增加到⼀个极端的⽔平，并突破它，从⽽修复体系的瓶颈或薄弱的地⽅。3．系统调优：重复运⾏测试，验证调整系统的活动得到了预期的结果，从⽽改进性能。检测软件中的问题：长时间的测试执⾏可导致程序发⽣由于内存泄露引起的失败，揭⽰程序中的隐含的问题或冲突。4．验证稳定性（resilience）可靠性（reliability）：在⼀个⽣产负荷下执⾏测试⼀定的时间是评估系统稳定性和可靠性是否满⾜要求的唯⼀⽅法。 性能测试类型包括负载测试，强度测试，容量测试等 负载测试：负载测试是⼀种性能测试指数据在超负荷环境中运⾏，程序是否能够承担。 强度测试： 强度测试是⼀种性能测试，他在系统资源特别低的情况下软件系统运⾏情况。 容量测试：确定系统可处理同时在线的最⼤⽤户数

观察指标： 性能测试主要是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。负载测试和压⼒测试都属于性能测试，两者可以结合进⾏。通过负载测试，确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压⼒测试是通过确定⼀个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最⼤服务级别的测试。 在实际中作中我们经常会对两种类型软件进⾏测试：bs和cs，这两⽅⾯的性能指标⼀般需要哪些内容呢？Bs结构程序⼀般会关注的通⽤指标如下（简）：Web服务器指标指标：* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

* Avg time to last byte per terstion （mstes）:平均每秒业务⾓本的迭代次数 ,有⼈会把这两者混淆；

* Successful Rounds：成功的请求；

* Failed Rounds ：失败的请求； * Successful Hits ：成功的点击次数；

* Failed Hits ：失败的点击次数；

* Hits Per Second ：每秒点击次数；

* Successful Hits Per Second ：每秒成功的点击次数；

* Failed Hits Per Second ：每秒失败的点击次数；

* Attempted Connections ：尝试链接数；CS结构程序，由于⼀般软件后台通常为数据库，所以我们更注重数据库的测试指标：* User 0 Connections ：⽤户连接数，也就是数据库的连接数量；

* Number of deadlocks：数据库死锁；

* Butter Cache hit ：数据库Cache的命中情况 当然，在实际中我们还会察看多⽤户测试情况下的内存，CPU，系统资源调⽤情况。这些指标其实是引申出来性能测试中的⼀种：竞争测试。什么是竞争测试，软件竞争使⽤各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能⼒。 我们知道软件架构在实际测试中制约着测试策略和⼯具的选择。如何选择性能测试策略是我们在实际⼯作中需要了解的。⼀般软件可以按照系统架构分成⼏种类型：c/sclient/Server 客户端/服务器架构基于客户端/服务器的三层架构基于客户端/服务器的分布式架构b/s基于浏览器/Web服务器的三层架构基于中间件应⽤服务器的三层架构l基于Web服务器和中间件的多层架构l三、性能测试的步骤 在每种不同的系统架构的实施中，开发⼈员可能选择不同的实现⽅式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这⾥只是介绍⼀种⽅法提供给你如何选择测试策略，从⽽帮助分析软件不同部分的性能指标，进⽽分析出整体架构的性能指标和性能瓶颈。

由于⼯程和项⽬的不同，所选⽤的度量,评估⽅法也有不同之处。不过仍然有⼀些通⽤的步骤帮助我们完成⼀个性能测试项⽬。步骤如下1． 制定⽬标和分析系统2． 选择测试度量的⽅法3． 学习的相关技术和⼯具4． 制定评估标准5． 设计测试⽤例6． 运⾏测试⽤例7． 分析测试结果·制定⽬标和分析系统 每⼀个性能测试计划中第⼀步都会制定⽬标和分析系统构成。只有明确⽬标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。

⽬标：1． 确定客户需求和期望2． 实际业务需求3． 系统需求系统组成 系统组成这⾥包含⼏⽅⾯含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试⽅法来进⾏测试。 系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构,需要掌握 http协议，java，html等技术 。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。 系统构成：硬件设置，操作系统设置是性能测试的制约条件，⼀般性能测试都是利⽤测试⼯具模仿⼤量的实际⽤户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。 系统功能：系统功能指系统提供的不同⼦系统，办公管理系统中的公⽂⼦系统，会议⼦系统等，系统⼯能是性能测试中要模拟的环节，了解这些是必要的。·选择测试度量的⽅法经过第⼀步，将会对系统有清醒的认识。接下来我们将把精⼒放在软件度量上，收集系统相关的数据。度量的相关⽅⾯：* 制定规范

* 制定相关流程, ⾓⾊，职责* 制定改进策略 * 制定结果对⽐标准

·学习的相关技术和⼯具

性能测试是通过⼯具，模拟⼤量⽤户操作，对系统增加负载。所以需要掌握⼀定的⼯具知识才能进⾏性能测试。⼤家都知道性能测试⼯具⼀般通过winsock,http等协议纪录⽤户操作。⽽协议选择是基于软件的系统架构实现（web⼀般选择http协议,cs选择winsock协议），不同的性能测试⼯具，脚本语⾔也不同，⽐如rational robot中vu脚本⽤类c语⾔实现。 开展性能测试需要对各种性能测试⼯具进⾏评估，因为每⼀种性能测试⼯具都有⾃⾝的特点，只有经过⼯具评估，才能选择符合现有软件架构的性能测试⼯具。确定测试⼯具后，需要组织测试⼈员进⾏⼯具的学习，培训相关技术。·制定评估标准 任何测试的⽬的都是确保软件符合预先规定的⽬标和要求。性能测试也不例外。所以必须制定⼀套标准。 通常性能测试有四种模型技术可⽤于评估： *线性投射：⽤⼤量的过去的，扩展的或者将来可能发⽣的数据组成散布图，利⽤这个图表不断和系统的当前状况对⽐。 *分析模型：⽤排队论公式和算法预测响应时间，利⽤描述⼯作量的数据和系统本质关联起来 *模仿：模仿实际⽤户的使⽤⽅法测试你的系统 *基准：定义测试和你最初的测试作为标准，利⽤它和所有后来进⾏的测试结果进⾏对⽐·设计测试⽤例 设计测试⽤例是在了解软件业务流程的基础上。设计测试⽤例的原则是受最⼩的影响提供最多的测试信息，设计测试⽤例的⽬标是⼀次尽可能的包含多个测试要素。这些测试⽤例必须是测试⼯具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试⽤例，尽可能把性能测试⽤例设计的复杂，才有可能发现软件的性能瓶颈。

·运⾏测试⽤例 通过性能测试⼯具运⾏测试⽤例。同⼀环境下作的性能测试得到的测试结果是不准确的，所以在运⾏这些测试⽤例的时候，需要⽤不同的测试环境，不同的机器配置上运⾏。

·分析测试结果 运⾏测试⽤例后，收集相关信息，进⾏数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的⽅法也不同，bs结构我们会分析⽹络带宽，流量对⽤户操作响应的影响，⽽cs结构我们可能更关⼼会系统整体配置对⽤户操作的影响。四、性能测试⽅法　　对于企业应⽤程序，有许多进⾏性能测试的⽅法，其中⼀些⽅法实⾏起来要⽐其他⽅法困难。所要进⾏的性能测试的类型取决于想要达到的结果。例如，对于可再现性，基准测试是最好的⽅法。⽽要从当前⽤户负载的⾓度测试系统的上限，则应该使⽤容量规划测试。本⽂将介绍⼏种设置和运⾏性能测试的⽅法，并讨论这些⽅法的区别。　　如果不进⾏合理的规划，对J2EE应⽤程序进⾏性能测试将会是⼀项令⼈望⽽⽣畏且有些混乱的任务。因为对于任何的软件开发流程，都必须收集需求、理解业务需要，并在进⾏实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动，并由⼀组⽤例阐明。这些⽤例可以基于历史数据（例如，服务器⼀周的负载模式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如何进⾏测试了。　　在开发阶段前期，应该使⽤基准测试来确定应⽤程序中是否出现性能倒退。基准测试可以在⼀个相对短的时间内收集可重复的结果。进⾏基准测试的最好⽅法是，每次测试改变⼀个且只改变⼀个参数。例如，如果想知道增加JVM内存是否会影响应⽤程序的性能，就逐次递增JVM内存（例如，从1024 MB增⾄1224MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下⼀阶段。这样在分析测试结果时就有迹可循。下⼀⼩节我将介绍什么是基准测试，以及运⾏基准测试的最佳参数。　　开发阶段后期，在应⽤程序中的bug已经被解决，应⽤程序达到⼀种稳定状态之后，可以运⾏更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗⼊测试(soak test)、峰⾕测试(peak-rest test)，它们旨在通过测试应⽤程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下⾯的描述应该从抽象的意义上理解，因为每个应⽤程序的使⽤模式都是不同的。例如，容量规划测试通常都使⽤较缓慢的ramp-up（下⽂有定义），但是如果应⽤程序在⼀天之中的某个时段中有快速突发的流量，那么⾃然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（⽐如ramp-up周期或⽤户的考虑时间(think-time)），测试的结果肯定也会改变。⼀个不错的⽅法是，运⾏⼀系列的基准测试，确⽴⼀个已知的可控环境，然后再对变化进⾏⽐较。基准测试　　基准测试的关键是要获得⼀致的、可再现的结果。可再现的结果有两个好处：减少重新运⾏测试的次数；对测试的产品和产⽣的数字更为确信。使⽤的性能测试⼯具可能会对测试结果产⽣很⼤影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟⽤户）的数⽬，以及每个虚拟⽤户请求之间的考虑时间的长短。很明显，与服务器通信的⽤户越多，负载就越⼤。同样，请求之间的考虑时间越短，负载也越⼤。这两个因素的不同组合会产⽣不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达⼀个点。　　注意，吞吐量以稳定的速度增长，然后在某⼀个点上稳定下来。　　在某⼀点上，执⾏队列开始增长，因为服务器上所有的线程都已投⼊使⽤，传⼊的请求不再被⽴即处理，⽽是放⼊队列中，当线程空闲时再处理。　　注意，最初的⼀段时间，执⾏队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有⾜够的空闲线程去处理增加的负载，最终它还是不能承受，⽽必须将其排⼊队列。　　当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。　　注意，在执⾏队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。　　为了获得真正可再现的结果，应该将系统置于相同的⾼负载下。为此，与服务器通信的虚拟⽤户应该将请求之间的考虑时间设为零。这样服务器会⽴即超载，并开始构建执⾏队列。如果请求（虚拟⽤户）数保持⼀致，基准测试的结果应该会⾮常精确，完全可以再现。　　您可能要问的⼀个问题是：“如何度量结果？”对于⼀次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯⼀⽅法是⼀次加载所有的⽤户，然后在预定的时间段内持续运⾏。这称为“flat”测试。　　与此相对应的是“ramp-up”测试。　　ramp-up测试中的⽤户是交错上升的（每⼏秒增加⼀些新⽤户）。ramp-up测试不能产⽣精确和可重现的平均值，这是因为由于⽤户的增加是每次⼀部分，系统的负载在不断地变化。因此，flat运⾏是获得基准测试数据的理想模式。　　这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运⾏的flat测试的范围⾮常有⽤。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运⾏的flat测试的范围。　　Flat测试的问题是系统会遇到“波动”效果。）　　注意波动的出现，吞吐量不再是平滑的。　　这在系统的各个⽅⾯都有所体现，包括CPU的使⽤量。　　注意，每隔⼀段时间就会出现⼀个波形。CPU使⽤量不再是平滑的，⽽是有了像吞吐量图那样的尖峰。　　此外，执⾏队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执⾏队列也在增长和缩减。　　注意，每隔⼀段时间就会出现⼀个波形。执⾏队列曲线与上⾯的CPU使⽤量图⾮常相似。　　最后，系统中事务的响应时间也遵循着这个波动模式。　　注意，每隔⼀段时间就会出现⼀个波形。事务的响应时间也与上⾯的图类似，只不过其效果随着时间的推移逐渐减弱。　　当测试中所有的⽤户都同时执⾏⼏乎相同的操作时，就会发⽣这种现象。这将会产⽣⾮常不可靠和不精确的结果，所以必须采取⼀些措施防⽌这种情况的出现。有两种⽅法可以从这种类型的结果中获得精确的测量值。如果测试可以运⾏相当长的时间（有时是⼏个⼩时，取决于⽤户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该⽅法的缺点是可以捕获数据的时间⾮常短。性能规划测试　　对于性能规划类型的测试来说，其⽬标是找出，在特定的环境下，给定应⽤程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因⼦。引⼊随机因⼦的⽬的是为了尽量模拟具有真实⽤户负载的现实世界应⽤程序。通常，具体的⽬标是找出系统在特定的服务器响应时间下⽀持的当前⽤户的最⼤数。例如，您可能想知道：如果要以5秒或更少的响应时间⽀持8,000个当前⽤户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。　　要确定系统的容量，需要考虑⼏个因素。通常，服务器的⽤户总数⾮常⼤（以⼗万计），但是实际上，这个数字并不能说明什么。真正需要知道的是，这些⽤户中有多少是并发与服务器通信的。其次要知道的是，每个⽤户的“考虑时间”即请求间时间是多少。这⾮常重要，因为考虑时间越短，系统所能⽀持的并发⽤户越少。例如，如果⽤户的考虑时间是1秒，那么系统可能只能⽀持数百个这样的并发⽤户。但是，如果⽤户的考虑时间是30秒，那么系统则可能⽀持数万个这样的并发⽤户（假定硬件和应⽤程序都是相同的）。在现实世界中，通常难以确定⽤户的确切考虑时间。还要注意，在现实世界中，⽤户不会精确地按照间隔时间发出请求。　　于是就引⼊了随机性。如果知道普通⽤户的考虑时间是5秒，误差为20%，那么在设计负载测试时，就要确保请求间的时间为5×（1 +/- 20%）秒。此外，可以利⽤“调步”的理念向负载场景中引⼊更多的随机性。它是这样的：在⼀个虚拟⽤户完成⼀整套的请求后，该⽤户暂停⼀个设定的时间段，或者⼀个⼩的随机时间段（例如，2×（1 +/- 25%）秒），然后再继续执⾏下⼀套请求。将这两种随机化⽅法运⽤到测试中，可以提供更接近于现实世界的场景。　　现在该进⾏实际的容量规划测试了。接下来的问题是：如何加载⽤户以模拟负载状态？最好的⽅法是模拟⾼峰时间⽤户与服务器通信的状况。这种⽤户负载状态是在⼀段时间内逐步达到的吗？如果是，应该使⽤ramp-up类型的测试，每隔⼏秒增加x个⽤户。或者，所有⽤户是在⼀个⾮常短的时间内同时与系统通信？如果是这样，就应该使⽤flat类型的测试，将所有的⽤户同时加载到服务器。两种不同类型的测试会产⽣没有可⽐性的不同测试。例如，如果进⾏ramp-up类型的测试，系统可以以4秒或更短的响应时间⽀持5,000个⽤户。⽽执⾏flat测试，您会发现，对于5,000个⽤户，系统的平均响应时间要⼤于4秒。这是由于ramp-up测试固有的不准确性使其不能显⽰系统可以⽀持的并发⽤户的精确数字。以门户应⽤程序为例，随着门户规模的扩⼤和集群规模的扩⼤，这种不确定性就会随之显现。　　这不是说不应该使⽤ramp-up测试。对于系统负载在⼀段⽐较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使⽤快速ramp-up测试，系统就会滞后，从⽽报告⼀个较相同⽤户负载的flat测试低的响应时间。那么，什么是确定容量的最好⽅法？结合两种负载类型的优点，并运⾏⼀系列的测试，就会产⽣最好的结果。例如，⾸先使⽤ramp-up测试确定系统可以⽀持的⽤户范围。确定了范围之后，以该范围内不同的并发⽤户负载进⾏⼀系列的flat测试，更精确地确定系统的容量。渗⼊测试　　渗⼊测试是⼀种⽐较简单的性能测试。渗⼊测试所需时间较长，它使⽤固定数⽬的并发⽤户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显⽰因长时间运⾏⽽出现的任何性能降低。测试运⾏的时间越久，您对系统就越了解。运⾏两次测试是⼀个好主意——⼀次使⽤较低的⽤户负载（要在系统容量之下，以便不会出现执⾏队列），⼀次使⽤较⾼的负载（以便出现积极的执⾏队列）。　　测试应该运⾏⼏天的时间，以便真正了解应⽤程序的长期健康状况。要确保测试的应⽤程序尽可能接近现实世界的情况，⽤户场景也要逼真（虚拟⽤户通过应⽤程序导航的⽅式要与现实世界⼀致），从⽽测试应⽤程序的全部特性。确保运⾏了所有必需的监控⼯具，以便精确地监测并跟踪问题。峰⾕测试　　峰⾕测试兼有容量规划ramp-up类型测试和渗⼊测试的特征。其⽬标是确定从⾼负载（例如系统⾼峰时间的负载）恢复、转为⼏乎空闲、然后再攀升到⾼负载、再降低的能⼒。　　实现这种测试的最好⽅法就是，进⾏⼀系列的快速ramp-up测试，继之以⼀段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息⼀下，然后再进⾏快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第⼆次⾼峰是否重现第⼀次的峰值？其后的每次⾼峰是等于还是⼤于第⼀次的峰值？在测试过程中，系统是否显⽰了内存或GC性能降低的有关迹象？测试运⾏（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。结束语　　本⽂介绍了进⾏性能测试的⼏种⽅法。取决于业务需求、开发周期和应⽤程序的⽣命周期，对于特定的企业，某些测试会⽐其他的更适合。但是，对于任何情况，在决定进⾏某⼀种测试前，都应该问⾃⼰⼀些基本问题。这些问题的答案将会决定哪种测试⽅法是最好的。　　这些问题包括：结果的可重复性需要有多⾼？

测试需要运⾏和重新运⾏⼏次？

您处于开放周期的哪个阶段？

您的业务需求是什么？

您的⽤户需求是什么？

您希望⽣产中的系统在维护停机时间中可以持续多久？

在⼀个正常的业务⽇，预期的⽤户负载是多少？

　　将这些问题的答案与上述性能测试类型相对照，应该就可以制定出测试应⽤程序的总体性能的完美计划。