性能测试——实战

一、实战

一、背景

公司之前的测试团队做API的自动化测试都是使用JMeter等工具来进行，这样的话测试效率而言不是那么很高，而且在扩展性方面不是很有竞争力的。所以开发了新的测试平台，但是考虑到公司的测试⼈员有1000⼈，那么就需要验证1000⼈同时使用测试平台，是否会出现平台无响应以及崩溃（雪崩）的情况

二、性能测试过程

测试前期准备（前置⼯作）

序号	⼯作内容	负责⼈	时间	备注
1	测试场景梳理	小陈	2022.18-2022.18
2	资源采购(阿里云服务器)	李四	2022.18-2022.18	与⽣产保持⼀致
3	⽬标输出	小陈	2022.18-2022.18
4	测试数据的准备	小A	2022.18-2022.19	需要10万数据
5	人员不够	测试经理协调	2022.18-2022.18

测试工具引入

基于梳理的业务场景，和服务底层稳定性体系的保障，性能测试⼯具的选择具体如下：

序号	⼯具	选择理由	备注
1	JMeter	开源，可以做常规以及并发测试
2	Locust	开源，基于协程，来测试服务稳定性这部分	验证服务是否出现崩溃
3	JVM监控⼯具	检测服务是否出现OOM
4	Grafana&InfluxDB	数据可视化报表展示

三、测试计划

1、背景

2、前置工作

人员配备

序号	工作内容	负责人	时间	备注
1	测试场景梳理	小陈	2022.18-2022.18
2	资源采购(阿里云服务器)	李四	2022.18-2022.18	与⽣产保持⼀致
3	⽬标输出	小陈	2022.18-2022.18
4	测试数据的准备	小A	2022.18-2022.19	需要10万数据
5	人员不够	测试经理协调	2022.18-2022.18

技术（工具）选择

序号	⼯具	选择理由	备注
1	JMeter	开源，可以做常规以及并发测试
2	Locust	开源，基于协程，来测试服务稳定性这部分	验证服务是否出现崩溃
3	JVM监控⼯具	检测服务是否出现OOM
4	Grafana&InfluxDB	数据可视化报表展示

测试范围

序号	场景	目标	负责人	时间	是否完成	备注
1	测试并发登录	满足100人同时登录	小A
2	产品列表加载	同时满足50个人加载,响应时间小于5秒	小A
3	产品搜索	同时满足50个人加载,响应时间小于5秒	小E
4	同时⽀持执行API测试用例	响应时间小于5秒,最⼤并发100	小B
5	上传⽂件最⼤⽀持2G	不能出现OOM	小C
6	⽀持持续的发送API请求	验证服务的稳定性	小D

3、测试风险

目前无风险

四、测试设计与开发

1、JMeter工具

1、测试并发登录——满足100人同时登录（有两种方式可以操作）

在测试过需要并发人数要求的结果后，也可以选择增加左右10人的操作，可以得到一个类似响应时间和同时登录的人数的函数，为后续服务器加载人数使用提供参考

注意：这种方式仅能保障每次启动100人，但无法保证立即执行登录操作

2、等待2秒后，可以保证每次都是启动100人

2、产品搜索

与登陆设置一样，有两种操作思路，操作中可以同时使用。当服务满足100个人同时登录时，再验证一下90和110个人同时登录的情况

3、产品列表加载

与产品搜索同理

4、同时支持执行API测试用例

首先在测试平台上设计相关的api测试用例，点击运行。打开jmeter填写测试用例，再考虑并发。

该场景有两种操作思路，通常一起使用更有说服力。当服务满足100个人同时登录时，再验证一下90和110个人同时登录的情况，设计思路与测试并发登录一致

测试最简单的方式:

在测试并发登录时，如需要满足50个人同时登录该测试平台，我们可以先测试一个人登录，看响应时间是否超过5s，如果超过5s表示需要优化，可不进行50个人同时登录该测试平台的测试，直接与开发沟通优化

5、上传文件最大支持2G（非功能性验证）

当被测平台的文件上传服务，最大支持上传2G的文件时，我们对平台做性能测试时，可以上传2G的文件，然后看上传过程中是否会出现timeout（解决办法：把文件先进行拆分，如拆分成4个500兆的文件，然后在进行上传，上传成功后再合并）、上传成功的文件是否会缺失或者上传成功的文件是否会乱码或者文件错乱。（出现socket表示网络层出现错误）

文件上传服务监控是否会出现内存泄露的步骤：打开JVM工具——获取pid——通过jvisualvm查看监控（CPU和memory）——页面操作文件上传——观察日志，如果日志中出现java.long.out of memory