性能测试

一、性能测试
首先，性能测试想做的事情，类似下图：

这是一个简化过的关于web应用的服务端的性能测试示意图，性能测试想要模拟真实业务场景。当一个应用上线，有很多用户通过客户端访问服务端。他们把请求通过用户界面发送给了服务端，于是在服务端接收到了大量的请求，如果用户数很多，那么服务端有可能承受不了这种压力，进而崩溃，严重的可能导致大量经济损失。
 
性能测试则是希望通过提前模拟这种压力，来发现系统中可能的瓶颈，提前修复这些bug，减少服务器宕机的风险。此外，性能测试还可以用来评估待测软件在不同负载下的运作状况，帮助管理层做一些决策。比如早期有的管理者会希望通过性能测试来评估需要买几台服务器。但，这种做法随着云计算的普及，已经过时。在云计算平台上，硬件资源可以弹性获取，自动调整。云计算也会对性能测试的方式产生影响，包括服务端资源监控在内的很多工作，未来都可以交给云计算平台了。大家也可以关注一下，云计算对传统测试工作的冲击。
二、性能测试的基本流程
下图表示了一个简单的性能测试的基本流程中，我们怎样得到性能测试的结果。

然后，这只是一轮性能测试的开始，得到性能测试的结果之后，还有很多工作：

可以说，这里的调优过程才是性能测试的技术含量所在。这可能也是性能专家这个角色存在的意义之一。而测试人员通过做性能测试，进阶成为性能专家，也是一种发展方向。 
调优的话，主要看调优小组推测的瓶颈在哪里，比如推测瓶颈在数据库，可能让DBA调整一下数据库配置，然后再测一遍。推测瓶颈在第三方提供的设备上，那就咨询一下第三方的技术支持，然后调整一下配置再测一遍。这个调优过程，可能比较长。
 
三、性能测试的前期准备
此外，还有一个性能测试还有一个前期准备阶段：

这里先补充一些名词解释，我只是根据自己理解写一下，并不精确。精确定义大家可以网上搜索，另外我最后会推荐一些参考资料。
 
吞吐量：
表示待测应用对业务的支持量，以TPS或QPS为单位，表示每秒钟能处理的请求数。需要分析业务场景来计算吞吐量。
 
请听题：小明办了一个电影网站，每天有2000个用户会上来看电影，假设每个人都只看一部电影，该电影网站每本电影需要播放两小时。每个用户每次看一本电影会向待测应用运行的服务器发送10个请求，其播放的电影数据存储和传输在第三方，本题中不需要考虑。每天晚上7点到9点为黄金时间，在每天的用户中会有一半人选择在这个时间点上来看电影。请计算该网站的平均吞吐量和峰值吞吐量。

四、关于线上指标的估算
性能测试过程中，我们调研时需要确认指标要求，以下是我总结的几种估算场景
A、监控观察法–准确度高：
针对线上现有接口，存在监控数据（请求量和RT），可以直接查看该接口的某一段时间的调用峰值，将统计粒度换算为每秒请求量（qps）。Rt响应时间
例：某服务1天36万笔（粗粒度统计），平均RT在100ms，指标计算如下
指标=(日量36万/10小时高峰期/3600秒)x5倍保险系数=50qps、rt100ms
例：某服务近期监控请求峰值为1小时36万笔（粗粒度统计），平均RT在100ms，，指标计算如下
指标=(时量36万/3600秒)x5倍保险系数=500qps、rt100ms
(监控粒度粗细和线上监控工具有关，分钟级的类似，除以60s即可)
 
B、类比法–准确度中：
针对新接口或者线上无监控的接口，但存在类似接口的监控，可以类比计算。
例：A接口线上指标为50qps、rt100ms，新接口B的使用场景和A相似度很高，那可以将B接口的性能也指标定位50qps、rt100ms
 
