Hey，do you know what are you talking about？I just feel how arogan you are.
Please, please do unstand it is just my opnion, it doesn't really matter.
You can present your idea or opnion with reasons,passions whatever it is you name it.
From my point of view, different scenarios formed different solutions, the manual execution is also one of these solutions. Please remember who are actually do the daily works in most cases, these testers,right? Please take care of them, otherwise, your work may be in trouble. You feel you are a manager, but so what. You even don't know What's your aim. Please make things done, not want things happen.

线程模型和 TPS 模型 这块听上去很有道理，感觉是不对的。
性能测试的指标主要就看： TPS 和响应时间 RT；线程模型去生成压力，也是产生 TPS 的一种。模拟用户行为对于服务器来说就是产生压力，服务器不管是机器产生还是人产生，对他都一样，就是压力，他的处理能力就是 TPS。

性能测试指标首先就是先看：

1. TPS
2. 响应时间

TPS 不能满足了要求了，再看资源使用问题，瓶颈在哪里了，如果看不出来就是加机器，水平扩展，如果一定要知道系统的上限在哪里，那就一直加机器提高 TPS 知道看到那个瓶颈的地方。

这个文章有点概念混淆的意思。那些限流/排队和性能测试本身没有任何关系， 就是为了实现满足特定 TPS 和响应时间的实现方法，这些实现能不能满足要求，需要用性能测试来衡量。

1. 查看 Python 环境
   

2. 看看环境设置指向哪个
   

3. 设置到你需要那个之后，可以考虑重启 pycharm，做好 index 之后再看看

这么杂的东西，其实可能花点钱上上这个论坛的大 V 的课说不定好点

需求管理都管不住，就不去测试用例管理了吧。

可以在你要测试接口地方设置等待多少个线程完成一起发送的。也是一种模拟性能测试的方式.

1. 同步释放请求： 模拟同时访问，看吞吐量和响应时间 Synchronizing Timer The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once. A SyncTimer can thus create large instant loads at various points of the test plan. https://jmeter.apache.org/usermanual/component_reference.html#Synchronizing_Timer

2. 不设置任何定时器， 就是随机访问，看吞吐量和响应时间，这个本质上也是符合系统场景的，到你要测试的接口，当然前面也有很多操作，那么自然也会形成系统负载，如果前面就撑不住了，到你这个接口也没有什么意义，这个像系统层面一点

3. 也可以设置其他定时器，按不同场景下吞吐量和响应时间

我看这个要求： 不是说是接口，是说页面加载时间，接口一个 3 秒？这太慢了吧，是慢的恐怖。

如何以上都很熟练了，我觉得是性价比最高的，不费力气，工资也还行吧。其他不要多想了，合适就行。

从解决实际问题出发：

1. 哪些经常重复做的？包括 Excel 处理，数据处理，是不是可以固定一些脚本，SQL
2. 自动化如果在有熟练的代码基础上，没什么太多内容，真的是没有什么内容，你看看你能不能回答一下问题：
3. 如何用 Python 处理 JSON/DICT
4. 如何用 Python 定义 Model，如果 Python 的类可以自由的和 JSON/DICT 转换
5. 如何访问 API，request/获取其他库，API 的要素有哪些？HEADER/METHOD/BODY
6. 如何使用 UI 自动化： 如何识别元素，识别元素有哪几种方法，selenium 也好，playwrite 也好，怎么操作元素？
7. Python 如何简单的实现数据库访问？使用 ORM 模式，使用 SQL 直接访问的模式
8. Python 如何自由的读取 EXCEL/CSV 文件，pandas 是不是可以用用？
9. Pytest 写写测试怎么写？一些特殊的 mark 是不是可以查查就知道了
10. Python 读写文件/操作环境变量/操作 Shell 命令
11. FastAPI 写个 Server API 试试，router，request，response，middleware 概念有了，随手写上 API 了

如果以上都随便写写就能了，其实大部分都能应付了。 80% 的测试自动化技术以上内容如何很熟练了，基本上问题不大了

