中小型系统必要可行的性能测试实践--性能测试理论基础

一、开发人员掌握性能测试的必要性
　　一说起测试，大部分想到的是业务功能测试。其实功能测试只是测试的一部分，另外还有性能测试、自动化测试、全链路测试、安全测试，不同规模、不同业务类型的的公司各有选择。自动化测试借助自动化工具代替人工按照预设条件进行测试，也可用于持续集成（比如和jenkins整合），目的提高测试效率；全链路测试通过一次测试尽可能将系统的所有业务链路全部验证完成；安全测试验证产品符合安全需求；性能测试对系统的各项性能指标进行测试，在不同场景下系统的性能表现，检验系统的稳定性、可靠性，识别系统瓶颈和弱点，检查系统隐藏的深层次的问题，而这些问题恰恰是大部分开发人员忽视、经验匮乏的地方，因此开发人员应该掌握性能测试，去主动的发现系统性能问题并改进。

二、功能测试与性能测试的区别
功能测试：系统提供的对应功能能否正常使用，是否复合原型设计；一件事有没有做，能不能用。
性能测试：不同情况下的性能表现；系统能否在极端情况下使用；一件事做的好不好，用的爽不爽。

举个例子：汽车厂造了一辆车，测试员开始测试这辆车：
功能测试：轮胎能不能跑；方向盘转弯了，车子是否转弯；刹车踩下去车辆是否能减速或刹住；车座位能不能做人等等；
性能测试：轮胎在下雪天、沙漠里、乡村道路、坑洼路面、被子弹击中、地雷炸等场景下行驶是否还能跑；刹车在速度100KM/h、200KM/h下能否刹住；座位能否承受住100KG、200KG的重量等。侧重同样的功能，在不同的场景下的性能表现。

三、性能测试流程
1、性能需求分析：客户希望的程序性能标准是什么？

一般来说性能需求有三类：
　　1）没有明确需求的基准性能测试，用于摸底这个系统目前的性能指标数据，一般常见于小公司，常见的说法：给一个测试报告；
　　2）明确的性能需求：给定性能指标，看是否达标，一般是中型公司；
　　3）出于性能优化的性能测试，一般是大公司，就是边测边改进，先测出性能数据，发现哪些指标不太理想，然后进行瓶颈分析并给出调优建议；
一般小规模系统基本不会做性能测试；中等规模系统做的比较简单；大规模系统一定会做专业的性能测试。一般测试人员会找项目经理、产品经理、业务人员、架构师、开发沟通，有些产品经理说的很笼统，XXX场景不要太慢，1s内出结果；或者只有一句话：做一下测试，看看系统性能怎么样？而大规模系统一般会有专业的性能测试方案。从这些岗位的视角主要关注的是并发量和响应时间，不太了解专业的性能测试指标，我们需要跟他们不断地沟通中分析出来真实的性能需求，要把这些诉求转化为专业性能测试指标，最后产出制定性能测试计划或测试方案。

（1）核心性能指标-并发量
单就性能指标而言，系统的并发用户数是指系统可以同时承载的、正常使用系统功能的用户总数量。

客户经常会问：我们的系统最多能处理多少并发？能不能抗住1000并发？
回答这个问题，先要明确问题里的并发指的是绝对并发还是相对并发？
a、绝对并发：同一时间有多少请求给服务器处理，在一些长连接的场景中更容易出现，发生绝对并发概率会高一些。比如实时聊天室、websocket通信等等，但也不会保证同时给服务器，比如每秒多少个请求，传输过程中有损耗等原因，没法保证这些请求是同时被服务器处理，所以不存在真正意义上的并发。
b、相对并发：一段时间内，服务器需要处理的请求数量，常用单位是1s：比如web应用，基本都是短连接的http请求，请求-->响应，然后就结束了。

