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

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 类吧:

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

讨论这些没有任何意义的，需要给这种讨论设定一些范围：

1. 比如说什么样阶段的产品
2. 比如说什么样阶段的公司
3. 等等外部其他因素 。。。。。。。。。。。

讨论了很多开发和测试工作的不同，这没有问题的，但是毕竟这些都是人做的工作，工作有些不同，不同的地方人就哪里需要哪些学呗，开发兼任测试不是不行，测试兼任开发也不是不行，就没有不行的。职位要求需要重心不同，这不代表就是完全不能做呀。

目标是降本提效，身兼多职；目标是跑马圈地，那就多找点人。

价格价格，价格范围

可以使用精准测试了。问问精准测试怎么做？

你说的没错的。就是这么个情况。

谁能给我用一个例子证明，自动化落地和必须与业务强关联这个有必然的因果关系？什么样的业务如果在人员能力，时间，成本没有任何约束的情况下不能做自动化？