刚好最近使用 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 的想法。

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

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

如果项目已经在用 gitlab 的 CICD，可以使用.gitlab-ci.yml ,根据不同改动触发不同 jenkins-job.

.gitlab-ci.yml

stages:
  - run-platformA-job
  - run-platformB-job

platformA:
  stage: run-platformA-job
  except:
    changes:
      - "platformB" # 当有platformB变动时，不触发A的job，执行run-platformB-job
  only:
    - merge_requests
    - branches
  allow_failure: false
  script:
    - curl -X POST http://xxxx/job/job-A/buildWithParameters? # 触发Jenkins job

platformB:
  stage: run-platformB-job
  except:
    changes:
      - "platformA" # 当有platformA变动时，不触发B的job，执行run-platformA-job
  only:
    - merge_requests
    - branches
  allow_failure: false
  script:
    - curl -X POST http://xxxx/job/job-B/buildWithParameters?

以上.gitlab-ci.yml 配置没有经过本地测试,不知道能否成功, 只是提供一种思路😄

Jenkins-->manage jenkins-->configure system-->Jenkins Location-->Jenkins URL 更改为新 IP 地址。
这种情况是因为电脑的 IP 动态变化了下，而 Jenkins 的 IP 没有跟随系统动态更新.

python3.5 以下版本不支持f"{}"的语法，两个方法解决：
①：python 安装 3.6 以上版本
②：坚持用 python3.5 版本，但使用低版本的Appium-Python-Client

今年需要多些耐心，别裸辞就好！

计算机专业的哈，【计算机科学与技术】

大家误解了，可能是因为【候选池】中选择更优秀的. 其实只要：个人优秀 + 一丢丢运气，很多很优秀同学，有很大机会进入一二线公司的。

目前暂时没有，抱歉！

一起加油！

这些问题还是需要数据支持的。描述中在强调：“大家都知道，大家都不做”，因为大部分情况，研发都是感官上觉得重要，身体很诚实。
所以第一个问题，针对研发质量差的建议是：
①：需测试 leader 和研发 leader 约定，冒烟不通过 90%，直接打回，直到提测通过。有些时候需要研发对质量差的有体感上的感同身受，不然大部分研发是不重视。测试需要做好 a:收集好打回的次数数据，做好数据的趋势图统计。b：测试本身技术能力，测试技能要过硬，不然无法说服研发和得到他们重视。
②：和研发沟通商量，对于【核心功能】，须经过研发小组长或者是资深研发工程师的 code review，测试建议也参与，能学到很多。
③：最核心的还是，测试把数据收集好，例如每个月打回的需求次数，占比。因为冒烟不通过导致延期的项目总数，占比。每个研发人员被打回需求的数据统计【这个还是私自发给研发 leader 为好，不要太公开】等等数据。

把这些数据，在月底的时候。如果你是测试 leader，找到研发 leader 一起过下【拉上越高级的人，越多的人越好】一起 check。多灌输一个观念：“质量出现问题，大家一荣俱荣，一损俱损的观念”。反正我每次和研发沟通，只要有机会就抛出这个观点。质量差，加班一起加，辛苦一起辛苦，还不如大家一起努力做好自己本职工作内容如何？

# setattr 是Python中的进阶用法，setattr作用是给对象“赋值”，例如：
# 赋值
In [1]: class Bar:pass
In [2]: setattr(Bar, 'name', 'allen')
In [3]: Bar.name
Out[3]: 'allen'
# 赋对象
In [10]: b = Bar()
In [11]: def foo():
    ...:     print('hello foo')
    ...:
In [12]: setattr(b, 'foo', foo)
In [13]: b.foo()
hello foo

# 还有更多高级用法，google下。

高可用架构最关键的是两个字：冗余。应该还有一句话，故障自动转移，高可用=冗余 + 故障自动转移。
故障自动转移=负载均衡中间件来保证。
冗余= 主从 + 集群 + 哨兵等架构来保证。
从上层的 DNS 到下层的 DB，差不多都是这个套路。说起来好像是很简单似的-_-||，最近也在朝这个方向学习，感谢楼主高质量的分享。

因为 locust 的分布式是跨进程的，你的 2 个 slave，对应 2 个进程。你代码里边的 queue，在 2 个进程里边实际上是 2 个实例。相当于 slave1 消费 queue1，slave2 消费 queue2【你可以打印 telqueue 的 ID，肯定是不一样的】所以有提示 userCode 重复。

上面建议你使用 multiprocess 进程的 queue 通信的方式，2 个进程都从一个 Q 中取任务消费，应该不会重复了。

目前有以下解决方案
①：如果你对于 userCode 没有强制的范围要求，只要不同就可以的话。可以一个 rang(1,20w),另外一个 (20w, 40w)。
②：你把 from multiprocessing import Queue 不要放到类里边，你放到最外层。
③：如果以上方法都不行，你可以 google 下如何实现进程间数据共享。
④：如果以上都不行的话，而你必须得用 range(1,20w), 最最挫的方式，你搭个 redis，把所有的数据都放到 redis 里边。userCode，从 redis 里边取。-_-||。

如果以上都不行，我就没招了。

queue 换成这个：from multiprocessing import Queue 试试看。

私聊一下，微信发给我，我加你哈。最近没什么时间上 testerhome，不好意思

db.session.commit()
db.session.flush() # 再加一行试试看