性能测试

什么是软件性能和性能测试

软件性能 定义：软件的性能是一种软件的非功能特性，它关注的不是软件是否能够完成特定的功能，而是在于完成功能时展现的及时性。
由以上定义可知性能关注的是软件的非功能特性，所以一般来说性能测试接入的时机是在功能测试完成之后。
由及时性可知性能也是一种指标，可以使用时间或者其他指标来衡量，通常我们会使用某些工具或者手段来检测软件的某些指标是否达到要求，这就是性能测试。

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

不同人眼中的软件性能

每个人都是不一样的人都有其矛盾的特殊性和普遍性，故对于同一事物或者问题的看法可能不同。对于软件性能也是如此，由于不同的视角所关注的点也不同。
用户： 响应时间 稳定性
开发者： 架构 数据库 算法 内存 线程安全与效率 等不同的性能
测试： 测试人员作为软件质量控制的一个角色 ，不仅仅是找Bug，需要对整个软件的质量负责，性能也属于质量的一部分。
1.测试人员需要考虑整体的性能，包括用户，开发，管理员等各个视角的性能
2.除开要关注表面现象还要关注本质，比如用户看不到的服务器资源利用率，架构设计是否合理，代码是否合理等等

性能测试类型和专业术语

          1.负载：模拟业务操作对服务造成的压力的过程，比如模拟100个用户发帖。
          2.基准测试：再给系统施加较低压力时候，查看系统的运行情况并记录相关数作为基础参考
          3.负载测试Load Test：是指对系统不断施加压力或者增加一定压力下的持续时间，直到系统的某项或者多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。
          4.压力测试Stress Test：压力测试是评估系统处于或超过预期负载时候的情况，关注点在于系统在峰值负载或者超过最大负载情况下的处理能力。
          5.稳定性测试：在给系统一定的业务压力的情况下，使系统运行一段时间，一检测系统是否稳定。
          6.并发测试：测试多个用户同时访问一个应用，同一个模块或者数据记录是否存在死锁或者其他性能问题

性能测试指标（非常重要）

系统指标：
响应时间
又叫请求响应时间：TTLB（time to last byte）
对请求作出响应所需要的时间
网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。

并发用户数：
并发用户数：是对服务器产生压力的用户。例如，可能在线的666个用户中，只有20%的用户对服务器产生了压力，这20%的用户数就是并发用户数。
并发数如何估算?
没有准确的估算方式，下面是一个估算方法
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C’ = C + 3根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一
个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系
统。那么：
平均并发用户数为：C = 4004/8 = 200
并发用户数峰值为：C’ = 200 + 3*根号200 = 243
点击率（Hit Per Second）
每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大，服务器压力越大。
这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。
吞吐量（Throughput）
单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒
来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络的角度来说，也可以用字节数/天来衡量。
思考时间（Think Time）
思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。
资源利用率
不同系统资源的使用情况。CPU,Memory，磁盘，网络。

性能测试模型

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

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