性能测试简单介绍

性能测试介绍

指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

对性能的认识

从用户的角度：
这里写图片描述
从开发的角度：

从系统管理员的角度：

那么？测试应该关注哪些呢？
测试人员通常是做为软件质量控制的一个角色，不仅仅是找bug，需要对整个软件的质量负责，性能也属于质量的一部分，因此测试人员眼中的性能应该是全面的，考虑的东西也需要全面：

测试人员需要考虑全面的性能，包括用户、开发、管理员等各个视角的性能。
测试人员在做性能测试时除开要关注表面的现象如响应时间，也需要关注本质，比如用户看不到的服务器资料利用率，架构设计是否合理？代码是否合理等方方面面。

性能测试类型

基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考
负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。
压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。
稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题

应用场景

性能测试应用场景（领域）主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较。

下表简单介绍和对比了这几个场景的各自用途和特点：

作用	主要用途	典型场景	特点	常用性能测试方法
能力验证	关注在给定的软硬件条件下，系统能否具有预期的能力表现	在要求平均响应时间小于2秒的前提下，如何判断系统是否能够支持50万用户/天的访问量？	a)要求在已确定的环境下运行b)需要根据典型场景设计测试方案和用例，包括操作序列和并发用户量，需要明确的性能目标	a)负载测试 b)压力测试 c)稳定性能测试
规划能力	关注如何使系统具有我们要求的性能能力	某某系统计划在一年内获客量在到xxx万，系统到时候是否能支持这么多用户量？如果不能需要如何调整系统的配置？	a) 它是一种探索性的测试 b) 常用于了解系统性能和获得扩展性能的方法	a) 负载测试 b) 压力测试 c) 配置测试
性能调优	主要用于对系统性能进行调优	某某系统上线运行一段时间后响应速度越来越慢，此时应该如何办？	每次只改变一个配置，切忌无休止的调优	a) 并发测试 b) 压力测试 c) 配置测试
缺陷发现	发现缺陷或问题重现、定位手段	某些缺陷只有在高负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露	做为系统测试的补充,用来发现并发问题，或是对系统已经出现的问题进行重现和定位	a) 并发测试 b) 压力测试
性能基准比较	常用于敏捷开发过程中，敏捷开发流程的特点是小步快走，快速试错，迭代周期短，需求变化频繁	很难定义完善的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，通过比较每次迭代中的性能表现变化，判断迭代是否达到了目标

性能测试基本概念

1、响应时间

定义：从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间
关键路径：下图为一次http请求经过的路径，请求会经过网络发送到web服务器进行处理，如果需要操作DB，再由网络转发到数据库进行处理，然后返回值给web服务器，web服务器最后把结果数据通过网络返回给客户端
计算方法：Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（网络时间 + 应用程序处理时间）
响应时间-负载对应关系：

图中拐点说明：
（1）响应时间突然增加
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位

2、吞吐量

定义：单位时间内系统处理的客户端请求的数量
计算单位：一般使用请求数／秒做为吞吐量的单位，也可以使用页面数／秒表表示。
另外，从业务角度来说也可以使用访问人数 /天或页面访问量／天做为单位。
计算方法：Throughput = (number of requests) / (total time).
吞吐量-负载对应关系：

图中拐点说明：
（1）吞吐量逐渐达到饱和
（2）意味着系统的一种或多种资源利用达到的极限
（3）通常可以利用拐点来进行性能测试分析与定位

3、并发数：

（1）并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能。
（2）在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求
（3）系统用户数：系统注册的总用户数据
　　　　
三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数

4、资源利用率

定义：指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量
通常需要关注的服务器资源如下：
（1）CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制
（2）内存：大脑中的记忆块区，将眼睛，皮肤等收集到的信息记录起来的地方，以供cpu进行判断，但是是临时的，访问速度快，如果关机或断电这里的数据会消失。
（3）磁盘IO：大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以便将来再次使用这些数据。
（4）网络：
资源利用-负载对应关系：

图中拐点说明：
（1）服务器某荐资源使用逐渐达到饱和
（2）通常可以利用拐点来进行性能测试分析与定位

其它常用概念：

TPS：Transactions Per Second，每秒事务数
思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的
点击数：每秒钟用户向WEB服务器提交的HTTP请求数。
这个指标是WEB应用特有的一个指标:WEB应用是”请求-响应”模式,用户发出一次申请,服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求.
PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个网站规模的重要指标。
UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）

性能测试模型

曲线拐点模型

这里写图片描述

X轴代表并发用户数，Y轴代表资源利用率、吞吐量、响应时间。X轴与Y轴区域从左往右分别是轻压力区、重压力区、拐点区。
随着并发用户数的增加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进入拐点区后倾斜率增大，响应时间急剧增加。
接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。
同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。
最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

地铁模型

假设：
某地铁站进站只有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、增大连接数）。

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