　　请求基本上是离散的到达服务器，基于这种事实，我们所说的并发一般指相对并发。有的人可能说使用jmeter的同步定时器，通过集合点方式控制请求一并发出。这也不是一定会产生绝对并发：首先设置1s内集合1000个请求发出，实际上结果第一秒内不一定发出1000个请求，可能第1s发出600个第2s发出400个，为什么？因为这需要压力机有足够的资源才能做到这一点；其次即使同时发出1000个请求，受到网络带宽、网络质量等原因，这些请求也不一定会同时到达服务器。集合点会提升并发数的概率，但并不一定实现定量请求的绝对并发。另外有人会在性能测试时加上思考时间用以模拟现实中人工操作，思考时间对性能测试的结果不会有本质意义的影响，不会因为增加了思考时间之后，系统该有的那些瓶颈就不会暴漏出来，所以不必太过纠结是否要加思考时间。

（2）核心性能指标-响应时间
计算的是端到端的时间，通俗讲是指从客户端发出交易请求到得到响应的整个过程。

（3）核心性能指标-吞吐量指标QPS、TPS

按照经典理论模型计算吞吐量TPS或者QPS应该是等于并发线程数除以平均响应时间，N  * （1 秒 / avgT 秒） = N / avgT。

按照监控数据统计角度计算：

　　QPS：每秒查询率（QPS = req/sec = 请求数/秒），是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
　　TPS：系统每秒处理交易的数量，单位是笔/秒。通常表示一次交易申请和响应返回的过程。

TPS计算公式：总的事务数/总的运行时间
比如：某一系统1分钟处理1000个事务，那么TPS=1000/60=16.7
比如：按去年的经营数据，2023年最高的一天有10万笔交易。预测2023年TPS需要多少合格？
总事务数=10万，时间=24*60*60=86,400秒
理论上TPS = 100000/86400=1.2
(1)如果没有更详细的数据：根据二八定律（80%的事务在20%的时间完成）计算：
TPS = 100000*0.8 / 86400*0.2=80000/17280=4.6
(2)如果有更详细的数据：5万比交易是晚上的8-9点完成的。
TPS=50000/3600=13.9
再考虑将来业务的增长：30%，那么新的值：
TPS=（50000+50000*0.3）/3600=18

（4）核心性能指标-成功率
在高并发状态下，程序是否会出现处理失败的情况。10000/s的请求，失败了100，成功率99%。
性能测试中，失败是否可以接受要区分分业务场景，查询场景有小部分失败是可以接受的，但是涉及到钱的场景（比如转账、支付等）是不允许接收的。

2、性能测试计划和方案制定。
主要有基准测试、负载测试、压力测试、稳定性测试，其他：配置测试，极限测试，浪涌测试。
3、性能测试准备阶段
人力，硬件，软件，环境折算。运行环境要干净，不相关的都不要装，条件允许的情况下，要和生产环境一模一样。

4、执行性能测试：检查程序在不同场景下的性能表现？
（1）用例场景设计
　　a、用户量增多场景（梯度压测）：通过不断地增加用户数（1个、10个、100个...）,不断的消耗系统的资源，以达到系统的瓶颈。

　　b、用户操作流程：单接口、多接口测试

（2）脚本生成与增强：使用工具jmeter、loadrunner(收费)、locust

（3）用例执行

　　比如：
　　　　a、1个用户 单接口 压测时长30s
　　　　b、10个用户 单接口 压测时长30s
　　　　c、10个用户 多接口 压测时长30s

（4）指标监控和收集
　　a、jmeter监视器：查看结果数、聚合报告、Hits per Second(每秒点击数HPS)、Transactions per Second（每秒事务数TPS）、Response Times Over Time（响应时间）、Active Threads Over Time（每秒活跃线程数）、Composite Graph（可以将上述四个图表整合在一张图上的复合图查看器）、PerfMon Metrics Collector+ServerAgent(服务器资源监控插件)
　　b、生产中一般用：jmeter无界面压测 + influxdb + Prometheus + Grafana,可以进行横向数据对比、直观、漂亮

　　c、监控程序，比如java程序就要监控JVM，mysql、nginx、redis、MQ，可借助阿里的Arthas深层次的监控java程序各项数据。

5、性能问题分析：性能瓶颈定位和性能调优

（1）结果分析
　　比如：平均响应时间5s > 客户要求3s,性能测试结果不符合要求【瓶颈】

（2）【瓶颈分析定位】非常重要：

