上周刚刚做完项目的性能测试。今天整理和总结一下，随便分享给大家。

首页呢，测试前，我们是有明确的性能指标的，而且测试环境和数据都已准备好，业务分析、场景分析大家根据自己的项目系统进行分析设计，我们选用的都是实际用户操作频繁、重要级别高的。还有一个好说明下，今天分享的是Jmeter做APP端的单接口性能测试。下面开始分享吧。

先贴一张我的脚本：

第一步，环境是运维搭建好，那我们只需要准备脚本和脚本数据。从上面的图中可以看出，我们需要准备：

1、需要开发帮忙去掉系统中的手机验证码、token的校验，因为我们是单接口，因此是绕过登录的，token校验呢去掉，用户ID的校验还是要保留的。

2、脚本数据：我用的是CSV，每个接口的请求数据，比如关键字查询，我们的业务是用户登录成功后，在首页可以进行关键字查询。那么我在我的CSV文件中准备了200个账号的用户ID和对应的关键字，根据你的性能指标去准备需要用多少个账号，当然，你也可以就用一个账号，不过还是没有前者实际。

3、编写接口脚本，除了去掉token校验和验证码校验，我们还需要自己在脚本中处理参数和参数的加密以及时间戳等，我用的是JSR223 中的JS，引用了一个外部js文件做加密处理。当然如果开发愿意，也可以协商去掉密码。脚本编写好了，要在测试环境进行测试，看是否能跑通。

4、添加一个定时器，用来确保按照需求进行正确的并发。

5、添加Jmeter插件，监控压力机与服务器的硬件性能情况。比如CPU、内存、网络、磁盘读写。

以上步骤全部搞定，那么性能测试工作就差不多准备完了。

第二步，开始执行。这个步骤很关键也很深。很多人对Jmeter做性能测试，认为只是简单的设置线程数就OK了。其实不然。

1、保证我们的脚本执行正确、发送正确的参数，得到正确的响应。那我是添加了结果响应断言，来确保结果的正确性，还有一些注意的，比如：

2、确保正确并发。单纯的设置线程数量和Ramp-up是达不到真正的并发的，可以通过结果观察树，查看每个请求的开始时间是否一样。这里呢，我是通过定时器来做的，如下：

 

线程数设置10，ramp-up设置5，循环1次。定时器中的组合设置10，超时设置10秒。意思就是：

5秒内启动10个线程，等全部启动完，也就是说10个线程准备好了，再一起发送，这样的操作执行1次。

线程数，不多做解释了，大家都明白。

Ramp-up：这个呢，字面意思也是很好理解的，就是在设置的时间内启动设置的线程数，启动完一个发送一个。那么会出现些什么情况呢？

                  a、设置的时间过短，不能在设置的时间内启动全部线程 （这也会为什么定时器的超时哪里要设置比Ramp-up的值大或等于的原因）

                  b、压力机不同，在相同的时间内，能启动的线程数量不同。这个就要看配置了。

                 一般我是先设置3秒或者5秒来测试自己的压力机合适设置多少。

定时器超时时间：如果Ramp-up设置的时间内，没有全部启动线程，就会处于等待状态，等待的时间就是这个超时时间。

所以，在做并发测试的时候，一定要注意，每个请求的开始时间是否一致

3、分布式，大家都知道，单台压力机可能不够，那么需要用到多台压力机，这就是Jmeter分布式的运用。具体用法百度很多，需要注意以下几点：

    a、每个压力机上都需要放脚本，而且路径一致

    b、使用了CSV文件的，也需要保存每个压力机上的CSV文件一致，脚本修改都要同步更新，保持一致

    c、每个压力机上的本地时间要保存一致，最好是同步Intelnet上的时间。不然并发也达不到真正的并发。

4、注意压力机自身的压力瓶颈。测试的过程中，要时刻观察压力机的情况。有时候线程数较多，一起并发，会瞬间对压力机产生很多压力。

5、观察服务器的性能变化。

6、建议在执行的过程中，要逐步加压，找到RT与TPS的交叉点（即TPS由上升到下降的那个点）

 

7、最后还要建议，测试的时候，最好选用压力机的配置不要太差，还有网络。

好了，测试完成，大家要开始写报告了，把你的测试过程、测试结果、以及你的分析写出来吧。

其实这也是我第二次真正意义上的做性能测试，自己也是一边学习一边摸索，其实我觉得性能测试是分成两个部分的，一个部分是测试执行，一个部分是问题分析，今天给大家分享的是测试执行，至于问题分析，可是很深的一门学问，需要慢慢累积，不过大家只要先保证，测试方案得到评审，测试也是正确的执行，这个过程中，其实你就会发现很多问题和学习到很多东西，最后把这些报告，然后协助开发一起分析问题，弄懂问题的原因，我想我们就会越来越能干了。欢迎大家来讨论。