看来招聘市场有点回暖了哇，招人好像有点了。

区块链是干什么的？

取消测试，就都解决了；提效可以去提别人的效了。

压测低频场景，而且不用平台有替代方案，一般公司都到不了要常年压测的程度；所以如果成本低做一个那到无所谓，
如果需要花费挺长时间做的，不如拿开源的用就好了。开源的有好多的。比如： https://github.com/andriisoldatenko/awesome-performance-testing 这个上面自己看看。

别预言这个预言那个了, 难道测试最擅长预测？客观的说，你的这几个例子的文章难道没有一点价值吗？可能对你没有价值，不代表对别人没有价值，各有各的活法，这么清楚的入门教程对一点不知道 python 的人，还是有帮助的；淘汰什么都不重要，重要的是你能写出不淘汰的东西；社区负面情绪稍微有点 。。。。。。

上面 AI 的回答估计是没用的，可能大家找到 AI 不能解决问题的场景了，是个好事吧。

1.看着讨论中说到技术自嗨的问题，我觉得这是两个问题，和这个讨论没什么关系，没必要带着这种情绪化的东西来说。
2.至于说因为这种问题说要换行业，我感觉也未必，其他行业不能解决的问题可能也有，你还不知道，你怎么知道不是掉进另外一个坑呢？

1. 这种问题没法 100% 解决，只能说什么程度是你接收的？比如一个月 2 次这样，一个月 1 次这样 。。。。。 方法选项：
2. 拉其他人一起下水： 关联系统为什么你要测试，你让其他组的开发测试一起测试，你可以找借口说你不熟，不是你负责的，怕出问题看他们怎么回答了；如果拉下水，都觉得难受了，这个问题可能就有解决方法了。
3. 足够自信： 你说我这个系统，只要你们的输入是按照约定来的，我就没问题，我自己测试完成，上线就成功了，我不关心你们系统怎么样，确实因为别人系统有问题，出现 Bug 了，但是这个和你系统上线有什么关系，Bug 是他们要改，不是你系统要改，你系统代码没有改动，为什么不能上线；
4. 当别人子弹： Leader 可能不方便和人冲突，但是你无所谓，你如果愿意当 Leader 子弹，你就直接把你情况在大群，邮件里面反馈，指出哪里问题，有什么风险或者干脆你说上不了线，没人回答，你就不上线；如果 Leader 不站你这边，反正你也不想干了，不是吗？
5. 接受这个情况，反正随便爱怎么来怎么来。。。。。

但是如果要想解决问题，自己一定要想清楚要什么？有具体的诉求点，有具体的事情可以说事，你担心别人扣钱，但是别人担心你身体了吗？ 不发 Bug，不可以直接群里说吗？或者你说来不及，让项目经理一起参与。 做好不能缓解一下就准备走人准备，虽然但是。。。。。。，但是确实很多公司就是这个样子，最底层，最没话语权的受罪。

来自 Kimi 的回答:

面对关联系统多且测试和上线过程中频繁出现问题的情况，可以采取以下策略来优化流程和减少问题发生的概率：

1. 需求明确和沟通：

   • 在项目初期，确保所有关联系统的需求和接口规范都被明确和沟通清楚。
   • 与关联系统的负责人和团队保持密切沟通，确保需求变更及时同步。

2. 提前规划和协调：

   • 在项目计划中，提前规划关联系统的测试和上线时间，确保有足够的时间进行协调和准备。

3. 接口文档和规范：

   • 确保所有关联系统都有清晰、详细的接口文档和规范，方便开发和测试团队理解和使用。

4. 自动化测试：

   • 引入自动化测试工具，对关联系统的接口进行自动化测试，减少人工测试的遗漏和错误。
   • 使用持续集成（CI）工具，如 Jenkins，自动执行测试脚本，及时发现问题。

5. 模拟环境测试：

   • 在开发和测试阶段，使用模拟环境来模拟关联系统的行为，确保新系统在上线前能够与关联系统正常交互。

