接口性能测试是用于验证应用程序中的接口是否可以满足系统的性能要求的一种测试方法。确定应用程序在各种负载条件下的性能指标，例如响应时间、吞吐量、并发性能等，以便提高系统的性能和可靠性。本文主要讲述接口性能测试从前期准备、方案设计到环境搭建执行及数据收集整理的完整流程。
本文主要根据自身经历介绍如何进行接口的性能摸底测试，进行摸底测试前需要进行哪些准备，如何执行，执行后结果分析与测试报告输出。
1 确定测试目标
明确性能摸底测试的目标，确定要测试的接口和预估性能指标，例如评估接口的响应时间、吞吐量、并发性能等性能指标；服务稳定性、资源消耗情况评估。可以从如下方面了解性能需求：
1、项目立项时定义的性能指标
2、产品或运营人员站在用户角度提测的性能需求
3、项目技术负责人从技术角度直接提测的性能需求
2 收集业务需求
2.1 系统未上线或新上线用户数据量少
与产品、项目侧沟通确认预计试用推广后正常使用该系统的用户量、活跃用户比例、系统工作时长，单业务每人每天平均调用次数和预估目标TPS，可参考下表。
2.2 系统已上线有稳定用户量
1、若系统已经投入使用且有一定的用户数据量，则与运维人员沟通拉取现网真实业务请求数据，详细要求可参考如下表格
2、业务选取原则如下：
1)系统选取占总业务量80%的业务，做为基础业务模型；
2)据业务量大小选取典型业务，一般通过统计现网系统业务量排序TOP10、TOP20确定；
3)选取现网系统中消耗资源最多，或者耗时最长的业务；
4)选取现网系统中业务路径最长的业务；
5)选取现网系统容易发生故障的业务；
6)为满足其他特殊测试目标需要选取的业务。
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036【暗号：csdn999】
2.3 环境调研
1、系统架构调研：
2、服务器配置调研：
3、数据库配置调研
2.4 铺底数据调研
2.4.1 铺底数据量调研
1、对于已上线且成熟的系统，数据库表的数据量可由现网获取；
2、对于未上线或刚上线的新系统，数据库中数据量相对较少，系统整体响应时间很快。随着业务的持续开展，数据量会成倍地增加，业务系统的相关操作响应时间会因为数据的快速增长等原因变长。因此，在性能测试时，需要加入相当规模的铺底数据，来模拟未来几年业务增长条件下系统相关操作的性能表现。可与产品、研发和业务方共同评估系统上线后2年后数据库的数据量，可根据业务正常推广后面向客户群数量估算；（估算方法可参考：面向客户群数量为M,每个用户产生数据量N条,该表的数据量为M*N） 。
2.4.2 铺底数据检查注意事项
1、数据量是否合理：数据量需要预估一下未来几年的数据量，来进行数据构造
2、数据构造尽可能贴合实际使用情况
3、数据分布是否合理
1）有的是数据库集群，数据的分片需要检查一下构造的数据分布是否均匀，每台服务器上分布的数据量是否差异很大；
2）查看是否有数据集中的问题，比如有一个查询交易，这个数据分为a、b两种类型。
3.1 测试场景设计
根据需要压测的业务和性能期望，分别进行基准场景、单业务压测场景、混合测试场景和稳定性场景设计详细的测试方法。
3.1.1 基准测试场景
获取单个业务在无压力的情况下的基准响应时间及验证测试数据正确性，作为其他场景的参考依据。一般情况下，建议一个脚本(线程)只包含一个完整的业务，不要把多个业务放到一个脚本中。因为，不同的业务其响应时间会不同，响应时间较长的业务会成为“瓶颈”。
3.1.2 单业务测试场景
单业务负载的场景是为了找到单个业务的最优TPS，检测单业务在并发情况下是否存在性能瓶颈。
单业务最优的衡量标准通常以应用或数据库等系统的CPU使用率不大于70%为标准。一般在生产上运行的应用，如果CPU使用率长期处于高水平那是非常严重的问题，应用的节点随时都可能挂掉。单业务设计压测场景可以从10个并发用户开始，执行几分钟后再增加10个用户，直到应用CPU使用率超过70%为止，找到TPS增长的拐点，确定最优TPS。
3.1.3混合测试场景
按照测试模型中的业务比例及目标TPS，对每个业务分配不同的并发用户数量，设置不同的延时，同时进行加压，通过多个子场景的不断尝试最终测试出应用能够达到的最优TPS。
3.1.4稳定性测试场景
给应用一个恒定的压力，使场景运行较长的时间，用于测试应用在长时间运行下的表现，TPS是否有较大波动、是否有错误和异常、是否存在内存溢出等。
根据业务类型不同一般会运行不同的时长，对于5*8这样的应用稳定性运行8小时即可，7*24这样的应用最好能够运行12小时以上；恒定的压力大概选择最优压力的80%为目标压力。
3.2 测试脚本准备
确认好测试工具和场景后就可以编写测试脚本，这里以jmeter脚本为例
1、基准压测：启动jmeter，添加线程组编写脚本，设置好基准测试时间和线程数就可执行
2、设置阶梯加压： 启动jmeter，添加线程组——jp@gc - Stepping Thread Group，设置阶梯加压方法编写脚本后即可执行
3、混合测试吞吐量设置：启动jmeter，添加线程组设置执行时间，添加吞吐量控制器—Throughput Controller，按一定的比例或数量分配设置每个接口的线程数，设置好后执行脚本即可
4.1 测试环境要求
1、硬件配置尽量和生产环境保持一致；
2、选用与被测软件相一致的操作系统和软件平台；
3、营造相对独立的测试环境；
4、系统架构和生产环境一致。
5、和生成环境在同一局域网
4.2 数据准备
测试时需要模拟数据量，尽量跟前期调研的数据量保持一致，可以从生产库导数据，或通过Loadrunner、Jmeter、DataFactory等方法生产数据。
5.1 脚本执行
当测试方案设计评审通过后，即可开始执行，在压测机上面执行脚本的同时观察是否有报错，及时查看日志寻找报错原因，可找研发协助解决。以下举例几种比较常见的错误。
1、不要在本地进行压测，要选取合适的压测机进行测试。本地端口有限，压测线程起来就容易占满，后续的就连接不上了，会导致接口大量报错，需要修改端口回收时间。
2、压测前先检查下服务磁盘空间，避免因服务磁盘空间不足导致压测中断，下图就是在压测过程中磁盘空间满了的错误和查看磁盘空间方法。
3、压测过程中并发增大过快等待时间过长导致的超时或接口不稳定概率性报错，此时需要查看日志找出报错的具体原因，可找研发协助排查分析
5.2 性能监控
在脚本执行过程中及时监控CPU使用率、内存溢出、是否有慢sql等情况
如果业务有集成监控可直接观察如Grafana平台，没有集成监控可使用服务器资源监控工具nmon、mysql性能分析工具MONyog等监控工具。
5.3 慢sql监控
除了监控工具外，还可以通过数据库配置的慢sql时间和log路径查看到慢sql情况，可以让运维人员帮忙导出日志信息。
5.4 结果记录
测试完成后记录过程数据，便于分析统计。可以通过jmeter查看tps和响应时间趋势。查看tps选择监听器jp@gc - Transactions per Second；查看响应时间选择监听器jp@gc - Response Times Over Time（需要安装jar包：将JmeterPlugins-Standard.jar和JmeterPlugins-Extras.jar放到jmeter安装路径/lib/ext中）
将测试的数据收集后进行整理分析，与预期结果进行对比，判断性能指标是否达到期望，并提出改进意见。
-
本文详细描述了接口性能摸底测试的完整链路，以及测试过程中可能遇到的问题和解决方法，希望对想要学习或需要进行接口性能测试的业务侧人员提供设计思路和指导。
END今天的分享就到此结束了，点赞关注不迷路~
