2023年6月21日发(作者：)
按测试对象的⾓度划分：性能测试、安全测试、兼容性测试、⽂档测试、易⽤性测试（⽤户体验测试）。。。性能测试性能测试是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。负载测试和压⼒测试都属于性能测试，两者可以结合进⾏。通过负载测试，确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压⼒测试是通过确定⼀个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最⼤服务级别的测试。中国软件评测中⼼将性能测试概括为三个⽅⾯：应⽤在客户端上性能的测试、应⽤在⽹络上性能的测试和应⽤在服务器端上性能的测试。通常情况下，三⽅⾯有效、合理的结合，可以达到对系统性能全⾯的分析和瓶颈的预测。定义狭义的性能测试主要⽤于描述常规的性能测试，是指通过模拟⽣产运⾏的业务压⼒或⽤户使⽤场景来测试系统的性能是否满⾜⽣产性能的要求。⼴义的性能测试则是压⼒测试、负载测试、强度测试、并发（⽤户）测试、⼤数据量测试、配置测试、可靠性测试等和性能相关的测试统称。基本策略测试的基本策略是⾃动负载测试，通过在⼀台或⼏台PC机上模拟成百或上千的虚拟⽤户同时执⾏业务的情景，对应⽤程序进⾏测试，同时记录下每⼀事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应⽤的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受⼒，就为最终⽤户规划整个运⾏环境的配置提供了有⼒的依据。⽬的⽬的是验证软件系统是否能够达到⽤户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件，最后起到优化系统的⽬的。包括以下⼏个⽅⾯：1．评估系统的能⼒，测试中得到的负荷和响应时间数据可以被⽤于验证所计划的模型的能⼒，并帮助作出决策。2．识别体系中的弱点：受控的负荷可以被增加到⼀个极端的⽔平，并突破它，从⽽修复体系的瓶颈或薄弱的地⽅。3．系统调优：重复运⾏测试，验证调整系统的活动得到了预期的结果，从⽽改进性能。4. 检测软件中的问题：长时间的测试执⾏可导致程序发⽣由于内存泄露引起的失败，揭⽰程序中的隐含的问题或冲突。5．验证稳定性（resilience）、可靠性（reliability）：在⼀个⽣产负荷下执⾏测试⼀定的时间是评估系统稳定性和可靠性是否满⾜要求的唯⼀⽅法。类型性能测试类型包括：负载测试、压⼒测试、并发测试、配置测试、基准测试、验收测试、可靠性测试、失效恢复测试、容量测试，稳定性测试等。⼀般企业会按照这个步骤去执⾏测试：先负载测试（逐步增加并发⽤户数来增加压⼒，只能找出性能指标的瓶颈范围，⽽不是具体的性能指标值），再性能测试（验证我们的性能指标的具体的值，即精确），最后压⼒测试。平时我们说的基准测试其实是在性能测试⾥的找出。压⼒测试：在⼀定的压⼒下，运⾏⽐较长的时间。⽬的是看服务器的稳定性。企业⼝语说的“压测”表达的是：要做负载测试和性能测试。
负载测试（Load Testing）定义负载测试是⼀种主要为了测试软件系统是否达到需求⽂档设计的⽬标，譬如软件在⼀定时期内，最⼤⽀持多少并发⽤户数，软件请求出错率等，测试的主要是软件系统的性能。负载测试是不断增加系统的负载，直到负载达到阈值——评估系统在预期⼯作负载下的性能的测试。这⾥增加负载的意思是在测试中增加并发⽤户数量、⽤户交互等，通常是在可控的环境下进⾏。典型的负载测试包括在负载测试过程中确定响应时间，吞吐量，误码率等。该⽅法可以找到系统的性能极限，可以为性能调优提供相关数据。该类⽅法通常要基于或模拟系统真实运⾏环境，且选取的业务场景也要尽可能地与实际情况相符。狭义的定义：是指对系统不断地增加压⼒或增加⼀定压⼒下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。运⽤场景：此类型的测试⽬前运⽤得⽐较少。⼀般情况下，是以服务器资源安全临界值为界限的测试。如果要模拟某个应⽤在指定服务器上最⼤且安全的负载量，则属于负载测试。⽬标确定并确保系统在超出最⼤预期⼯作量的情况下仍能正常运⾏。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的⽅⾯。负载测试的⽬标是测试在⼀定负载情况下系统性能（不关注稳定性，也就是说不关注长时间运⾏，只是得到不同负载下相关性能指标即可）；实际中我们常从⽐较⼩的负载开始，逐渐增加模拟⽤户的数量（增加负载）， 观察不同负载下应⽤程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统的不同负载情况下的性能指标。⽬的负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或⾏为来发现问题，从⽽为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的⼀部分。但它们两者的⽬的是不⼀样的，负载测试是为了发现缺陷，⽽性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，⽽是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所⽤的⼀种技术，即性能测试使⽤负载测试的技术、使⽤负载测试的⼯具。性能测试要获得在不同的负载情况下的性能指标数据。通过负载测试和压⼒测试都可以获得系统正常⼯作时的极限负载或最⼤容量。容量测试，⾃然也是采⽤负载测试技术来实现，⽽在破坏性的压⼒测试中，容量的确可以看作是⼀种副产品——间接结果。负载测试的必要准备1.什么是你真正需要了解的？2.确定⽤户数量3.研究你的分析4.组建你的团队5.准备你的浏览器6.准备测试你的应⽤7.预留时间分析结果8.预留时间修改9.计划⼀个敏捷测试⽅法压⼒测试（Stress Testing）定义压⼒测试是在强负载（⼤数据量、⼤量并发⽤户等）下的测试，查看应⽤系统在峰值使⽤情况下操作⾏为，从⽽有效地发现系统的某项功能隐患、系统是否具有良好的容错能⼒和可恢复能⼒。压⼒测试分为⾼负载下的长时间（如24⼩时以上）的稳定性压⼒测试和极限负载情况下导致系统崩溃的破坏性压⼒测试。压⼒测试可以被看作是负载测试的⼀种，即⾼负载下的负载测试，或者说压⼒测试采⽤负载测试技术。通过压⼒测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使⽤或系统出错的概率⽐较低，可能⼀个⽉只出现⼀次，但在⾼负载（压⼒测试）下，可能⼀天就出现，从⽽发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这⼀点，某个电⼦商务⽹站的订单提交功能，在10个并发⽤户时错误率是零，在50个并发⽤户时错误率是1%，⽽在200个并发⽤户时错误率是20%。狭义的定义：压⼒测试是指超过安全负载的情况下，对系统不断施加压⼒，是通过确定⼀个系统的瓶颈或不能接收⽤户请求的性能点，来获得系统能提供的最⼤服务级别的测试。运⽤场景：此类型的测试⽬前运⽤得⽐较少。但对于⼤型的共享中⼼或者核⼼的应⽤也会⽤到。⽬标压⼒测试的⽬标是测试在⼀定的负载下系统长时间运⾏的稳定性，尤其关注⼤业务量情况下长时间运⾏系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）；压⼒测试是测试系统的限制和故障恢复能⼒，它包括两种情况：稳定性压⼒测试：在选定的压⼒值下，长时间持续运⾏。通过这类压⼒测试，可以考察各项性能指标是否在指定范围内，有⽆内存泄漏、有⽆功能性故障等；破坏性压⼒测试：在稳定性压⼒测试中可能会出现⼀些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的⼿段，往往能快速造成系统的崩溃或让问题明显的暴露出来。⽬的压⼒测试主要是为了发现在⼀（任意）定条件下软件系统的性能的变化情况，通过改变应⽤程序的输⼊以对应⽤程序施加越来越⼤的负载（并发，循环操作，多⽤户） 并测量在这些不同的输⼊时性能的改变，也就是通常说的概念：压⼒测试考察当前软硬件环境下系统所能承受的最⼤负荷并帮助找出系统瓶颈所在。其实这种测试也 可以称为负载测试，但是负载测试通常描述⼀种特定类型的压⼒测试——增加⽤户数量以对应⽤程序进⾏压⼒测试。⽐如实际中我们说从⽐较⼩的负载开始，逐渐增加模拟⽤户的数量， 直到应⽤程序响应时间超时，就是说的负载测试。压⼒测试主要是为了测试硬件系统是否达到需求⽂档设计的性能⽬标，譬如在⼀定时期内，系统的cpu利⽤率，内存使⽤率，磁盘I/O吞吐率，⽹络吞吐量等，压⼒测试和负载测试最⼤的差别在于测试⽬的不同。压⼒测试是指当硬件资源如cpu、内存、磁盘空间等不充⾜时对软件稳定性的检查。压⼒测试属于负⾯测试（Negative testing），使⼤量并发⽤户/进程加载软件以使系统硬件资源不能应付，这个测试也被称为是疲劳测试（Fatigue testing），通过超出其能⼒的测试来捕获应⽤程序的稳定性。压⼒测试的主要思想是确定系统故障，关注系统如何优雅地恢复正常，这种质量被称为是可恢复性。负⾯测试(Negative testing)是相对于正⾯测试(Positive testing)⽽⾔的。正⾯测试就是测试系统是否完成了它应该完成的功能；⽽负⾯测试就是测试系统是否不执⾏它不应该完成的操作。配置测试同功能测试⼀样，如果需求规格说明中有明确的性能需求，例如完成复杂运算处理的解算时间要求，解算精度要求，⽹络传输吞吐量，数据库的最⼤容量，服务器能允许的同时在线访问数量等等，都要反映在配置项测试⾥。如果没有明确指出性能要求，测试⼈员可根据软件产品所处⾏业，⾃⾏产⽣测试需求。——这很考验测试⼈员的素质和⽔平的哦。例如前⾯所提到的，服务器能允许的最⼤同时在线访问量，就是互联⽹⾏业的⼀个性能需求。当然，还有常规的空间性能（存储和占⽤计算机硬件资源）和时间性能（软件处理⼀个任务所⽤时间），如今的计算机资源，基本都满⾜要求，除⾮你是航空发射，武器控制等特殊⾏业，才需要⾮常关注配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整 Oracle 的内存参数来进⾏测试，使之达到⼀个较好的性能。可以看出，配置测试本质上是前⾯提到的某些种类的性能测试组合在⼀起⽽进⾏的测试。
并发测试定义 所谓并发，它的特点是“并⾏”和“同时”。在loadrunner中就得使⽤集合点的功能来实现。 测试多个⽤户同时访问同⼀个应⽤、同⼀个模块或者数据记录时是否存在死锁或者其他性能问题，⼏乎所有的性能测试都会涉及⼀些并发测试。通常的测试⽅法是设置集合点。⽬的测试⽬的并⾮为了获得性能指标，⽽是为了发现并发引起的问题。并发概念的浅谈想确定⽤户并发数；必须知道系统所承载的在线⽤户数；对于并发，我过去接触了⼏种理解，在接触的第⼀种理解中，“并发”是由loadrunner中获取，即脚本中所有或部分vuser执⾏⾄集合点函数时进⾏停留，等待触发条件发⽣以后，同时执⾏集合点函数后的请求操作的这⼀个过程，为“并发”（这⼀个请求操作⼀般存在多个http请求），可惜这种“并发”是⽆法直接⽤于衡量系统性能的。LoadRuner的并发很好理解，就是虚拟⽤户数。因为LR有个集合点，可以在所有虚拟⽤户初始化且到达集合点后，再⼀起执⾏后续操作，从⽽达到同时且并⾏的效果。⽽在接触的第⼆种理解中，“并发”的理解是相对于服务器某⼀个时间区间内接收的请求数，也就是每秒的点击率（loadrunner考虑到这点，也就是analysis⾥⾯的hits/s），为“并发”，这种“并发”是可以⽤于对系统性能状况进⾏量化的，但是这种测试思想只是⽐较⽚⾯的从性能指标的⾓度去衡量系统性能，不能体现出系统性能带给⽤户何种性能体验（这也是不少开源性能测试⼯具的问题）。前⼀种“并发”的理解普遍获得了loadrunner初级⽤户的认可，后⼀种“并发”的理解普遍获得系统运维、开发⼈员的认可，在沟通中为了⽅便区别开来，在两种⾓⾊⾥⾯，当⼤家意识到并发的理解存在差异时，⼤家把前⼀种被称为“狭义上的并发”，⽽后⼀种被称为“⼴义上的并发”。后来，⼜从淘宝团队⾥⾯了解了⼀种定义，貌似淘宝QA把“并发”定义为⼀个完整的事务请求数量过程（loadrunner也考虑到这点，也就是analysis⾥⾯的Transactions per Second）。⼀直以来，还有⼀种技术范围以外对“并发”的粗略的理解被第三⽅测试拿来⽤了，那就是⽤户在线数中的某个百分⽐即并发数。如果⼀个团队⾥⾯对“并发”的理解有这么多种，那么当我们在讨论性能需求的“⽀持并发数”时，我们究竟在讨论什么呢？个⼈认为，有⼀部分的原因是由于loadrunner是惠普saas（软件即服务的解决⽅案）的⼀部分，所以并不是⼀个纯粹技术⼈员使⽤的测试⼯具，它同时也是⼀个业务⼈员可以相对轻易掌握的性能测试⼯具，因此loadrunner内很多名词解释也不能单纯从技术⼈员的⾓度从字⾯意义上理解。通常来说，⾯对同样100笔业务交易量，普遍会认为100vuser对服务器产⽣的负载会⽐50vuser要⾼，但是在性能脚本能够在较快的响应时间中完成时，由于50vuser执⾏过程中每⼀个vuser都需要发⽣两次迭代，导致了性能场景中vuser在脚本action部分停留的时间更长，因此反⽽能够得到⽐100vuser的更⾼的vuser在线数，更⾼在线数带来的也就是更⼤的负载，也就是说：同等业务量的情况下，50线程所产⽣的负载完全有可能⽐100线程所产⽣的负载要⾼。为了避免发⽣这种问题，“并发（集合点）”的真正作⽤就体现出来了，通过集合点函数控制了vuser的⾏为相对⼀致，降低了初始化过程和事务前后⽂请求产⽣的时间差影响。测试⼯具中并发存在的真正意义也就在这⾥，对集合点所理解的“并发”，和现场实际⽤户⾥⾯同时触发的请求关系不是太⼤。分析“并发”需求时的⼀些典型：a) 某个业务系统⾥⾯有10000⽤户，但是能够访问这个系统的终端数只有1000个、或者所需测试的业务每个⽉上限是1000笔，那么最⾼在线⽤户数就不可能超过1000、业务量也不可能超过1000。所以，有些时候在分析性能需求的时候，去统计⼀个业务系统的⽤户数还不如去统计能够访问这个系统的终端数、甚⾄业务量靠谱。b) 某个业务系统⾥⾯，各个业务模块都不⼀样，那么就是说完成⼀笔业务交易，所产⽣的请求数也是不⼀样的，例如表单新增，有的需要填写20个字段，有的只需要填写5个字段，各个表单都不⼀样，那么为了更接近的去模拟⽤户现场负载，请求数都不⼀样的各种业务混在⼀起，并发数⼜应该是多少呢？为了解决这些问题，需要⾸先考虑“并发”的粒度，以真实的业务场景为例：a) 把粒度控制在⽤户上来看，假定所有⽤户访问⼀次系统平均耗时500秒，⼀个业务峰值会有800⽤户在线，则800/500=1.6。理论上，系统的性能需求是每秒要成功处理1.6个⽤户的请求；b) 把粒度控制在事务上来看，假定所有⽤户执⾏⼀次完整的、成功的业务操作平均需要500秒，⼀个业务峰值有2000笔所关注的业务需要去执⾏，则2000/500=4。理论上，系统的性能需求是每秒要成功处理4笔业务交易；c) 把粒度控制在请求上来看，假定所有⽤户执⾏⼀次完整的、不管成功或者失败的HTTP请求操作平均需要0.08秒，⼀个业务峰值有28000个请求需要去完成，则28000/0.08=350000。理论上，系统的性能需求是每秒要成功处理350000个请求。分类1、独⽴业务性能测试：核⼼业务模块的某⼀业务并发性能测试； 2、组合业务性能测试：⼀个或多个模块的多个业务同时进⾏并发测试。
独⽴业务性能测试1、完全⼀样功能的并发测试：检查程序对同⼀时刻并发操作的处理，例如模拟多个⽤户在同⼀时刻向数据库写⼊相同数据，或者多个⽤户在同⼀时刻发出请求测试系统能否正确响应。2、完全⼀样操作的并发测试：在同⼀时刻完成完全⼀样的操作，即从宏观上看操作对系统的影响是⼀致的，例如同时单击保存按钮。这类测试⽬的在于验证⼤量⽤户使⽤同⼀功能时系统能否正常⼯作。3、相同/不同的⼦功能并发测试：同⼀模块⼤多数功能相互耦合，针对⼀些⼦功能较多的模块做组合测试。组合的依据就是⽤户使⽤的场景，每个不同的⼦功能都模拟⼀定的⽤户数量进⾏并发测试。组合业务性能测试1、不同核⼼业务模块的⽤户进⾏并发，模块之间具有⼀定耦合：这种测试⽐较接近⽤户使⽤情况，测试的对象是多个模块组，每个组相关的模块之间具有⼀定耦合关系。组与组之间的关系相对独⽴。例如实际中各类型的⽤户都会对应⼀组模块，相当于不同的业务组并发的访问系统。2、具有耦合关系的核⼼模块组进⾏并发，每组模块内部存在耦合关系：主要测试多⽤户并发条件下⼀些存在耦合或者数据接⼝的模块是否正常运⾏，可以参考集成测试⽤例和概要设计⽂档，分析出⼀些核⼼模块的接⼝。3、基于⽤户场景的并发测试：选择⽤户的⼀些经典场景做测试，测试对象可以是核⼼模块，也可以是⾮核⼼模块。这种测试更接近⽤户使⽤的实际情况，测试需要充分考虑实际场景。设计组合模块⽤户并发性测试⽤例⼀般⽤不同“⼦功能”或者“⼦事务”为单位，来进⾏各种模块的不同核⼼功能组合。并发⽤户数量设计⽅法 容量测试（Volume Testing）定义 所谓容量，即系统处于最⼤负载状态或某项指标达到所能接受的最⼤阈值下对请求的最⼤处理能⼒。容量测试是⼀种⾮功能的测试，它通过向应⽤程序中添加⼤量的数据来实现检查被测系统处理⼤数据量的能⼒。可以通过向数据库插⼊⼤量的数据或让应⽤程序处理⼀个⼤型⽂件来进⾏测试应⽤程序。通过容量测试，可以识别应⽤程序中具有⼤数据时的瓶颈，检查应⽤程序的效率，进⽽得到不同数据量级下应⽤程序的性能。确定系统最⼤承受量，譬如系统最⼤⽤户数，最⼤存储量，最多处理的数据流量等。
举例：在⼀个新开发的⽹络游戏应⽤程序中，在进⾏容量测试时，可以通过向数据库中插⼊数百万⾏的数据，然后在这些数据的基础上进⾏性能的测试。注意，这⾥所说的数据⼀定是符合其功能场景的，不是毫⽆关系的数据。⽬的容量测试的⽬的是通过测试预先分析出反映软件系统应⽤特征的某项指标的极限值（如最⼤并发⽤户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运⾏。容量测试还将确定测试对象在给定时间内能够持续处理的最⼤负载或⼯作量。软件容量的测试能让软件开发商或⽤户了解该软件系统的承载能⼒或提供服务的能⼒，如某个电⼦商务⽹站所能承受的、同时进⾏交易或结算的在线⽤户数。知道了系统的实际容量，如是不能满⾜设计要求，就应该寻求新的技术解决⽅案，以提⾼系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使⽤中的性能状况充满信⼼，同时也可以帮助⽤户经济地规划应⽤系统，优化系统的部署。如何统计容量指标？统计维度⼀般来说，可以从如下两个维度来定量系统的容量：
统计⽅法⼀般来说，常⽤的采集数据的⽅法，有以下⼏种⽅式：①、埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进⾏数据采集；②、⽇志/数据库：通过⽇志服务（⽐如ELK）或者运维监控（现在很流⾏的Devops），采集分析数据；③、Agent/探针：在需要采集的节点添加Agent/探针，实时采集，数据存⼊时序数据库（⽐如influxdb），实时展⽰；注意事项①、采集对⽐的数据⼀定要采集线上的真实数据，这样才能反映真实客观的系统压⼒。②、容量测试环境的配置，⼀定要和线上保持⼀致（服务器数量可以不同，但配置尽可能保持⼀致）。测试思路①、根据具体的业务情况和系统架构，通过配置测试的⼿段，测量得到单个服务节点在对应的业务场景下最⼤的性能表现；②、根据系统架构（集群、分布式、微服务）特点，通过启⽤≥2的服务节点，来得到服务节点的增加和系统性能的提升⽐例；③、通过线上采集的系统数据，分析出过去某段时间（或某个业务）的⾼峰流量，然后通过计算，得到容量扩容，需要投⼊的实际服务数量；约束/停⽌条件在测试过程中，只要限定的某项指标达到最⼤可接受阈值或某项资源达到最⼤使⽤状态，即刻停⽌测试。选择合适的容量指标考虑到业务需求和系统架构的不同，在选取容量指标时⼀般遵循如下原则：①、数据密集型：即并发请求量较⼤的类型，⼀般TPS和RT是⽐较关注的指标；②、数据存储型：即需要存储读写的数据量较⼤的类型，⼀般吞吐量和IO是⽐较关注的指标；容量规划为什么需要容量规划？对于业务越来越复杂的商业形态，每个业务都由⼀系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的⽬的在于让每⼀个业务系统能够清晰地知道：①、什么时候应该增加服务节点，什么时候应该减少服务节点（⽐如服务端接受到的流量达到什么量级）？（⽐如双⼗⼀，⼤促，秒杀）②、为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可⽤性、稳定性，⼜能节约成本？容量规划四步⾛①、业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击；②、系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配⽐，然后计算每个业务⼤概需要多少服务节点来提供可靠稳定的性能⽀撑；③、系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进⾏针对性的调整；④、流量分配调整阶段：根据压测的结果，设定限流、服务降级等系统保护措施，来预防当实际流量超过系统所能承受的最⼤流量时，系统⽆法提供服务；扩容⼿段①、垂直扩容升级服务的硬件配置，让单个服务节点的容量更⼤，来提供更⾼的系统服务能⼒。⽐如：加⼤服务机器的CPU数量和内存，更换性能更好的⾼速缓存服务器，数据存储⽤NAS盘替换等。②、⽔平扩展即增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能⼒。常见的⽅式有：服务集群：服务器的数量由1→N（但需要重点关注负载均衡）；分布式：提供服务的节点由统⼀集中管理部署，分散到不同的地点；容器：提供更灵活的弹性扩容机制，根据具体的访问流量⼤⼩来弹性扩容或者缩容；容量测试的优点以下是任何软件应⽤程序的容量或洪⽔测试的优点。它提供了运⾏软件应⽤程序所需的硬件类型的清晰图像，包括CPU、内存等。可以很早地确定可扩展性计划。它有助于节省可能⽤于应急计划的⼤量资⾦。它有助于尽早发现应⽤程序操作中的瓶颈。它确保了经过容量测试的应⽤程序已准备好投⼊实际使⽤。它有助于让应⽤程序上线或不上线。容量测试的缺点此类测试增加了项⽬的额外成本，因为它是由不同的性能测试团队在功能测试的基础上完成的。为什么经常推荐容量测试？由于以下原因，通常建议进⾏容量测试。当到数据库中的数据量增加时，它有助于检查系统性能。使⽤⼤量数据研究软件应⽤程序⾏为。评估应⽤程序稳定性开始降低的点。它可以识别正常，低，中，⾼容量下的应⽤能⼒。容量测试检查在容量或洪⽔测试期间评估和检查以下参数。容量测试旨在检查是否有任何数据丢失。进⾏容量测试以记录不同容量条件下的响应时间并评估平均响应时间。它旨在评估数据库中的数据是否正确保存。它旨在验证数据是否被任何通知覆盖。它旨在检查警告和错误消息，以及它们在不同容量级别的关联。它旨在检查⾼数据量是否会以任何⽅式影响被测系统中处理请求的速度。容量测试最佳实践以下是最佳容量测试结果⼴泛遵循的最佳实践。在检查所有⽇志 (即服务器和应⽤程序的⽇志) 时, 不要忘记停⽌所有服务器。在开始容量测试之前，确保正⾯（正常）场景正常⼯作。为了从容量测试中获得最佳结果，始终建议错开⽤户数量。平衡你的容量试时间以克服许可限制。引⼊的任何新版本都应该⾮常谨慎地处理。建⽴基线后，应分析⽤例以提⾼性能。在出现性能瓶颈的情况下，应该反复重复进⾏容量测试，以深⼊研究性能问题。可靠性测试定义软件可靠性测试是指为了保证和验证软件的可靠性要求⽽对软件进⾏的测试。其采⽤的是按照软件运⾏剖⾯(对软件实际使⽤情况的统计规律的描述)对软件进⾏随机测试的测试⽅法。软件可靠性是软件系统在规定的时间内以及规定的环境条件下，完成规定功能的能⼒。⼀般情况下，只能通过对软件系统进⾏测试来度量其可靠性。对软件可靠性进⾏定量的评估或验证，为了达到和验证软件的可靠性定量要求⽽对软件进⾏的测试。软件可靠性测试通常是在系统测试、验收、交付阶段进⾏，它主要是在实验室内仿真环境下进⾏，也可以根据需要和可能在⽤户现场进⾏。在给系统加载⼀定业务压⼒的情况下，使系统运⾏⼀段时间，以此检测系统是否稳定。例如，可以施加让 CPU 资源保持 70%～90%使⽤率的压⼒，连续对系统加压 8 个⼩时，然后根据结果分析系统是否稳定。这么多类型的性能测试看起来很吓⼈，实际上它们⼤多是密切相关的。例如，运⾏ 8 个⼩时来测试系统是否可靠，⽽这个测试极有可能包含了可靠性测试、强度测试、并发（⽤户）测试、负载测试，等等。特点
测试的⽬的(1)通过在有使⽤代表性的环境中执⾏软件，以证实软件需求是否正确实现。(2)为进⾏软件可靠性估计采集准确的数据，预测软件在实际运⾏中的可靠性。估计软件可靠性⼀般可分为四个步骤，即数据采集、模型选择、模型拟合以及软件可靠性评估。可以认为，数据采集是整个软件可靠性估计⼯作的基础，数据的准确与否关系到软件可靠性评估的准确度。(3)通过软件可靠性测试找出所有对软件可靠性影响较⼤的错误。(4)通过测试可以提⾼整个软件系统的防错、容错和纠错的能⼒。通过软件可靠性测试可以达到以下⽬的：(1) 有效地发现程序中影响软件可靠性的缺陷，从⽽实现可靠性增长：软件可靠性是指“在规定的时间内，规定的条件下，软件不引起系统失效的能⼒，其概率度量称为软件可靠度。”软件的“规定的条件”主要包括相对不变的条件和相对变化的条件，相对不变的条件如计算机及其操作系统;相对变化的条件是指输⼊的分布，⽤软件的运⾏剖⾯来描述。认为按照软件的运⾏剖⾯对软件进⾏测试⼀般先暴露在使⽤中发⽣概率⾼的缺陷，然后是发⽣概率低的缺陷。⽽⾼发⽣概率的缺陷是影响产品可靠性的主要缺陷，通过排除这些缺陷可以有效地实现软件可靠性的增长。(2) 验证软件可靠性满⾜⼀定的要求：通过对软件可靠性测试中观测到的失效情况进⾏分析，可以验证软件可靠性的定量要求是否得到满⾜。(3) 估计、预计软件可靠性⽔平通过对软件可靠性测试中观测到的失效数据进⾏分析，可以评估当前软件可靠性的⽔平，预测未来可能达到的⽔平，从⽽为开发管理提供决策依据。软件可靠性测试中暴露的缺陷既可以是影响功能需求的缺陷也可以是影响性能需求的缺陷。软件可靠性测试⽅法从概念上讲是⼀种⿊盒测试⽅法，因为它是⾯向需求、⾯向使⽤的测试，它不需要了解程序的结构以及如何实现等问题。分析⽅法⽬前主要的软件可靠性分析⽅法有失效模式影响分析法、严酷性分析法、故障树分析法、事件树分析法、潜在线路分析法。测试过程包括五个步骤：确定可靠性⽬标，定义软件运⾏剖⾯，设计测试⽤例，实施可靠性测试，分析测试结果。失败恢复性测试 对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发⽣故障⽤户是否能够继续使⽤系统，⽤户收到多⼤的影响。
强度测试强度测试是⼀种性能测试，它在系统资源特别低的情况下软件系统运⾏情况，⽬的是找到系统在哪⾥失效以及如何失效的地⽅。 强度测试主要是为了检查程序对异常情况的抵抗能⼒。强度测试总是迫使系统在异常的资源配置下运⾏。例如： 当正常的⽤户点击率为“1000 次/秒”时，运⾏点击率为“2000 次/秒”的测试⽤例； 运⾏需要最⼤存储空间（或其他资源）的测试⽤例； 运⾏可能导致操作系统崩溃或磁盘数据剧烈抖动的测试⽤例，等等。强度测试是⼀种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进⾏的测试，更容易发现系统是否稳定以及性能⽅⾯是否容易扩展。疲劳测试疲劳测试是采⽤系统稳定运⾏情况下能够⽀持的最⼤并发⽤户数，持续执⾏⼀段时间业务，通过综合分析交易执⾏指标和资源监控指标来确定系统处理最⼤⼯作量强度性能的过程。是⼀类特殊的强度测试，主要测试系统长时间运⾏后的性能表现，例如 7× 24 ⼩时的压⼒测试。尖峰测试（Spike testing）尖峰测试（Spike testing）其实可以算作是压⼒测试（Stress Testing）的⼦集。尖峰测试是在⽬标系统经受短时间内反复增加⼯作负载，以⾄超出预期⽣产操作的负载量时，分析系统的⾏为，验证其性能特征。它还包括检查应⽤程序是否可以从突然增加的超预期负荷中恢复出来的测试。举例：在电商应⽤程序中经常有“整点秒杀”的活动，所以在整点时间前后的两三分钟时间⾥，会有巨⼤数量的⽤户进⼊到该活动中秒杀商品。尖峰测试就是为了分析这类场景。持久测试（Endurance testing）持久测试（Endurance testing），也被称为是浸泡测试（Soak Testing），它也是⼀种⾮功能的测试。持久测试是指在相当长的时间内使⽤预期的负载量对系统进⾏测试，以检查系统的各种⾏为，如内存泄露、系统错误、随机⾏为等。这⾥的提到的相当长的时间是相对⽽⾔的，举例来说，如果⼀个系统设计为运⾏3个⼩时的时间，那可以使⽤6个⼩时的时间来进⾏持久测试；如果设计为5个⼩时的时间，不妨⽤10个⼩时的时间来进⾏持久测试。对于现在的许多⽹络类应⽤程序，通常情况下会持续运⾏好多天，那么进⾏持久测试时可以选择更长的时间段。稳定性测试狭义的定义：稳定性测试是指被测试系统在特定硬件、软件、⽹络环境条件下，给系统加载⼀定业务压⼒，使系统运⾏⼀段较长时间，以此检测系统是否稳定，⼀般稳定性测试时间为 n*12 ⼩时。运⽤场景：此类型的测试⽬前也最常见，针对需要长时间稳定运⾏的性能点，需要执⾏稳定性测试。往往在⼀个项⽬的性能测试过程中，会划分出优先级较⾼的性能点，做稳定性测试。例如：宝贝详情页⾯等等。如何实施识别并确认软件主要业务（是否需要稳定性测试）将稳定性测试的重⼼放在软件最有Value的地⽅，⽐如说⼀个抢票系统，它最有value的地⽅是当有⼀定数量的⽤户同时进⾏买票操作是系统的响应时间，资源利⽤率等是否能够正常且稳定，⽽不是⽤户如何添加新的联系⼈，修改个⼈信息等。罗列主要⽤户场景及响应负载量⽤户场景可以根据软件主要业务进⾏设定对主要场景负载量需要有⼀个清晰的定义（或者通过负载测试验证了⽤户场景的负载量，这将作为⼀个标准的负载在稳定性测试中使⽤）制定稳定性指标模型（Modeling）根据⽤户场景建模，创建合适合理的稳定性指标模型（之后会有⼀个例⼦）测试环境准备（对软硬件环境的配置：配置的来源可以是客户环境模拟、需求⽂档规定的配置或者配置测试得出的最佳配置）识别稳定性的主要性能指标（KPI）⽤来描述稳定性测试关注的系统指标，⽐如响应时间、CPU、内存使⽤率等等，需要根据具体业务进⾏定义测试的执⾏和数据收集，按照相应稳定性指标模型（Modeling)分析测试结果，将测试结果应⽤在稳定性测试模型中，观察是否满⾜稳定性要求持续改进（如有必要）⼤数据量测试主要针对数据库有特殊要求的系统进⾏的测试，如电信业务系统的⼿机短信业务；可以分为实时⼤数据量，主要⽬的是测试⽤户较多或者某些业务产⽣较⼤数据量时，系统能否稳定运⾏；极限状态下的测试，测试系统使⽤⼀段时间即系统累计⼀点量的数据时能否正常的运⾏业务；前⾯两种的结合，测试系统已经累计了较⼤数据量时，⼀些实时产⽣较⼤数据量的模块能否稳定⼯作；如下⼤数量测试⽤例： 功能：数据库中的短信息表可以保存所有不能及时发送的短信息，⽤户上线后⼜能及时发送已经保存的信息；⼤数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进⾏⼤数据量的独⽴数据量测试；与压⼒性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试⽅案。⼤数据量测试的关键是测试数据的准备，可以依靠⼯具准备测试数据。速度测试速度测试主要是针对关键有速度要求的业务进⾏⼿⼯测速度，可以在多次测试的基础上求平均值，可以和⼯具测得的响应时间等指标做对⽐分析。不同类型测试之间的区别性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，⽽负载测试、压⼒测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常⼯作时所能承受的最⼤负载，这时负载测试就成为容量测试。通过压⼒测试，可以知道在什么极限情况下系统会崩溃、系统是否具有⾃我恢复性等，但更多的是为了确定系统的稳定性。压⼒测试是测试系统什么情况下失效或者崩溃；负载测试是测试系统什么情况下超出需求指标；强度测试是测试系统在瞬时⾼负载、长时间负载情况下系统反应；容量测试是测试系统在⼤数据量交互的反应！ 性能指标性能测试最基本要考虑以下⼏点1、时间特性，主要指的是软件产品的事务响应时间（⽤户发出请求到收到应答的这段时间）2、资源利⽤率，包括：cpu、内存、⽹络、硬盘、虚拟内存（如Java虚拟机）3、服务器可靠性，指服务器能在相对⾼负载情况下持续的运⾏4、可配置优化性，指服务器配置优化、业务逻辑优化、代码优化等检查系统是否满⾜需求规格说明书中规定的性能，通常表现在以下⼏个⽅⾯：1、对资源利⽤（包括：cpu、内存、⽹络、硬盘、虚拟内存（如Java虚拟机）等）进⾏的精确度量；2、对执⾏间隔；3、⽇志事件（如中断，报错）4、响应时间5、吞吐量（TPS）6、辅助存储区（例如缓冲区、⼯作区的⼤⼩等）7、处理精度等进⾏的监测TPS:服务器综合能⼒指标值，服务器最主要的指标值。吞吐量有个单位是：平均事务数/秒loadrunner和jmeter的TPS是有区别的，jmeter有两种每秒事务数。jmeter除了每个业务的请求到响应完成的统计外，还有事务逻辑控制器对多个单个业务请求打包成⼀个全链路业务流的业务的请求到响应完成的统计等。性能测试不是去找功能上的bug，是找出服务器的瓶颈。在实际⼯作中我们经常会对两种类型软件进⾏测试：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：数据库死锁；* Buffer Cache hit ：数据库Cache的命中情况当然，在实际中我们还会察看多⽤户测试情况下的内存，CPU，系统资源调⽤情况。这些指标其实是引申出来性能测试中的⼀种：竞争测试。什么是竞争测试，软件竞争使⽤各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能⼒。我们知道软件架构在实际测试中制约着测试策略和⼯具的选择。如何选择性能测试策略是我们在实际⼯作中需要了解的。⼀般软件可以按照系统架构分成⼏种类型：c/sclient/Server 客户端/服务器架构基于客户端/服务器的三层架构基于客户端/服务器的分布式架构b/s基于浏览器/Web服务器的三层架构基于中间件应⽤服务器的三层架构l基于Web服务器和中间件的多层架构l性能指标的两个⽅⾯ 外部指标|系统指标（与⽤户场景和需求相关指标）从外部看，性能测试主要关注如下四个指标吞吐量：每秒钟系统能够处理客户的请求数、任务数，其直接体现系统的承载的能⼒。并发⽤户数：同⼀时刻与服务器进⾏数据交互的所有⽤户数量；响应时间：服务处理⼀个请求或⼀个任务的耗时。错误率：⼀批请求中结果出错的请求所占⽐例。响应时间从单个请求来看就是服务响应⼀次请求的花费的时间。但是在性能测试中，单个请求的响应时间并没有什么参考价值，通常考虑的是完成所有请求的平均响应时间及中位数时间。
平均响应时间很好理解，就是完成请求花费的总时间/完成的请求总数。但是平均响应时间有⼀点不靠谱，因为系统的运⾏并不是平稳平滑的，如果某⼏个请求的时间超短或者超长就会导致平均数偏离很多。因此有时候我们会⽤中位数响应时间。所谓中位数的意思就是把将⼀组数据按⼤⼩顺序排列，处在最中间位置的⼀个数叫做这组数据的中位数 ，这意味着⾄少有50%的数据低于或⾼于这个中位数。当然，最为正确的统计做法是⽤百分⽐分布统计。也就是英⽂中的TP – Top Percentile ，TP50的意思在，50%的请求都⼩于某个值，TP90表⽰90%的请求⼩于某个时间。响应时间的指标取决于具体的服务。如智能提⽰⼀类的服务，返回的数据有效周期短（⽤户多输⼊⼀个字母就需要重新请求），对实时性要求⽐较⾼，响应时间的上限⼀般在100ms以内。⽽导航⼀类的服务，由于返回结果的使⽤周期⽐较长（整个导航过程中），响应时间的上限⼀般在2-5s。决定系统响应时间要素我们做项⽬要排计划，可以多⼈同时并发做多项任务，也可以⼀个⼈或者多个⼈串⾏⼯作，始终会有⼀条关键路径，这条路径就是项⽬的⼯期。系统⼀次调⽤的响应时间跟项⽬计划⼀样，也有⼀条关键路径，这个关键路径是就是系统响应时间；关键路径是由CPU运算、IO、外部系统响应等等组成。计算公式1、响应时间：对⼀个请求做出响应所需要的时间⽹络传输时间：N1+N2+N3+N4应⽤服务器处理时间：A1+A3数据库服务器处理时间：A2响应时间=⽹络响应时间+应⽤程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3)注：绝对不允许⽤⽣产环境，公司如果有准⽣产环境最好。从⽣产的集群⾥抽取⼀个单机拿出来专门做性能测试的独⽴服务器。但是其数据库数据和服务都彻底从集群中移出来，这样不影响⽣产环境正常业务发展。独⽴⽹络：就是必须使⽤⽹线有线连接，千万不要使⽤wifi，VPN，堡垒机（把两个⽹络连接起来的桥梁），最好是测试负载机和控制机在同⼀个⽹络⽽且都是独⽴的局域⽹⾥直接路由跳出去访问外⽹的服务器。否则⽹速会严重影响数据的传输和加载，会出现数据包丢失严重的现象。最主要的是严重影响响应时间的指标值，偏差太⼤，没有参考价值。2、平均响应时间：所有请求花费的平均时间系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页⾯，⼀般响应时间为3秒左右。如：如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms平均响应时间： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms，引申出百分位数百分位数：以响应时间为例，指的是 99% 的请求响应时间，都处在这个值以下，更能体现整体效率。注：（⼀般响应时间在3s内，⽤户会感觉⽐较满意。在3s~8s之间⽤户勉强能接受，⼤于8s⽤户就可能⽆法接受，从⽽刷新页⾯或者离开，仅供参考）响应时间与负载对应关系图中拐点说明：（1）响应时间突然增加（2）意味着系统的⼀种或多种资源利⽤达到的极限（3）通常可以利⽤拐点来进⾏性能测试分析与定位并发⽤户数⼀、⾸先涉及到并发⽤户数可以从以下⼏个⽅⾯去做数据判断。1.系统⽤户数2.在线⽤户数3.并发⽤户数⼆、三者之间的关系1.在线⽤户数的预估可以采取20%的系统⽤户数。例如某个系统在系统⽤户数有1000，则同时在线⽤户数据有可能达到200，或者预估200做参考。2.在线⽤户数和并发⽤户数⼜存在着关系。即：平均并发⽤户数为:c=NL/T L为在线时长，T为考核时长。例如:考核时长为1天，即8⼩时，但是⽤户平均在线时长为2⼩时，则c=n*2/8 n为登录系统的⽤户数，L为登录的时常。例如:⼀个系统有400个⽤户登录，然后每个⽤户登录⼤概停留2⼩时，则以⼀天8⼩时考核，算平均并发⽤户则为:c=400*2/8并发主要是针对服务器⽽⾔，在同⼀时刻与服务器进⾏交互（指向服务器发出请求）的在线⽤户数。（1）并发⽤户数：某⼀物理时刻同时向系统提交请求的⽤户数，提交的请求可能是同⼀个场景或功能，也可以是不同场景或功能。（2）在线⽤户数：某段时间内访问系统的⽤户数，这些⽤户并不⼀定同时向系统提交请求。如多个⽤户在浏览⽹页，但没有对同时对服务器进⾏数据请求，需要与并发⽤户数区分开。（3）系统⽤户数：系统注册的总⽤户数据 三者之间的关系：系统⽤户数 >= 在线⽤户数 >= 并发⽤户数同时在线⽤户数：在⼀定的时间范围内，最⼤的同时在线⽤户数量。同时在线⽤户数=每秒请求数RPS（吞吐量）+并发连接数+平均⽤户思考时间平均并发⽤户数的计算：C=nL / T其中C是平均的并发⽤户数，n是平均每天访问⽤户数（login session），L是⼀天内⽤户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（⼀天内多长时间有⽤户使⽤系统）并发⽤户数峰值计算：C^约等于C + 3*根号C 也是峰值C1,即最⼤并发数，计算公式C1=C+³√C其中C^是并发⽤户峰值，C是平均并发⽤户数，该公式遵循泊松分布理论。注：理解最佳并发⽤户数和最⼤并发⽤户数
看了《LoadRunner没有告诉你的》之理发店模式，对最佳并发⽤户数和最⼤的并发⽤户数的理解⼩⼩整理了⼀下。所谓的理发店模式，简单地阐述⼀下，⼀个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利⽤，这时3个⽤户数即为最佳的并发⽤户数；当理发店来了9个客户的时候，3个客户理发，⽽6个⽤户在等待，3个客户的等待时间为1个⼩时，另外的3个客户的等待时间为2⼩时，客户的最⼤忍受时间为3⼩时包括理发的1个⼩时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最⼤并发⽤户数。吞吐量我把吞吐量定义为“单位时间内系统处理的客户请求的数量”（ 吞吐量表⽰单位时间内能够完成的事务数量，因此也被称为每秒事务数（Transaction Per Second），计算⽅式是完成的事务数除以时间。），直接体现软件系统的性能承载能⼒，对于交互式应⽤系统来说、吞吐量反映的是服务器承受的压⼒、在容量规划的测试中、吞吐量是⼀个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。吞吐量的指标受到响应时间、服务器软硬件配置、⽹络状态等多⽅⾯因素影响。吞吐量越⼤，响应时间越长。服务器硬件配置越⾼，吞吐量越⼤。⽹络越差，吞吐量越⼩。在低吞吐量下的响应时间的均值、分布⽐较稳定，不会产⽣太⼤的波动。在⾼吞吐量下，响应时间会随着吞吐量的增长⽽增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。系统吞度量要素 ⼀个系统的吞度量（承压能⼒）与request对CPU的消耗、外部接⼝、IO等等紧密关联。单个reqeust 对CPU消耗越⾼，外部系统接⼝、IO影响速度越慢，系统吞吐能⼒越低，反之越⾼。系统吞吐量⼏个重要参数：QPS（TPS）、并发数、响应时间QPS(每秒请求数)（TPS （Transaction Per Second）每秒事务数）：每秒钟系统处理的request/事务 数量，它是衡量系统处理能⼒的重要指标；并发数：系统同时处理的request/事务数响应时间：⼀般取平均响应时间理解了上⾯三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间 ⼀个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有⼀个相对极限值，在应⽤场景访问压⼒下，只要某⼀项达到系统最⾼值，系统的吞吐量就上不去了，如果压⼒继续增⼤，系统的吞吐量反⽽会下降，原因是系统超负荷⼯作，上下⽂切换、内存等等其它消耗导致系统性能下降。系统吞吐量评估我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。⽽通常境况下，我们⾯对需求，我们评估出来的QPS、并发数之外，还有另外⼀个维度：⽇页⾯流量PV。PV：访问⼀个URL，产⽣⼀个PV（Page View，页⾯访问量），每⽇每个⽹站的总PV量是形容⼀个 ⽹站规模的重要指标。通过观察系统的访问⽇志发现，在⽤户量很⼤的情况下，各个时间周期内的同⼀时间段的访问流量⼏乎⼀样。只要能拿到⽇流量图和QPS我们就可以推算⽇流量。通常的技术⽅法：1. 找出系统的最⾼TPS和⽇PV，这两个要素有相对⽐较稳定的关系（除了放假、季节性因素影响之外）2. 通过压⼒测试或者经验预估，得出最⾼TPS，然后跟进1的关系，计算出系统最⾼的⽇吞吐量。⽆论有⽆思考时间（T_think），测试所得的TPS值和并发虚拟⽤户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运⾏情况下）：TPS=U_concurrent / (T_response+T_think)。并发数、QPS、平均响应时间三者之间关系
X轴代表并发⽤户数，Y轴代表资源利⽤率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压⼒区、重压⼒区、拐点区。随着并发⽤户数的增加，在轻压⼒区的响应时间变化不⼤，⽐较平缓，进⼊重压⼒区后呈现增长的趋势，最后进⼊拐点区后倾斜率增⼤，响应时间急剧增加。接着看吞吐量，随着并发⽤户数的增加，吞吐量增加，进⼊重压⼒区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。同理，随着并发⽤户数的增加，资源利⽤率逐步上升，最后达到饱和状态。最后，把所有指标融合到⼀起来分析，随着并发⽤户数的增加，吞吐量与资源利⽤率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于⽐较好的状态。但随着并发⽤户数的持续增加，压⼒也在持续加⼤，吞吐量与资源利⽤率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压⼒区与重压⼒区的交界点是系统的最佳并发⽤户数，因为各种资源都利⽤充分，响应也很快；⽽重压⼒区与拐点区的交界点就是系统的最⼤并发 ⽤户数，因为超过这个点，系统性能将会急剧下降甚⾄崩溃。Light Load（较轻压⼒）-----最佳⽤户数（资源利⽤最⾼）---（较重压⼒，系统可以持续⼯作，但⽤户等待时间较长，满意度会下降）-----Heavy Load-------最⼤并发⽤户数--------Buckle Zone（⽤户⽆法忍受⽽放弃请求）最佳并发⽤户数：当系统的负载等于最佳并发⽤户数时，系统的整体效率最⾼，没有资源被浪费，⽤户也不需要等待 最⼤并发⽤户数：系统的负载⼀直持续，有些⽤户在处理⽽有的⽤户在⾃⼰最⼤的等待时间内等待的时候我们需要保证的是：（1）最佳并发⽤户数需⼤于系统的平均负载（2）系统的最⼤并发⽤户数要⼤于系统需要承受的峰值负载怎么理解这两句话呢？（1）系统的平均负载：在特定的时间内，系统正在处理的⽤户数和等待处理的⽤户数的总和如果系统的平均负载⼤于最佳并发⽤户数，则⽤户的满意度会下降，所以我们需要保证系统的平均负载⼩于或者等于最佳并发⽤户数（2）峰值：指的是系统的最⼤能承受的⽤户数的极值只有最⼤并发⽤户数⼤于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下计算公式指单位时间内系统处理⽤户的请求数从业务⾓度看，吞吐量可以⽤：请求数/秒、页⾯数/秒、⼈数/天或处理业务数/⼩时等单位来衡量从⽹络⾓度看，吞吐量可以⽤：字节/秒来衡量对于交互式应⽤来说，吞吐量指标反映的是服务器承受的压⼒，他能够说明系统的负载能⼒以不同⽅式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒⽅式可以表⽰数要受⽹络基础设施、服务器架构、应⽤服务器制约等⽅⾯的瓶颈；已请求数/秒的⽅式表⽰主要是受应⽤服务器和应⽤代码的制约体现出的瓶颈。当没有遇到性能瓶颈的时候，吞吐量与虚拟⽤户数之间存在⼀定的联系，可以采⽤以下公式计算：F=VU * R /T其中F为吞吐量，VU表⽰虚拟⽤户个数，R表⽰每个虚拟⽤户发出的请求数，T表⽰性能测试所⽤的时间
吞吐量与负载对应关系图中拐点说明：（1）吞吐量逐渐达到饱和（2）意味着系统的⼀种或多种资源利⽤达到的极限（3）通常可以利⽤拐点来进⾏性能测试分析与定位错误率超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的⽐率。错误率和服务的具体实现有关。通常情况下，由于⽹络超时等外部原因造成的错误⽐例不应超过5%%，由于服务本⾝导致的错误率不应超过1% 。内部指标|资源指标（与硬件资源消耗相关指标） 资源利⽤率：资源利⽤率指的是对不同系统资源的使⽤程度，⼀般使⽤“资源实际使⽤/总的资源可⽤量”形成资源利⽤率。例如服务器的CPU 利⽤率、磁盘利⽤率等。资源利⽤率是分析系统性能指标进⽽改善性能的主要依据，因此，它是 Web 性能测试⼯作的重点。资源利⽤率主要针对 Web 服务器、操作系统、数据库服务器、⽹络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利⽤率参数来进⾏分析。从服务器的⾓度看，性能测试主要关注CPU、内存、服务器负载、⽹络、磁盘IO等1.硬件性能指标：CPU，内存Memory，磁盘I/O（Disk I/O），⽹络I/O（Network I/O）CPU：主要解释计算机指令以及处理计算机软件中的数据Linux系统中top命令查看CPU的使⽤率CPU的利⽤率（<=75%）有：user（⽤户使⽤）,sys（系统调⽤<=30%）,wait（等待<=5%），idle（空闲）当user消耗⾼时，通过top命令查看哪个⽤户进程占⽤cpu的使⽤user消耗过⾼的原因可能有:（1）代码问题。如代码中耗时循环中不加sleep，即例如while的死循环中，没有加sleep时间，导致没有空余的时间将cpu的控制权给其他的进程，⼀直陷⼊该死循环中，cpu得不到休息，所以usr的消耗过⾼，则cpu的消耗⾼（2）gc频繁。gc则为垃圾回收，由于垃圾回收也是需要⼤量的计算，也消耗cpu，所以当gc频繁时也导致usr⽤户空间的消耗也过⾼，cpu消耗过⾼当sys消耗⾼时，通过top命令查看系统调⽤资源的情况sys消耗过⾼的原因可能有：（1）上下⽂切换频繁。上下⽂切换发⽣的情况有：中断处理，多任务处理，⽤户状态改变。中断处理，当cpu停⽌处理当前的进程转⽽处理中断请求的进程时发⽣上下⽂切换。多任务处理则为有多个进程请求cpu的处理，进程的数量多于cpu的核数，则分配进程时间⽚，根据时间⽚处理进程，意味着会强制停⽌⼀个进程⽽去处理另⼀个进程，形成频繁的上下⽂切换。⽤户状态改变则为user状态与sys状态的改变。wait较⾼时，即等待的进程占⽐⾼则可以考虑是否磁盘读写，磁盘瓶颈问题， 等待的进程较多时，cpu⽆论如何切换都是切换到等待的进程，导致cpu⼀直在频繁切换等待的线程⽽利⽤率较低内存：与cpu沟通的桥梁，计算机中所有程序的运⾏都在内存中进⾏，内存分为物理内存、页⾯交换（Paging），SWAP内存（虚拟内存）页⾯交换：当物理内存即实际的内存满了的时候，将物理内存中不常⽤的进程调出存储到虚拟内存中，以缓解物理内存空间的压⼒，所以当物理内存与虚拟内存的数据交换频繁的时候，这时候就要关注下内存的性能情况。SWAP内存：为进程分配虚拟的内存空间，即调⽤硬盘的空间作为内存使⽤。内存的性能分析是⼜可⽤内存与页⾯交换来分析的，可⽤内存使⽤占70%-80%为上限，当超出这个数值，内存性能情况就⽐较危险，⽽且即使可⽤内存使⽤不超过80%的数值时，页⾯交换⽐较频繁时，也是要关注下内存情⼀般物理内存即使是满内存也不能代表内存出现问题，主要是看虚拟内存swap，虚拟内存应该<=70%，⼤于则可以考虑是否内存问题或者内存泄漏磁盘吞吐量，指单位时间内通过磁盘的数据量。主要关注磁盘的繁忙率，如果⾼于70%，则磁盘瓶颈⽹络吞吐量，指单位时间内通过⽹络的数据量，当吞吐量⼤于⽹路设备或链路最⼤传输能⼒，即带宽时，则应该考虑升级⽹络设备或者增加带宽，Linux命令netstate⽹络IO也有可能出现终⽌连接失败。例如当服务端出现⼤量的TIME_WAIT，见以下TCP终⽌连接的第4个步骤，在主动发起关闭连接⽅接收到结束符FIN时状态变为TIME_WAIT,这时在服务端发现⼤量的TIME_WAIT,意味着关闭连接是由服务端发起的。常⽤的三个状态是：ESTABLISHED 表⽰正在通信，TIME_WAIT 表⽰主动关闭，CLOSE_WAIT 表⽰被动关闭。问？什么情况是由服务端发起关闭连接？答：在⽤户端的应⽤程序忘记关闭连接另外如果在服务端发现⼤量状态CLOSE_WAIT,则说明第⼆次关闭回不去，也就是TCP关闭连接的第三个步骤没有执⾏，停留在CLOSE_WAIT的状态，浏览器如果这时发起请求则会返回超时连接，因为服务端这边⼀直⽆法进⾏第⼆次关闭，将结束符返回去给⽤户端。注：普及TCP连接的三次握⼿，终⽌连接的四次握⼿TCP三次握⼿连接：(1)⽤户端发送SYN给服务器，⽤户端的状态为SYN_SEND(2)服务端接收到后发送ACK给⽤户端，服务端的状态为SYN_RECV(3)⽤户端接收到服务端发送过来的后发送了ACK给服务端，⽤户端的状态变为EstabilishedTCP终⽌连接：(1)⽤户端的应⽤主动发起关闭连接，即应⽤调⽤close发送FIN给服务端(2)服务端接收到FIN后发送ACK给⽤户端，服务端的状态变为CLOSE_WAIT(3)服务端发送ACK给⽤户端的同时也将FIN作为⼀个⽂件结束符传递给接收端应⽤程序(4)⽤户端的应⽤程序接收到FIN后将调⽤close关闭它的套接字，确认FIN，这时⽤户端的状态变为TIME_WAIT(5)⽤户端发送ACK回执给服务端，连接终⽌2.中间件：常⽤的中间件例如web服务器Tomcat,Weblogic web服务器，JVM（java虚拟机），ThreadPool线程池，JDBC数据驱动注：http服务器和web服务器与应⽤服务器的差别是⼀个存储静态⽹页的服务器，⼀个是存储css，js等动态加载⽹页的服务器，⽽tomcat则属于应⽤服务器注：对中间件例如对服务器的性能测试，需要将监控的jmeter-server的⽂件下载在服务端上，然后开启即可监控被测服务器的性能，或者将监控的软件下载在被测服务器上，远程启动监控软件等3.数据库指标应关注SQL，吞吐量，缓存命中率，连接数等，则是关注sql语句执⾏时间，以微妙为单位，吞吐量TPS，缓存命中率应>=95%注：对数据库的性能测试通过jemter利⽤批量的sql语句对数据库进⾏操作，从⽽测试数据库的性能，前提是需要将jdbc的驱动加载在测试计划添加的驱动⽂件中，然后添加jdbc的前置处理器和jdbc的请求sample。，java虚拟机，为使java的代码可以编译运⾏在不同的平台上顺畅，仿真模拟各种计算机来实现GC：⾃动内存管理程序，被引⽤的对象保存在内存中，当对象不被引⽤时则释放。关注的参数有Full GC完全java虚拟机垃圾部分回收频率5.前端指标前端应该关注页⾯展⽰，即⾸次显⽰时间，页⾯数量，页⾯⼤⼩，⽹络startRender，firstRender等注：关注前端的性能与后端的性能的不同点在于，前端是每个⽤户的直观的感受，以及前端页⾯的加载元素耗费时间给予⽤户的感受，⽽后端的性能关注点在于多⽤户使⽤系统时，服务器是否能够承受或者服务器的处理能⼒如何，能否以较好的响应时间响应。：系统平均负载，特定时间间隔内运⾏进程数，Load与cpu核数⼀致CPUCPU使⽤率：指⽤户进程与系统进程消耗的CPU时间百分⽐，长时间情况下，⼀般可接受上限不超过85%。后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利⽤率对服务的性能起着决定性的作⽤。Linux系统的CPU主要有如下⼏个维度的统计数据：us：⽤户态使⽤的cpu时间百分⽐sy：系统态使⽤的cpu时间百分⽐ni：⽤做nice加权的进程分配的⽤户态cpu时间百分⽐id：空闲的cpu时间百分⽐wa：cpu等待IO完成时间百分⽐hi：硬中断消耗时间百分⽐si：软中断消耗时间百分⽐下图是线上开放平台转发服务某台服务器上top命令的输出，下⾯以这个服务为例对CPU各项指标进⾏说明
us & sy：⼤部分后台服务使⽤的CPU时间⽚中us和sy的占⽤⽐例是最⾼的。同时这两个指标⼜是互相影响的，us的⽐例⾼了，sy的⽐例就低，反之亦然。通常sy⽐例过⾼意味着被测服务在⽤户态和系统态之间切换⽐较频繁，此时系统整体性能会有⼀定下降。另外，在使⽤多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使⽤率过⾼会导致其他CPU核⼼之间的调度效率变低。因此测试过程中CPU0需要重点关注。ni：每个Linux进程都有个优先级，优先级⾼的进程有优先执⾏的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。这个修正值就叫做进程的nice值。⼀般来说，被测服务和服务器整体的ni值不会很⾼。如果测试过程中ni的值⽐较⾼，需要从服务器Linux系统配置、被测服务运⾏参数查找原因id：线上服务运⾏过程中，需要保留⼀定的id冗余来应对突发的流量激增。在性能测试过程中，如果id⼀直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。wa：磁盘、⽹络等IO操作会导致CPU的wa指标提⾼。通常情况下，⽹络IO占⽤的wa资源不会很⾼，⽽频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务，那需要检查被测服务的⽇志量、数据载⼊频率等。hi & si：硬中断是外设对CPU的中断，即外围硬件发给CPU或者内存的异步信号就是硬中断信号；软中断由软件本⾝发给操作系统内核的中断信号。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断，也就是我们常说的系统调⽤(System Call)。在性能测试过程中，hi会有⼀定的CPU占⽤率，但不会太⾼。对于IO密集型的服务，si的CPU占⽤率会⾼⼀些。内存内存利⽤率：内存利⽤率=（1-空闲内存/总内存⼤⼩）*100%，⼀般⾄少有10%可⽤内存，内存使⽤率可接受上限为85%。性能测试过程中对内存监控的主要⽬的是检查被测服务所占⽤内存的波动情况。在Linux系统中有多个命令可以获取指定进程的内存使⽤情况，最常⽤的是top命令，如下图所⽰
其中VIRT：进程所使⽤的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页⾯，所有已申请的总内存空间RES：进程正在使⽤的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值SHR：进程使⽤共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使⽤SWAP：进程使⽤的虚拟内存中被换出的⼤⼩，交换的是已经申请，但没有使⽤的空间，包括（栈、堆、共享内存）DATA：进程除可执⾏代码以外的物理内存总量，即进程栈、堆申请的总空间从上⾯的解释可以看出，测试过程中主要监控RES和VIRT，对于使⽤了共享内存的多进程架构服务，还需要监控SHR。LOAD（服务器负载）Linux的系统负载指运⾏队列的平均长度，也就是等待CPU的平均进程数从服务器负载的定义可以看出，服务器运⾏最理想的状态是所有CPU核⼼的运⾏队列都为1，即所有活动进程都在运⾏，没有等待。这种状态下服务器运⾏在负载阈值下。通常情况下，按照经验值，服务器的负载应位于阈值的70%~80%，这样既能利⽤服务器⼤部分性能，⼜留有⼀定的性能冗余应对流量增长。Linux提供了很多查看系统负载的命令，最常⽤的是top和uptimetop和uptime针对负载的输出内容相同，都是系统最近1分钟、5分钟、15分钟的负载均值
Uptime命令结果的每⼀列的含义如下：“当前时间 系统运⾏时长 登录的⽤户数最 近1分钟、5分钟、15分钟的平均负载”查看系统负载阈值的命令如下，下⽅是查看CPU每个核⼼的使⽤情况：
在性能测试过程中，系统负载是评价整个系统运⾏状况最重要的指标之⼀。通常情况下，压⼒测试时系统负载应接近但不能超过阈值，并发测试时的系统负载最⾼不能超过阈值的80%，稳定性测试时，系统负载应在阈值的50%左右。⽹络⽹络带宽：⼀般使⽤计数器Bytes Total/sec来度量，Bytes Total/sec表⽰为发送和接收字节的速率，包括帧字符在内。判断⽹络连接速度是否是瓶颈，可以⽤该计数器的值和⽬前⽹络的带宽⽐较。性能测试中⽹络监控主要包括⽹络流量、⽹络连接状态的监控。⽹络流量监控可以使⽤nethogs命令。该命令与top类似，是⼀个实时交互的命令，运⾏界⾯如下
在后台服务性能测试中，对于返回⽂本结果的服务，并不需要太多关注在流量⽅⾯。⽹络连接状态监控性能测试中对⽹络的监控主要是监控⽹络连接状态的变化和异常。对于使⽤TCP协议的服务，需要监控服务已建⽴连接的变化情况（即ESTABLISHED状态的TCP连接）。对于HTTP协议的服务，需要监控被测服务对应进程的⽹络缓冲区的状态、TIME_WAIT状态的连接数等。Linux⾃带的很多命令如netstat、ss都⽀持如上功能。下图是netstat对指定pid进程的监控结果磁盘IO 磁盘主要⽤于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是读IO操作，⼀般使⽤% Disk Time（磁盘⽤于读写操作所占⽤的时间百分⽐）度量磁盘读写性能。性能测试过程中，如果被测服务对磁盘读写过于频繁，会导致⼤量请求处于IO等待的状态，系统负载升⾼，响应时间变长，吞吐量下降。Linux下可以⽤iostat命令来监控磁盘状态，如下图
tps：该设备每秒的传输次数。“⼀次传输”意思是“⼀次I/O请求”。多个逻辑请求可能会被合并为“⼀次I/O请求”。“⼀次传输”请求的⼤⼩是未知的kB_read/s：每秒从设备（driveexpressed）读取的数据量，单位为KilobyteskB_wrtn/s：每秒向设备（driveexpressed）写⼊的数据量，单位为KilobyteskB_read：读取的总数据量，单位为KilobyteskB_wrtn：写⼊的总数量数据量，单位为Kilobytes从iostat的输出中，能够获得系统运⾏最基本的统计数据。但对于性能测试来说，这些数据不能提供更多的信息。需要加上-x参数
rrqm/s：每秒这个设备相关的读取请求有多少被合并了（当系统调⽤需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）wrqm/s：每秒这个设备相关的写⼊请求有多少被Merge了await：每⼀个IO请求的处理的平均时间（单位是毫秒）%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，⽽0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，该参数暗⽰了设备的繁忙程度。资源利⽤与负载对应关系图中拐点说明：（1）服务器某⼀资源使⽤逐渐达到饱和（2）通常可以利⽤拐点来进⾏性能测试分析与定位性能计数器（counters）是描述服务器或操作系统性能的⼀些数据指标，如使⽤内存数、进程时间，在性能测试中发挥着“监控和分析”的作⽤，尤其是在分析系统可扩展性、进⾏新能瓶颈定位时有着⾮常关键的作⽤。常见性能瓶颈吞吐量到上限时系统负载未到阈值：⼀般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因CPU的us和sy不⾼，但wa很⾼：如果被测服务是磁盘IO密集型型服务，wa⾼属于正常现象。但如果不是此类服务，最可能导致wa⾼的原因有两个，⼀是服务对磁盘读写的业务逻辑有问题，读写频率过⾼，写⼊数据量过⼤，如不合理的数据载⼊策略、log过多等，都有可能导致这种问题。⼆是服务器内存不⾜，服务在swap分区不停的换⼊换出。同⼀请求的响应时间忽⼤忽⼩：在正常吞吐量下发⽣此问题，可能的原因有两⽅⾯，⼀是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了⼤量的时间等待资源解锁；⼆是Linux本⾝分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执⾏。内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使⽤valgrind等内存检查⼯具进⾏定位。性能瓶颈定位之拐点分析法 “拐点分析”⽅法是⼀种利⽤性能计数器曲线图上的拐点进⾏性能分析的⽅法。它的基本思想就是性能产⽣瓶颈的主要原因就是因为某个资源的使⽤达到了极限，此时表现为随着压⼒的增⼤，系统性能却出现急剧下降，这样就产⽣了“拐点”现象。当得到“拐点”附近的资源使⽤情况时，就能定位出系统的性能瓶颈。软件性能的其它术语思考时间的计算公式Think Time，从业务⾓度来看，这个时间指⽤户进⾏操作时每个请求之间的时间间隔，⽽在做新能测试时，为了模拟这样的时间间隔，引⼊了思考时间这个概念，来更加真实的模拟⽤户的操作。在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个⽤户发出的请求数R和时间T的函数，⽽其中的R⼜可以⽤时间T和⽤户思考时间TS来计算：R = T / TS下⾯给出⼀个计算思考时间的⼀般步骤：1、⾸先计算出系统的并发⽤户数C=nL / T F=R×C2、统计出系统平均的吞吐量F=VU * R / T R×C = VU * R / T3、统计出平均每个⽤户发出的请求数量R=u*C*T/VU4、根据公式计算出思考时间TS=T/R软件性能的影响因素（1）硬件设施（部署结构、机器配置）（2）⽹络环境（客户端带宽、服务器端带宽）（3）操作系统（类型、版本、参数配置）（4）中间件（类型、版本、参数配置）（5）应⽤程序（性能）（6）并发⽤户数（系统当前访问状态）（7）客户端（8）数据服务器（9）编程语⾔、程序实现⽅式、算法软件性能的关注点
⾸先，开发软件的⽬的是为了让⽤户使⽤，我们先站在⽤户的⾓度分析⼀下，⽤户需要关注哪些性能。对于⽤户来说，当点击⼀个按钮、链接或发出⼀条指令开始，到系统把结果已⽤户感知的形式展现出来为⽌，这个过程所消耗的时间是⽤户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较⼩时，⽤户体验是很好的，当然⽤户体验的响应时间包括个⼈主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到⽤户最佳的体验。如：⽤户在⼤数据量查询时，我们可以将先提取出来的数据展⽰给⽤户，在⽤户看的过程中继续进⾏数据检索，这时⽤户并不知道我们后台在做什么。⽤户关注的是⽤户操作的响应时间。
其次，我们站在管理员的⾓度考虑需要关注的性能点。1、 响应时间2、 服务器资源使⽤情况是否合理3、 应⽤服务器和数据库资源使⽤是否合理4、 系统能否实现扩展5、 系统最多⽀持多少⽤户访问、系统最⼤业务处理量是多少6、 系统性能可能存在的瓶颈在哪⾥7、 更换那些设备可以提⾼性能8、 系统能否⽀持7×24⼩时的业务访问再次，站在开发（设计）⼈员⾓度去考虑。1、 架构设计是否合理2、 数据库设计是否合理3、 代码是否存在性能⽅⾯的问题4、 系统中是否有不合理的内存使⽤⽅式5、 系统中是否存在不合理的线程同步⽅式6、 系统中是否存在不合理的资源竞争那么站在性能测试⼯程师的⾓度，我们要关注什么呢？ ⼀句话，我们要关注以上所有的性能点。
性能测试的核⼼原理性能测试的核⼼原理，开发测试⼯具也是基于前两点：1、基于协议（前端后端通信机制），基于界⾯（决定和前端交互），基于代码（后端）。基于⽹络的分布式架构：基于⽹络协议去模拟⽤户发送请求；2、多线程：模拟多线程操作，多⼈同时操作，模拟⼤负载量（功能测试在于⽤以测试功能）；3、模拟真实场景：真实的⽹络环境，⽤户操作时间不确定性，操作不确定，得出的数据是准确的，场景不对，数据也不⼀定可⽤。性能问题分析原则
性能测试原则1）情况许可时，应使⽤⼏种测试⼯具或⼿段分别独⽴进⾏测试，并将结果相互印证，避免单⼀⼯具或测试⼿段⾃⾝缺陷影响结果的准确性；2）对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；3）查找瓶颈的过程应由易到难逐步排查： 服务器硬件瓶颈及⽹络瓶颈（局域⽹环境下可以不考虑⽹络因素） 应⽤服务器及中间件操作系统瓶颈（数据库、WEB服务器等参数配置） 应⽤业务瓶颈（SQL语句、数据库设计、业务逻辑、算法、数据等）4）性能调优过程中不宜对系统的各种参数进⾏随意的改动，应该以⽤户配置⼿册中相关参数设置为基础，逐步根据实际现场环境进⾏优化，⼀次只对某个领域进⾏性能调优（例如对CPU的使⽤情况进⾏分析），并且每次只改动⼀个设置，避免相关因素互相⼲扰；5）调优过程中应仔细进⾏记录，保留每⼀步的操作内容及结果，以便⽐较分析；6）性能调优是⼀个经验性的⼯作，需要多思考、分析、交流和积累；7）了解“有限的资源，⽆限的需求”；8）尽可能在开始前明确调优⼯作的终⽌标准。性能测试的注意要点
性能调优应该注意的要点
性能测试流程
⼀般企业会按照这个步骤去执⾏测试：先负载测试（逐步增加并发⽤户数来增加压⼒，只能找出性能指标的瓶颈范围，⽽不是具体的性能指标值），再性能测试（验证我们的性能指标的具体的值，即精确），最后压⼒测试。平时我们说的基准测试其实是在性能测试⾥的找出。压⼒测试：在⼀定的压⼒下，运⾏⽐较长的时间。⽬的是看服务器的稳定性。企业⼝语说的“压测”表达的是：要做负载测试和性能测试。
注：绝对不允许⽤⽣产环境，公司如果有准⽣产环境最好。从⽣产的集群⾥抽取⼀个单机拿出来专门做性能测试的独⽴服务器。但是其数据库数据和服务都彻底从集群中移出来，这样不影响⽣产环境正常业务发展。独⽴⽹络：就是必须使⽤⽹线有线连接，千万不要使⽤wifi，VPN，堡垒机（把两个⽹络连接起来的桥梁），最好是测试负载机和控制机在同⼀个⽹络⽽且都是独⽴的局域⽹⾥直接路由跳出去访问外⽹的服务器。否则⽹速会严重影响数据的传输和加载，会出现数据包丢失严重的现象。最主要的是严重影响响应时间的指标值，偏差太⼤，没有参考价值。TPS:服务器综合能⼒指标值，服务器最主要的指标值。吞吐量有个单位是：平均事务数/秒loadrunner和jmeter的TPS是有区别的，jmeter有两种每秒事务数。jmeter除了每个业务的请求到响应完成的统计外，还有事务逻辑控制器对多个单个业务请求打包成⼀个全链路业务流的业务的请求到响应完成的统计等。性能测试不是去找功能上的bug，是找出服务器的瓶颈。采⽤⾃动化负载测试⼯具执⾏的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执⾏跟踪，结果分析与定位问题所在，测试报告与测试评估。
⼀、性能测试需求分析 性能需求分析是整个性能测试⼯作开展的基础，如果连性能的需求都没弄清楚，后⾯的性能测试执⾏其实是没有任何意义的，⽽且性能需求分析做的好不好直接影响到性能测试的结果。 ⼀些性能测试⼈员常犯的错误就是测试⼀开始就直接⽤⼯具对系统进⾏加压，没有弄清楚性能测试的⽬的，稀⾥糊涂做完了以后也不知道结果是否满⾜性能需求。市⾯上的书籍也⼤都是直接讲性能测试⼯具如LR，jmeter如何使⽤，导致很多新⼿⼀提到性能测试就直接拿⼯具来进⾏录制回放，使得很多⼈认为会使⽤性能测试⼯具就等于会性能测试了，殊不知⼯具其实只是性能测试过程中很⼩的⼀部分。 在需求分析阶段，测试⼈员需要与项⽬相关的⼈员进⾏沟通，收集各种项⽬资料，对系统进⾏分析，建⽴性能测试数据模型，并将其转化为可衡量的具体性能指标，确认测试的⽬标。所以性能测试需求分析过程是繁杂的，需要测试⼈员有深厚的性能理论知识，除此之外还需要懂⼀些数学建模的知识来帮助我们建⽴性能测试模型。⾸先，让我们来看看通过性能需求分析我们需要得出哪些结论或⽬标：明确倒底要不要做性能测试？性能测试的⽬的是什么？明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等明确被测系统的基本业务、关键业务，⽤户⾏为明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，⼜是为什么？明确被测系统未来的业务拓展规划以及性能需求？明确性能测试策略，即应该怎么测试？明确性能测试的指标，知道测试出来的结果怎么算通过？其次，需求分析阶段我们可以从以下⼏个⽅⾯⼊⼿：1、系统信息调研： 指对被测试系统进⾏分析，需要对其有全⾯的了解和认识，这是我们做好性能测试的前提，⽽且在后续进⾏性能分析和调优时将会⼤有⽤处，试想如果连系统的架构、协议都不了解，我们如何进⾏准确的性能测试？如果进⾏性能分析与调优？ 需要分析的系统信息如下（包括但不仅限于如下这些）：
2、业务信息调研： 指对被测试的业务进⾏分析，通过对业务的分析和了解，⽅便我们后续进⾏性能测试场景的确定以及性能测试指标的确定。 需要分析的业务信息如下（包括但不仅限于如下这些）：
3、性能需求评估： 在实施性能测试之前，我们需要对被测系统做相应的评估，主要⽬的是明确是否需要做性能测试。如果确定需要做性能测试，需要进⼀步确⽴性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满⾜将来⼀定时间段的业务压⼒。 判断是否进⾏性能测试主要从下⾯两个⽅⾯进⾏思考：业务⾓度: 系统是公司内部 or 对外？系统使⽤的⼈数的多少？如果⼀个系统上线后基本没⼏个⼈使⽤，⽆论系统多⼤，设计多么复杂，并发性的性能测试都是没必要的，前期可以否决。当然，除⾮在功能测试阶段发现⾮常明显的性能问题，使得⽤户体验较差的，此时可进⾏性能测试来排查问题。系统⾓度：系统⼜可以从以下3个⽅⾯进⾏分析 a）系统架构： 如果⼀个系统采⽤的框架是⽼的系统框架（通常⼤公司都有⾃⼰的统⼀框架），只是在此框架上增加⼀些应⽤，其实是没有必要做性能测试，因为⽼框架的使⽤肯定是经过了验证的。如果⼀个系统采⽤的是⼀种新的框架，可以考虑做性能测试。 b）数据库要求： 很多情况下，性能测试是⼤数据量的并发访问、修改数据库，⽽瓶颈在于连接数据库池的数量，⽽⾮数据库本⾝的负载、吞吐能⼒。这时，可以结合DBA的建议，来决定是否来做性能测试。 c）系统特殊要求： 从实时性⾓度来分析，某些系统对响应时间要求⽐较，⽐如证券系统，系统的快慢直接影响客户的收益，这种情况就有作并发测试的必要，在⼤并发量的场景下，查看这个功能的响应时间。 从⼤数据量上传下载⾓度分析，某些系统经常需要进⾏较⼤数据量的上传和下载操作，虽然此种操作使⽤的⼈数不会太多，但是也有必要进⾏性能测试，确定系统能处理的最⼤容量，如果超过这个容量时系统需要进⾏相关控制，避免由于不⼈⼯误操作导致系统内存溢出或崩溃。4、确定性能测试点：
在上⾯第3点中，我们简单分析了如何确定⼀个系统是否需要做性能测试。下⾯简单总结下如果⼀个系统确定要做性能测试，我们如何确定被测系统的性能测试点？ 我们可以从下⾯⼏个⽅⾯进⾏分析：关键业务： 确定被测项⽬是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接⼝。如果项⽬（或功能点）不属于关键业务（或关键业务点），则可转⼊下⾯。⽇请求量： 确定被测项⽬各功能点的⽇请求量（可以统计不同时间粒度下的请求量如：⼩时，⽇，周，⽉）。如果⽇请求量很⾼，系统压⼒很⼤，⽽且⼜是关键业务，该项⽬需要做性能测试，⽽且关键业务点，可以被确定为性能点。逻辑复杂度： 判定被测项⽬各功能点的逻辑复杂度。如果⼀个主要业务的⽇请求量不⾼，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式⽅式的调⽤中，当某⼀个环节响应较慢，就会影响到其它环节，造成雪崩效应。运营推⼴活动： 根据运营的推⼴计划来判定待测系统未来的压⼒。未⾬绸缪、防患于未然、降低运营风险是性能测试的主要⽬标。被测系统的性能不仅能满⾜当前压⼒，更需要满⾜未来⼀定时间段内的压⼒。因此，事先了解运营推⼴计划，对性能点的制定有很⼤的作⽤。例如，运营计划做活动，要求系统每天能⽀撑多少 PV、多少 UV，或者⼀个季度后，需要能⽀撑多⼤的访问量等等数据。当新项⽬（或功能点）属于运营重点推⼴计划范畴之内，则该项⽬（或功能点）也需要做性能测试。以上 4 点，是相辅相成、环环相扣的。在实际⼯作中应该具体问题具体分析。例如，当⼀个功能点不满⾜以上 4 点，但⼜属于资源⾼消耗（内存、CPU），也可列⼊性能测试点⾏列。注：PV：访问⼀个URL，产⽣⼀个PV（Page View，页⾯访问量），每⽇每个⽹站的总PV量是形容⼀个 ⽹站规模的重要指标。UV：作为⼀个独⽴的⽤户，访问站点的所有页⾯均算作⼀个UV（Unique Visitor，⽤户访问）5、确定性能指标：
性能需求分析⼀个很重要的⽬标就是需要确定后期性能分析⽤的性能指标，性能指标有很多，可以根据具体项⽬选取和设定，⽽具体的指标值则需要根据业务特点进⾏设定，本⽂不详细进⾏阐述，后续可考虑就此单独写⼀篇。⼆、性能测试准备1、测试环境准备：（见：四：测试脚本设计与开发） a）系统运⾏环境：这个通常就是我们的测试环境，有些时候需求⽐较多，做性能测试担⼼把环境搞跨了影响其它的功能测试，可能需要重新搭建⼀套专门⽤来做性能测试的环境。 b）执⾏机环境：这个就是⽤来⽣成负载的执⾏机，通常需要在物理机上运⾏，⽽物理机⼜是稀缺资源，所以我们每次做性能测试都需要提前准备好执⾏机环境。2、测试场景设计：（见：四：测试脚本设计与开发）根据性能需求分析来设计符合⽤户使⽤习惯的场景，场景设计的好不好直接影响到性能测试的效果。3、性能⼯具准备： a）负载⼯具：根据需求分析和系统特点选择合适的负载⼯具，⽐如LR、Jmeter或galting等 b）监控⼯具：准备性能测试时的服务器资源、JVM、数据库监控⼯具，以便进⾏后续的性能测试分析与调优。4、测试脚本准备：如果性能测试⼯具不能满⾜被测系统的要求或只能满⾜部分要求时，需要我们⾃⼰开发脚本配合⼯具进⾏性能测试。5、测试数据准备： a）负载测试数据：并发测试时需要多少数据？⽐如登录场景？ b）DB数据量⼤⼩：为了尽量符合⽣产场景，需要模拟线上⼤量数据情况，那么要往数据库⾥提前插⼊⼀定的数据量。这可能需要花费⼀些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。6、性能测试团队组建：如果需要其它关联系统或专业⼈⼠如DBA配合的，也需要提前进⾏沟通。三、性能测试计划测试计划阶段最重要的是分析⽤户场景，确定系统性能⽬标。1、性能测试领域分析根据对项⽬背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满⾜实际运⾏时的需要，还是⽬前的系统在哪些⽅⾯制约系统性能的表现，或者，哪些系统因素导致系统⽆法跟上业务发展？确定测试领域，然后具体问题具体分析。2、⽤户场景剖析和业务建模根据对系统业务、⽤户活跃时间、访问频率、场景交互等各⽅⾯的分析，整理⼀个业务场景表，当然其中最好对⽤户操作场景、步骤进⾏详细的描述，为测试脚本开发提供依据。3、确定性能⽬标前⾯已经确定了本次性能测试的应⽤领域，接下来就是针对具体的领域关注点，确定性能⽬标（指标）；其中需要和其他业务部门进⾏沟通协商，以及结合当前系统的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使⽤率等⽬标；⽐如：①登录请求到登录成功的页⾯响应时间不能超过2秒；②报表审核提交的页⾯响应时间不能超过5秒；③⽂件的上传、下载页⾯响应时间不超过8秒；④服务器的CPU平均使⽤率⼩于70%，内存使⽤率⼩于75%；⑤ 各个业务系统的响应时间和服务器资源使⽤情况在不同测试环境下，各指标随负载变化的情况等；web性能测试之响应时间4、制定测试计划的实施时间预设本次性能测试各⼦模块的起⽌时间，产出，参与⼈员等等。（1）明确测试范围（2）制订时间（进度）计划（3）制订成本计划（4）制订环境计划（5）测试⼯具规划（6）测试风险分析四、测试脚本设计与开发性能测试中，测试脚本设计与开发占据了很⼤的时间⽐测试重。1、测试环境设计本次性能测试的⽬标是需要验证系统在实际运⾏环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，在不同的硬件配置上检查应⽤系统的性能，并对不同配置下系统的测试结果进⾏分析，得出最优结果（最适合当前系统的配置）。这⾥所说的配置⼤概是如下⼏类：①数据库服务器②应⽤服务器③负载模拟器④软件运⾏环境，平台测试环境测试数据，可以根据系统的运⾏预期来确定，⽐如需要测试的业务场景，数据多久执⾏⼀次备份转移，该业务场景涉及哪些表，每次操作数据怎样写⼊，写⼊⼏条，需要多少的测试数据来使得测试环境的数据保持⼀致性等等。可以在⾸次测试数据⽣成时，将其导出到本地保存，在每次测试开始前导⼊数据，保持⼀致性。2、测试场景设计通过和业务部门沟通以及以往⽤户操作习惯，确定⽤户操作习惯模式，以及不同的场景⽤户数量，操作次数，确定测试指标，以及性能监控等。3、测试⽤例设计确认测试场景后，在系统已有的操作描述上，进⼀步完善为可映射为脚本的测试⽤例描述，⽤例⼤概内容如下：⽤例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）⽤例条件：⽤户已登录、具有对应权限等。。。操作步骤：①进⼊对应页⾯。。。。。。②查询相关数据。。。。。。③勾选导出数据。。。。。。④修改上传数据。。。。。。PS：这⾥的操作步骤只是个例⼦，具体以系统业务场景描述；4、脚本和辅助⼯具的开发及使⽤按照⽤例描述，可利⽤⼯具进⾏录制，然后在录制的脚本中进⾏修改；⽐如参数化、关联、检查点等等，最后的结果使得测试脚本可⽤，能达到测试要求即可；PS：个⼈⽽⾔，建议尽量⾃⼰写脚本来实现业务操作场景，这样对个⼈技能提升较⼤；⼀句话：能写就绝不录制五、性能测试执⾏在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试⽤例脚本，部署环境，执⾏测试并记录结果即可。 1、⼈⼯边执⾏边分析 通常我们做性能测试都是⼈⼯执⾏并随时观察系统运⾏的情况、资源的使⽤率等指标。性能测试的吸引⼒之⼀就在于它的不可预知性。当我们在做性能测试的时候，遇到跟预期不符的情况很正常，这个时候需要冷静的分析。但这个过程可能会很漫长，需要不断的调整系统配置或程序代码来定位问题，耗时耗⼈⼒。特别是在当前敏捷开发模式⽐较流⾏的⼤环境下，版本发布⾮常频繁且版本周期短（通常1~2周⼀个版本），没有那么长的时间来做性能测试。2、⽆⼈值守执⾏性能测试 ⽆⼈值守是最理想化的⽬标，⽬前我们也朝着这个⽅向努⼒。⽆⼈值守不是说没有⼈⼒介⼊，⽽是把⼈为的分析和执⾏过程分离，执⾏过程只是机器服从指令的运⾏⽽已。通常测试环境在⽩天⽐较繁忙，出现性能问题及定位难度较⼤且会影响功能测试。所以⼀般性能测试最好在晚上或周末进⾏，在相对较安静的条件有利于测试结果的稳定性。这种⽅法也相对⽐较适合敏捷的模式，不需要⼈⼯⼀直守着。只需要在拿到结果后进⾏分析就好了。同时，这种⽅式对测试⼈员能⼒的要求⽐较⾼，需要我们能进⾏⾃动化的收集各种监控数据、⽣成报表便于后续分析。六、结果分析与调优1、测试环境的系统性能分析根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进⾏对⽐，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据进⾏具体情况具体分析（影响性能的因素很多，这⼀点，可以根据经验和数据表现来判断分析）。2、硬件设备对系统性能表现的影响分析由于之前设计了⼏个不同的测试环境，故可以根据不同测试环境的硬件资源使⽤状况图进⾏分析，确定瓶颈是再数据库服务器、应⽤服务器抑或其他⽅⾯，然后针对性的进⾏优化等操作。3、其他影响因素分析影响系统性能的因素很多，可以从⽤户能感受到的场景分析，哪⾥⽐较慢，哪⾥速度尚可，这⾥可以根据258原则对其进⾏分析；⾄于其他诸如⽹络带宽、操作动作、存储池、线程实现、服务器处理机制等⼀系列的影响因素，具体问题具体分析，这⾥就不⼀⼀表述了。4、测试中发现的问题在性能测试执⾏过程中，可能会发现某些功能上的不⾜或存在的缺陷，以及需要优化的地⽅，这也是执⾏多次测试的优点。1.性能分析⽅法分类：（1）指标达成法：⽤于验证性能指标（2）最优化分析法：⽤于能⼒验证型测试2.常⽤性能分析⽅法：（1）快速瓶颈识别：①硬件上的性能瓶颈 ②应⽤软件上的性能瓶颈 ③应⽤程序上的性能瓶颈
④操作系统上的性能瓶颈 ⑤⽹络设备上的性能瓶颈（2）性能下降曲线：单⽤户区域、性能平坦区、压⼒区域、性能拐点（3）内存分析⽅法 （4）处理器分析⽅法 （5）磁盘IO分析⽅法 （6）进程分析⽅法 （7）⽹络分析⽅法七、测试报告与总结 性能测试报告是性能测试的⾥程碑，通过报告能展⽰出性能测试的最终成果，展⽰系统性能是否符合需求，是否有性能隐患。性能测试报告中需要阐明性能测试⽬标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中遇到的问题和解决办法等。性能测试⼯程师完成该次性能测试后，需要将测试结果进⾏备案，并作为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优⽅案等。同时需要将测试过程中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题，以及解决办法或解决⽅案，进⾏知识沉淀性能测试的实施过程
客户端性能测试应⽤在客户端性能测试的⽬的是考察客户端应⽤的性能，测试的⼊⼝是客户端。它主要包括并发性能测试、疲劳强度测试、⼤数据量测试和速度测试等，其中并发性能测试是重点。并发性能测试的过程是⼀个负载测试和压⼒测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执⾏指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使⽤等来决定系统的性能。负载测试是⼀个分析软件应⽤程序和⽀撑架构、模拟真实环境的使⽤，从⽽来确定能够接收的性能过程。压⼒测试（Stress Testing）是通过确定⼀个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最⼤服务级别的测试。并发性能测试的⽬的主要体现在三个⽅⾯：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应⽤程序的功能或者新的应⽤程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的⽤户负载，以预测系统的未来性能；通过模拟成百上千个⽤户，重复执⾏和运⾏测试，可以确认性能瓶颈并优化和调整应⽤，⽬的在于寻找到瓶颈问题。⽹络端性能测试应⽤在⽹络上性能的测试重点是利⽤成熟先进的⾃动化技术进⾏⽹络应⽤性能监控、⽹络应⽤性能分析和⽹络预测。⽹络应⽤性能分析的⽬的是准确展⽰⽹络带宽、延迟、负载和TCP端⼝的变化是如何影响⽤户的响应时间的。⽹络应⽤性能监控在系统试运⾏之后，需要及时准确地了解⽹络上正在发⽣什么事情；什么应⽤在运⾏，如何运⾏；多少PC正在访问LAN或WAN；哪些应⽤程序导致系统瓶颈或资源竞争，这时⽹络应⽤性能监控以及⽹络资源管理对系统的正常稳定运⾏是⾮常关键的。利⽤⽹络应⽤性能监控⼯具，可以达到事半功倍的效果，在这⽅⾯我们可以提供的⼯具是Network Vantage。通俗地讲，它主要⽤来分析关键应⽤程序的性能，定位问题的根源是在客户端、服务器、应⽤程序还是⽹络。在⼤多数情况下⽤户较关⼼的问题还有哪些应⽤程序占⽤⼤量带宽，哪些⽤户产⽣了最⼤的⽹络流量，这个⼯具同样能满⾜要求。⽹络预测考虑到系统未来发展的扩展性，预测⽹络流量的变化、⽹络结构的变化对⽤户系统的影响⾮常重要。根据规划数据进⾏预测并及时提供⽹络性能预测数据。我们利⽤⽹络预测分析容量规划⼯具PREDICTOR可以作到：设置服务⽔平、完成⽇⽹络容量规划、离线测试⽹络、⽹络失效和容量极限分析、完成⽇常故障诊断、预测⽹络设备迁移和⽹络设备升级对整个⽹络的影响。从⽹络管理软件获取⽹络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可⼈⼯⽣成流量数据），这样可以得到现有⽹络的基本结构。在基本结构的基础上，可根据⽹络结构的变化、⽹络流量的变化⽣成报告和图表，说明这些变化是如何影响⽹络性能的。PREDICTOR提供如下信息：根据预测的结果帮助⽤户及时升级⽹络，避免因关键设备超过利⽤阀值导致系统性能下降；哪个⽹络设备需要升级，这样可减少⽹络延迟、避免⽹络瓶颈；根据预测的结果避免不必要的⽹络升级。服务器端性能测试对于应⽤在服务器上性能的测试，可以采⽤⼯具监控，也可以使⽤系统本⾝的监控命令，例如Tuxedo中可以使⽤Top命令监控资源使⽤情况。实施测试的⽬的是实现服务器设备、服务器操作系统、数据库系统、应⽤在服务器上性能的全⾯监控，测试原理如下图。UNIX资源监控指标和描述监控指标 描述平均负载 系统正常状态下，最后60秒同步进程的平均个数冲突率 在以太⽹上监测到的每秒冲突数进程/线程交换率 进程和线程之间每秒交换次数CPU利⽤率 CPU占⽤率（%）磁盘交换率 磁盘交换速率接收包错误率 接收以太⽹数据包时每秒错误数包输⼊率 每秒输⼊的以太⽹数据包数⽬中断速率 CPU每秒处理的中断数输出包错误率 发送以太⽹数据包时每秒错误数包输⼊率 每秒输出的以太⽹数据包数⽬读⼊内存页速率 物理内存中每秒读⼊内存页的数⽬写出内存页速率 每秒从物理内存中写到页⽂件中的内存页数⽬或者从物理内存中删掉的内存页数⽬内存页交换速率 每秒写⼊内存页和从物理内存中读出页的个数进程⼊交换率 交换区输⼊的进程数⽬进程出交换率 交换区输出的进程数⽬系统CPU利⽤率 系统的CPU占⽤率（%）⽤户CPU利⽤率 ⽤户模式下的CPU占⽤率（%）磁盘阻塞 磁盘每秒阻塞的字节数分析优化性能思路流程性能测试总结1、硬件上的性能瓶颈：⼀般指的是CPU、内存、磁盘读写等的瓶颈，为服务器硬件瓶颈。2、应⽤软件上的性能瓶颈：⼀般指的是服务器操作系统瓶颈（参数配置）、数据库瓶颈（参数配置）、web服务器瓶颈（参数配置）、中间件瓶颈（参数配置）等3、应⽤程序上的性能瓶颈：⼀般指的是开发⼈员，开发出来的应⽤程序（如sql语句、数据库设计、业务逻辑、算法等）。4、操作系统上的性能瓶颈：⼀般指的是Windows、linux等操作系统，如出现物理内存不⾜时，或虚拟内存设置不合理（虚拟内存设置不合理，会导致虚拟内存的交换率⼤⼤降低，从⽽导致⾏为的响应时间⼤⼤增加，可以认为在操作系统上出现了性能瓶颈）。5、⽹络设备上的性能瓶颈：⼀般指的是防⽕墙、动态负载均衡器、交换机等设备。安全测试安全测试是⼀个相对独⽴的领域，需要更多的专业知识。如：WEB的安全测试、需要熟悉各种⽹络协议、防⽕墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。采⽤成熟的⽹络漏洞检查⼯具检查系统相关漏洞（即⽤最专业的⿊客攻击⼯具攻击试⼀下，现在最常⽤的是 NBSI 系列和 IPhacker IP ）安全测试主要是根据对应的项⽬来进⾏的安全测试⽤例设计及编写后执⾏安全测试。⽐如主要是对⽤户登录的校验、密码是否加密、权限；设计充值、提现等必须是否绑定⼿机号的短信验证码校验等；需要实名认证的，甚⾄⼈脸识别技术等；做压⼒测试的时候，⽐如需要考虑同⼀个IP地址的请求过多或频繁，需要有对应的判断是否为恶意攻击及判断后的相应解决措施等。兼容性测试兼容性测试主要是指，软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率⼯作，会不会影响导致系统的崩溃。平台测试浏览器测试软件本⾝能否向前或向后兼容测试软件能否与其它相关软件兼容数据兼容性测试最常见的兼容性测试就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页⾯显⽰不同。常见的IE8的兼容性。⽂档测试国家有关计算机软件产品开发⽂件编制指南中共有14种⽂件，可分为3⼤类。开发⽂件：可⾏性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。⽤户⽂件：⽤户⼿册、操作⼿册，⽤户⽂档的作⽤：改善易安装性；改善软件的易学性与易⽤性；改善软件可靠性；降低技术⽀持成本。管理⽂件：项⽬开发计划、测试计划、测试分析报告、开发进度⽉报、项⽬开发总结报告。在实际的测试中，最常见的就是⽤户⽂件的测试，例如：⼿册说明书等。⽂档测试关注的点：⽂档的术语⽂档的正确性⽂档的完整性⽂档的⼀致性⽂档的易⽤性易⽤性测试（⽤户体验测试）易⽤性（Useability）是交互的适应性、功能性和有效性的集中体现。⼜叫⽤户体验测试。业务测试业务测试是指：测试⼈员将系统的整个模块串接起来运⾏、模拟真实⽤户实际的⼯作流程。满⾜⽤户需求定义的功能来进⾏测试的过程。界⾯测试界⾯测试（简称UI测试)，测试⽤户界⾯的功能模块的布局是否合理、整体风格是否⼀致、各个控件的放置位置是否符合客户使⽤习惯，此外还要测试界⾯操作便捷性、导航简单易懂性，页⾯元素的可⽤性，界⾯中⽂字是否正确，命名是否统⼀，页⾯是否美观，⽂字、图⽚组合是否完美等。安装与卸载测试安装测试是指：测试程序的安装、卸载。最典型的就是APP的安装、卸载。内存泄漏测试内存泄漏的检测：1、对于不同的程序可以使⽤不同的⽅法来进⾏内存泄露的检查，还可以使⽤⼀些专门的⼯具来进⾏内存问题的检查，例如、Purify、BundsChecker等。 有些开发⼯具本⾝就带有内存问题检查机制．要确保程序员在编写程序和编译程序的时候打开这些功能。2、通过代码扫描分析⼯具来检查
2023年6月21日发(作者：)
按测试对象的⾓度划分：性能测试、安全测试、兼容性测试、⽂档测试、易⽤性测试（⽤户体验测试）。。。性能测试性能测试是通过⾃动化的测试⼯具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进⾏测试。负载测试和压⼒测试都属于性能测试，两者可以结合进⾏。通过负载测试，确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压⼒测试是通过确定⼀个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最⼤服务级别的测试。中国软件评测中⼼将性能测试概括为三个⽅⾯：应⽤在客户端上性能的测试、应⽤在⽹络上性能的测试和应⽤在服务器端上性能的测试。通常情况下，三⽅⾯有效、合理的结合，可以达到对系统性能全⾯的分析和瓶颈的预测。定义狭义的性能测试主要⽤于描述常规的性能测试，是指通过模拟⽣产运⾏的业务压⼒或⽤户使⽤场景来测试系统的性能是否满⾜⽣产性能的要求。⼴义的性能测试则是压⼒测试、负载测试、强度测试、并发（⽤户）测试、⼤数据量测试、配置测试、可靠性测试等和性能相关的测试统称。基本策略测试的基本策略是⾃动负载测试，通过在⼀台或⼏台PC机上模拟成百或上千的虚拟⽤户同时执⾏业务的情景，对应⽤程序进⾏测试，同时记录下每⼀事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应⽤的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受⼒，就为最终⽤户规划整个运⾏环境的配置提供了有⼒的依据。⽬的⽬的是验证软件系统是否能够达到⽤户提出的性能指标，同时发现软件系统中存在的性能瓶颈，以优化软件，最后起到优化系统的⽬的。包括以下⼏个⽅⾯：1．评估系统的能⼒，测试中得到的负荷和响应时间数据可以被⽤于验证所计划的模型的能⼒，并帮助作出决策。2．识别体系中的弱点：受控的负荷可以被增加到⼀个极端的⽔平，并突破它，从⽽修复体系的瓶颈或薄弱的地⽅。3．系统调优：重复运⾏测试，验证调整系统的活动得到了预期的结果，从⽽改进性能。4. 检测软件中的问题：长时间的测试执⾏可导致程序发⽣由于内存泄露引起的失败，揭⽰程序中的隐含的问题或冲突。5．验证稳定性（resilience）、可靠性（reliability）：在⼀个⽣产负荷下执⾏测试⼀定的时间是评估系统稳定性和可靠性是否满⾜要求的唯⼀⽅法。类型性能测试类型包括：负载测试、压⼒测试、并发测试、配置测试、基准测试、验收测试、可靠性测试、失效恢复测试、容量测试，稳定性测试等。⼀般企业会按照这个步骤去执⾏测试：先负载测试（逐步增加并发⽤户数来增加压⼒，只能找出性能指标的瓶颈范围，⽽不是具体的性能指标值），再性能测试（验证我们的性能指标的具体的值，即精确），最后压⼒测试。平时我们说的基准测试其实是在性能测试⾥的找出。压⼒测试：在⼀定的压⼒下，运⾏⽐较长的时间。⽬的是看服务器的稳定性。企业⼝语说的“压测”表达的是：要做负载测试和性能测试。
负载测试（Load Testing）定义负载测试是⼀种主要为了测试软件系统是否达到需求⽂档设计的⽬标，譬如软件在⼀定时期内，最⼤⽀持多少并发⽤户数，软件请求出错率等，测试的主要是软件系统的性能。负载测试是不断增加系统的负载，直到负载达到阈值——评估系统在预期⼯作负载下的性能的测试。这⾥增加负载的意思是在测试中增加并发⽤户数量、⽤户交互等，通常是在可控的环境下进⾏。典型的负载测试包括在负载测试过程中确定响应时间，吞吐量，误码率等。该⽅法可以找到系统的性能极限，可以为性能调优提供相关数据。该类⽅法通常要基于或模拟系统真实运⾏环境，且选取的业务场景也要尽可能地与实际情况相符。狭义的定义：是指对系统不断地增加压⼒或增加⼀定压⼒下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。运⽤场景：此类型的测试⽬前运⽤得⽐较少。⼀般情况下，是以服务器资源安全临界值为界限的测试。如果要模拟某个应⽤在指定服务器上最⼤且安全的负载量，则属于负载测试。⽬标确定并确保系统在超出最⼤预期⼯作量的情况下仍能正常运⾏。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的⽅⾯。负载测试的⽬标是测试在⼀定负载情况下系统性能（不关注稳定性，也就是说不关注长时间运⾏，只是得到不同负载下相关性能指标即可）；实际中我们常从⽐较⼩的负载开始，逐渐增加模拟⽤户的数量（增加负载）， 观察不同负载下应⽤程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统的不同负载情况下的性能指标。⽬的负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或⾏为来发现问题，从⽽为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的⼀部分。但它们两者的⽬的是不⼀样的，负载测试是为了发现缺陷，⽽性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，⽽是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所⽤的⼀种技术，即性能测试使⽤负载测试的技术、使⽤负载测试的⼯具。性能测试要获得在不同的负载情况下的性能指标数据。通过负载测试和压⼒测试都可以获得系统正常⼯作时的极限负载或最⼤容量。容量测试，⾃然也是采⽤负载测试技术来实现，⽽在破坏性的压⼒测试中，容量的确可以看作是⼀种副产品——间接结果。负载测试的必要准备1.什么是你真正需要了解的？2.确定⽤户数量3.研究你的分析4.组建你的团队5.准备你的浏览器6.准备测试你的应⽤7.预留时间分析结果8.预留时间修改9.计划⼀个敏捷测试⽅法压⼒测试（Stress Testing）定义压⼒测试是在强负载（⼤数据量、⼤量并发⽤户等）下的测试，查看应⽤系统在峰值使⽤情况下操作⾏为，从⽽有效地发现系统的某项功能隐患、系统是否具有良好的容错能⼒和可恢复能⼒。压⼒测试分为⾼负载下的长时间（如24⼩时以上）的稳定性压⼒测试和极限负载情况下导致系统崩溃的破坏性压⼒测试。压⼒测试可以被看作是负载测试的⼀种，即⾼负载下的负载测试，或者说压⼒测试采⽤负载测试技术。通过压⼒测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使⽤或系统出错的概率⽐较低，可能⼀个⽉只出现⼀次，但在⾼负载（压⼒测试）下，可能⼀天就出现，从⽽发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这⼀点，某个电⼦商务⽹站的订单提交功能，在10个并发⽤户时错误率是零，在50个并发⽤户时错误率是1%，⽽在200个并发⽤户时错误率是20%。狭义的定义：压⼒测试是指超过安全负载的情况下，对系统不断施加压⼒，是通过确定⼀个系统的瓶颈或不能接收⽤户请求的性能点，来获得系统能提供的最⼤服务级别的测试。运⽤场景：此类型的测试⽬前运⽤得⽐较少。但对于⼤型的共享中⼼或者核⼼的应⽤也会⽤到。⽬标压⼒测试的⽬标是测试在⼀定的负载下系统长时间运⾏的稳定性，尤其关注⼤业务量情况下长时间运⾏系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）；压⼒测试是测试系统的限制和故障恢复能⼒，它包括两种情况：稳定性压⼒测试：在选定的压⼒值下，长时间持续运⾏。通过这类压⼒测试，可以考察各项性能指标是否在指定范围内，有⽆内存泄漏、有⽆功能性故障等；破坏性压⼒测试：在稳定性压⼒测试中可能会出现⼀些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的⼿段，往往能快速造成系统的崩溃或让问题明显的暴露出来。⽬的压⼒测试主要是为了发现在⼀（任意）定条件下软件系统的性能的变化情况，通过改变应⽤程序的输⼊以对应⽤程序施加越来越⼤的负载（并发，循环操作，多⽤户） 并测量在这些不同的输⼊时性能的改变，也就是通常说的概念：压⼒测试考察当前软硬件环境下系统所能承受的最⼤负荷并帮助找出系统瓶颈所在。其实这种测试也 可以称为负载测试，但是负载测试通常描述⼀种特定类型的压⼒测试——增加⽤户数量以对应⽤程序进⾏压⼒测试。⽐如实际中我们说从⽐较⼩的负载开始，逐渐增加模拟⽤户的数量， 直到应⽤程序响应时间超时，就是说的负载测试。压⼒测试主要是为了测试硬件系统是否达到需求⽂档设计的性能⽬标，譬如在⼀定时期内，系统的cpu利⽤率，内存使⽤率，磁盘I/O吞吐率，⽹络吞吐量等，压⼒测试和负载测试最⼤的差别在于测试⽬的不同。压⼒测试是指当硬件资源如cpu、内存、磁盘空间等不充⾜时对软件稳定性的检查。压⼒测试属于负⾯测试（Negative testing），使⼤量并发⽤户/进程加载软件以使系统硬件资源不能应付，这个测试也被称为是疲劳测试（Fatigue testing），通过超出其能⼒的测试来捕获应⽤程序的稳定性。压⼒测试的主要思想是确定系统故障，关注系统如何优雅地恢复正常，这种质量被称为是可恢复性。负⾯测试(Negative testing)是相对于正⾯测试(Positive testing)⽽⾔的。正⾯测试就是测试系统是否完成了它应该完成的功能；⽽负⾯测试就是测试系统是否不执⾏它不应该完成的操作。配置测试同功能测试⼀样，如果需求规格说明中有明确的性能需求，例如完成复杂运算处理的解算时间要求，解算精度要求，⽹络传输吞吐量，数据库的最⼤容量，服务器能允许的同时在线访问数量等等，都要反映在配置项测试⾥。如果没有明确指出性能要求，测试⼈员可根据软件产品所处⾏业，⾃⾏产⽣测试需求。——这很考验测试⼈员的素质和⽔平的哦。例如前⾯所提到的，服务器能允许的最⼤同时在线访问量，就是互联⽹⾏业的⼀个性能需求。当然，还有常规的空间性能（存储和占⽤计算机硬件资源）和时间性能（软件处理⼀个任务所⽤时间），如今的计算机资源，基本都满⾜要求，除⾮你是航空发射，武器控制等特殊⾏业，才需要⾮常关注配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重要依据。例如，可以通过不停地调整 Oracle 的内存参数来进⾏测试，使之达到⼀个较好的性能。可以看出，配置测试本质上是前⾯提到的某些种类的性能测试组合在⼀起⽽进⾏的测试。
并发测试定义 所谓并发，它的特点是“并⾏”和“同时”。在loadrunner中就得使⽤集合点的功能来实现。 测试多个⽤户同时访问同⼀个应⽤、同⼀个模块或者数据记录时是否存在死锁或者其他性能问题，⼏乎所有的性能测试都会涉及⼀些并发测试。通常的测试⽅法是设置集合点。⽬的测试⽬的并⾮为了获得性能指标，⽽是为了发现并发引起的问题。并发概念的浅谈想确定⽤户并发数；必须知道系统所承载的在线⽤户数；对于并发，我过去接触了⼏种理解，在接触的第⼀种理解中，“并发”是由loadrunner中获取，即脚本中所有或部分vuser执⾏⾄集合点函数时进⾏停留，等待触发条件发⽣以后，同时执⾏集合点函数后的请求操作的这⼀个过程，为“并发”（这⼀个请求操作⼀般存在多个http请求），可惜这种“并发”是⽆法直接⽤于衡量系统性能的。LoadRuner的并发很好理解，就是虚拟⽤户数。因为LR有个集合点，可以在所有虚拟⽤户初始化且到达集合点后，再⼀起执⾏后续操作，从⽽达到同时且并⾏的效果。⽽在接触的第⼆种理解中，“并发”的理解是相对于服务器某⼀个时间区间内接收的请求数，也就是每秒的点击率（loadrunner考虑到这点，也就是analysis⾥⾯的hits/s），为“并发”，这种“并发”是可以⽤于对系统性能状况进⾏量化的，但是这种测试思想只是⽐较⽚⾯的从性能指标的⾓度去衡量系统性能，不能体现出系统性能带给⽤户何种性能体验（这也是不少开源性能测试⼯具的问题）。前⼀种“并发”的理解普遍获得了loadrunner初级⽤户的认可，后⼀种“并发”的理解普遍获得系统运维、开发⼈员的认可，在沟通中为了⽅便区别开来，在两种⾓⾊⾥⾯，当⼤家意识到并发的理解存在差异时，⼤家把前⼀种被称为“狭义上的并发”，⽽后⼀种被称为“⼴义上的并发”。后来，⼜从淘宝团队⾥⾯了解了⼀种定义，貌似淘宝QA把“并发”定义为⼀个完整的事务请求数量过程（loadrunner也考虑到这点，也就是analysis⾥⾯的Transactions per Second）。⼀直以来，还有⼀种技术范围以外对“并发”的粗略的理解被第三⽅测试拿来⽤了，那就是⽤户在线数中的某个百分⽐即并发数。如果⼀个团队⾥⾯对“并发”的理解有这么多种，那么当我们在讨论性能需求的“⽀持并发数”时，我们究竟在讨论什么呢？个⼈认为，有⼀部分的原因是由于loadrunner是惠普saas（软件即服务的解决⽅案）的⼀部分，所以并不是⼀个纯粹技术⼈员使⽤的测试⼯具，它同时也是⼀个业务⼈员可以相对轻易掌握的性能测试⼯具，因此loadrunner内很多名词解释也不能单纯从技术⼈员的⾓度从字⾯意义上理解。通常来说，⾯对同样100笔业务交易量，普遍会认为100vuser对服务器产⽣的负载会⽐50vuser要⾼，但是在性能脚本能够在较快的响应时间中完成时，由于50vuser执⾏过程中每⼀个vuser都需要发⽣两次迭代，导致了性能场景中vuser在脚本action部分停留的时间更长，因此反⽽能够得到⽐100vuser的更⾼的vuser在线数，更⾼在线数带来的也就是更⼤的负载，也就是说：同等业务量的情况下，50线程所产⽣的负载完全有可能⽐100线程所产⽣的负载要⾼。为了避免发⽣这种问题，“并发（集合点）”的真正作⽤就体现出来了，通过集合点函数控制了vuser的⾏为相对⼀致，降低了初始化过程和事务前后⽂请求产⽣的时间差影响。测试⼯具中并发存在的真正意义也就在这⾥，对集合点所理解的“并发”，和现场实际⽤户⾥⾯同时触发的请求关系不是太⼤。分析“并发”需求时的⼀些典型：a) 某个业务系统⾥⾯有10000⽤户，但是能够访问这个系统的终端数只有1000个、或者所需测试的业务每个⽉上限是1000笔，那么最⾼在线⽤户数就不可能超过1000、业务量也不可能超过1000。所以，有些时候在分析性能需求的时候，去统计⼀个业务系统的⽤户数还不如去统计能够访问这个系统的终端数、甚⾄业务量靠谱。b) 某个业务系统⾥⾯，各个业务模块都不⼀样，那么就是说完成⼀笔业务交易，所产⽣的请求数也是不⼀样的，例如表单新增，有的需要填写20个字段，有的只需要填写5个字段，各个表单都不⼀样，那么为了更接近的去模拟⽤户现场负载，请求数都不⼀样的各种业务混在⼀起，并发数⼜应该是多少呢？为了解决这些问题，需要⾸先考虑“并发”的粒度，以真实的业务场景为例：a) 把粒度控制在⽤户上来看，假定所有⽤户访问⼀次系统平均耗时500秒，⼀个业务峰值会有800⽤户在线，则800/500=1.6。理论上，系统的性能需求是每秒要成功处理1.6个⽤户的请求；b) 把粒度控制在事务上来看，假定所有⽤户执⾏⼀次完整的、成功的业务操作平均需要500秒，⼀个业务峰值有2000笔所关注的业务需要去执⾏，则2000/500=4。理论上，系统的性能需求是每秒要成功处理4笔业务交易；c) 把粒度控制在请求上来看，假定所有⽤户执⾏⼀次完整的、不管成功或者失败的HTTP请求操作平均需要0.08秒，⼀个业务峰值有28000个请求需要去完成，则28000/0.08=350000。理论上，系统的性能需求是每秒要成功处理350000个请求。分类1、独⽴业务性能测试：核⼼业务模块的某⼀业务并发性能测试； 2、组合业务性能测试：⼀个或多个模块的多个业务同时进⾏并发测试。
独⽴业务性能测试1、完全⼀样功能的并发测试：检查程序对同⼀时刻并发操作的处理，例如模拟多个⽤户在同⼀时刻向数据库写⼊相同数据，或者多个⽤户在同⼀时刻发出请求测试系统能否正确响应。2、完全⼀样操作的并发测试：在同⼀时刻完成完全⼀样的操作，即从宏观上看操作对系统的影响是⼀致的，例如同时单击保存按钮。这类测试⽬的在于验证⼤量⽤户使⽤同⼀功能时系统能否正常⼯作。3、相同/不同的⼦功能并发测试：同⼀模块⼤多数功能相互耦合，针对⼀些⼦功能较多的模块做组合测试。组合的依据就是⽤户使⽤的场景，每个不同的⼦功能都模拟⼀定的⽤户数量进⾏并发测试。组合业务性能测试1、不同核⼼业务模块的⽤户进⾏并发，模块之间具有⼀定耦合：这种测试⽐较接近⽤户使⽤情况，测试的对象是多个模块组，每个组相关的模块之间具有⼀定耦合关系。组与组之间的关系相对独⽴。例如实际中各类型的⽤户都会对应⼀组模块，相当于不同的业务组并发的访问系统。2、具有耦合关系的核⼼模块组进⾏并发，每组模块内部存在耦合关系：主要测试多⽤户并发条件下⼀些存在耦合或者数据接⼝的模块是否正常运⾏，可以参考集成测试⽤例和概要设计⽂档，分析出⼀些核⼼模块的接⼝。3、基于⽤户场景的并发测试：选择⽤户的⼀些经典场景做测试，测试对象可以是核⼼模块，也可以是⾮核⼼模块。这种测试更接近⽤户使⽤的实际情况，测试需要充分考虑实际场景。设计组合模块⽤户并发性测试⽤例⼀般⽤不同“⼦功能”或者“⼦事务”为单位，来进⾏各种模块的不同核⼼功能组合。并发⽤户数量设计⽅法 容量测试（Volume Testing）定义 所谓容量，即系统处于最⼤负载状态或某项指标达到所能接受的最⼤阈值下对请求的最⼤处理能⼒。容量测试是⼀种⾮功能的测试，它通过向应⽤程序中添加⼤量的数据来实现检查被测系统处理⼤数据量的能⼒。可以通过向数据库插⼊⼤量的数据或让应⽤程序处理⼀个⼤型⽂件来进⾏测试应⽤程序。通过容量测试，可以识别应⽤程序中具有⼤数据时的瓶颈，检查应⽤程序的效率，进⽽得到不同数据量级下应⽤程序的性能。确定系统最⼤承受量，譬如系统最⼤⽤户数，最⼤存储量，最多处理的数据流量等。
举例：在⼀个新开发的⽹络游戏应⽤程序中，在进⾏容量测试时，可以通过向数据库中插⼊数百万⾏的数据，然后在这些数据的基础上进⾏性能的测试。注意，这⾥所说的数据⼀定是符合其功能场景的，不是毫⽆关系的数据。⽬的容量测试的⽬的是通过测试预先分析出反映软件系统应⽤特征的某项指标的极限值（如最⼤并发⽤户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运⾏。容量测试还将确定测试对象在给定时间内能够持续处理的最⼤负载或⼯作量。软件容量的测试能让软件开发商或⽤户了解该软件系统的承载能⼒或提供服务的能⼒，如某个电⼦商务⽹站所能承受的、同时进⾏交易或结算的在线⽤户数。知道了系统的实际容量，如是不能满⾜设计要求，就应该寻求新的技术解决⽅案，以提⾼系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使⽤中的性能状况充满信⼼，同时也可以帮助⽤户经济地规划应⽤系统，优化系统的部署。如何统计容量指标？统计维度⼀般来说，可以从如下两个维度来定量系统的容量：
统计⽅法⼀般来说，常⽤的采集数据的⽅法，有以下⼏种⽅式：①、埋点采集：即在系统的各个节点，根据需要添加埋点，针对性的进⾏数据采集；②、⽇志/数据库：通过⽇志服务（⽐如ELK）或者运维监控（现在很流⾏的Devops），采集分析数据；③、Agent/探针：在需要采集的节点添加Agent/探针，实时采集，数据存⼊时序数据库（⽐如influxdb），实时展⽰；注意事项①、采集对⽐的数据⼀定要采集线上的真实数据，这样才能反映真实客观的系统压⼒。②、容量测试环境的配置，⼀定要和线上保持⼀致（服务器数量可以不同，但配置尽可能保持⼀致）。测试思路①、根据具体的业务情况和系统架构，通过配置测试的⼿段，测量得到单个服务节点在对应的业务场景下最⼤的性能表现；②、根据系统架构（集群、分布式、微服务）特点，通过启⽤≥2的服务节点，来得到服务节点的增加和系统性能的提升⽐例；③、通过线上采集的系统数据，分析出过去某段时间（或某个业务）的⾼峰流量，然后通过计算，得到容量扩容，需要投⼊的实际服务数量；约束/停⽌条件在测试过程中，只要限定的某项指标达到最⼤可接受阈值或某项资源达到最⼤使⽤状态，即刻停⽌测试。选择合适的容量指标考虑到业务需求和系统架构的不同，在选取容量指标时⼀般遵循如下原则：①、数据密集型：即并发请求量较⼤的类型，⼀般TPS和RT是⽐较关注的指标；②、数据存储型：即需要存储读写的数据量较⼤的类型，⼀般吞吐量和IO是⽐较关注的指标；容量规划为什么需要容量规划？对于业务越来越复杂的商业形态，每个业务都由⼀系列不同的系统来提供服务，每个业务系统都部署在不同的机器上。容量规划的⽬的在于让每⼀个业务系统能够清晰地知道：①、什么时候应该增加服务节点，什么时候应该减少服务节点（⽐如服务端接受到的流量达到什么量级）？（⽐如双⼗⼀，⼤促，秒杀）②、为了双 11 、促销、秒杀、渠道拓展引流等业务需求，需要扩充到什么数量级的服务，才能即保证系统的可⽤性、稳定性，⼜能节约成本？容量规划四步⾛①、业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击；②、系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配⽐，然后计算每个业务⼤概需要多少服务节点来提供可靠稳定的性能⽀撑；③、系统容量测试阶段：通过全链路压测或者PAT/UAT环境的压测，来模拟真实的业务场景，确定每个服务节点的具体性能表现，进⾏针对性的调整；④、流量分配调整阶段：根据压测的结果，设定限流、服务降级等系统保护措施，来预防当实际流量超过系统所能承受的最⼤流量时，系统⽆法提供服务；扩容⼿段①、垂直扩容升级服务的硬件配置，让单个服务节点的容量更⼤，来提供更⾼的系统服务能⼒。⽐如：加⼤服务机器的CPU数量和内存，更换性能更好的⾼速缓存服务器，数据存储⽤NAS盘替换等。②、⽔平扩展即增加服务节点的数量，让可提供服务的服务变得更多，来提升系统总体的服务能⼒。常见的⽅式有：服务集群：服务器的数量由1→N（但需要重点关注负载均衡）；分布式：提供服务的节点由统⼀集中管理部署，分散到不同的地点；容器：提供更灵活的弹性扩容机制，根据具体的访问流量⼤⼩来弹性扩容或者缩容；容量测试的优点以下是任何软件应⽤程序的容量或洪⽔测试的优点。它提供了运⾏软件应⽤程序所需的硬件类型的清晰图像，包括CPU、内存等。可以很早地确定可扩展性计划。它有助于节省可能⽤于应急计划的⼤量资⾦。它有助于尽早发现应⽤程序操作中的瓶颈。它确保了经过容量测试的应⽤程序已准备好投⼊实际使⽤。它有助于让应⽤程序上线或不上线。容量测试的缺点此类测试增加了项⽬的额外成本，因为它是由不同的性能测试团队在功能测试的基础上完成的。为什么经常推荐容量测试？由于以下原因，通常建议进⾏容量测试。当到数据库中的数据量增加时，它有助于检查系统性能。使⽤⼤量数据研究软件应⽤程序⾏为。评估应⽤程序稳定性开始降低的点。它可以识别正常，低，中，⾼容量下的应⽤能⼒。容量测试检查在容量或洪⽔测试期间评估和检查以下参数。容量测试旨在检查是否有任何数据丢失。进⾏容量测试以记录不同容量条件下的响应时间并评估平均响应时间。它旨在评估数据库中的数据是否正确保存。它旨在验证数据是否被任何通知覆盖。它旨在检查警告和错误消息，以及它们在不同容量级别的关联。它旨在检查⾼数据量是否会以任何⽅式影响被测系统中处理请求的速度。容量测试最佳实践以下是最佳容量测试结果⼴泛遵循的最佳实践。在检查所有⽇志 (即服务器和应⽤程序的⽇志) 时, 不要忘记停⽌所有服务器。在开始容量测试之前，确保正⾯（正常）场景正常⼯作。为了从容量测试中获得最佳结果，始终建议错开⽤户数量。平衡你的容量试时间以克服许可限制。引⼊的任何新版本都应该⾮常谨慎地处理。建⽴基线后，应分析⽤例以提⾼性能。在出现性能瓶颈的情况下，应该反复重复进⾏容量测试，以深⼊研究性能问题。可靠性测试定义软件可靠性测试是指为了保证和验证软件的可靠性要求⽽对软件进⾏的测试。其采⽤的是按照软件运⾏剖⾯(对软件实际使⽤情况的统计规律的描述)对软件进⾏随机测试的测试⽅法。软件可靠性是软件系统在规定的时间内以及规定的环境条件下，完成规定功能的能⼒。⼀般情况下，只能通过对软件系统进⾏测试来度量其可靠性。对软件可靠性进⾏定量的评估或验证，为了达到和验证软件的可靠性定量要求⽽对软件进⾏的测试。软件可靠性测试通常是在系统测试、验收、交付阶段进⾏，它主要是在实验室内仿真环境下进⾏，也可以根据需要和可能在⽤户现场进⾏。在给系统加载⼀定业务压⼒的情况下，使系统运⾏⼀段时间，以此检测系统是否稳定。例如，可以施加让 CPU 资源保持 70%～90%使⽤率的压⼒，连续对系统加压 8 个⼩时，然后根据结果分析系统是否稳定。这么多类型的性能测试看起来很吓⼈，实际上它们⼤多是密切相关的。例如，运⾏ 8 个⼩时来测试系统是否可靠，⽽这个测试极有可能包含了可靠性测试、强度测试、并发（⽤户）测试、负载测试，等等。特点
测试的⽬的(1)通过在有使⽤代表性的环境中执⾏软件，以证实软件需求是否正确实现。(2)为进⾏软件可靠性估计采集准确的数据，预测软件在实际运⾏中的可靠性。估计软件可靠性⼀般可分为四个步骤，即数据采集、模型选择、模型拟合以及软件可靠性评估。可以认为，数据采集是整个软件可靠性估计⼯作的基础，数据的准确与否关系到软件可靠性评估的准确度。(3)通过软件可靠性测试找出所有对软件可靠性影响较⼤的错误。(4)通过测试可以提⾼整个软件系统的防错、容错和纠错的能⼒。通过软件可靠性测试可以达到以下⽬的：(1) 有效地发现程序中影响软件可靠性的缺陷，从⽽实现可靠性增长：软件可靠性是指“在规定的时间内，规定的条件下，软件不引起系统失效的能⼒，其概率度量称为软件可靠度。”软件的“规定的条件”主要包括相对不变的条件和相对变化的条件，相对不变的条件如计算机及其操作系统;相对变化的条件是指输⼊的分布，⽤软件的运⾏剖⾯来描述。认为按照软件的运⾏剖⾯对软件进⾏测试⼀般先暴露在使⽤中发⽣概率⾼的缺陷，然后是发⽣概率低的缺陷。⽽⾼发⽣概率的缺陷是影响产品可靠性的主要缺陷，通过排除这些缺陷可以有效地实现软件可靠性的增长。(2) 验证软件可靠性满⾜⼀定的要求：通过对软件可靠性测试中观测到的失效情况进⾏分析，可以验证软件可靠性的定量要求是否得到满⾜。(3) 估计、预计软件可靠性⽔平通过对软件可靠性测试中观测到的失效数据进⾏分析，可以评估当前软件可靠性的⽔平，预测未来可能达到的⽔平，从⽽为开发管理提供决策依据。软件可靠性测试中暴露的缺陷既可以是影响功能需求的缺陷也可以是影响性能需求的缺陷。软件可靠性测试⽅法从概念上讲是⼀种⿊盒测试⽅法，因为它是⾯向需求、⾯向使⽤的测试，它不需要了解程序的结构以及如何实现等问题。分析⽅法⽬前主要的软件可靠性分析⽅法有失效模式影响分析法、严酷性分析法、故障树分析法、事件树分析法、潜在线路分析法。测试过程包括五个步骤：确定可靠性⽬标，定义软件运⾏剖⾯，设计测试⽤例，实施可靠性测试，分析测试结果。失败恢复性测试 对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发⽣故障⽤户是否能够继续使⽤系统，⽤户收到多⼤的影响。
强度测试强度测试是⼀种性能测试，它在系统资源特别低的情况下软件系统运⾏情况，⽬的是找到系统在哪⾥失效以及如何失效的地⽅。 强度测试主要是为了检查程序对异常情况的抵抗能⼒。强度测试总是迫使系统在异常的资源配置下运⾏。例如： 当正常的⽤户点击率为“1000 次/秒”时，运⾏点击率为“2000 次/秒”的测试⽤例； 运⾏需要最⼤存储空间（或其他资源）的测试⽤例； 运⾏可能导致操作系统崩溃或磁盘数据剧烈抖动的测试⽤例，等等。强度测试是⼀种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具有重要的意义。在这种异常条件下进⾏的测试，更容易发现系统是否稳定以及性能⽅⾯是否容易扩展。疲劳测试疲劳测试是采⽤系统稳定运⾏情况下能够⽀持的最⼤并发⽤户数，持续执⾏⼀段时间业务，通过综合分析交易执⾏指标和资源监控指标来确定系统处理最⼤⼯作量强度性能的过程。是⼀类特殊的强度测试，主要测试系统长时间运⾏后的性能表现，例如 7× 24 ⼩时的压⼒测试。尖峰测试（Spike testing）尖峰测试（Spike testing）其实可以算作是压⼒测试（Stress Testing）的⼦集。尖峰测试是在⽬标系统经受短时间内反复增加⼯作负载，以⾄超出预期⽣产操作的负载量时，分析系统的⾏为，验证其性能特征。它还包括检查应⽤程序是否可以从突然增加的超预期负荷中恢复出来的测试。举例：在电商应⽤程序中经常有“整点秒杀”的活动，所以在整点时间前后的两三分钟时间⾥，会有巨⼤数量的⽤户进⼊到该活动中秒杀商品。尖峰测试就是为了分析这类场景。持久测试（Endurance testing）持久测试（Endurance testing），也被称为是浸泡测试（Soak Testing），它也是⼀种⾮功能的测试。持久测试是指在相当长的时间内使⽤预期的负载量对系统进⾏测试，以检查系统的各种⾏为，如内存泄露、系统错误、随机⾏为等。这⾥的提到的相当长的时间是相对⽽⾔的，举例来说，如果⼀个系统设计为运⾏3个⼩时的时间，那可以使⽤6个⼩时的时间来进⾏持久测试；如果设计为5个⼩时的时间，不妨⽤10个⼩时的时间来进⾏持久测试。对于现在的许多⽹络类应⽤程序，通常情况下会持续运⾏好多天，那么进⾏持久测试时可以选择更长的时间段。稳定性测试狭义的定义：稳定性测试是指被测试系统在特定硬件、软件、⽹络环境条件下，给系统加载⼀定业务压⼒，使系统运⾏⼀段较长时间，以此检测系统是否稳定，⼀般稳定性测试时间为 n*12 ⼩时。运⽤场景：此类型的测试⽬前也最常见，针对需要长时间稳定运⾏的性能点，需要执⾏稳定性测试。往往在⼀个项⽬的性能测试过程中，会划分出优先级较⾼的性能点，做稳定性测试。例如：宝贝详情页⾯等等。如何实施识别并确认软件主要业务（是否需要稳定性测试）将稳定性测试的重⼼放在软件最有Value的地⽅，⽐如说⼀个抢票系统，它最有value的地⽅是当有⼀定数量的⽤户同时进⾏买票操作是系统的响应时间，资源利⽤率等是否能够正常且稳定，⽽不是⽤户如何添加新的联系⼈，修改个⼈信息等。罗列主要⽤户场景及响应负载量⽤户场景可以根据软件主要业务进⾏设定对主要场景负载量需要有⼀个清晰的定义（或者通过负载测试验证了⽤户场景的负载量，这将作为⼀个标准的负载在稳定性测试中使⽤）制定稳定性指标模型（Modeling）根据⽤户场景建模，创建合适合理的稳定性指标模型（之后会有⼀个例⼦）测试环境准备（对软硬件环境的配置：配置的来源可以是客户环境模拟、需求⽂档规定的配置或者配置测试得出的最佳配置）识别稳定性的主要性能指标（KPI）⽤来描述稳定性测试关注的系统指标，⽐如响应时间、CPU、内存使⽤率等等，需要根据具体业务进⾏定义测试的执⾏和数据收集，按照相应稳定性指标模型（Modeling)分析测试结果，将测试结果应⽤在稳定性测试模型中，观察是否满⾜稳定性要求持续改进（如有必要）⼤数据量测试主要针对数据库有特殊要求的系统进⾏的测试，如电信业务系统的⼿机短信业务；可以分为实时⼤数据量，主要⽬的是测试⽤户较多或者某些业务产⽣较⼤数据量时，系统能否稳定运⾏；极限状态下的测试，测试系统使⽤⼀段时间即系统累计⼀点量的数据时能否正常的运⾏业务；前⾯两种的结合，测试系统已经累计了较⼤数据量时，⼀些实时产⽣较⼤数据量的模块能否稳定⼯作；如下⼤数量测试⽤例： 功能：数据库中的短信息表可以保存所有不能及时发送的短信息，⽤户上线后⼜能及时发送已经保存的信息；⼤数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进⾏⼤数据量的独⽴数据量测试；与压⼒性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试⽅案。⼤数据量测试的关键是测试数据的准备，可以依靠⼯具准备测试数据。速度测试速度测试主要是针对关键有速度要求的业务进⾏⼿⼯测速度，可以在多次测试的基础上求平均值，可以和⼯具测得的响应时间等指标做对⽐分析。不同类型测试之间的区别性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，⽽负载测试、压⼒测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常⼯作时所能承受的最⼤负载，这时负载测试就成为容量测试。通过压⼒测试，可以知道在什么极限情况下系统会崩溃、系统是否具有⾃我恢复性等，但更多的是为了确定系统的稳定性。压⼒测试是测试系统什么情况下失效或者崩溃；负载测试是测试系统什么情况下超出需求指标；强度测试是测试系统在瞬时⾼负载、长时间负载情况下系统反应；容量测试是测试系统在⼤数据量交互的反应！ 性能指标性能测试最基本要考虑以下⼏点1、时间特性，主要指的是软件产品的事务响应时间（⽤户发出请求到收到应答的这段时间）2、资源利⽤率，包括：cpu、内存、⽹络、硬盘、虚拟内存（如Java虚拟机）3、服务器可靠性，指服务器能在相对⾼负载情况下持续的运⾏4、可配置优化性，指服务器配置优化、业务逻辑优化、代码优化等检查系统是否满⾜需求规格说明书中规定的性能，通常表现在以下⼏个⽅⾯：1、对资源利⽤（包括：cpu、内存、⽹络、硬盘、虚拟内存（如Java虚拟机）等）进⾏的精确度量；2、对执⾏间隔；3、⽇志事件（如中断，报错）4、响应时间5、吞吐量（TPS）6、辅助存储区（例如缓冲区、⼯作区的⼤⼩等）7、处理精度等进⾏的监测TPS:服务器综合能⼒指标值，服务器最主要的指标值。吞吐量有个单位是：平均事务数/秒loadrunner和jmeter的TPS是有区别的，jmeter有两种每秒事务数。jmeter除了每个业务的请求到响应完成的统计外，还有事务逻辑控制器对多个单个业务请求打包成⼀个全链路业务流的业务的请求到响应完成的统计等。性能测试不是去找功能上的bug，是找出服务器的瓶颈。在实际⼯作中我们经常会对两种类型软件进⾏测试：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：数据库死锁；* Buffer Cache hit ：数据库Cache的命中情况当然，在实际中我们还会察看多⽤户测试情况下的内存，CPU，系统资源调⽤情况。这些指标其实是引申出来性能测试中的⼀种：竞争测试。什么是竞争测试，软件竞争使⽤各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能⼒。我们知道软件架构在实际测试中制约着测试策略和⼯具的选择。如何选择性能测试策略是我们在实际⼯作中需要了解的。⼀般软件可以按照系统架构分成⼏种类型：c/sclient/Server 客户端/服务器架构基于客户端/服务器的三层架构基于客户端/服务器的分布式架构b/s基于浏览器/Web服务器的三层架构基于中间件应⽤服务器的三层架构l基于Web服务器和中间件的多层架构l性能指标的两个⽅⾯ 外部指标|系统指标（与⽤户场景和需求相关指标）从外部看，性能测试主要关注如下四个指标吞吐量：每秒钟系统能够处理客户的请求数、任务数，其直接体现系统的承载的能⼒。并发⽤户数：同⼀时刻与服务器进⾏数据交互的所有⽤户数量；响应时间：服务处理⼀个请求或⼀个任务的耗时。错误率：⼀批请求中结果出错的请求所占⽐例。响应时间从单个请求来看就是服务响应⼀次请求的花费的时间。但是在性能测试中，单个请求的响应时间并没有什么参考价值，通常考虑的是完成所有请求的平均响应时间及中位数时间。
平均响应时间很好理解，就是完成请求花费的总时间/完成的请求总数。但是平均响应时间有⼀点不靠谱，因为系统的运⾏并不是平稳平滑的，如果某⼏个请求的时间超短或者超长就会导致平均数偏离很多。因此有时候我们会⽤中位数响应时间。所谓中位数的意思就是把将⼀组数据按⼤⼩顺序排列，处在最中间位置的⼀个数叫做这组数据的中位数 ，这意味着⾄少有50%的数据低于或⾼于这个中位数。当然，最为正确的统计做法是⽤百分⽐分布统计。也就是英⽂中的TP – Top Percentile ，TP50的意思在，50%的请求都⼩于某个值，TP90表⽰90%的请求⼩于某个时间。响应时间的指标取决于具体的服务。如智能提⽰⼀类的服务，返回的数据有效周期短（⽤户多输⼊⼀个字母就需要重新请求），对实时性要求⽐较⾼，响应时间的上限⼀般在100ms以内。⽽导航⼀类的服务，由于返回结果的使⽤周期⽐较长（整个导航过程中），响应时间的上限⼀般在2-5s。决定系统响应时间要素我们做项⽬要排计划，可以多⼈同时并发做多项任务，也可以⼀个⼈或者多个⼈串⾏⼯作，始终会有⼀条关键路径，这条路径就是项⽬的⼯期。系统⼀次调⽤的响应时间跟项⽬计划⼀样，也有⼀条关键路径，这个关键路径是就是系统响应时间；关键路径是由CPU运算、IO、外部系统响应等等组成。计算公式1、响应时间：对⼀个请求做出响应所需要的时间⽹络传输时间：N1+N2+N3+N4应⽤服务器处理时间：A1+A3数据库服务器处理时间：A2响应时间=⽹络响应时间+应⽤程序响应时间=（N1+N2+N3+N4）+(A1+A2+A3)注：绝对不允许⽤⽣产环境，公司如果有准⽣产环境最好。从⽣产的集群⾥抽取⼀个单机拿出来专门做性能测试的独⽴服务器。但是其数据库数据和服务都彻底从集群中移出来，这样不影响⽣产环境正常业务发展。独⽴⽹络：就是必须使⽤⽹线有线连接，千万不要使⽤wifi，VPN，堡垒机（把两个⽹络连接起来的桥梁），最好是测试负载机和控制机在同⼀个⽹络⽽且都是独⽴的局域⽹⾥直接路由跳出去访问外⽹的服务器。否则⽹速会严重影响数据的传输和加载，会出现数据包丢失严重的现象。最主要的是严重影响响应时间的指标值，偏差太⼤，没有参考价值。2、平均响应时间：所有请求花费的平均时间系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页⾯，⼀般响应时间为3秒左右。如：如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms平均响应时间： (98 * 1 + 2 * 100) / 100.0 = 2.98ms，但是，2.98ms并不能反映服务器的整体效率，因为98个请求耗时才1ms，引申出百分位数百分位数：以响应时间为例，指的是 99% 的请求响应时间，都处在这个值以下，更能体现整体效率。注：（⼀般响应时间在3s内，⽤户会感觉⽐较满意。在3s~8s之间⽤户勉强能接受，⼤于8s⽤户就可能⽆法接受，从⽽刷新页⾯或者离开，仅供参考）响应时间与负载对应关系图中拐点说明：（1）响应时间突然增加（2）意味着系统的⼀种或多种资源利⽤达到的极限（3）通常可以利⽤拐点来进⾏性能测试分析与定位并发⽤户数⼀、⾸先涉及到并发⽤户数可以从以下⼏个⽅⾯去做数据判断。1.系统⽤户数2.在线⽤户数3.并发⽤户数⼆、三者之间的关系1.在线⽤户数的预估可以采取20%的系统⽤户数。例如某个系统在系统⽤户数有1000，则同时在线⽤户数据有可能达到200，或者预估200做参考。2.在线⽤户数和并发⽤户数⼜存在着关系。即：平均并发⽤户数为:c=NL/T L为在线时长，T为考核时长。例如:考核时长为1天，即8⼩时，但是⽤户平均在线时长为2⼩时，则c=n*2/8 n为登录系统的⽤户数，L为登录的时常。例如:⼀个系统有400个⽤户登录，然后每个⽤户登录⼤概停留2⼩时，则以⼀天8⼩时考核，算平均并发⽤户则为:c=400*2/8并发主要是针对服务器⽽⾔，在同⼀时刻与服务器进⾏交互（指向服务器发出请求）的在线⽤户数。（1）并发⽤户数：某⼀物理时刻同时向系统提交请求的⽤户数，提交的请求可能是同⼀个场景或功能，也可以是不同场景或功能。（2）在线⽤户数：某段时间内访问系统的⽤户数，这些⽤户并不⼀定同时向系统提交请求。如多个⽤户在浏览⽹页，但没有对同时对服务器进⾏数据请求，需要与并发⽤户数区分开。（3）系统⽤户数：系统注册的总⽤户数据 三者之间的关系：系统⽤户数 >= 在线⽤户数 >= 并发⽤户数同时在线⽤户数：在⼀定的时间范围内，最⼤的同时在线⽤户数量。同时在线⽤户数=每秒请求数RPS（吞吐量）+并发连接数+平均⽤户思考时间平均并发⽤户数的计算：C=nL / T其中C是平均的并发⽤户数，n是平均每天访问⽤户数（login session），L是⼀天内⽤户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（⼀天内多长时间有⽤户使⽤系统）并发⽤户数峰值计算：C^约等于C + 3*根号C 也是峰值C1,即最⼤并发数，计算公式C1=C+³√C其中C^是并发⽤户峰值，C是平均并发⽤户数，该公式遵循泊松分布理论。注：理解最佳并发⽤户数和最⼤并发⽤户数
看了《LoadRunner没有告诉你的》之理发店模式，对最佳并发⽤户数和最⼤的并发⽤户数的理解⼩⼩整理了⼀下。所谓的理发店模式，简单地阐述⼀下，⼀个理发店有3个理发师，当同时来理发店的客户有3个的时候，那么理发师的资源能够有效地利⽤，这时3个⽤户数即为最佳的并发⽤户数；当理发店来了9个客户的时候，3个客户理发，⽽6个⽤户在等待，3个客户的等待时间为1个⼩时，另外的3个客户的等待时间为2⼩时，客户的最⼤忍受时间为3⼩时包括理发的1个⼩时，所以6个客户的等待时间都在客户的可以承受范围内，故9个客户是该理发店的最⼤并发⽤户数。吞吐量我把吞吐量定义为“单位时间内系统处理的客户请求的数量”（ 吞吐量表⽰单位时间内能够完成的事务数量，因此也被称为每秒事务数（Transaction Per Second），计算⽅式是完成的事务数除以时间。），直接体现软件系统的性能承载能⼒，对于交互式应⽤系统来说、吞吐量反映的是服务器承受的压⼒、在容量规划的测试中、吞吐量是⼀个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。吞吐量的指标受到响应时间、服务器软硬件配置、⽹络状态等多⽅⾯因素影响。吞吐量越⼤，响应时间越长。服务器硬件配置越⾼，吞吐量越⼤。⽹络越差，吞吐量越⼩。在低吞吐量下的响应时间的均值、分布⽐较稳定，不会产⽣太⼤的波动。在⾼吞吐量下，响应时间会随着吞吐量的增长⽽增长，增长的趋势可能是线性的，也可能接近指数的。当吞吐量接近系统的峰值时，响应时间会出现激增。系统吞度量要素 ⼀个系统的吞度量（承压能⼒）与request对CPU的消耗、外部接⼝、IO等等紧密关联。单个reqeust 对CPU消耗越⾼，外部系统接⼝、IO影响速度越慢，系统吞吐能⼒越低，反之越⾼。系统吞吐量⼏个重要参数：QPS（TPS）、并发数、响应时间QPS(每秒请求数)（TPS （Transaction Per Second）每秒事务数）：每秒钟系统处理的request/事务 数量，它是衡量系统处理能⼒的重要指标；并发数：系统同时处理的request/事务数响应时间：⼀般取平均响应时间理解了上⾯三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间 ⼀个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有⼀个相对极限值，在应⽤场景访问压⼒下，只要某⼀项达到系统最⾼值，系统的吞吐量就上不去了，如果压⼒继续增⼤，系统的吞吐量反⽽会下降，原因是系统超负荷⼯作，上下⽂切换、内存等等其它消耗导致系统性能下降。系统吞吐量评估我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。⽽通常境况下，我们⾯对需求，我们评估出来的QPS、并发数之外，还有另外⼀个维度：⽇页⾯流量PV。PV：访问⼀个URL，产⽣⼀个PV（Page View，页⾯访问量），每⽇每个⽹站的总PV量是形容⼀个 ⽹站规模的重要指标。通过观察系统的访问⽇志发现，在⽤户量很⼤的情况下，各个时间周期内的同⼀时间段的访问流量⼏乎⼀样。只要能拿到⽇流量图和QPS我们就可以推算⽇流量。通常的技术⽅法：1. 找出系统的最⾼TPS和⽇PV，这两个要素有相对⽐较稳定的关系（除了放假、季节性因素影响之外）2. 通过压⼒测试或者经验预估，得出最⾼TPS，然后跟进1的关系，计算出系统最⾼的⽇吞吐量。⽆论有⽆思考时间（T_think），测试所得的TPS值和并发虚拟⽤户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运⾏情况下）：TPS=U_concurrent / (T_response+T_think)。并发数、QPS、平均响应时间三者之间关系
X轴代表并发⽤户数，Y轴代表资源利⽤率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压⼒区、重压⼒区、拐点区。随着并发⽤户数的增加，在轻压⼒区的响应时间变化不⼤，⽐较平缓，进⼊重压⼒区后呈现增长的趋势，最后进⼊拐点区后倾斜率增⼤，响应时间急剧增加。接着看吞吐量，随着并发⽤户数的增加，吞吐量增加，进⼊重压⼒区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。同理，随着并发⽤户数的增加，资源利⽤率逐步上升，最后达到饱和状态。最后，把所有指标融合到⼀起来分析，随着并发⽤户数的增加，吞吐量与资源利⽤率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于⽐较好的状态。但随着并发⽤户数的持续增加，压⼒也在持续加⼤，吞吐量与资源利⽤率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压⼒区与重压⼒区的交界点是系统的最佳并发⽤户数，因为各种资源都利⽤充分，响应也很快；⽽重压⼒区与拐点区的交界点就是系统的最⼤并发 ⽤户数，因为超过这个点，系统性能将会急剧下降甚⾄崩溃。Light Load（较轻压⼒）-----最佳⽤户数（资源利⽤最⾼）---（较重压⼒，系统可以持续⼯作，但⽤户等待时间较长，满意度会下降）-----Heavy Load-------最⼤并发⽤户数--------Buckle Zone（⽤户⽆法忍受⽽放弃请求）最佳并发⽤户数：当系统的负载等于最佳并发⽤户数时，系统的整体效率最⾼，没有资源被浪费，⽤户也不需要等待 最⼤并发⽤户数：系统的负载⼀直持续，有些⽤户在处理⽽有的⽤户在⾃⼰最⼤的等待时间内等待的时候我们需要保证的是：（1）最佳并发⽤户数需⼤于系统的平均负载（2）系统的最⼤并发⽤户数要⼤于系统需要承受的峰值负载怎么理解这两句话呢？（1）系统的平均负载：在特定的时间内，系统正在处理的⽤户数和等待处理的⽤户数的总和如果系统的平均负载⼤于最佳并发⽤户数，则⽤户的满意度会下降，所以我们需要保证系统的平均负载⼩于或者等于最佳并发⽤户数（2）峰值：指的是系统的最⼤能承受的⽤户数的极值只有最⼤并发⽤户数⼤于系统所能承受的峰值负载，才不会造成等待空间资源的浪费，导致系统的效率低下计算公式指单位时间内系统处理⽤户的请求数从业务⾓度看，吞吐量可以⽤：请求数/秒、页⾯数/秒、⼈数/天或处理业务数/⼩时等单位来衡量从⽹络⾓度看，吞吐量可以⽤：字节/秒来衡量对于交互式应⽤来说，吞吐量指标反映的是服务器承受的压⼒，他能够说明系统的负载能⼒以不同⽅式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒⽅式可以表⽰数要受⽹络基础设施、服务器架构、应⽤服务器制约等⽅⾯的瓶颈；已请求数/秒的⽅式表⽰主要是受应⽤服务器和应⽤代码的制约体现出的瓶颈。当没有遇到性能瓶颈的时候，吞吐量与虚拟⽤户数之间存在⼀定的联系，可以采⽤以下公式计算：F=VU * R /T其中F为吞吐量，VU表⽰虚拟⽤户个数，R表⽰每个虚拟⽤户发出的请求数，T表⽰性能测试所⽤的时间
吞吐量与负载对应关系图中拐点说明：（1）吞吐量逐渐达到饱和（2）意味着系统的⼀种或多种资源利⽤达到的极限（3）通常可以利⽤拐点来进⾏性能测试分析与定位错误率超时错误率：主要指事务由于超时或系统内部其它错误导致失败占总事务的⽐率。错误率和服务的具体实现有关。通常情况下，由于⽹络超时等外部原因造成的错误⽐例不应超过5%%，由于服务本⾝导致的错误率不应超过1% 。内部指标|资源指标（与硬件资源消耗相关指标） 资源利⽤率：资源利⽤率指的是对不同系统资源的使⽤程度，⼀般使⽤“资源实际使⽤/总的资源可⽤量”形成资源利⽤率。例如服务器的CPU 利⽤率、磁盘利⽤率等。资源利⽤率是分析系统性能指标进⽽改善性能的主要依据，因此，它是 Web 性能测试⼯作的重点。资源利⽤率主要针对 Web 服务器、操作系统、数据库服务器、⽹络等，是测试和分析瓶颈的主要参数。在性能测试中，要根据需要采集具体的资源利⽤率参数来进⾏分析。从服务器的⾓度看，性能测试主要关注CPU、内存、服务器负载、⽹络、磁盘IO等1.硬件性能指标：CPU，内存Memory，磁盘I/O（Disk I/O），⽹络I/O（Network I/O）CPU：主要解释计算机指令以及处理计算机软件中的数据Linux系统中top命令查看CPU的使⽤率CPU的利⽤率（<=75%）有：user（⽤户使⽤）,sys（系统调⽤<=30%）,wait（等待<=5%），idle（空闲）当user消耗⾼时，通过top命令查看哪个⽤户进程占⽤cpu的使⽤user消耗过⾼的原因可能有:（1）代码问题。如代码中耗时循环中不加sleep，即例如while的死循环中，没有加sleep时间，导致没有空余的时间将cpu的控制权给其他的进程，⼀直陷⼊该死循环中，cpu得不到休息，所以usr的消耗过⾼，则cpu的消耗⾼（2）gc频繁。gc则为垃圾回收，由于垃圾回收也是需要⼤量的计算，也消耗cpu，所以当gc频繁时也导致usr⽤户空间的消耗也过⾼，cpu消耗过⾼当sys消耗⾼时，通过top命令查看系统调⽤资源的情况sys消耗过⾼的原因可能有：（1）上下⽂切换频繁。上下⽂切换发⽣的情况有：中断处理，多任务处理，⽤户状态改变。中断处理，当cpu停⽌处理当前的进程转⽽处理中断请求的进程时发⽣上下⽂切换。多任务处理则为有多个进程请求cpu的处理，进程的数量多于cpu的核数，则分配进程时间⽚，根据时间⽚处理进程，意味着会强制停⽌⼀个进程⽽去处理另⼀个进程，形成频繁的上下⽂切换。⽤户状态改变则为user状态与sys状态的改变。wait较⾼时，即等待的进程占⽐⾼则可以考虑是否磁盘读写，磁盘瓶颈问题， 等待的进程较多时，cpu⽆论如何切换都是切换到等待的进程，导致cpu⼀直在频繁切换等待的线程⽽利⽤率较低内存：与cpu沟通的桥梁，计算机中所有程序的运⾏都在内存中进⾏，内存分为物理内存、页⾯交换（Paging），SWAP内存（虚拟内存）页⾯交换：当物理内存即实际的内存满了的时候，将物理内存中不常⽤的进程调出存储到虚拟内存中，以缓解物理内存空间的压⼒，所以当物理内存与虚拟内存的数据交换频繁的时候，这时候就要关注下内存的性能情况。SWAP内存：为进程分配虚拟的内存空间，即调⽤硬盘的空间作为内存使⽤。内存的性能分析是⼜可⽤内存与页⾯交换来分析的，可⽤内存使⽤占70%-80%为上限，当超出这个数值，内存性能情况就⽐较危险，⽽且即使可⽤内存使⽤不超过80%的数值时，页⾯交换⽐较频繁时，也是要关注下内存情⼀般物理内存即使是满内存也不能代表内存出现问题，主要是看虚拟内存swap，虚拟内存应该<=70%，⼤于则可以考虑是否内存问题或者内存泄漏磁盘吞吐量，指单位时间内通过磁盘的数据量。主要关注磁盘的繁忙率，如果⾼于70%，则磁盘瓶颈⽹络吞吐量，指单位时间内通过⽹络的数据量，当吞吐量⼤于⽹路设备或链路最⼤传输能⼒，即带宽时，则应该考虑升级⽹络设备或者增加带宽，Linux命令netstate⽹络IO也有可能出现终⽌连接失败。例如当服务端出现⼤量的TIME_WAIT，见以下TCP终⽌连接的第4个步骤，在主动发起关闭连接⽅接收到结束符FIN时状态变为TIME_WAIT,这时在服务端发现⼤量的TIME_WAIT,意味着关闭连接是由服务端发起的。常⽤的三个状态是：ESTABLISHED 表⽰正在通信，TIME_WAIT 表⽰主动关闭，CLOSE_WAIT 表⽰被动关闭。问？什么情况是由服务端发起关闭连接？答：在⽤户端的应⽤程序忘记关闭连接另外如果在服务端发现⼤量状态CLOSE_WAIT,则说明第⼆次关闭回不去，也就是TCP关闭连接的第三个步骤没有执⾏，停留在CLOSE_WAIT的状态，浏览器如果这时发起请求则会返回超时连接，因为服务端这边⼀直⽆法进⾏第⼆次关闭，将结束符返回去给⽤户端。注：普及TCP连接的三次握⼿，终⽌连接的四次握⼿TCP三次握⼿连接：(1)⽤户端发送SYN给服务器，⽤户端的状态为SYN_SEND(2)服务端接收到后发送ACK给⽤户端，服务端的状态为SYN_RECV(3)⽤户端接收到服务端发送过来的后发送了ACK给服务端，⽤户端的状态变为EstabilishedTCP终⽌连接：(1)⽤户端的应⽤主动发起关闭连接，即应⽤调⽤close发送FIN给服务端(2)服务端接收到FIN后发送ACK给⽤户端，服务端的状态变为CLOSE_WAIT(3)服务端发送ACK给⽤户端的同时也将FIN作为⼀个⽂件结束符传递给接收端应⽤程序(4)⽤户端的应⽤程序接收到FIN后将调⽤close关闭它的套接字，确认FIN，这时⽤户端的状态变为TIME_WAIT(5)⽤户端发送ACK回执给服务端，连接终⽌2.中间件：常⽤的中间件例如web服务器Tomcat,Weblogic web服务器，JVM（java虚拟机），ThreadPool线程池，JDBC数据驱动注：http服务器和web服务器与应⽤服务器的差别是⼀个存储静态⽹页的服务器，⼀个是存储css，js等动态加载⽹页的服务器，⽽tomcat则属于应⽤服务器注：对中间件例如对服务器的性能测试，需要将监控的jmeter-server的⽂件下载在服务端上，然后开启即可监控被测服务器的性能，或者将监控的软件下载在被测服务器上，远程启动监控软件等3.数据库指标应关注SQL，吞吐量，缓存命中率，连接数等，则是关注sql语句执⾏时间，以微妙为单位，吞吐量TPS，缓存命中率应>=95%注：对数据库的性能测试通过jemter利⽤批量的sql语句对数据库进⾏操作，从⽽测试数据库的性能，前提是需要将jdbc的驱动加载在测试计划添加的驱动⽂件中，然后添加jdbc的前置处理器和jdbc的请求sample。，java虚拟机，为使java的代码可以编译运⾏在不同的平台上顺畅，仿真模拟各种计算机来实现GC：⾃动内存管理程序，被引⽤的对象保存在内存中，当对象不被引⽤时则释放。关注的参数有Full GC完全java虚拟机垃圾部分回收频率5.前端指标前端应该关注页⾯展⽰，即⾸次显⽰时间，页⾯数量，页⾯⼤⼩，⽹络startRender，firstRender等注：关注前端的性能与后端的性能的不同点在于，前端是每个⽤户的直观的感受，以及前端页⾯的加载元素耗费时间给予⽤户的感受，⽽后端的性能关注点在于多⽤户使⽤系统时，服务器是否能够承受或者服务器的处理能⼒如何，能否以较好的响应时间响应。：系统平均负载，特定时间间隔内运⾏进程数，Load与cpu核数⼀致CPUCPU使⽤率：指⽤户进程与系统进程消耗的CPU时间百分⽐，长时间情况下，⼀般可接受上限不超过85%。后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利⽤率对服务的性能起着决定性的作⽤。Linux系统的CPU主要有如下⼏个维度的统计数据：us：⽤户态使⽤的cpu时间百分⽐sy：系统态使⽤的cpu时间百分⽐ni：⽤做nice加权的进程分配的⽤户态cpu时间百分⽐id：空闲的cpu时间百分⽐wa：cpu等待IO完成时间百分⽐hi：硬中断消耗时间百分⽐si：软中断消耗时间百分⽐下图是线上开放平台转发服务某台服务器上top命令的输出，下⾯以这个服务为例对CPU各项指标进⾏说明
us & sy：⼤部分后台服务使⽤的CPU时间⽚中us和sy的占⽤⽐例是最⾼的。同时这两个指标⼜是互相影响的，us的⽐例⾼了，sy的⽐例就低，反之亦然。通常sy⽐例过⾼意味着被测服务在⽤户态和系统态之间切换⽐较频繁，此时系统整体性能会有⼀定下降。另外，在使⽤多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使⽤率过⾼会导致其他CPU核⼼之间的调度效率变低。因此测试过程中CPU0需要重点关注。ni：每个Linux进程都有个优先级，优先级⾼的进程有优先执⾏的权利，这个叫做pri。进程除了优先级外，还有个优先级的修正值。这个修正值就叫做进程的nice值。⼀般来说，被测服务和服务器整体的ni值不会很⾼。如果测试过程中ni的值⽐较⾼，需要从服务器Linux系统配置、被测服务运⾏参数查找原因id：线上服务运⾏过程中，需要保留⼀定的id冗余来应对突发的流量激增。在性能测试过程中，如果id⼀直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。wa：磁盘、⽹络等IO操作会导致CPU的wa指标提⾼。通常情况下，⽹络IO占⽤的wa资源不会很⾼，⽽频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务，那需要检查被测服务的⽇志量、数据载⼊频率等。hi & si：硬中断是外设对CPU的中断，即外围硬件发给CPU或者内存的异步信号就是硬中断信号；软中断由软件本⾝发给操作系统内核的中断信号。通常是由硬中断处理程序或进程调度程序对操作系统内核的中断，也就是我们常说的系统调⽤(System Call)。在性能测试过程中，hi会有⼀定的CPU占⽤率，但不会太⾼。对于IO密集型的服务，si的CPU占⽤率会⾼⼀些。内存内存利⽤率：内存利⽤率=（1-空闲内存/总内存⼤⼩）*100%，⼀般⾄少有10%可⽤内存，内存使⽤率可接受上限为85%。性能测试过程中对内存监控的主要⽬的是检查被测服务所占⽤内存的波动情况。在Linux系统中有多个命令可以获取指定进程的内存使⽤情况，最常⽤的是top命令，如下图所⽰
其中VIRT：进程所使⽤的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页⾯，所有已申请的总内存空间RES：进程正在使⽤的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值SHR：进程使⽤共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使⽤SWAP：进程使⽤的虚拟内存中被换出的⼤⼩，交换的是已经申请，但没有使⽤的空间，包括（栈、堆、共享内存）DATA：进程除可执⾏代码以外的物理内存总量，即进程栈、堆申请的总空间从上⾯的解释可以看出，测试过程中主要监控RES和VIRT，对于使⽤了共享内存的多进程架构服务，还需要监控SHR。LOAD（服务器负载）Linux的系统负载指运⾏队列的平均长度，也就是等待CPU的平均进程数从服务器负载的定义可以看出，服务器运⾏最理想的状态是所有CPU核⼼的运⾏队列都为1，即所有活动进程都在运⾏，没有等待。这种状态下服务器运⾏在负载阈值下。通常情况下，按照经验值，服务器的负载应位于阈值的70%~80%，这样既能利⽤服务器⼤部分性能，⼜留有⼀定的性能冗余应对流量增长。Linux提供了很多查看系统负载的命令，最常⽤的是top和uptimetop和uptime针对负载的输出内容相同，都是系统最近1分钟、5分钟、15分钟的负载均值
Uptime命令结果的每⼀列的含义如下：“当前时间 系统运⾏时长 登录的⽤户数最 近1分钟、5分钟、15分钟的平均负载”查看系统负载阈值的命令如下，下⽅是查看CPU每个核⼼的使⽤情况：
在性能测试过程中，系统负载是评价整个系统运⾏状况最重要的指标之⼀。通常情况下，压⼒测试时系统负载应接近但不能超过阈值，并发测试时的系统负载最⾼不能超过阈值的80%，稳定性测试时，系统负载应在阈值的50%左右。⽹络⽹络带宽：⼀般使⽤计数器Bytes Total/sec来度量，Bytes Total/sec表⽰为发送和接收字节的速率，包括帧字符在内。判断⽹络连接速度是否是瓶颈，可以⽤该计数器的值和⽬前⽹络的带宽⽐较。性能测试中⽹络监控主要包括⽹络流量、⽹络连接状态的监控。⽹络流量监控可以使⽤nethogs命令。该命令与top类似，是⼀个实时交互的命令，运⾏界⾯如下
在后台服务性能测试中，对于返回⽂本结果的服务，并不需要太多关注在流量⽅⾯。⽹络连接状态监控性能测试中对⽹络的监控主要是监控⽹络连接状态的变化和异常。对于使⽤TCP协议的服务，需要监控服务已建⽴连接的变化情况（即ESTABLISHED状态的TCP连接）。对于HTTP协议的服务，需要监控被测服务对应进程的⽹络缓冲区的状态、TIME_WAIT状态的连接数等。Linux⾃带的很多命令如netstat、ss都⽀持如上功能。下图是netstat对指定pid进程的监控结果磁盘IO 磁盘主要⽤于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是读IO操作，⼀般使⽤% Disk Time（磁盘⽤于读写操作所占⽤的时间百分⽐）度量磁盘读写性能。性能测试过程中，如果被测服务对磁盘读写过于频繁，会导致⼤量请求处于IO等待的状态，系统负载升⾼，响应时间变长，吞吐量下降。Linux下可以⽤iostat命令来监控磁盘状态，如下图
tps：该设备每秒的传输次数。“⼀次传输”意思是“⼀次I/O请求”。多个逻辑请求可能会被合并为“⼀次I/O请求”。“⼀次传输”请求的⼤⼩是未知的kB_read/s：每秒从设备（driveexpressed）读取的数据量，单位为KilobyteskB_wrtn/s：每秒向设备（driveexpressed）写⼊的数据量，单位为KilobyteskB_read：读取的总数据量，单位为KilobyteskB_wrtn：写⼊的总数量数据量，单位为Kilobytes从iostat的输出中，能够获得系统运⾏最基本的统计数据。但对于性能测试来说，这些数据不能提供更多的信息。需要加上-x参数
rrqm/s：每秒这个设备相关的读取请求有多少被合并了（当系统调⽤需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）wrqm/s：每秒这个设备相关的写⼊请求有多少被Merge了await：每⼀个IO请求的处理的平均时间（单位是毫秒）%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，⽽0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，该参数暗⽰了设备的繁忙程度。资源利⽤与负载对应关系图中拐点说明：（1）服务器某⼀资源使⽤逐渐达到饱和（2）通常可以利⽤拐点来进⾏性能测试分析与定位性能计数器（counters）是描述服务器或操作系统性能的⼀些数据指标，如使⽤内存数、进程时间，在性能测试中发挥着“监控和分析”的作⽤，尤其是在分析系统可扩展性、进⾏新能瓶颈定位时有着⾮常关键的作⽤。常见性能瓶颈吞吐量到上限时系统负载未到阈值：⼀般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因CPU的us和sy不⾼，但wa很⾼：如果被测服务是磁盘IO密集型型服务，wa⾼属于正常现象。但如果不是此类服务，最可能导致wa⾼的原因有两个，⼀是服务对磁盘读写的业务逻辑有问题，读写频率过⾼，写⼊数据量过⼤，如不合理的数据载⼊策略、log过多等，都有可能导致这种问题。⼆是服务器内存不⾜，服务在swap分区不停的换⼊换出。同⼀请求的响应时间忽⼤忽⼩：在正常吞吐量下发⽣此问题，可能的原因有两⽅⾯，⼀是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了⼤量的时间等待资源解锁；⼆是Linux本⾝分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执⾏。内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使⽤valgrind等内存检查⼯具进⾏定位。性能瓶颈定位之拐点分析法 “拐点分析”⽅法是⼀种利⽤性能计数器曲线图上的拐点进⾏性能分析的⽅法。它的基本思想就是性能产⽣瓶颈的主要原因就是因为某个资源的使⽤达到了极限，此时表现为随着压⼒的增⼤，系统性能却出现急剧下降，这样就产⽣了“拐点”现象。当得到“拐点”附近的资源使⽤情况时，就能定位出系统的性能瓶颈。软件性能的其它术语思考时间的计算公式Think Time，从业务⾓度来看，这个时间指⽤户进⾏操作时每个请求之间的时间间隔，⽽在做新能测试时，为了模拟这样的时间间隔，引⼊了思考时间这个概念，来更加真实的模拟⽤户的操作。在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个⽤户发出的请求数R和时间T的函数，⽽其中的R⼜可以⽤时间T和⽤户思考时间TS来计算：R = T / TS下⾯给出⼀个计算思考时间的⼀般步骤：1、⾸先计算出系统的并发⽤户数C=nL / T F=R×C2、统计出系统平均的吞吐量F=VU * R / T R×C = VU * R / T3、统计出平均每个⽤户发出的请求数量R=u*C*T/VU4、根据公式计算出思考时间TS=T/R软件性能的影响因素（1）硬件设施（部署结构、机器配置）（2）⽹络环境（客户端带宽、服务器端带宽）（3）操作系统（类型、版本、参数配置）（4）中间件（类型、版本、参数配置）（5）应⽤程序（性能）（6）并发⽤户数（系统当前访问状态）（7）客户端（8）数据服务器（9）编程语⾔、程序实现⽅式、算法软件性能的关注点
⾸先，开发软件的⽬的是为了让⽤户使⽤，我们先站在⽤户的⾓度分析⼀下，⽤户需要关注哪些性能。对于⽤户来说，当点击⼀个按钮、链接或发出⼀条指令开始，到系统把结果已⽤户感知的形式展现出来为⽌，这个过程所消耗的时间是⽤户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较⼩时，⽤户体验是很好的，当然⽤户体验的响应时间包括个⼈主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到⽤户最佳的体验。如：⽤户在⼤数据量查询时，我们可以将先提取出来的数据展⽰给⽤户，在⽤户看的过程中继续进⾏数据检索，这时⽤户并不知道我们后台在做什么。⽤户关注的是⽤户操作的响应时间。
其次，我们站在管理员的⾓度考虑需要关注的性能点。1、 响应时间2、 服务器资源使⽤情况是否合理3、 应⽤服务器和数据库资源使⽤是否合理4、 系统能否实现扩展5、 系统最多⽀持多少⽤户访问、系统最⼤业务处理量是多少6、 系统性能可能存在的瓶颈在哪⾥7、 更换那些设备可以提⾼性能8、 系统能否⽀持7×24⼩时的业务访问再次，站在开发（设计）⼈员⾓度去考虑。1、 架构设计是否合理2、 数据库设计是否合理3、 代码是否存在性能⽅⾯的问题4、 系统中是否有不合理的内存使⽤⽅式5、 系统中是否存在不合理的线程同步⽅式6、 系统中是否存在不合理的资源竞争那么站在性能测试⼯程师的⾓度，我们要关注什么呢？ ⼀句话，我们要关注以上所有的性能点。
性能测试的核⼼原理性能测试的核⼼原理，开发测试⼯具也是基于前两点：1、基于协议（前端后端通信机制），基于界⾯（决定和前端交互），基于代码（后端）。基于⽹络的分布式架构：基于⽹络协议去模拟⽤户发送请求；2、多线程：模拟多线程操作，多⼈同时操作，模拟⼤负载量（功能测试在于⽤以测试功能）；3、模拟真实场景：真实的⽹络环境，⽤户操作时间不确定性，操作不确定，得出的数据是准确的，场景不对，数据也不⼀定可⽤。性能问题分析原则
性能测试原则1）情况许可时，应使⽤⼏种测试⼯具或⼿段分别独⽴进⾏测试，并将结果相互印证，避免单⼀⼯具或测试⼿段⾃⾝缺陷影响结果的准确性；2）对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；3）查找瓶颈的过程应由易到难逐步排查： 服务器硬件瓶颈及⽹络瓶颈（局域⽹环境下可以不考虑⽹络因素） 应⽤服务器及中间件操作系统瓶颈（数据库、WEB服务器等参数配置） 应⽤业务瓶颈（SQL语句、数据库设计、业务逻辑、算法、数据等）4）性能调优过程中不宜对系统的各种参数进⾏随意的改动，应该以⽤户配置⼿册中相关参数设置为基础，逐步根据实际现场环境进⾏优化，⼀次只对某个领域进⾏性能调优（例如对CPU的使⽤情况进⾏分析），并且每次只改动⼀个设置，避免相关因素互相⼲扰；5）调优过程中应仔细进⾏记录，保留每⼀步的操作内容及结果，以便⽐较分析；6）性能调优是⼀个经验性的⼯作，需要多思考、分析、交流和积累；7）了解“有限的资源，⽆限的需求”；8）尽可能在开始前明确调优⼯作的终⽌标准。性能测试的注意要点
性能调优应该注意的要点
性能测试流程
⼀般企业会按照这个步骤去执⾏测试：先负载测试（逐步增加并发⽤户数来增加压⼒，只能找出性能指标的瓶颈范围，⽽不是具体的性能指标值），再性能测试（验证我们的性能指标的具体的值，即精确），最后压⼒测试。平时我们说的基准测试其实是在性能测试⾥的找出。压⼒测试：在⼀定的压⼒下，运⾏⽐较长的时间。⽬的是看服务器的稳定性。企业⼝语说的“压测”表达的是：要做负载测试和性能测试。
注：绝对不允许⽤⽣产环境，公司如果有准⽣产环境最好。从⽣产的集群⾥抽取⼀个单机拿出来专门做性能测试的独⽴服务器。但是其数据库数据和服务都彻底从集群中移出来，这样不影响⽣产环境正常业务发展。独⽴⽹络：就是必须使⽤⽹线有线连接，千万不要使⽤wifi，VPN，堡垒机（把两个⽹络连接起来的桥梁），最好是测试负载机和控制机在同⼀个⽹络⽽且都是独⽴的局域⽹⾥直接路由跳出去访问外⽹的服务器。否则⽹速会严重影响数据的传输和加载，会出现数据包丢失严重的现象。最主要的是严重影响响应时间的指标值，偏差太⼤，没有参考价值。TPS:服务器综合能⼒指标值，服务器最主要的指标值。吞吐量有个单位是：平均事务数/秒loadrunner和jmeter的TPS是有区别的，jmeter有两种每秒事务数。jmeter除了每个业务的请求到响应完成的统计外，还有事务逻辑控制器对多个单个业务请求打包成⼀个全链路业务流的业务的请求到响应完成的统计等。性能测试不是去找功能上的bug，是找出服务器的瓶颈。采⽤⾃动化负载测试⼯具执⾏的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执⾏跟踪，结果分析与定位问题所在，测试报告与测试评估。
⼀、性能测试需求分析 性能需求分析是整个性能测试⼯作开展的基础，如果连性能的需求都没弄清楚，后⾯的性能测试执⾏其实是没有任何意义的，⽽且性能需求分析做的好不好直接影响到性能测试的结果。 ⼀些性能测试⼈员常犯的错误就是测试⼀开始就直接⽤⼯具对系统进⾏加压，没有弄清楚性能测试的⽬的，稀⾥糊涂做完了以后也不知道结果是否满⾜性能需求。市⾯上的书籍也⼤都是直接讲性能测试⼯具如LR，jmeter如何使⽤，导致很多新⼿⼀提到性能测试就直接拿⼯具来进⾏录制回放，使得很多⼈认为会使⽤性能测试⼯具就等于会性能测试了，殊不知⼯具其实只是性能测试过程中很⼩的⼀部分。 在需求分析阶段，测试⼈员需要与项⽬相关的⼈员进⾏沟通，收集各种项⽬资料，对系统进⾏分析，建⽴性能测试数据模型，并将其转化为可衡量的具体性能指标，确认测试的⽬标。所以性能测试需求分析过程是繁杂的，需要测试⼈员有深厚的性能理论知识，除此之外还需要懂⼀些数学建模的知识来帮助我们建⽴性能测试模型。⾸先，让我们来看看通过性能需求分析我们需要得出哪些结论或⽬标：明确倒底要不要做性能测试？性能测试的⽬的是什么？明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等明确被测系统的基本业务、关键业务，⽤户⾏为明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，⼜是为什么？明确被测系统未来的业务拓展规划以及性能需求？明确性能测试策略，即应该怎么测试？明确性能测试的指标，知道测试出来的结果怎么算通过？其次，需求分析阶段我们可以从以下⼏个⽅⾯⼊⼿：1、系统信息调研： 指对被测试系统进⾏分析，需要对其有全⾯的了解和认识，这是我们做好性能测试的前提，⽽且在后续进⾏性能分析和调优时将会⼤有⽤处，试想如果连系统的架构、协议都不了解，我们如何进⾏准确的性能测试？如果进⾏性能分析与调优？ 需要分析的系统信息如下（包括但不仅限于如下这些）：
2、业务信息调研： 指对被测试的业务进⾏分析，通过对业务的分析和了解，⽅便我们后续进⾏性能测试场景的确定以及性能测试指标的确定。 需要分析的业务信息如下（包括但不仅限于如下这些）：
3、性能需求评估： 在实施性能测试之前，我们需要对被测系统做相应的评估，主要⽬的是明确是否需要做性能测试。如果确定需要做性能测试，需要进⼀步确⽴性能测试点和指标，明确该测什么、性能指标是多少，测试通过or不通过的标准？性能指标也会根据情况评估，要求被测系统能满⾜将来⼀定时间段的业务压⼒。 判断是否进⾏性能测试主要从下⾯两个⽅⾯进⾏思考：业务⾓度: 系统是公司内部 or 对外？系统使⽤的⼈数的多少？如果⼀个系统上线后基本没⼏个⼈使⽤，⽆论系统多⼤，设计多么复杂，并发性的性能测试都是没必要的，前期可以否决。当然，除⾮在功能测试阶段发现⾮常明显的性能问题，使得⽤户体验较差的，此时可进⾏性能测试来排查问题。系统⾓度：系统⼜可以从以下3个⽅⾯进⾏分析 a）系统架构： 如果⼀个系统采⽤的框架是⽼的系统框架（通常⼤公司都有⾃⼰的统⼀框架），只是在此框架上增加⼀些应⽤，其实是没有必要做性能测试，因为⽼框架的使⽤肯定是经过了验证的。如果⼀个系统采⽤的是⼀种新的框架，可以考虑做性能测试。 b）数据库要求： 很多情况下，性能测试是⼤数据量的并发访问、修改数据库，⽽瓶颈在于连接数据库池的数量，⽽⾮数据库本⾝的负载、吞吐能⼒。这时，可以结合DBA的建议，来决定是否来做性能测试。 c）系统特殊要求： 从实时性⾓度来分析，某些系统对响应时间要求⽐较，⽐如证券系统，系统的快慢直接影响客户的收益，这种情况就有作并发测试的必要，在⼤并发量的场景下，查看这个功能的响应时间。 从⼤数据量上传下载⾓度分析，某些系统经常需要进⾏较⼤数据量的上传和下载操作，虽然此种操作使⽤的⼈数不会太多，但是也有必要进⾏性能测试，确定系统能处理的最⼤容量，如果超过这个容量时系统需要进⾏相关控制，避免由于不⼈⼯误操作导致系统内存溢出或崩溃。4、确定性能测试点：
在上⾯第3点中，我们简单分析了如何确定⼀个系统是否需要做性能测试。下⾯简单总结下如果⼀个系统确定要做性能测试，我们如何确定被测系统的性能测试点？ 我们可以从下⾯⼏个⽅⾯进⾏分析：关键业务： 确定被测项⽬是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易相关的功能点。例如转账，扣款等接⼝。如果项⽬（或功能点）不属于关键业务（或关键业务点），则可转⼊下⾯。⽇请求量： 确定被测项⽬各功能点的⽇请求量（可以统计不同时间粒度下的请求量如：⼩时，⽇，周，⽉）。如果⽇请求量很⾼，系统压⼒很⼤，⽽且⼜是关键业务，该项⽬需要做性能测试，⽽且关键业务点，可以被确定为性能点。逻辑复杂度： 判定被测项⽬各功能点的逻辑复杂度。如果⼀个主要业务的⽇请求量不⾼，但是逻辑很复杂，则也需要通过性能测试。原因是，在分布式⽅式的调⽤中，当某⼀个环节响应较慢，就会影响到其它环节，造成雪崩效应。运营推⼴活动： 根据运营的推⼴计划来判定待测系统未来的压⼒。未⾬绸缪、防患于未然、降低运营风险是性能测试的主要⽬标。被测系统的性能不仅能满⾜当前压⼒，更需要满⾜未来⼀定时间段内的压⼒。因此，事先了解运营推⼴计划，对性能点的制定有很⼤的作⽤。例如，运营计划做活动，要求系统每天能⽀撑多少 PV、多少 UV，或者⼀个季度后，需要能⽀撑多⼤的访问量等等数据。当新项⽬（或功能点）属于运营重点推⼴计划范畴之内，则该项⽬（或功能点）也需要做性能测试。以上 4 点，是相辅相成、环环相扣的。在实际⼯作中应该具体问题具体分析。例如，当⼀个功能点不满⾜以上 4 点，但⼜属于资源⾼消耗（内存、CPU），也可列⼊性能测试点⾏列。注：PV：访问⼀个URL，产⽣⼀个PV（Page View，页⾯访问量），每⽇每个⽹站的总PV量是形容⼀个 ⽹站规模的重要指标。UV：作为⼀个独⽴的⽤户，访问站点的所有页⾯均算作⼀个UV（Unique Visitor，⽤户访问）5、确定性能指标：
性能需求分析⼀个很重要的⽬标就是需要确定后期性能分析⽤的性能指标，性能指标有很多，可以根据具体项⽬选取和设定，⽽具体的指标值则需要根据业务特点进⾏设定，本⽂不详细进⾏阐述，后续可考虑就此单独写⼀篇。⼆、性能测试准备1、测试环境准备：（见：四：测试脚本设计与开发） a）系统运⾏环境：这个通常就是我们的测试环境，有些时候需求⽐较多，做性能测试担⼼把环境搞跨了影响其它的功能测试，可能需要重新搭建⼀套专门⽤来做性能测试的环境。 b）执⾏机环境：这个就是⽤来⽣成负载的执⾏机，通常需要在物理机上运⾏，⽽物理机⼜是稀缺资源，所以我们每次做性能测试都需要提前准备好执⾏机环境。2、测试场景设计：（见：四：测试脚本设计与开发）根据性能需求分析来设计符合⽤户使⽤习惯的场景，场景设计的好不好直接影响到性能测试的效果。3、性能⼯具准备： a）负载⼯具：根据需求分析和系统特点选择合适的负载⼯具，⽐如LR、Jmeter或galting等 b）监控⼯具：准备性能测试时的服务器资源、JVM、数据库监控⼯具，以便进⾏后续的性能测试分析与调优。4、测试脚本准备：如果性能测试⼯具不能满⾜被测系统的要求或只能满⾜部分要求时，需要我们⾃⼰开发脚本配合⼯具进⾏性能测试。5、测试数据准备： a）负载测试数据：并发测试时需要多少数据？⽐如登录场景？ b）DB数据量⼤⼩：为了尽量符合⽣产场景，需要模拟线上⼤量数据情况，那么要往数据库⾥提前插⼊⼀定的数据量。这可能需要花费⼀些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表。6、性能测试团队组建：如果需要其它关联系统或专业⼈⼠如DBA配合的，也需要提前进⾏沟通。三、性能测试计划测试计划阶段最重要的是分析⽤户场景，确定系统性能⽬标。1、性能测试领域分析根据对项⽬背景，业务的了解，确定本次性能测试要解决的问题点；是测试系统能否满⾜实际运⾏时的需要，还是⽬前的系统在哪些⽅⾯制约系统性能的表现，或者，哪些系统因素导致系统⽆法跟上业务发展？确定测试领域，然后具体问题具体分析。2、⽤户场景剖析和业务建模根据对系统业务、⽤户活跃时间、访问频率、场景交互等各⽅⾯的分析，整理⼀个业务场景表，当然其中最好对⽤户操作场景、步骤进⾏详细的描述，为测试脚本开发提供依据。3、确定性能⽬标前⾯已经确定了本次性能测试的应⽤领域，接下来就是针对具体的领域关注点，确定性能⽬标（指标）；其中需要和其他业务部门进⾏沟通协商，以及结合当前系统的响应时间等数据，确定最终我们需要达到的响应时间和系统资源使⽤率等⽬标；⽐如：①登录请求到登录成功的页⾯响应时间不能超过2秒；②报表审核提交的页⾯响应时间不能超过5秒；③⽂件的上传、下载页⾯响应时间不超过8秒；④服务器的CPU平均使⽤率⼩于70%，内存使⽤率⼩于75%；⑤ 各个业务系统的响应时间和服务器资源使⽤情况在不同测试环境下，各指标随负载变化的情况等；web性能测试之响应时间4、制定测试计划的实施时间预设本次性能测试各⼦模块的起⽌时间，产出，参与⼈员等等。（1）明确测试范围（2）制订时间（进度）计划（3）制订成本计划（4）制订环境计划（5）测试⼯具规划（6）测试风险分析四、测试脚本设计与开发性能测试中，测试脚本设计与开发占据了很⼤的时间⽐测试重。1、测试环境设计本次性能测试的⽬标是需要验证系统在实际运⾏环境中的性能外，还需要考虑到不同的硬件配置是否会是制约系统性能的重要因素！因此在测试环境中，需要部署多个不同的测试环境，在不同的硬件配置上检查应⽤系统的性能，并对不同配置下系统的测试结果进⾏分析，得出最优结果（最适合当前系统的配置）。这⾥所说的配置⼤概是如下⼏类：①数据库服务器②应⽤服务器③负载模拟器④软件运⾏环境，平台测试环境测试数据，可以根据系统的运⾏预期来确定，⽐如需要测试的业务场景，数据多久执⾏⼀次备份转移，该业务场景涉及哪些表，每次操作数据怎样写⼊，写⼊⼏条，需要多少的测试数据来使得测试环境的数据保持⼀致性等等。可以在⾸次测试数据⽣成时，将其导出到本地保存，在每次测试开始前导⼊数据，保持⼀致性。2、测试场景设计通过和业务部门沟通以及以往⽤户操作习惯，确定⽤户操作习惯模式，以及不同的场景⽤户数量，操作次数，确定测试指标，以及性能监控等。3、测试⽤例设计确认测试场景后，在系统已有的操作描述上，进⼀步完善为可映射为脚本的测试⽤例描述，⽤例⼤概内容如下：⽤例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）⽤例条件：⽤户已登录、具有对应权限等。。。操作步骤：①进⼊对应页⾯。。。。。。②查询相关数据。。。。。。③勾选导出数据。。。。。。④修改上传数据。。。。。。PS：这⾥的操作步骤只是个例⼦，具体以系统业务场景描述；4、脚本和辅助⼯具的开发及使⽤按照⽤例描述，可利⽤⼯具进⾏录制，然后在录制的脚本中进⾏修改；⽐如参数化、关联、检查点等等，最后的结果使得测试脚本可⽤，能达到测试要求即可；PS：个⼈⽽⾔，建议尽量⾃⼰写脚本来实现业务操作场景，这样对个⼈技能提升较⼤；⼀句话：能写就绝不录制五、性能测试执⾏在这个阶段，只需要按照之前已经设计好的业务场景、环境和测试⽤例脚本，部署环境，执⾏测试并记录结果即可。 1、⼈⼯边执⾏边分析 通常我们做性能测试都是⼈⼯执⾏并随时观察系统运⾏的情况、资源的使⽤率等指标。性能测试的吸引⼒之⼀就在于它的不可预知性。当我们在做性能测试的时候，遇到跟预期不符的情况很正常，这个时候需要冷静的分析。但这个过程可能会很漫长，需要不断的调整系统配置或程序代码来定位问题，耗时耗⼈⼒。特别是在当前敏捷开发模式⽐较流⾏的⼤环境下，版本发布⾮常频繁且版本周期短（通常1~2周⼀个版本），没有那么长的时间来做性能测试。2、⽆⼈值守执⾏性能测试 ⽆⼈值守是最理想化的⽬标，⽬前我们也朝着这个⽅向努⼒。⽆⼈值守不是说没有⼈⼒介⼊，⽽是把⼈为的分析和执⾏过程分离，执⾏过程只是机器服从指令的运⾏⽽已。通常测试环境在⽩天⽐较繁忙，出现性能问题及定位难度较⼤且会影响功能测试。所以⼀般性能测试最好在晚上或周末进⾏，在相对较安静的条件有利于测试结果的稳定性。这种⽅法也相对⽐较适合敏捷的模式，不需要⼈⼯⼀直守着。只需要在拿到结果后进⾏分析就好了。同时，这种⽅式对测试⼈员能⼒的要求⽐较⾼，需要我们能进⾏⾃动化的收集各种监控数据、⽣成报表便于后续分析。六、结果分析与调优1、测试环境的系统性能分析根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进⾏对⽐，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据进⾏具体情况具体分析（影响性能的因素很多，这⼀点，可以根据经验和数据表现来判断分析）。2、硬件设备对系统性能表现的影响分析由于之前设计了⼏个不同的测试环境，故可以根据不同测试环境的硬件资源使⽤状况图进⾏分析，确定瓶颈是再数据库服务器、应⽤服务器抑或其他⽅⾯，然后针对性的进⾏优化等操作。3、其他影响因素分析影响系统性能的因素很多，可以从⽤户能感受到的场景分析，哪⾥⽐较慢，哪⾥速度尚可，这⾥可以根据258原则对其进⾏分析；⾄于其他诸如⽹络带宽、操作动作、存储池、线程实现、服务器处理机制等⼀系列的影响因素，具体问题具体分析，这⾥就不⼀⼀表述了。4、测试中发现的问题在性能测试执⾏过程中，可能会发现某些功能上的不⾜或存在的缺陷，以及需要优化的地⽅，这也是执⾏多次测试的优点。1.性能分析⽅法分类：（1）指标达成法：⽤于验证性能指标（2）最优化分析法：⽤于能⼒验证型测试2.常⽤性能分析⽅法：（1）快速瓶颈识别：①硬件上的性能瓶颈 ②应⽤软件上的性能瓶颈 ③应⽤程序上的性能瓶颈
④操作系统上的性能瓶颈 ⑤⽹络设备上的性能瓶颈（2）性能下降曲线：单⽤户区域、性能平坦区、压⼒区域、性能拐点（3）内存分析⽅法 （4）处理器分析⽅法 （5）磁盘IO分析⽅法 （6）进程分析⽅法 （7）⽹络分析⽅法七、测试报告与总结 性能测试报告是性能测试的⾥程碑，通过报告能展⽰出性能测试的最终成果，展⽰系统性能是否符合需求，是否有性能隐患。性能测试报告中需要阐明性能测试⽬标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中遇到的问题和解决办法等。性能测试⼯程师完成该次性能测试后，需要将测试结果进⾏备案，并作为下次性能测试的基线标准，具体包括性能测试结果数据、性能测试瓶颈和调优⽅案等。同时需要将测试过程中遇到的问题，包括代码瓶颈、配置项问题、数据问题和沟通问题，以及解决办法或解决⽅案，进⾏知识沉淀性能测试的实施过程
客户端性能测试应⽤在客户端性能测试的⽬的是考察客户端应⽤的性能，测试的⼊⼝是客户端。它主要包括并发性能测试、疲劳强度测试、⼤数据量测试和速度测试等，其中并发性能测试是重点。并发性能测试的过程是⼀个负载测试和压⼒测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执⾏指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种⼯作负载下系统的性能，⽬标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使⽤等来决定系统的性能。负载测试是⼀个分析软件应⽤程序和⽀撑架构、模拟真实环境的使⽤，从⽽来确定能够接收的性能过程。压⼒测试（Stress Testing）是通过确定⼀个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最⼤服务级别的测试。并发性能测试的⽬的主要体现在三个⽅⾯：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应⽤程序的功能或者新的应⽤程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的⽤户负载，以预测系统的未来性能；通过模拟成百上千个⽤户，重复执⾏和运⾏测试，可以确认性能瓶颈并优化和调整应⽤，⽬的在于寻找到瓶颈问题。⽹络端性能测试应⽤在⽹络上性能的测试重点是利⽤成熟先进的⾃动化技术进⾏⽹络应⽤性能监控、⽹络应⽤性能分析和⽹络预测。⽹络应⽤性能分析的⽬的是准确展⽰⽹络带宽、延迟、负载和TCP端⼝的变化是如何影响⽤户的响应时间的。⽹络应⽤性能监控在系统试运⾏之后，需要及时准确地了解⽹络上正在发⽣什么事情；什么应⽤在运⾏，如何运⾏；多少PC正在访问LAN或WAN；哪些应⽤程序导致系统瓶颈或资源竞争，这时⽹络应⽤性能监控以及⽹络资源管理对系统的正常稳定运⾏是⾮常关键的。利⽤⽹络应⽤性能监控⼯具，可以达到事半功倍的效果，在这⽅⾯我们可以提供的⼯具是Network Vantage。通俗地讲，它主要⽤来分析关键应⽤程序的性能，定位问题的根源是在客户端、服务器、应⽤程序还是⽹络。在⼤多数情况下⽤户较关⼼的问题还有哪些应⽤程序占⽤⼤量带宽，哪些⽤户产⽣了最⼤的⽹络流量，这个⼯具同样能满⾜要求。⽹络预测考虑到系统未来发展的扩展性，预测⽹络流量的变化、⽹络结构的变化对⽤户系统的影响⾮常重要。根据规划数据进⾏预测并及时提供⽹络性能预测数据。我们利⽤⽹络预测分析容量规划⼯具PREDICTOR可以作到：设置服务⽔平、完成⽇⽹络容量规划、离线测试⽹络、⽹络失效和容量极限分析、完成⽇常故障诊断、预测⽹络设备迁移和⽹络设备升级对整个⽹络的影响。从⽹络管理软件获取⽹络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可⼈⼯⽣成流量数据），这样可以得到现有⽹络的基本结构。在基本结构的基础上，可根据⽹络结构的变化、⽹络流量的变化⽣成报告和图表，说明这些变化是如何影响⽹络性能的。PREDICTOR提供如下信息：根据预测的结果帮助⽤户及时升级⽹络，避免因关键设备超过利⽤阀值导致系统性能下降；哪个⽹络设备需要升级，这样可减少⽹络延迟、避免⽹络瓶颈；根据预测的结果避免不必要的⽹络升级。服务器端性能测试对于应⽤在服务器上性能的测试，可以采⽤⼯具监控，也可以使⽤系统本⾝的监控命令，例如Tuxedo中可以使⽤Top命令监控资源使⽤情况。实施测试的⽬的是实现服务器设备、服务器操作系统、数据库系统、应⽤在服务器上性能的全⾯监控，测试原理如下图。UNIX资源监控指标和描述监控指标 描述平均负载 系统正常状态下，最后60秒同步进程的平均个数冲突率 在以太⽹上监测到的每秒冲突数进程/线程交换率 进程和线程之间每秒交换次数CPU利⽤率 CPU占⽤率（%）磁盘交换率 磁盘交换速率接收包错误率 接收以太⽹数据包时每秒错误数包输⼊率 每秒输⼊的以太⽹数据包数⽬中断速率 CPU每秒处理的中断数输出包错误率 发送以太⽹数据包时每秒错误数包输⼊率 每秒输出的以太⽹数据包数⽬读⼊内存页速率 物理内存中每秒读⼊内存页的数⽬写出内存页速率 每秒从物理内存中写到页⽂件中的内存页数⽬或者从物理内存中删掉的内存页数⽬内存页交换速率 每秒写⼊内存页和从物理内存中读出页的个数进程⼊交换率 交换区输⼊的进程数⽬进程出交换率 交换区输出的进程数⽬系统CPU利⽤率 系统的CPU占⽤率（%）⽤户CPU利⽤率 ⽤户模式下的CPU占⽤率（%）磁盘阻塞 磁盘每秒阻塞的字节数分析优化性能思路流程性能测试总结1、硬件上的性能瓶颈：⼀般指的是CPU、内存、磁盘读写等的瓶颈，为服务器硬件瓶颈。2、应⽤软件上的性能瓶颈：⼀般指的是服务器操作系统瓶颈（参数配置）、数据库瓶颈（参数配置）、web服务器瓶颈（参数配置）、中间件瓶颈（参数配置）等3、应⽤程序上的性能瓶颈：⼀般指的是开发⼈员，开发出来的应⽤程序（如sql语句、数据库设计、业务逻辑、算法等）。4、操作系统上的性能瓶颈：⼀般指的是Windows、linux等操作系统，如出现物理内存不⾜时，或虚拟内存设置不合理（虚拟内存设置不合理，会导致虚拟内存的交换率⼤⼤降低，从⽽导致⾏为的响应时间⼤⼤增加，可以认为在操作系统上出现了性能瓶颈）。5、⽹络设备上的性能瓶颈：⼀般指的是防⽕墙、动态负载均衡器、交换机等设备。安全测试安全测试是⼀个相对独⽴的领域，需要更多的专业知识。如：WEB的安全测试、需要熟悉各种⽹络协议、防⽕墙、CDN、熟悉各种操作系统的漏洞、熟悉路由器等。采⽤成熟的⽹络漏洞检查⼯具检查系统相关漏洞（即⽤最专业的⿊客攻击⼯具攻击试⼀下，现在最常⽤的是 NBSI 系列和 IPhacker IP ）安全测试主要是根据对应的项⽬来进⾏的安全测试⽤例设计及编写后执⾏安全测试。⽐如主要是对⽤户登录的校验、密码是否加密、权限；设计充值、提现等必须是否绑定⼿机号的短信验证码校验等；需要实名认证的，甚⾄⼈脸识别技术等；做压⼒测试的时候，⽐如需要考虑同⼀个IP地址的请求过多或频繁，需要有对应的判断是否为恶意攻击及判断后的相应解决措施等。兼容性测试兼容性测试主要是指，软件之间能否很好的运作，会不会有影响、软件和硬件之间能否发挥很好的效率⼯作，会不会影响导致系统的崩溃。平台测试浏览器测试软件本⾝能否向前或向后兼容测试软件能否与其它相关软件兼容数据兼容性测试最常见的兼容性测试就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页⾯显⽰不同。常见的IE8的兼容性。⽂档测试国家有关计算机软件产品开发⽂件编制指南中共有14种⽂件，可分为3⼤类。开发⽂件：可⾏性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。⽤户⽂件：⽤户⼿册、操作⼿册，⽤户⽂档的作⽤：改善易安装性；改善软件的易学性与易⽤性；改善软件可靠性；降低技术⽀持成本。管理⽂件：项⽬开发计划、测试计划、测试分析报告、开发进度⽉报、项⽬开发总结报告。在实际的测试中，最常见的就是⽤户⽂件的测试，例如：⼿册说明书等。⽂档测试关注的点：⽂档的术语⽂档的正确性⽂档的完整性⽂档的⼀致性⽂档的易⽤性易⽤性测试（⽤户体验测试）易⽤性（Useability）是交互的适应性、功能性和有效性的集中体现。⼜叫⽤户体验测试。业务测试业务测试是指：测试⼈员将系统的整个模块串接起来运⾏、模拟真实⽤户实际的⼯作流程。满⾜⽤户需求定义的功能来进⾏测试的过程。界⾯测试界⾯测试（简称UI测试)，测试⽤户界⾯的功能模块的布局是否合理、整体风格是否⼀致、各个控件的放置位置是否符合客户使⽤习惯，此外还要测试界⾯操作便捷性、导航简单易懂性，页⾯元素的可⽤性，界⾯中⽂字是否正确，命名是否统⼀，页⾯是否美观，⽂字、图⽚组合是否完美等。安装与卸载测试安装测试是指：测试程序的安装、卸载。最典型的就是APP的安装、卸载。内存泄漏测试内存泄漏的检测：1、对于不同的程序可以使⽤不同的⽅法来进⾏内存泄露的检查，还可以使⽤⼀些专门的⼯具来进⾏内存问题的检查，例如、Purify、BundsChecker等。 有些开发⼯具本⾝就带有内存问题检查机制．要确保程序员在编写程序和编译程序的时候打开这些功能。2、通过代码扫描分析⼯具来检查
发布评论