C、估算法–准确度低：
针对新接口或者线上无监控的接口，也没有类似的接口可以参考，仅从产品或者市场调研估算出某一天的量或者某一段时间的量，接下来估算方法和A方法类似。关于RT，如没特别说明，将会采用默认性能要求值（单服务单表类rt<100ms；较复杂接口rt<300ms；大list类或调用链较长接口rt<1s）
例：通过运营数据得知接口A在1天内要完成36万笔交易，指标计算如下
指标=(日量36万/10小时高峰期/3600秒)x8倍保险系数=80qps、rt100ms
 
D、其他情况：
除以上场景外，针对新接口无任何数据，无法给出指标值情况，性能压测不再关注指标压测，仅执行阶梯性的负载测试，压测出该接口的最优处理能力。（此情况存在较大风险，上线后需要时刻关注，请避免此情形。）

五、关于压测策略
我们日常性能压测分为三类：指标压测、负载测试、混合场景稳定性测试，我也建议如果在时间计划允许的前提下，将这三项全部做到！

结合上面说到的指标，多说一点：比如我们某个接口线上指标为200tps,测试环境指标50tps，经过我负载测试，该接口单机都能压测到200tps（可能cpu会占用较高，），那么这类接口的性能风险可以说几乎没有
Tps吞吐量

六、关于指标折算
99%的情况不会在线上环境进行性能压测，
10%的公司会有独立的性能压测环境，而一般都是单机环境，由于机器数量的差异，我们需要对线上指标折算为测试环境压测指标。

Min：最小响应时间
Max：最大响应时间
Error%：本次测试中出现错误的请求的数量/请求的总数
Throughput：吞吐量。默认情况下标示每秒完成的请求数（具体单位如下图）
KB/sec：每秒从服务器端接收到的数据量。
七、整体流程
选择协议——录制脚本——调试脚本——场景设置——运行场景——分析结果

选择协议：了解几个常用协议，一个一个来学习；（目前最常用的是WEB的HTTP协议；这个是重点学习对象，以后有时间时，再学习win socket协议及协议）主要还是根据自己公司的被测系统类型来选择；
录制脚本：如何录制、录制时参数怎么配置等；
调试脚本：运行时设置、集合点、事务、脚本参数化、关联等；
场景设置：了解不同场景设置的区别；
运行场景：如何查看运行日志，分析错误，各种监控器的使用（事务响应时间、系统资源等等）

八、脚本录制的方法
1.JMeter自带的录制功能
      我们说性能测试，特别是借助工具的性能测试，主要分为三个部分：1.获取用户脚本 2.设置负载场景 3.执行压力测试，输出测试报告。这三个流程在JMeter或者Loadrunner都是一样的。今天作为本系列的第一篇，我们来学习下如何利用JMeter自身的录制脚本功能，来实现对百度的网站的脚本录制。
 
前提条件准备：
1.下载并解压JMeter，保证JMeter能正常运行起来。
2.一个火狐浏览器
3.能连接互联网（能打开百度）
接下来，我就一步一步教你如何使用JMeter进行脚本录制，然后测试下录制的脚本。
 
1.打开JMeter
 
这里，我从（https://archive.apache.org/dist/jmeter/binaries/） 下载了一个3.3版本，建议你下载版本和我一样，因为最新JMeter4.0版本UI发生了变化。

2.添加代理服务器
 
点击 “工作台”，然后右键，根据如下图步骤，添加一个代理服务器。

添加之后，界面如下图

注意上面端口号我用红圈给标注出来，下面的步骤我们就需要利用这个端口来录制，接下来会使用端口和目标控制器来管理录制脚本。
 
3.浏览器设置代理
 
打开火狐浏览器，找到高级-网络-设置-设置代理。

下面我们设置填写 localhost 和端口8082

上面除了可以写localhost，还可以输入你机器的IP地址，端口就是随便填写一个，只要不要和系统其它程序的端口冲突就可以，这里我设置成8082，点击确定，浏览器不要关闭。
 
4.添加逻辑控制器
 
       在 工作台 下点击前面添加的代理服务器，右键，点击添加，添加一个逻辑控制器下的录制控制器。

