刚好最近使用 locust 进行生产持续 15 天压测，可以和你分享下一部分：

• PS：我们压测的 QPS 平均在 4.2w 左右，远没有达到 100WQPS。

先说结论：locust 单机最高的并发是多少？这要看压力机配置。理论上如果 QPS 上不去，可以分布式机器，每台机器启 CPU 个数的 worker 来提升。

1. 在写业务类时，优先继承 FastHttpUser，在同一机器上比 HttpUser 的 QPS 提升 5 倍左右。
2. 如果对于 go 比较熟悉，使用 go 语言压测引擎 boomer 启动 worker，预计性能可以再提升 2 倍【在 FastHttpUser 的情况下】。
3. 建议压测服务和服务器在同一台，通过内网请求最好。
4. 在自己实验中 mbp、M1 芯片、8c16g、内网请求情况下，1000 并发，Go 的 QPS 可达到 5wQPS【本机关闭其它程序】，FastHttpUser 在 2.6w 左右，HttpUser 在 5000 左右.【请求接口很简单只返还 OK，仅为测试】。
5. 如果是 ws 的压测，会占用非常高 90% 以上的 CPU，若要达到百万级 QPS，可能需要很好 CPU 配置，反而内存使用率不高。
6. 过高并发数量，可能并不会压测出很高 QPS，因为涉及到两台机器的端口数量、Master 进程对 worker 进程中线程数调度等问题。

刚好之前也遇到过前端加载非常慢问题，经过优化也有几倍提升，也在此一同分享下。

1. 如果 js 过大，而又必须使用，可以考虑异步。 vue3 中对于组件的导入可以使用 defineAsycComponent(() => import('@/components/xxx'))
2. 如果是 nginx 代理，可以考虑开启以下配置：

# 开启gzip
gzip on;
# 启用gzip压缩的最小文件，小于设置值的文件将不会压缩
gzip_min_length 1k;
# 设置压缩所需要的缓冲区大小
gzip_buffers 16 64k;
# 设置gzip压缩针对的HTTP协议版本
gzip_http_version 1.1;
# gzip 压缩级别，1-9，数字越大压缩的越好，也越占用CPU时间
gzip_comp_level 3;
gzip_types text/plain application/x-javascript application/javascript text/javascript text/css application/xml application/x-httpd-php image/jpeg image/gif image/png;
# 是否在http header中添加Vary: Accept-Encoding，建议开启

同时项目中配置

vue.config.js
const CompressionWebpackPlugin = require('compression-webpack-plugin');
// 定义压缩文件类型
const productionGzipExtensions = ['js', 'css']

留下个疑问，之前前端项目在 vue2 的时候访问特别慢，链接路径也打不开，后面升级到 vue3，再经过以上优化快很多，不是专业前端开发，所以也搞不懂是不是 vue2 自己使用的姿势不对？

你离职想法 leader 知道了，现在加薪可能是暂时挽留，后续动作大概会找替代你的人。 而且你还年轻，有 owne 经验，到哪都会很快展示出来。

有一个插件:pytest-json-report 可以使用。

google 下， pytest 基本你想要的功能，都有已实现的插件。

用例设计根据当前需要。一般接口用例分成单接口和业务流接口，正常和异常的 case 设计取舍还是根据当前团队情况。
简单例子：团队需要把和钱相关业务场景尽快覆盖，那就优先写正常 “钱”+ 部分异常 “钱” 相关的业务流用例.另外用例的展开也分阶段的，无法一蹴而就。

入参模型是自动生成的。

我不是大佬噢，论坛里和论坛外很多很多真.大佬. 我上面回复是指【接口管理自动更新】哈。

你楼下有回复了一个。我们会做业务测试的，不可能脱离业务。

接口是根据研发代码仓库里的文件自动生成的，研发有改动，我们也会同步一键修改.

因为一直在做服务端方面测试，和大家交流下自己的思考.

• 写 python 代码来的有效率，还是使用接口平台效率高？

  • 效率高低的考虑，再升级是把领导吩咐的事 orOKR 尽快完成。如果目的是短期做出来，那就使用接口平台. 如果不是第一个目的，选择 Python 写。从经验来看，使用接口平台中后期「3-6 个月之后」会遇到很多问题，最终放弃.现在我们是属于自己开发.原因很简答①之前的接口平台无法再支持我们业务复杂度的开发，如果扩展我们再写代码又回到了最初的选择上了②领导有要求测试人员全部转型测开.③团队人员技术基础素质很好. 所以答案就看目前所在团队的 OKR 了
  • 自动化的运行环境是一个通病，每个公司都有，我们现在做法在执行前会进行各种健康检查和第二步可选择的环境发布管理。按照经验，也是很有帮助的，我们可以很好的提前中断 case，避免误报。因为有消息通知机制，也会第一时间同步环境问题给所有人。

• 用例都写完了，怎么更能体现价值，只在测试冒烟阶段执行？ 还是开发？生产都执行？

  • 能够输出价值，才是我们所做事情意义所在。我的思考是①自动化用例设计很重要②自动化用例执行频率很重要③自动化用例数量很重要④执行节点很重要 [作为卡点，生产之前全量执行一次，在测试环境回归执行一次] 以上是第一层，第二层思考①接口自动化可能执行一段时间，也没有预防住和发现一些问题，所以 自始至终需要给团队和 leader 说明，有接口自动化项目肯定是非常好的加分项，不管对谁。对于业务来说，至少在服务端，我们可以很自信的说，放心上线服务端功能，这块不会出现 P0 问题。这是需要慢慢传递给所有人的②自动化测试提供了很好的工程效率③接口自动化是可以很好做横向和纵向的扩展的，例如横向的性能测试，业务监控等等，纵向的是收集错误用例历史数据分析，复制和回放等等。

• 其实围绕一个接口自动化项目，也可以做很多事情，如果不从上面的技术角度扩展，就从项目角度可以延伸很多，一个简单例子借此机会提高培训团队人员 code 能力，借此项目扩展到其他维度的自动化等等，这个也可以和 leader 讨论，看 leader 的想法。

但是以上所有做的事情都有一个大前提，你有一个好领导,支持你！！！！😄

以上是个人浅见，希望有帮助!