第3章  软件性能测试

3.1性能测试介绍

3.1.1  性能测试的定义

性能测试在质量ISO2510 2006模型中属于效率，根据维基百科定义，^[30]软件性能测试作为软件质量保证必不可少的环节，指的是软件系统或构件对于其及时性要求符合程度的指标；它是一种规范，可以用来量化更改业务指标所产生的影响，进而说明部署软件的风险。一般用响应时间|、QTP、吞吐率、每秒点击数等参数指标进行衡量。

远古时候，人类发现自己的精力是有限的，为了能够到达更远的地方，发明了马车、牛车等用牲口作为动力的车。到了十八世纪随着蒸汽机的发现后，在1769年，法国人N·J·居纽制造了世界上第一辆蒸汽驱动的三轮汽车，人类的代步工具进入了工业化的时代。随着后来普通火车、飞机、高速火车的发明，使人类的远足变得越来越方便快捷。据说在不久的将来，就能坐上胶囊式火车，这种火车的车体在一个完全真空的胶囊中运行，时速非常得快，从北京到上海，20分钟就可到达。

所以性能给人的第一感觉就是“快”。一个软件产品除了功能正确以外，性能是非功能属性中很重要的特性，可以想象下打开一个网站首页每次都超过15秒，这样的网站功能做得再好，也不会有人使用的。另外性能问题也会引起一些很大的问题，见下面几个的案例。

3.1.2  由于性能测试没做到位发生的缺陷

1. 奥运门票事件

2007年10月，北京奥组委向境内公众启动第二阶段奥运会门票预售。由于实行了“先到先得，售完为止”的销售政策，公众纷纷抢在第一时间订票，使票务官方网站的压力激增，承受了超过自身设计容量八倍的流量，系统开工半小时即瘫痪导致系统瘫痪。为此，北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意，同时宣布奥运门票暂停销售5天。

2. 12306事件

2014年1月16日是春运第一天，大家通过互联网、电话渠道正式购买列车车票。首轮春运“抢票高峰”刚刚到来，众多网友纷纷称，12306网站网络系统并不稳定，且出现了“串号”问题，用户甚至可轻易获取陌生人的身份证号码、手机号码等隐私信息。

3.淘宝双11事件

2018年11月11日双11如期到来，淘宝与许多电子商务网站一样，在双11推出了许多产品降价促销活动。有些网友采取大量囤货买进，然后挑选自己合适的商品留下，不合适退货的策略。另外双11快递比较多，快递公司工作量猛增，好些网友长时间内收不到货，所以要求退货。由于退货太多，对于淘宝开发人员而言也没有对这个不太重要的模块专门进行过性能测试，从而造成“退货退款”模块瘫痪，使得造成网友无法退货的情形。

4. “艺术升”事件

2019年1月6日，许多艺术生的考生通过“艺术升”APP报名考试，由于系统响应时间非常得慢，甚至造成卡顿。当轮到自己可以报名了出现“XXX院校考点报名人数已满，无法再报名”的现象，引起社会的强烈不满。

那么应该如何做好软件性能测试呢，下面进行详细介绍。

3.1.3  性能测试类型

对于性能测试类型的术语在测试业界是比较混乱的，读者关键在于掌握每种测试类型里面的含义，然后接触其他书籍或文章中，通过内容来达到以不变应万变的目的。本节提到的软件性能测试如图3-1，包括普通性能测试、负载测试（包括并发测试与容量测试）、疲劳性测试、强度测试和配置测试。

                         

图3-1  软件性能测试类型

1.普通性能测试（Perfoemce Testing）

普通情况下的性能测试是指在低负载、低容量下系统的性能体现。普通性能测试通常在功能测试同时进行，通过测试工程师的抓包或者用户体验来进行测试。

2．负载测试（Load Testing）

负载测试分为并发测试和容量测试。

1）并发测试（Concurrent Testing）

先来介绍一下什么叫并发，如图3-2所示。

图3-2 并发测试场景

1.没有任何用户到达集合点2.部分用户到达集合点

