网站测试基本方法-12. 网站性能测试总结

1 引言

    性能测试与分析是软件开发过程中介于架构和调整的一个广泛并比较不容易理解的领域，更是一项较为复杂的活动。就像下棋游戏一样，有效的性能测试和分析只能在一个良好的计划策略和具备了对不可预料事件的处理能力的条件下顺利地完成。一个下棋高手赢得比赛靠的不仅仅是对游戏规则的认识，更是靠他的自己的能力和不断地专注于分析自己对手的实力来更加有效地利用和发挥规则的作用。同样一个优秀的性能测试和分析人员将要面对的是来自一个全新的应用程序和环境下带来的整个项目的挑战。本文简单介绍一下网站性能测试需要关注的几个方面。

2 网站性能测试目的

    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 结构为主的政府网站产品来说，性能是一项必测的内容。

    关于性能方面的测试，在很多地方又被细分为：网站响应时间、网站访问压力、网站并发性等等。这种细分在概念描述上有一些用处，但在实际工作中很少会只单独的进行其中的某一项测试，实际测试基本上都是交叉性的。我们这里把所有与性能相关的测试统称为性能测试，不做具体区别。