11.软件测试-----性能测试

【例1】某电商交易系统，业务要求支持2亿用户（同一时刻1%的用户在线)，每天支持2000万次交易量（交易的时间集中在早上8点到凌晨2点），交易响应时间要求在1s中之内。此外，高峰期系统的处理能力要求是平均值的3倍；本地交易响应时间正常低于1s,在高峰时可以高于1s，但是要在3s内。正常及交易成功率100%，在高峰期不能低于99.9% 这样的业务要求，作为测试人员，如何转化为可以性能测试可以验证的指标呢？

3.1关键性能指标分析

同一时刻支持200万用户在线

18个小时需要处理2000万次交易，平均每秒处理309次请求

高峰期 927次/秒

3.2关键业务分析

系统如果出现问题，一般不是系统所有的功能出现问题，而是一些关键的业务或者功能存在问题导致

在分析性能指标时，要选择用户频繁使用的功能
计算量比较大的业务

4.常见的性能指标

系统/事务的平均响应时间

事务处理效率TPS（Transaction Per Second）

吞吐率

每秒点击次数（Hits Per Second)

服务器资源占用情况，内存和CPU使用率

软、硬件配置是否合适（容量规划/硬件选型）

5.不同维度衡量系统的性能

5.1软件设计研发人员：

系统的架构是否合理，是否支持多线程并发的操作

数据库设计是否合理

核心算法是否高效

设计和代码，是否存在不合理的线程同步方式和不合理的资源竞争

5.2系统运维人员：

系统对资源的利用率，服务器(CPU、内存、磁盘、网络带宽等)的利用率和数据库的使用状况

系统的容量，系统支持的最大用户数

系统的稳定性：是否可以稳定运行，一天24小时

系统的可扩展性，如果需要进行扩容操作，系统是否可以支持

5.3终端用户：

使用是否舒适，响应是否速度快，稳定性好

5.4性能测试人员：

以上所有层面都需要关注

当系统性能无法达标时，关注引起系统性能的瓶颈

6.性能测试中基本知识

6.1并发用户数

业务层面的并发数：同一时刻向后端服务器发送请求的用户的数量

后端服务器的并发数：同一时刻向后台服务器发送请求的数量

6.2响应时间

用户发送请求，到用户所期待的响应完全展示到前端所需要的时间

响应时间分为前端展示时间和系统响应时间两部分。

前端展示时间：客户端收到服务器返回的数据后渲染前端页面，所耗费的时间。

系统的响应时间：分为web服务器，应用服务器，数据库服务器，等各种服务器之间通信和处理请求的时间。

6.3事务响应时间

每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性性能指标。

这里的一个事务是一个业务度量单位，是指一组密切相关的子操作的组合。比如，一笔电子支付操作，后台处理的时候可能需要经过会员系统，账务系统，支付系统，银行系统等，这就是是一个关于支付事务里面包含的操作。而对于用户，往往也只关注整个支付花费了多长时间。

6.4每秒事务通过数

平均每秒处理的事务的数量

6.5点击率

每秒点击数代表用户每秒向Web服务器提交的HTTP请求的个数，点击率越大，服务器的压力越大

这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求

6.6吞吐量

单位时间系统处理的信息量

6.7思考时间

模拟正式用户在实际操作时的停顿间隔时间，从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。

6.8资源利用率

系统在运行的时候的资源使用情况，包括CPU、内存、硬盘、网络等

7.性能测试模型

图源https://www.testwo.com/blog/8249（1）X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。

（2）随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。

（3）接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。

（4）同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

（5）最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

8.地铁模型

假设：

# 某地铁站进站只有3个刷卡机。

# 人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要1s。

# 乘客耐心有限，如果等待超过30min，就暴躁、唠叨，甚至放弃。

场景一：只有1名乘客进站时，这名乘客可以在1s的时间内完成进站，且只利用了一台刷卡机，剩余2台等待着。

场景二：只有2名乘客进站时，2名乘客仍都可以在1s的时间内完成进站，且利用了2台刷卡机，剩余1台等待着。

场景三：只有3名乘客进站时，3名乘客还能在1s的时间内完成进站，且利用了3台刷卡机，资源得到充分利用。

场景四：A、B、C三名乘客进站，同时D、E、F乘客也要进站，因为A、B、C先到，所以D、E、F乘客需要排队。那么，A、B、C乘客进站时间为1s，而D、E、F乘客必须等待1s，所以他们3位在进站的时间是2s。

场景五：假设这次进站一次来了9名乘客，有3名的“响应时间”为1s，有3名的“响应时间”为2s（等待 1s+进站1s），还有3名的“响应时间”为3s（等待2s+进站1s）。

场景六：如果地铁正好在火车站，每名乘客都拿着大小不同的包，包太大导致卡在刷卡机堵塞，每名乘客的进站时间就会又不一样。刷卡机有加宽的和正常宽度的两种类型，那么拿大包的乘客可以通过加宽的刷卡机快速进站（增加带宽）。

场景七：进站的乘客越来越多，3台刷卡机已经无法满足需求，为了减少人流的积压，需要再多开几个刷卡机，增加进站的人流与速度（提升TPS、增大连接数）。

场景八：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，那么增加发车频率（加快应用服务器、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

9.性能测试方法

9.1基准测试

系统的新版本/新接手的系统，需要进行基准测试，获得系统的性能指标，作为以后改善系统性能，保持系统性能的基准。

进行基准测试不仅可以获取系统的基准性能指标，也可能发现新系统的一些性能问题

9.2并发测试

同一时刻，向后端服务器发送请求，测试系统的表现，检查系统是否会由于大量的用户出现资源竞争，死锁的问题

9.3压力测试

压力测试一般指后端压力测试，不断对系统施加压力，检查系统在长期处于临界饱和情况下，系统的稳定性以及系统性能指标的变化，进行压力测试的时候会不断向系统增加负载，使得系统长期处于高负荷情况，检查系统在极限情况下是否稳定，确定系统在极限情况下是否稳定，确定系统在极限情况下CPU利用率，内存使用情况等其他指标

9.4配置测试

系统性能的好坏，不仅仅取决于软件自身的设计和实现，也取决于软件运行所依赖的硬件，网络环境。为了达到系统性能指标要求，就需要调整系统的硬件配置，如增加服务器或者服务器集群来达到更高的性能。这时，会在不同配置的情况下，来测定系统的性能指标，从而决定在系统部署时采用什么样的软硬件配置，找到能够使得系统性能发挥最优的配置