性能测试实施心得分享

本文为博主做过了一些性能测试项目之后的经验心得总结，做过的不多，还需要继续积累沉淀，现在写下来给自己做个笔记~

性能实施整体思路

1、需求调研—需求调研阶段要确定的东西：

（1）确定测试接口、接口逻辑、预期tps、混合交易配比；
（2）确定测试执行及监控所用工具；
（3）了解应用服务部署环境及应用服务配置规格；

2、环境和脚本—测试执行前需要做哪些准备：
（1）确定测试环境，保证各接口调用成功，明确其入参和返回值的意思，是否调用外部接口，是否需要加挡板；
（2）对于请求报文较复杂的接口，要明确是否有必传校验、唯一性校验、接口直接是否有关联性等。
如有唯一性校验的参数是否可以去掉校验方便压测。
如不能去掉唯一性校验，是否可以提前让开发准备相应数据配合压测。
如开发不能提供数据，测试人员需内部商讨自行解决，不能解决就寻求帮助。
如果接口有关联性，进一步确定需求是否需要接口关联一起压测。
如果需要分开压测则需进一步沟通，加挡板或准备测试数据。
等等...
（3）对于请求报文很简单的接口，比如查询类接口入参可以只有一个，且对查询类接口影响较大的因素是查询范围里数据的多少，为了更接近实际数据，可进一步沟通需求并提供与实际业务相同的查询数据量。
（4）寻找最简单有效的脚本思路。

3、测试执行—执行过程中的关注点：
（1）jmeter模拟业务请求接口，通过控制并发数量给应用加压，并尽可能找到性能最优点；
（2）测试执行和性能监控同步进行；
（3）添加响应断言，避免有接口请求成功但返回状态码为失败的情况；
（4）相同应用服务配置，正常情况下同一并发数请求过程中，tps呈上升趋势，直到到达该并发的最大tps（拐点除外）；并发数越高，tps越高（拐点除外）；压测过程中出现tps明显抖动时需关注其他指标情况，如接口有无报错，应用cpu情况，GC情况等；
（5）扩展性测试，通过改变副本个数/CPU核数等方法，得到不同服务器配置、相同压力场景的吞吐量变化

（6）异常测试，通过删除副本/kill进程等异常操作，监控服务是否正常运行/重启恢复。

4、性能监控—监控方式及指标等：
（1）性能监控和测试执行同步进行；
（2）专有云和金融云监控利用阿里自带的监控页面，主要关注应用的cpu、内存、JVM性能，数据库的cpu、内存、连接数等；
（3）监控页面无数据或者报错等其他情况及时联系sre部门解决；
（4）未部署在阿里云上的应用监控，采用nmon工具监控应用服务性能；
（5）可随时翻看群里的<性能测试问题集>以便在监控到异常指标时能及时定位问题；
（6）性能相关指标含义不再赘述，自行百度；

4.1、一个nmon监控的小例子（X项目性能测试-信创云测试环境）
（1）ssh连接到X项目信创云测试环境，在此环境下安装nmon监控工具，安装目录无限制；
安装方式一：命令行直接请求下载链接安装（wget http://sourceforge.net/projects/nmon/files/nmon16e_mpginc.tar.gz）但执行的时候X项目信创云测试环境不支持连接外网，下载失败；
安装方式二：下载到本地，然后上传到服务器；（因为连接信创云测试环境是通过阿里云运维管理页面进入并连接的，不清楚目录，无法上传。与开发人员沟通后，通过scp远程文件拷贝的命令，从另一台X项目测试服务器拷贝文件到信创云测试服务器。scp命令可自行百度了解）

 

（2） ./nmon_x86_64_centos7 -F /app/server/nmon/test01.nmon -t -s 10 -c 19

    启动nmon监控并把监控文件存入/app/server/nmon/test01.nmon，10s采集一次数据，采集19次。

（3）scp -r /app/server/nmon co_risktomcat@111.11.111.11:/home/co_risktomcat/tmptomcat/logs

    把nmon监控生成的文件拷贝到X项目测试服务器。

（4）在本地用nmon analyser的宏表格打开.nmon文件，即可查看各个指标情况

测试报告产出阶段

5、性能调优—如何判断性能需要优化：

（1）把压测结果反馈给开发人员，让开发人员判断数据是否在可接受范围内；
（2）提前了解接口的大概逻辑，比如是简单的一个接口请求，还是包含多个接口，是否有数据查询和插入数据库，根据接口逻辑复杂程度和预期交易量判断测试结果是否在正常范围内；
（3）比较相同项目/类似项目的性能结果数据（指部署环境相同或接口相同或接口逻辑类似或接口实际业务类似等）差异较大的，需要反馈开发并协助复现和调优；
（4）测试结果数据出现极端情况，比如tps极低甚至出现个位数/s、tps极高甚至4000以上、响应时间过长出现>500ms甚至1s以上，接口逻辑复杂的需结合实际另外分析；
（5）低并发时应用cpu过高、应用cpu突然升高、数据库cpu突然升高等异常情况；
（6）FGC间断性为1次且影响tps、FGC次数过多且影响tps；
（7）异常数据出现后首先排查脚本编写和执行是否有问题，如是否因同一请求单号入库过多，导致再次请求查询时响应时间过长；