3. 所有用户到达集合点，开始并发4. 正在进行并发

在图3-2的（1）表示并发操作即将执行，在并发测试执行之前，必须定义好集合点和事务起始点。所谓事务就是需要执行并发的一个业务操作。比如登录系统、查询文章。集合点往往设置在事务起点之前，所有设置的用户在没有达到并发条件之前在集合点等待，一旦达到集合点，就触发并发操作。在图3-2的（2）中上来了部分用户，但是还没有达到并发条件。在图3-2的（3）中达到了并发条件，开始进行并发操作。在图3-2的（4）中正在进行并发操作。

并发测试（Concurrent Testing）是指在一定的软件、硬件及网络环境下，通过运行一种或多种业务在不同虚拟用户数量情况下测试服务器的性能指标是否在用户的要求范围内，用于确定系统能承载的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率。

案例3-1：并发测试。

以并发用户5000开始对某产品的模糊查询功能进行负载测试（数据库中的数据一直保持为10000条），记录错误的虚拟用户+失败的虚拟用户与所有虚拟用户的比值，然后每次增加500个并发用户，每次测试持续时间为10分钟。发现这个记录的比值随着并发用户的增大逐渐增大，当并发用户达到13500时发现这个比值为5.8%（一般认为在5.0%以下为正常，在5.0%以上为不正常），确定这个版本的并发用户的拐点为9500个。（也有一些企业通过查看响应时间来判断，如果响应时间超过设定的值，比如3秒，则说明找到拐点）（容量测试中也可使用二分法来寻找拐点，在第3.1.10节中将进行描述）。

2）容量测试（Volume Testing）

容量测试（VolumeTesting）是指在一定的软件、硬件及网络环境下，例如向数据库中构造不同数量级别的数据记录，通过运行一种或多种业务在一定的虚拟用户数量情况下，获取不同数据级别的服务器性能指标，以确定数据库的最佳容量。

案例3-2：容量测试。

在案例3-1场景下，保持并发用户为4000，数据库数据从10000条开始每次增加1000条记录请求响应时间，每次测试持续时间为10分钟。当数据达到30000后，发现平均响应时间超过规定的3秒，达到3.24秒。所以，确定本次模糊查询模块的容量测试拐点为30000条。（容量测试中也可使用二分法来寻找拐点，在第3.1.10节中将进行描述）。

负载测试的评判结果是基准法，即这一版本的拐点值在通常情况下不得低于上一次的95%以下。在这里特别需要提及的是通常情况，如果产品功能增加了很多或者其他原因，在公司技术高层的协商下是可以低于95%的。

案例3-3：用基准法来评判并发测试。

在案例3-1的产品设计的版本下发布了一个新的版本，得到的最大并发数拐点为9200，最大容量拐点为28000条。与上一次的测试结果比较：并发9200/9500×100%≈97%，28000/30000×100%=93%。所以，这次性能测试中并发测试结果是正常的，而容量测试是不正常的，需要进一步定位容量测试性能降低的原因。

3. 疲劳性测试（Stress Testing）

疲劳性测试（StressTesting）是指在一定的软件、硬件及网络环境下，通过模拟大量的虚拟用户向服务器产生负载，使服务器的资源处于极限状态下长时间连续运行，以测试服务器在高负载情况下是否能够稳定工作。通常在70%～80%最高负载下持续运行48小时。这里的负载可以是并发负载也可以是容量负载，甚至既可以是并发负载+容量负载，在并发负载+容量负载同时作用下，通常取50%～60%并发负载和50%～60%容量负载进行测试。

案例3-4：疲劳性测试。

在案例3-1场景下（数据库中的数据一直保持为10000条），将并发用户设置为最大并发用户的75%，即9500×75%=7125，持续运行48小时，使用监控软件监控应用服务器以及数据库设备的各个资源的使用率情况。48小时后，通过查看测试日志，发现在第36小时34分，服务器端查询进程的内存出现了飙升，持续12秒后降到0点，这时查询进程的CPU使用率也一下降到0点，确定在这个时刻可能存在一个内存溢出的问题而导致系统宕机。