添加完是这样的，我们可以给这个录制控制器重命名下，例如我们录制百度，那么我们就写百度新闻（BaiDu_News），待会录制首页点击新闻链接。

点击HTTP代理服务器，切换到代理服务器配置界面，修改以下两处红圈位置。

第一个是端口号，和我们在火狐浏览器里面设置的端口保持一致，第二个是选择我们百度新闻这个录制控制器，也就是说，接下来我们录制的脚本都是在百度首页点击新闻。注意到这个页面还有一个启动和停止录制的按钮，接下来介绍。
5.启动录制脚本
点击代理服务器右侧里面的启动录制按钮，弹出一个根证书的弹窗，点击确定。

我们开始手动在火狐浏览器地址栏手动输入www.baidu.com，等页面加载完成，我们点击“新闻”这个链接，页面加载完成，我们选择停止录制，然后点击展开BaiDu_News这个录制控制器，可以看到以下这些请求。

上面点击根路径（/）这个请求，右侧HTTP请求页面可以显示请求的服务器是百度新闻。关于左侧这些请求编号，一般是从启动JMeter第一次录制开始计数，从1开始，上面我只记录了6个不同请求。
 
注意：可能在录制点击新闻过程中，出现“代理服务器拒绝连接”的错误。一般来说，因为你设置了代理，只有JMeter没有启动录制，你直接在火狐浏览器操作点击新闻，应该会报这个错误。但是录制过程中也有可能，这个就是JMeter代理录制脚本不稳定性的一面。
6.录制脚本
 重复以上4和5步骤，录制一个脚本。

如果你录制的请求编号和我不一致，没有关系，大致看得出录制上了就可以。我们就录制这两个页面，接下来，我们在线程组里面进行测试回放一下录制的脚本。
注意：
只要你确定不再使用JMeter进行脚本录制，那么你要记得把火狐浏览器的网络代理给设置回来，点系统默认代理。

7.测试运行录制的脚本
我们点击测试计划，然后添加线程组。

然后把HTTP代理服务器下的两个录制控制器，拖拽到线程组下，并且给线程组添加一个结果树监听报告。

点击 运行（会提醒你保存当前测试计划），观察结果树报告。

测试结果来看，我们录制的几个动作的脚本是可以用来进行压力测试。
 
 
2.使用jmeter进行App服务器压力测试
1、打开jmeter，在测试计划中新建一个线程组，该线程组可以不用设置。
2、在工作台中新建一个HTTP代理服务器，

在HTTPS Domains中填写打开jmeter的电脑的ip地址（在dos命令行中使用ipconfig可以查看网络地址信息），注意的是，该电脑与测试手机应该处于同一个wifi网络，然后是目标控制器选择刚刚在测试计划中新建的线程组（使用测试手机进行测试的时候，会把所有的请求都放在该线程组下面），其他设置有兴趣的同学可以深入研究。
3、下面以iphone6，ios11测试为例：
在wifi中设置所在网络的代理服务器：

选择手动：

服务器填写刚才的IP地址，端口号根据代理服务器中的端口进行设置，默认应该是8888。
4、设置完了之后，使用测试手机运行app，在操作app过程中所有的请求都会被记录在线程组中，操作完之后应该可以在线程组中看到许多url请求：

可以根据需要删除部分不需要测试的请求。
5、线程组中得到需要压测的请求之后，根据需要设置线程组的属性，然后添加监听器，这里我添加的是查看结果树以及聚合报告监听器，准备就绪之后点击绿色的三角按钮运行线程组，执行完之后，可以在查看结果树中查看请求运行状态：

九、性能测试数据

在聚合报告中可以看到每个请求的基本信息：

图形报表

图表底部参数的含义如下：
样本数目是总共发送到服务器的请求数。
最新样本是代表时间的数字,是服务器响应最后一个请求的时间。
吞吐量是服务器每分钟处理的请求数。 
平均值是总运行时间除以发送到服务器的请求数。 
中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。 
偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。