⽹站性能测试总结
性能测试与分析是软件开发过程中介于架构和调整的⼀个⼴泛并⽐较不容易理解的领域，更是⼀项较为复杂的活动。就像下棋游戏⼀样，有效的性能测试和分析只能在⼀个良好的计划策略和具备了对不可预料事件的处理能⼒的条件下顺利地完成。⼀个下棋⾼⼿赢得⽐赛靠的不仅仅是对游戏规则的认识，更是靠他的⾃⼰的能⼒和不断地专注于分析⾃⼰对⼿的实⼒来更加有效地利⽤和发挥规则的作⽤。同样⼀个优秀的性能测试和分析⼈员将要⾯对的是来⾃⼀个全新的应⽤程序和环境下带来的整个项⽬的挑战。本⽂简单介绍⼀下⽹站性能测试需要关注的⼏个⽅⾯。
Web 应⽤程序是决定⽹站性能的关键，对其进⾏测试是⽹站测试的核⼼。压⼒测试的⽬的是测试系统在各种负荷（由并发⽤户所产⽣的综合处理量）下的性能和稳定性。为了保证Web 应⽤程序的压⼒测试能取得理想的测试效果，压⼒测试也应该遵循软件⼯程中软件测试的⼀般规范。整个测试流程应有⽂档记录，压⼒测试应得到相应的重视。需求分析对不同的系统其压⼒测试的强度和侧重点也不同。⼀个⽤于中⼩企业内部⽹和⼀个要处理⼤量⽤户的的政府门户⽹站负荷量和负荷分布是明显不同的。前者的最⼤负荷量和负荷分布是可预期的，⽽且对企事业单位内部⽹来说，暂时关闭系统后重新起动也是可以接受的。⽽对于后者却⽆法预期有多少客户会同时访问站点，对⾼峰负荷出现的时间也⽆法预知。因此在压⼒测试前必须进⾏需求分析，它是编写良好测试案例的基础。确定测试⽬标在确定压⼒测试⽬标中，要定义测试的对象，并对每⼀个测试对象给出清晰说明，也要定义测试结束的⽬标。为控制测试的有效性
在线代码运行器以及完成程度，必须定义准则和策略，以判断何时结束测试阶段。准则必须是客观的。
3 ⽹站响应时间
性能测试的⽬的是检查软件的平均响应时间或者吞吐量是否符合指定的标准。
例如，当测试前已经获知在线⼈数为10000，可以设定性能测试的⽬的是检测软件典型交易的平均响应时间是否符合⼩于5秒的指标值。例如，当测试前不知道在线⼈数是多少，但是已经获知该软件在⼀定的时间周期内（t）必须处理N笔交易，可以设定性能测试的⽬的是检测软件典型交易的吞吐量是否符合⼤于25笔交易/秒的指标值。
但是，在第⼆种情况出现时，还应该考虑若软件的吞吐量符合指定的指标值时，软件典型交易的平均响应时间是否符合⼩于5秒的指标值。
为什么呢？
我们可以利⽤“门”的概念来理解这⾥⾯的偏差！
⾸先，我们假设如下的情况：
• 共有5个⼈；
• 有1扇门；
• ⼀个⼈通过这扇门需要花费1秒的时间；
此时，这扇门的吞吐量为1⼈/秒。5个⼈通过这扇门的平均响应时间为（1+2+3+4+5）/5=3秒。
如何才能提⾼⼈的通过效率呢？即，如何才能提⾼门的吞吐量呢？
有两种⽅法：
（1）减⼩通过门的时间；
（2）增加门的数量
例如，
（1）将⼀个⼈通过门的时间减⼩为0.5秒，门的吞吐量变成了2⼈/秒；
（2）增加⼀个门，门的吞吐量也变成了2⼈/秒
结果是：
（1）5个⼈通过改善通过时间的门的平均响应时间为（0.5+1+1.5+2+2.5）/5＝1.5秒；
（2）5个⼈通过两扇门的平均响应时间为（1+1+2+2+3）/5＝1.8秒
此时，你可以发现，软件开发员改进软件处理并发交易请求的⽅法有两个，第⼀种是提⾼单个请求的处理速率，第⼆种是增加处理请求的线程的数量；或者是两种⽅法的组合。但是，不同⽅法的使⽤并不代表吞吐量得到了提⾼，⽽同时软件典型交易的平均响应时间也获得了相同值的改善。
因此，在性能测试以吞吐量为检测指标的时候，不光要评估吞吐量是否符合了性能指标的要求，同时也必须考虑响应时间是否符合性能指标的要求。
假设，在测试前，规定了吞吐量为⼤于25笔交易/秒，平均响应时间为⼩于5秒，在测试后，若实际吞吐量等于27笔交易/秒，不能仅凭这个27笔交易/秒就确定该软件的性能符合要求了，还要看平均响应时间是否符合要求。这时的平均响应时间可能⼤于5秒。
⽽，如果测试前，规定了在线⼈数为10000，平均响应时间为⼩于5秒，在测试后，仅凭实际平均响应时间等于4秒就可以判断该软件的性能符合要求。
请求响应时间：指的是客户端发出请求到得到响应的整个过程的时间。在某些⼯具中，请求响应时间通常会被成为“TLLB”，即“Time to last byte”，意思是从发起⼀个请求开始，到客户端接收到最后⼀个
字节的响应时间所耗费的时间。请求响应时间过程的单位⼀般为“秒”或
者“毫秒”。
事务响应时间：事务可能由⼀系列请求组成，事务的响应时间主要是针对⽤户⽽⾔，属于宏观上的概念，是为了向⽤户说明业务响应时间⽽提出的。例如：跨⾏取款事务的响应时间就是由⼀系列的请求组成的。事务响应时间和后⾯的业务吞吐率都是直接衡量系统性能的参数.
吞吐量：指的是在⼀次性能测试过程中⽹络上传输的数据量的总和。吞吐量/传输时间，就是吞吐率。
TPS：每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能⼒的重要指标。
4 ⽹站访问压⼒
性能测试经常和压⼒测试⼀起进⾏，⽽且常常需要硬件和软件测试设备，这就是说，常常有必要的在⼀种苛刻的环境中衡量资源的使⽤（⽐如，处理器周期）。外部的测试设备可以监测测试执⾏，当出现情况（如中断）时记录下来。通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。
压⼒测试：对系统不断施加压⼒的测试，是通过确定⼀个系统的瓶颈或者不能接收的性能点，来获得
系统能提供的最⼤服务级别的测试。例如测试⼀个 Web 站点在⼤量的负荷下，何时系统的响应会退化或失败。
性能测试：在交替进⾏负荷和强迫测试时常⽤的术语。性能测试关注的是系统的整体。它和通常所说的强度、压⼒/负载测试测试有密切关系。所以压⼒和强度测试应该于性能测试⼀同进⾏。
举例说明：针对⼀个⽹站进⾏测试，模拟10到50个⽤户就是在进⾏常规性能测试，⽤户增加到1000乃⾄上万就变成了压⼒/负载测试。如果同时对系统进⾏⼤量的数据查询操作，就包含了强度测试。
(1)什么是压⼒测试
压⼒测试是指模拟巨⼤的⼯作负荷来测试应⽤程序在峰值情况下如何执⾏操作。例如模拟实际软硬件环境，在超出⽤户常规负荷下，长时间运⾏测试⼯具来测试被测系统的可靠性，和测试被测系统的响应时间，⽬的是在极限负载下识别程序的弱点。
在众多类型的软件测试中，压⼒测试主要是以软件响应速度为测试⽬标，尤其是针对在较短时间内⼤量并发⽤户访问时软件的抗压能⼒。因此，压⼒测试是在⼀种需要反常数量、频率或资源下运⾏系统。由于我们之前对“反常”这个关键词没有理解好，只进⾏了常规的测试，在这⼀点上客户的批评让我们感到⾮常汗颜，说我们是“头发长，见识短”。
(2)压⼒测试和负载测试的区别
在这次项⽬测试前，我⼀直对压⼒测试和负载测试存在着⼀定程度的混淆。经过这次系统崩溃后，我对压⼒测试和负载测试的区别有了新的认识。压⼒测试是在超常规负荷条件下，长时间连续运⾏系统，检验应⽤程序的各种性能表现和反应。负载测试是指测试应⽤程序在常规负荷下，确认响应时间和其它的性能和表现。
实际上，压⼒测试也是从⽐较⼩的负载开始，逐渐增加模拟⽤户的数量，直到应⽤程序响应时间超时。压⼒测试的特点是长时间连续运⾏，增加超负荷(并发，循环操作，多⽤户)来测试什么时候系统会产⽣异常，以及异常处理能⼒，出瓶颈所在。现在的我终于明⽩到其实压⼒测试实际上就是超常规的负载测试。
(3)压⼒测试的核⼼原则
⼀个有效的压⼒测试需要遵循⼀些核⼼的基本原则，这些原则可以让我们在测试过程中时刻提醒我们压⼒测试是否还有更多的极端可能。
①重复：最明显且最容易理解的压⼒原则就是测试的重复。换句话说，重复测试就是⼀遍⼜⼀遍地执⾏某个操作或功能。功能测试是验证⼀个操作能否正常执⾏，⽽压⼒测试则是确定⼀个操作能否在长时间内每次执⾏时都正常。
②并发：并发是同时执⾏多个操作的⾏为。换句话说，就是在同⼀时间执⾏多个测试⽤例。功能测试或单元测试⼏乎不会与任何并发设计结合。因此，压⼒系统必须超越功能测试，要同时遍历多条代码路径。
③量级：压⼒测试另⼀个重要原则就是要给每个操作增加超常规的负载量。就是说压⼒测试可以重复执⾏⼀个操作，但是在操作⾃⾝过程中也要尽量给程序增加负担，增加操作的量级。⼀般来说，单独的⾼强度操作重复⾃⾝可能发现不了代码错误，但与其他压⼒测试⽅法(如并发和量级)结合在⼀起时，将可以增加发现错误的机会。
④随机：意思是任何压⼒测试都应该多多少少具有⼀些随机性。例如随机组合前⾯三种压⼒测试原则，然后变化出⽆数种测试形式，就能够在每次测试运⾏时应⽤许多不同的代码路径来进⾏压⼒测试。当⼀个压⼒测试结合的原则越多，测试执⾏的时间越长，就可以遍历越多的代码路径，发现的错误也会越多。
(4) 压⼒测试对系统的重要作⽤
我们对应⽤程序进⾏压⼒测试时经常会出现这种情况，就是测试到了最后却发现不明⽩测试结果有什么意义?实际上，当我们都不明⽩压⼒测试的意义时，我们就不能设计出各种极限测试⽤例。
压⼒测试不同于功能测试，软件的正确性并不是它的测试重点，它所看重的是软件的执⾏效率，尤其是短时间内访问⽤户数爆炸性增长时软件的响应速度。因此，明⽩压⼒测试的作⽤，对我们⾼效完成压⼒测试有⾄关重要的指导意义。
(1)测试应⽤程序的可靠性
在系统崩溃后总结之前失败的压⼒测试时，我忽视的第⼀个要点就是没有测试出应⽤程序在压⼒下的可靠性。压⼒测试除了对每个单独的组件进⾏压⼒测试外，更应该对带有其所有组件和⽀持服务的整个应⽤程序进⾏集中压⼒测试，以检查在巨⼤的⼯作负荷时，应⽤程序在峰值情况下是否可靠的执⾏操作。例如，当实际情况是平均每秒出现1个或2个中断的情形下，应当对每秒出现10个中断的情形来进⾏特殊的测试;⼜或者把输⼊数据的量提⾼⼀个数量级来测试输⼊功能是否可靠的响应。从本质上来说，压⼒测试是想要看在最⼤极限时程序是否可靠的运⾏。
(2)测试应⽤程序的并发性能
进⾏压⼒测试需要对实际的并发访问量有⼀个正确的预期估算，否则在负载远远⼤于事前预测的压⼒下系统将脆弱得不堪⼀击。导致系统崩溃的因素有很多，处理能⼒、存储速度、响应时间、⽹络带宽等⽆论哪部分出现短板拥堵、后果都可能导致全盘崩溃。
现在我明⽩，哪怕硬件条件达到了，如果软件的并⾏处理能⼒不⾜将会导致等候队列过长，响应时间变慢，系统崩溃也只是时间问题。简单说就是：压⼒测试是考察当前软硬件环境下系统所能承受的最⼤并发负荷，并帮助出软件程序的瓶颈所在。
(3)测试应⽤程序的最⼤负载能⼒
压⼒测试的⽬的之⼀是出应⽤程序能够⽀持的最⼤客户端数。通过多次的运⾏和对测试结果中正在运⾏⽤户数与错误⽤户的对⽐，然后根据可接受错误率就可得到该功能的最⼤负载访问的⽤户数。最⼤负载压⼒测试⽤来评估在超越最⼤负载的情况下系统将如何运⾏，这时的⽬标是要发现在⾼负载的条件下应⽤程序的缺陷 (Bug)，例如内存泄漏等。因此，最⼤负载能⼒不但是应⽤程序⼀个重要的技术指标，也是客户评估和验收软件的⼀个关键指标。
(5)如何进⾏⾼效的压⼒测试?
软件测试有两句通俗的话：开发是尽可能地让程序通过;⽽测试则是尽可能地让程序通不过。对于压⼒测试⽽⾔，测试效果好不好，测试计划的好坏是关键。所以，针对不同的情况，分析后有针对的进⾏测试，⽐起拿乱打、⽆的放⽮显然要⾼效得多。
进⾏⼀次切实可⾏的压⼒测试并不像乍看之下那么简单，遇到的问题也可能⾮常微妙。例如，我的测
试团队就经常遇到诸如“客户端每⼩时将要处理100个客户订单请求”等此类的需求，于是测试团队就试图把该需求转化为某种测试需求，执⾏这种测试需求的常见⽅法就是以死循环的形式对服务器进⾏反复请求，然后静观其效。然⽽，通常事情进⾏得并不顺利，原因在于这只是把需求表⾯化了，没有分析出测试需求的本质。⾼效的压⼒测试应遵循以下这⼏个步骤：
(1)确定测试⽬标
在确定压⼒测试⽬标中，我们要定义测试的对象，并对每⼀个测试对象给出清晰说明，也要定义测试结束的⽬标。为控制测试的有效性以及完成程度，必须定义准则和策略。准则必须是客观的，可量化的，⽽不能是经验或感觉。例如压⼒测试⽬标可能是测定终端⽤户处理事务的响应时间，它可能随⽤户的增加⽽增加，但要定义⼀个可接受时间。在确定压⼒测试⽬标过程中，最好能邀请客户、设计⼈员等⼀同对测试⽬标进⾏评审。
(2)制定压⼒测试计划
测试计划内容包括：定义测试资源、制定测试进度表、选择测试⼯具等。制定测试计划的⽬的是使压⼒测试有章可循并得到⼈⼒、物⼒等各⽅⾯的保证；在制定测试进度表时应考虑和开发进度相互协调；对于测试⼯具的选择应以满⾜测试⽬标为前提。所以，这并不是说测试⼯具提供的功能越多就越好，在实际的选择过程中适⽤才是根本。
(3)编写测试案例和设置测试数据
测试⼈员⼀般是根据测试案例进⾏实际的测试⼯作，因此测试案例的编写应做到客观全⾯、重点突出，也就是要求编写的测试案例应该尽可能模拟真实的负荷，不遗漏重要的测试内容。为了让所有的测试顺利执⾏，可采取数据驱动⽅式进⾏，同时应该对测试数据进⾏参数化。另外，⼀般不提倡在开发环境中进⾏压⼒测试，最好是另外构建测试环境。
(4)结果分析及测试报告
压⼒测试运⾏结束后，应把所有的数据汇总并记录到⽂件中，以⽅便对测试结果进⾏分析和得出结论。若测试失败，应先分析失败原因，如果是软件系统造成的，应返回给设计⼈员修改。如果测试结果不满⾜预期需求，应先对软件程序进⾏优化调理，然后再次运⾏测试，直到可以满⾜预期需求或调整已⽆法改善结果。
最后需要注意的是测试报告。报告应包括测试提要、测试环境和测试结果。提要应简单说明测试⽅法、策略、范围、内容；测试环境应包括资源开销、环境配置等；测试结果必须包括测试是否通过或拒绝，并要对测试结论进⾏说明，并对软件程序的性能做出评价。
5 ⽹站并发性
在软件系统⽇益复杂的今天，性能已经成为软件质量的重要衡量标准之⼀，这⼀点尤其体现在和WEB相关的系统上。接下来介绍⼀些WEB性能测试中的术语，这些术语都是WEB性能测试中出现频繁的⽐较⾼的词汇，只有掌握这些基础的性能知识才可以进⼀步开展测试⼯作。这些术语主要有并发⽤户，并发⽤户数量，请求响应时间，事务响应时间，吞吐量，吞吐率，TPS，点击率，资源利⽤率等。
并发⽤户：并发⼀般分为2种情况。⼀种是严格意义上的并发，即所有的⽤户在同⼀时刻做同⼀件事情或者操作，这种操作⼀般指做同⼀类型的业务。⽐如在信⽤卡审批业务中，⼀定数⽬的拥护在同⼀时刻对已经完成的审批业务进⾏提交；还有⼀种特例，即所有⽤户进⾏完全⼀样的操作，例如在信⽤卡审批业务中，所有的⽤户可以⼀起申请业务，或者修改同⼀条记录。
另外⼀种并发是⼴义范围的并发。这种并发与前⼀种并发的区别是，尽管多个⽤户对系统发出了请求或者进⾏了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个系统⽽⾔，仍然是有很多⽤户同时对系统进⾏操作，因此也属于并发的范畴。
可以看出，后⼀种并发是包含前⼀种并发的。⽽且后⼀种并发更接近⽤户的实际使⽤情况，因此对于⼤多数的系统，只有数量很少的⽤户进⾏“严格意义上的并发”。对于WEB性能测试⽽⾔，这2种并发情况⼀般都需要进⾏测试，通常做法是先进⾏严格意义上的并发测试。严格意义上的⽤户并发⼀般发⽣在使⽤⽐较频繁的模块中，尽管发⽣的概率不是很⼤，但是⼀旦发⽣性能问题，后果很可能是致命的。
严格意义上的并发测试往往和功能测试关联起来，因为并发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的⼀部分。
⽤户并发数量：关于⽤户并发的数量，有2种常见的错误观点。⼀种错误观点是把并发⽤户数量理解为使⽤系统的全部⽤户的数量，理由是这些⽤户可能同时使⽤系统；还有⼀种⽐较接近正确的观点是把在线⽤户数量理解为并发⽤户数量。实际上在线⽤户也不⼀定会和其他⽤户发⽣并发，例如正在浏览⽹页的⽤户，对服务器没有任何影响，但是，在线⽤户数量是计算并发⽤户数量的主要依据之⼀。
6 结论
我们在这⾥所说的性能测试，指的是对系统整体性能的测试，不涉及单元模块的性能检测。
性能测试是为了检验系统或系统部件是否达到需求规格说明中规定的各类性能指标，并满⾜⼀些性能相关的约束和限制条件，它必须对系统或系统部件具有的性能（例如，速度、精度、频率）做出规定的要求。
性能测试通常在系统测试阶段执⾏，常常与强度测试结合起来，⼀般需要使⽤测试⼯具。评估测试对象的性能⾏为时，可以使⽤多种评测，这些评测侧重于获取与⾏为相关的数据，如响应时间、计时配置⽂件、执⾏流、操作可靠性和限制。这些评测主要在评估测试活动中进⾏，也可以在执⾏测试活动中使⽤性能评测评估测试进度和状态。
对于⽬前以 B/S 结构为主的政府⽹站产品来说，性能是⼀项必测的内容。
关于性能⽅⾯的测试，在很多地⽅⼜被细分为：⽹站响应时间、⽹站访问压⼒、⽹站并发性等等。这种细分在概念描述上有⼀些⽤处，但在实际⼯作中很少会只单独的进⾏其中的某⼀项测试，实际测试基本上都是交叉性的。我们这⾥把所有与性能相关的测试统称为性能测试，不做具体区别。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。