疲劳性测试是在拐点下进行测试的，见图3-3所示。

图3-3 疲劳性测试

4.强度测试（Strength Testing）

强度测试（StrengthTest）在高于性能测试拐点的情形上，测试软件的表现形式。严格来说，强度测试是应该属于可靠性测试范畴的，但是它与负载测试中的拐点息息相关，所以在性能测试中进行介绍。图3-4是标准的强度测试。

图3-4 标准的强度测试

疲劳测试是在最高负载之下运行的，而强度测试是在最高负载之上运行的。并且强度测试运行持续长度比较短，而疲劳测试需要持续长度比较长。一般在标准强度测试下很难发现问题，往往在图3-5两种情形下发现的问题最多。

图3-5 衍生的强度测试

在图3-5左边，系统在高于最高负载之上运行，然后突然将系统负载降到最低，观察各项性能指标是否有能力恢复正常。在图3-5右边，系统的负载忽高忽低，这种情况在实际中是经常遇到的，当系统终于高压状态运行，系统的监控系统发现超载，启用保护模块，把负载降为正常。当系统达到正常状态后，监控系统认为运行正常，禁用保护模块，造成系统又处于最高负载运行状态。在这种“过山车”的情形下也是容易发现问题的，这样的测试类型也可叫做浪涌测试。。

5.配置测试（Configuration Testing）

配置测试（ConfigurationTesting）是指在不同的软件、硬件、环境以及网络环境配置下，通过运行一种或多种业务在一定的虚拟用户数量情况下获得不同配置的性能指标，用于选择最佳的设备及参数配置。

案例3-5：配置测试。

对某款Web软件在几个主流的服务器上（Windows Server 2019、Ubuntu、openSUSE、Mac）不同的浏览器（IE、Edge、Chrome、Firefox、Safari），Tomcat不同的运行模式下运行，测试其性能情况。

3.1.4  性能测试指标

1.响应时间（Response Time）

响应时间=用户响应时间+前端响应时间+网络响应时间+服务器端响应时间+数据库响应时间，是反映系统处理效率的指标之一。

响应时间是从开始到完成某项工作所需时间的度量。嵌入式产品，响应时间不包括人的反应时间，而对于其他产品，大多数都是人机交互的，响应时间体现在人的直观体验感受。在B/S系统中有一个著名的2/5/10原则，即网页在0-2秒内显示，所有用户可以接受；在2-5秒内显示，大部分用户可以接受；5-10秒内显示，只有少部分用户可以接受；10秒以上就几乎没有用户可以接受了。

另外合理的响应时间要与用户需求相结合，如在银行输入系统中，导入数据花费2个小时，那么输出响应能在20分钟内完成，性能就很不错了。

通过图3-6可以看出，响应时间=B1+W1+S1+W2+D+W3+S2+W4+B2，其中。

•W1、W2、W3、W4。网络响应时间。

•B1、B2。前端响应时间。

•S1、S2。服务器响应时间。

•D=数据库处理时间。

图3-6  响应时间

案例3-6：某网站的表单提交响应时间。

一个网站前端使用的是HTML5+CSS3+JavaScript+Ajax技术，服务器语言采用的是JSP+JavaBean技术，数据库采用的是Orcale。该网站某个表单提交的响应时间包括如下步骤。

（1）用户输入信息提交表单的时间。

（2）前端验证输入信息的时间。

（3）前端处理输入信息的时间。

（4）前端输入信息传输到Web Server的时间。

（5）jsp+javabean程序处理输入信息的时间。

（6）输入信息从Web Server到Oracle的传输时间。

（7）Oracle插入数据处理时间。

（8）Oracle将插入数据成功与否的信息传输到Web Server的时间。

（9）Web Server将插入数据成功与否的信息传输到前端的时间。

（10）前端插入数据成功与否的信息展示时间。

（11）用户接收到显示信息的时间。

2. 吞吐率（Throughput Rate）

