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

压测低频场景，而且不用平台有替代方案，一般公司都到不了要常年压测的程度；所以如果成本低做一个那到无所谓，
如果需要花费挺长时间做的，不如拿开源的用就好了。开源的有好多的。比如： 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. 也不知道自己要什么技术相关的内容。。。。。。。。，反正我是这样的

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

都是很矛盾的东西。