软件性能测试（连载1）
1性能测试介绍
1.1 性能测试的定义
性能测试在质量ISO2510 2006模型中属于效率，根据维基百科定义，[30]软件性能测试作为软件质量保证必不可少的环节，指的是软件系统或构件对于其及时性要求符合程度的指标；它是一种规范，可以用来量化更改业务指标所产生的影响，进而说明部署软件的风险。一般用响应时间|、QTP、吞吐率、每秒点击数等参数指标进行衡量。
远古时候，人类发现自己的精力是有限的，为了能够到达更远的地方，发明了马车、牛车等用牲口作为动力的车。到了十八世纪随着蒸汽机的发现后，在1769年，法国人N·J·居纽制造了世界上第一辆蒸汽驱动的三轮汽车，人类的代步工具进入了工业化的时代。随着后来普通火车、飞机、高速火车的发明，使人类的远足变得越来越方便快捷。据说在不久的将来，就能坐上胶囊式火车，这种火车的车体在一个完全真空的胶囊中运行，时速非常得快，从北京到上海，20分钟就可到达。
所以性能给人的第一感觉就是“快”。一个软件产品除了功能正确以外，性能是非功能属性中很重要的特性，可以想象下打开一个网站首页每次都超过15秒，这样的网站功能做得再好，也不会有人使用的。另外性能问题也会引起一些很大的问题，见下面几个的案例。
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院校考点报名人数已满，无法再报名”的现象，引起社会的强烈不满。
那么应该如何做好软件性能测试呢，下面进行详细介绍。
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秒，则说明找到拐点）（容量测试中也可使用二分法来寻找拐点，在第1.10节中将进行描述）。
2）容量测试（Volume Testing）
容量测试（VolumeTesting）是指在一定的软件、硬件及网络环境下，例如向数据库中构造不同数量级别的数据记录，通过运行一种或多种业务在一定的虚拟用户数量情况下，获取不同数据级别的服务器性能指标，以确定数据库的最佳容量。
案例3-2：容量测试。
在案例3-1场景下，保持并发用户为4000，数据库数据从10000条开始每次增加1000条记录请求响应时间，每次测试持续时间为10分钟。当数据达到30000后，发现平均响应时间超过规定的3秒，达到3.24秒。所以，确定本次模糊查询模块的容量测试拐点为30000条。（容量测试中也可使用二分法来寻找拐点，在第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不同的运行模式下运行，测试其性能情况。