吞吐率是单位时间内的吞吐量。吞吐量是服务器所能处理事务的能力。吞吐率的单位为字节数/秒、业务数/秒、点击数/秒、请求数/秒。随着负载的增加，吞吐率往往增长到一个峰值后，然后下降，队列变长。注意：在性能测试领域吞吐量是没有意义的，吞吐率才有意义。比如说某台服务器可以处理5T大小的数据，那么多的数据是1小时内处理完毕还是一天（24小时）处理完毕？如果是1小时内处理完毕，吞吐率为5T/h，性能是非常不错的；但是如果是24小时内处理完毕，吞吐率为5T÷24=208 G/h，性能就差很多。

为了让各位更好地理解吞吐率。以马路作为一个例子，见图3-7。

图3-7  马路的吞吐率

当马路上只有一辆车子运行，车子运行是非常畅通的，吞吐量也为1；随着汽车越来越多，单位时间内通过的车越来越多，也就是说这时候马路上车的吞吐量为n（n>1）；随着更多的车子加入，马路达到饱和，出现了堵车的情形。虽然想进入这条马路上的车和在这条马路上的车为k，但是马路上最多可以行使的车保持在m辆（n<m<k）。也就是说马路达到了拐点，最多处理能力为同时行驶m辆车。。

案例3-7：理发师模型

理发师模型是经典的解释吞吐率与响应时间的模型。比如有一家理发馆，里面有3名理发师，每个理发师水平相当，每给一位顾客理发需要10分钟的时间，如表3-1所示。

表3-1理发师模型

•当有1个人来理发的时候，需要10分钟的理发时间、平均响应时间为10分钟、实际并发数为1。

•当有2个人来理发的时候，2个人可以同时进行，共需要10×2=20分钟的理发时间、平均响应时间仍旧为20/2=10分钟、实际并发数为2。

•当有3个人来理发的时候，3个人仍旧可以同时进行，共需要10×3=30分钟的理发时间、平均响应时间仍旧为30/3=10分钟、实际并发数为3。

•当有4个人来理发的时候，3个人可以同时进行，但有1个人需要等到下一轮，这个时候需要20分钟×1+10分钟×3=50分钟的理发时间、平均响应时间为50/4=12.5分钟、由于理发师没有增加，实际并发数仍旧为3。

•当有5个人来理发的时候，3个人可以同时进行，2个人需要等到下一轮，这个时候需要20分钟×2+10分钟×3=70分钟的理发时间、平均响应时间为70/5=14分钟、由于理发师没有增加，实际并发数仍旧为3。

•当有6个人来理发的时候，3个人可以同时进行，3个人需要等到下一轮，这个时候需要20分钟×3+10分钟×3=90分钟的理发时间、平均响应时间为90/6=15分钟、由于理发师没有增加，实际并发数仍旧为3。

•当有7个人来理发的时候，3个人可以同时进行，3个人需要等到下一轮，1个人需要等到两轮，这个时候需要30分钟×1+20分钟×3+10分钟×3=120分钟的理发时间、平均响应时间为120/7=17.1分钟、由于理发师没有增加，实际并发数仍旧为3。

•当有8个人来理发的时候，3个人可以同时进行，3个人需要等到下一轮，2个人需要等到两轮，这个时候需要30分钟×2+20分钟×3+10分钟×3=150分钟的理发时间、平均响应时间为150/8=18.75分钟、由于理发师没有增加，实际并发数仍旧为3。

…

图3-8和图3-9分别是理发师模型平均响应时间、实际并发数与设置并发数对应曲线。

图3-8  理发师模型平均响应时间与设置并发数对应曲线

图3-9  理发师模型实际并发数与设置并发数对应曲线

在不到拐点的场景下，随着设置并发数的增加，平均响应时间基本保持不变，并且实际并发数与设置并发数保持一致；当超过拐点的场景下，随着设置并发数的增加，平均响应时间持续上升，而实际并发数在最高值保持不变。这与软件性能测试的情形是基本吻合的。如果要提高性能从硬件上考虑可以增加理发师，从软件上考虑可以加强理发师水平，减少给每一位顾客理发的时间。