怎样测试服务器压力

下载并安装WAST；

1．设置并行连接数；

2．设置持续时间；

3．其余设置；

注：所有以上的选项可以根据自己的需要进行设置。

设置完成后就可以进行压力测试。测试的步骤如下：

第一步，点击工具栏上的“New Script”按钮，在打开的面板中点击“Nanual”按钮创建一个新的测试项目。在打开的窗口中对它进行设置，在主选项中的Server中填写要测试的服务器的IP地址。这里我们填写192.168.1.20。在下方选择测试的Web连接方式，这里的方式Verb选择get。Path选择要测试的Web页面路径，这里填写/Index.asp即动网的首页文件，WAST可以设置更多的Path。

第二步，在“Settings”功能设置中将Stress Level （Threads）线程数设置为1000。然后点工具中的灰色三角按钮即可进行测试。测试过程中我们可以从服务器的任务管理器中看到CPU使用率已经达到100%，损耗率达到最大。在CMD窗口中使用命令netstat -an，可以看到客户端的IP地址在服务器上的80端口进行了非常多的连接，而且Web网站已经打不开了，提示过多用户连接。

主要内容：

http://jmeter.apache.org/download_jmeter.cgi

用来统一管理待测试的服务器地址和端口

这里将测试服务器地址设置为 http://127.0.0.1:9999

这里的线程组来模拟登录使用只需要执行一次即可，所以单独用一个线程组。

在这个线程组下新建 HTTP请求来模拟登录

我这里登录是用的JSON格式，所以下面设置登录请求头为Content-Type:application/json

测试是否登录成功，新建 查看结果树

运行测试计划

可以看到登录已经成果返回了

1.提取token

新建 JSON提取器

这里 $ 就是返回的JSON对象 $.data.token 就是获取token 然后赋值给 token 变量

2.将token赋值全局变量

新建 Bean shell 后置处理程序

${__setProperty(Token,${token},)} 将token赋值给Token

类似于登录，我们新建一个线程组来测试业务接口

在线程组下有个HTTP信息头管理器，我们可以设置获取全局Token

${__P(Token,)} 获取Token

这样设置后线程组下面的所有业务接口都能复用第一次登录的token了。

前面我们已经获取到全局的Token现在只需要给线程组设置规则就好了

新建 聚合报告

运行，并查看报告

https://www.jianshu.com/p/e31b995d80e3

一、压测流程

可参照上篇压测对抗流程

二、压测需求

需要明确需要压测的环境

需要压测的接口，其中包含接口的入参

需要明确接口的预计qps

需要明确线上机器配置

三、压测准备

3.1、服务端开发准备：

1.根据需要测试的接口，决定需要部署哪些相关依赖服务

2.测试接口对应的服务、接口

3.相关配置

4.相关数据库

5.需要的机器整理，其中包含机器的配置，需要几台机器

3.2、前端开发准备：

1.测试的接口和服务应用

2.域名

3.需要准备的机器

4.根据需要测试的接口，决定要部署哪些相关依赖

3.3、测试准备：

1.准备压测的测试方案和测试计划

2.通过接口确认压测的场景，其中包含每一个接口需要测试的场景，预计接口需要的压测线程。通过测试场景确认测试方案。

3.根据测试计划准备测试脚本

4.根据每一个接口的情况准备对应的测试场景。

5.根据测试场景准备需要的测试数据。其中会包含登录账号相关，接口返回有数据相关等。建议可以将线上的数据库直接copy一份到压测环境中

6.测试申请施压机器的权限

7.施压机上准备压测需要跑的工具

四、压测方案和计划

4.1、编写压测方案和计划

1.压测方案和计划的模板查看

2.在测试方案中将信息进行整合和处理，其中包含需要测试的接口，每一个流程对应的时间节点。

3.测试方案和测试计划确定后需要跟对应的人员（包含服务端开发、前端开发、测试人员、前端运维、服务端运维等）进行评审，确认最终的流程的时间节点。

4.根据测试计划中的时间输出对应的结果。其中包含服务券和前端代码部署、机器申请和部署、测试的测试脚本输出

4.2、测试编写测试脚本

1.确认测试接口是否依赖于登录，是否需要登录信息

2.确认需要测试的接口属于atop接口还是http接口。

3.确认需要编写哪些脚本

4.调试测试脚本5.

自动化脚本或者jmeter脚本编写，可查看jmeter使用

4.3、测试验证测试脚本

1.在日常环境对测试脚本进行验证，确定脚本能够正常跑

2.对测试接口需要的准备数据进行整理

3.对测试接口需要的断言进行准备

4.4、施压机上对压测环境的验证

1.将测试脚本中对应的域名和数据等换成压测环境的数据

2.在压测环境中对环境和脚本进行验证

3.与开发调试压测环境中的问题，并调试脚本问题

4.5、在压测环境中进行模拟压测

1.使用一个接口进行模拟压测，确认需要收集的图标信息、结果是否满足预期

2.确认施压机和压测机器是否正常，是否需要更换

3.确认需要采集数据的采集

4.确认断言方式是否ok

五、压测开始

5.1、正式压测：

1.开始正式压测，将各路人马（开发、运维、DBA等人进行封闭压测）

2.针对压测的接口进行决定接口压测的顺序

3.压测中需要逐渐增加线程数量

4.在压测过程中观察实时的qps和报错相关，并通知开发进行查询对应的接口响应时间。

5.根据接口的链路分别通知对应的人员进行查看压测过程中其接收时间、响应时间等。

5.2、当次压测结果分析：

1.当次接口压测结束后，对结果进行分析，确认压测后的qps、报错率、10%、50%、90%用户的响应时间

2.开发寻找对应浪费的时间，当场进行优化后，可以针对此接口在进行压测，以便找到性能瓶颈问题。

3.压测结果最终是需要找到最大的qps和开始出现报错的并发数

4.当前线程数对应的线程数，如没有达到对应的qps要求，可根据qps进行决定增加多少线程数。若线程数增加后，qps没有提高，大致已经找到qps的极限。

5.3、稳定性测试：

1.找到比较稳定的qps对应的线程数，进行稳定性测试

2.稳定性测试与压测的区别在于持续的时间。

3.可通过稳定性测试进行观察持续性调用接口时系统的表现。

4.后续可根据稳定性测试和压测的qps进行计算出对应的每日能够承受的日活量。

六、压测后测试报告整理

1.测试报告整理

a.对此次压测进行整理测试报告

b.测试报告中需要记录压测对应的时间节点、此次压测对应的qps、此次压测中的错误率

c.此次压测10%、50%、90%用户的响应时间

d.压测过程中出现的毛刺时间节点

e.压测过程中曲线不正常对应的原因。

f.此报告需要开发、测试同步进行整理

g.测试记录压测数据和图标

h.开发记录对应系统的cpu使用率、负载、数据库负载等信息。

i.测试报告模板

---