浅看性能测试项目实战之风暴平台
1、背景公司之前的测试团队做API的⾃动化测试都是使⽤JMeter等工具来进行，这样的话测试效率⽽⾔不是那么很⾼，⽽ 且在扩展性⽅⾯不是很有竞争⼒的。所以开发了新的测试平台，但是考虑到公司的测试⼈员有1000⼈，那么就需要验证1000⼈同时使⽤测试平台，是否会出现平台⽆响应以及崩溃（雪崩）的情况。2、性能测试过程2.1测试前期准备（前置工作）https://pic3.zhimg.com/80/v2-cddf9f20b68c2d03ef7f62b42507b0e6_720w.webp
2.2测试工具引入基于梳理的业务场景，和服务底层稳定性体系的保障，性能测试⼯具的选择具体如下：https://pic1.zhimg.com/80/v2-e3f6512fc949c3e12480e6a5e17f90e4_720w.webp
2.3测试计划2.3.1背景公司之前的测试团队做API的⾃动化测试都是使⽤JMeter等⼯具来进⾏，这样的话测试效率⽽⾔不是那么很⾼，⽽ 且在扩展性⽅⾯不是很有竞争⼒的。所以开发了新的测试平台，但是考虑到公司的测试⼈员有1000⼈，那么就需要验证1000⼈同时使⽤测试平台，是否会出现平台⽆响应以及崩溃（雪崩）的情况。2.3.2前置工作（1）人员配置https://pic2.zhimg.com/80/v2-682b3ed62ca65c4493ffa682dfb4eb35_720w.webp （2）技术（工具）选择https://pic2.zhimg.com/80/v2-38fecccc523cec2a0921fcb8d58f94f5_720w.webp （3）测试范围https://pic3.zhimg.com/80/v2-64f247d1e147db2727d0a8ecbef0a876_720w.webp （4）测试风险目前无风险，一般情况下，无风险，就可以填写无。2.3.3测试设计与开发jmeter工具jmeter如何写接口的测试用例，在接口测试里说过，此处不再赘述，本次通过浏览器的network抓取接口数据。（1）测试并发登录该场景有两种设置设计思路，一般一起使用，比较有说服力。当服务满足100个人同时登录时，再验证一下90和110个人同时登录的情况，可以得到一个响应时间和同时登录的人数的函数，为后续服务器的使用提供一个参考数据。使用调度器的设计思路，可以保证负载达到目标要求。https://pic4.zhimg.com/80/v2-f3d2e0a2e1cb82fd4de52d1206e7a617_720w.webp 不使用调度器的思路，这种方法无法保证服务器的负载达到要求。https://pic2.zhimg.com/80/v2-b8189db3d78f6f0b3f4d8fece38c11a1_720w.webp（2）产品列表加载该场景有两种设置设计思路，一般一起使用，比较有说服力。当服务满足50个人同时登录时，再验证一下40和60个人同时登录的情况，可以得到一个响应时间和同时登录的人数的函数，为后续服务器的使用提供一个参考数据。使用调度器的设计思路https://pic2.zhimg.com/80/v2-726d4dda4e3ee9ba367948b1e5fd85bd_720w.webp不使用调度器的思路https://pic3.zhimg.com/80/v2-e8d145b154f18f7443cb548df7960f96_720w.webp（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.log.out ofmemory表示内存泄漏。loucst（6）支持连续的发送api请求该场景需要用到locust工具，我们首先需要创建locustfile文件夹，内容如下：
https://pic4.zhimg.com/80/v2-914c6835f3f15259ccd84f51e9f6d95f_720w.webp接下来，我们打开控制台进入存放locustfile文件的目录下，输入locust -f locustfile文件夹的文件名，然后进入locust网站，进行场景设计，发送请求，然后点击charts就可以查看到响应时间等数据表。2.4测试执行与管理执行我们的测试计划，收集监控结果。以测试并发登录的场景为例，我们通过jmeter执行测试计划，然后通过Grafana进行数据的检测，我们主要需要添加如下图所示的两项资源：https://pic1.zhimg.com/80/v2-b4c17098edb7cb889343afae461848ac_720w.webp我们需要特别注意的几个结果如图：summary的总述部分、响应时间、吞吐量和系统负载。
https://pic1.zhimg.com/80/v2-28e4b84af3fab8618d1afefd843b015c_720w.webp
https://pic1.zhimg.com/80/v2-d31bfa2bead716caf7bc3d1404551884_720w.webp
2.5数据收集收集执行过程中的数据。2.6测试分析（写测试报告）
2.6.1人员参与
https://pic4.zhimg.com/80/v2-fb6a965fd5c8f9a99a007ececd2ce70b_720w.webp
2.6.2报告汇总需要对每个场景进行单独的具体的分析，这里我们以测试并发登录为例，对该场景进行分析如下：测试并发登录场景（1）测试结论：测试结果不符合预期，在100⽤户并发登录的情况下，响应时间最⼤是31.88s。（2）过程数据：把summary的总述部分、响应时间、吞吐量和系统负载的数据图截下来放到报告中，进行简单的分析。
https://pic1.zhimg.com/80/v2-28e4b84af3fab8618d1afefd843b015c_720w.webphttps://pic1.zhimg.com/80/v2-d31bfa2bead716caf7bc3d1404551884_720w.webp
从上图中，我们可以看到吞吐量在15:40:40时，吞吐量达到最大，而在15:40~15:41这个时间段中，系统的负载和响应时间页达到了最高点。
（3）错误汇总
此时简单的描述下错误类型，然后把错误日志截图下来，如下图：
https://pic3.zhimg.com/80/v2-d636f024ec939211f931df0d29213f8a_720w.webp
*注意在截图错误日志时，我们在日志中找到错误行的信息，然后截图时截取该错误信息的上下个30行日志信息，并且要截取到详细时间。
2.6.3测试风险
这里预期会发生的风险也需要考虑到，如图：
https://pic4.zhimg.com/80/v2-6c3fa8b5f6c3beee11fbcd7c4fcdba3b_720w.webp
2.6.4测试结论最后，总体的对各个测试场景性能测试是否通过，做一个汇总，这里只以测试并发登录为例进行填写。依据上述的各个结果，整体测试结论具体汇总如下图：最后，总体的对各个测试场景性能测试是否通过，做一个汇总，这里只以测试并发登录为例进行填写。依据上述的各个结果，整体测试结论具体汇总如下图：
https://pic3.zhimg.com/80/v2-0c489d9ec6d928bfb11a10dd93596dc2_720w.webp
页:
[1]