6. 灰度发布：

   • 采用灰度发布策略，逐步将新系统推向生产环境，减少对关联系统的影响和风险。

7. 监控和日志：

   • 在生产环境中部署监控系统，实时监控关联系统的状态和性能，及时发现并解决问题。
   • 确保所有系统都有详细的日志记录，方便问题排查和分析。

8. 应急预案：

   • 制定应急预案，明确在出现问题时的响应流程和责任人，减少问题处理的时间。

9. 培训和知识共享：

   • 定期对团队成员进行培训，提高他们对关联系统和接口的理解。
   • 鼓励知识共享，让团队成员能够快速了解和掌握关联系统的相关技术。

10. 持续改进：

    • 每次上线后，组织复盘会议，总结经验教训，持续改进测试和上线流程。

11. 跨团队协作：

    • 建立跨团队协作机制，确保开发、测试、运维等不同团队之间的信息同步和协作顺畅。

通过这些措施，可以有效地减少关联系统带来的问题，提高测试和上线的效率和成功率。

看着有点像https://www.nocobase.com/ nocobase 的风格

1. 调用
2. 等 35 分钟验证数据

666

这种情况挺常见的。看看有没有优点再决定吧

主要是能写的不太多，你看前几年流行的：

1. 全链路压力测试
2. 精准测试
3. 工具平台 无数的文章和话题关于这些，该写的也都写了；这些严格说不是测试直接相关，这些测试工具开发相关，只是和测试有关系。慢慢大家可能觉得和实际小厂，或者一个小的 code base 关系不大，而一直说来说去也就是这些，如果想用下，还买不到产品直接用，加上目前测试招人也可能不太看这些东西，实际上招人一直都不太看这些东西，只是大厂出来演讲人喜欢说这个，大厂内部肯定对于这些也有不同看法，他们实际的时间，看到的效果比一般人都多，他们对于好坏会有更多的体会。时间久了，什么都不新鲜了。

现在又开始流行 AI，但是这些也和常见的业务测试直接相关性不大。 测试要么不知道哪里下手，要么其实直接问就行了。那亮点能体现在哪里？

而一些基础内容大部分其实也是和开发相关，这些也是有分化：

1. 会的人觉得这太简单了，懒的看和写
2. 不会的人觉得这太慢了，能做什么，学了也不能马上有效
3. 不仅要学，还要自己动手写写，这也花时间，然后看了和没看区别不大，练了和没练才区别大，肌肉记忆其实很重要，但这都需要时间，换句话说短时间可能用处不大，长时间某天才发现有用，但是不经过短时间内不停的练习和积累，更本没机会看到长时间产生的效果
4. 也不知道自己要什么技术相关的内容。。。。。。。。，反正我是这样的

测试直接马上能看到效果的，还是所谓敏捷，流程，设置各种卡点。。。。。。。，这是可能马上能看到效果的，但是这些确实和技术又不相关了。

都是很矛盾的东西。

如果有人知道怎么变现是不会告诉你的，告诉你就是多个竞争对手，为什么要告诉你？是不是都想多了，怎么把竞争变成合作才好点呀，怎么变现我也不知道，只是感觉有可能，比如做机器人，发社交媒体什么的 。。。。。。。。。。，至于怎么变现，真不知道；当然真知道了，估计也不会告诉你

RPA，什么的说不定可以有点副业，影刀，UIBot，反正都是自动化，不如自动化业务流程呢。

技术群里讨论问题，大部分问两个问题看看有没有人讨论，两个问题是：

1. 举个例子说说呢？
2. 和 XXX 比较起来有什么好处呢？有什么不好的地方呢？

如果类似这种问题有回答的，建议这个群保留着。

我估计如果从头实现需要前后端各半天 (乐观一点).

如果用一些好用的工具实现呢？大概是 1 个小时吧。假设需要实现一个如下的文件上传功能需要多少开发量？

如果用一些好用工具实现，一个 JAVA 类吧:

我就是这么实现一个前后端都有的上传功能。 至少个人认为，有些东西确实没有必要什么重零开始，尤其是测试开发相关的东西.