　　1）什么是系统瓶颈？系统为什么会有性能瓶颈？系统的瓶颈在哪里（拐点）？
　　程序运行是需要占用系统资源的（CPU、内存、网络、磁盘等），而资源是有限的，当某一个资源被用光之后就会碰到瓶颈。 补充一个带宽的小知识：通常服务商所说的100Mbps指的是bit/s，而我们生活中通常所说的都是Byte/s，所以转化为我们理解的带宽要除以8，那么100Mbps/8=12.5MBps。从广义的角度来讲，系统瓶颈不单单指系统资源用光了，比如响应时间超过客户要求，也可以称之为达到了系统瓶颈，这个瓶颈的概念不绝对，只是大家常用来指系统资源的消耗。
　　2）系统是否到了瓶颈？
　　----如果没到，什么原因导致出现了性能问题？
　　　　如果系统资源未被完全消耗完，就出现了性能问题。那就要从程序着手分析，结合程序监控数据，比如java程序就要看JVM、mysql、nginx、redis、MQ等指标数据，借助yourKit、Arthas等工具深入分析程序中资源利用情况，线程、堆内存、连接数、缓存、索引、超时时间等等，导致性能问题的原因各种各样，没有规律，这个地方是难点，需要具备丰富的技术积累（广度+深度）。
　　----如果到了，什么原因导致系统到了瓶颈？
　　　　监控系统的资源使用情况，比如压测过程中发现CPU使用率到达100%，其他资源使用未达到极限值，这个时候系统就到达了瓶颈值。

这里我们再来回答客户的问题：
<1>我们的系统最多能处理多少并发？能不能抗住1000并发？这里的并发一般指相对并发，系统能处理的并发量约等于最大吞吐量，为什么？
举例：一个程序，每秒只能处理100个请求，也就是tps=100/s;
　　1秒 来了100个请求 ---> 程序1秒内全部能处理完毕；
　　1秒 来了150个请求 ---> 处理不过来了，其中100个请求1秒钟内能处理，多出来的50个请求就要等待到下一秒，下一秒又回来150个请求，会有100个请求延迟到再下一秒，以此类推，会产生大量的请求积压，就可能会垮掉。
<2>那如何确定系统的最大的吞吐量？
使用梯度压测，逐步增加线程数；线程数增加，并发量就增加；并发量增加，吞吐量会随着增加；吞吐量到达一定值以后，不再增加，趋于平稳，此时吞吐量对应一次系统瓶颈。
<3>为什么会出现这种情况？
把系统=银行营业厅，柜员数量=服务器CPU/内存/网络/磁盘资源
银行柜台例子：10个银行柜员，处理存取款业务，每个柜台每次处理业务，需要1秒钟。
每秒来了5个人去办理业务---->银行营业厅吞吐量：5/秒，平均响应时间：1*5/5=1秒
每秒来了8个人去办理业务---->银行营业厅吞吐量：8/秒，平均响应时间：1*8/8=1秒
每秒来了10个人去办理业务---->银行营业厅吞吐量：10/秒，平均响应时间：1*10/10=1秒
每秒来了15个人去办理业务---->银行营业厅吞吐量：10/秒，平均响应时间：(1*10+2*5) / 15=1.33秒 （这是理想情况，未考虑下一秒会有新的一批请求）
每秒来了50个人去办理业务---->银行营业厅吞吐量：10/秒，平均响应时间：(1*10 + 2*10 + 3*10 + 4*10 + 5*10 )/ 50=3秒 （这是理想情况，未考虑下一秒会有新的一批请求）
柜员数量是有限的，随着每秒客户数量增加，吞吐量逐渐增加到最大值，平均响应时间逐渐增加。

（3）调优建议
如果是未到达系统瓶颈而出现性能问题，就要根据JVM、mysql、nginx、redis、MQ监控数据分析得出的原因结论给出优化程序的建议；
如果是到达了系统瓶颈导致了性能问题，两个方面建议：
　　1）提高机器配置：比如CPU资源是第一个被消耗完的资源，那么就要增加CPU，原先是2核，建议增加到4核；
　　2）优化代码：如果公司觉得提高机器资源成本高，那就让开发人员从代码角度提升程序性能；

6、输出测试报告和总结