之前思考过意识是什么，个人理解，就是多镜面互相反射的系统，意识就是反射。我知道我知道我知道我知道 *N 的无限死循环系统，但是人脑不可能针对具体某个反射做死循环，它会有个停止，就会出现我知道我知道这个循环本身的现象，即意识到意识的存在。其他的意识现象，只是这个死循环中加的钩子，钩子可以挂载视听触感嗅。。。跟操作系统何其相似。。。

试用期间双向选择，哪里高去哪里

高内聚低耦合。分开肯定是好的。用你分开的 java 类再拼个功能类不就可以了。甚至，你抽象一个工厂，通过工厂来组装业务（拼接口的类），测试代码只依赖工厂。。。。再抽几个 java 的 interface 类，主要定义测试行为，业务接口的 java 实现这些个 interface

我干着测试的工作，业余时间都不学测试了……
HR 朋友说过，简历堆里面，大致前端和测试是最多的，最多意味着最卷啊
所有研发岗里，测试的能力边界是最广的，并不简单啊……
“拒绝新鲜血液 + 排外”，你是没懂啊，背后表达的逻辑，是没有安全感啊，卷啊，上升空间不大啊，
再说个体能拒绝新鲜血液吗，并不能……徒伤悲啊

我内驱力超强，每天下班都在学，周六日大部分时间也在学。其实我也很苦恼，啥都想学，精力有限，学过很多东西，也没产生收益，然后也很焦虑

学开发比较容易找个项目敲出来，但学测试，很难找到被测的对象。

刚工作一年，还是研究生，还刷 LeetCode，做测试浪费人才了。转开发吧，反正也没啥机会，熬个小半年，大环境会变好的。

支持楼上所有劝考研，劝做开发，不要做测试的建议。

4 楼很委婉。

我直接一点吧，别做测试。

直接撸代码。什么难不难的，你计算机原理学通了嘛，代码码得出来，是你的业务不太懂而已。

借我一学计算科学同事的话说：“当初就是不想写代码做了测试……”。

退而求其次的路，不是什么好路。

同行轻喷，劝退一个是一个，人少不卷。emmmm。

成都这个招聘怎么这么辣眼睛，35 的你不招就算了，写出来是不是不太好。
大龄测试们，你们觉得呢？

个人经验，优先级如下，前面的优先级高：
1、优先大城市
2、大城市及周边优势成熟产业
3、成熟产业中相关专业
4、相关专业中适合或者爱好
5、985/211 带响就行
要考研，把 5 提到 2，还得加上专业排名。

我现在的看法是，企业界的技术没什么难的，有基础 + 人不笨，都能学会，真正能把事做好，还是要下细功夫，而得到做事的机会显得更重要。结论大概就是：大环境不好，学啥都不会给你太高的回报，根据兴趣来，想学什么就学什么，因为学了你也落不了地，顶多是下次有机会的时候，比别人多懂一丢丢。。

airtest 可以

入行才半年，看你这多空闲时间，干完活了，明目张胆的学点技术，不想提 bug 就自己努力换个方向（事在人为，我站着说话，嗯腰不疼，但是你年轻，还有可能），要是你只是间歇性不想提，好好干吧，攒点经验，几年一跳，越跳工资越高，达到行业收入上部，你打工的日子差不多就是出头了，剩下的就该焦虑了。。。emmm

横看成岭侧成峰，远近高低各不同。
不识测试真面目，只缘身在点点功。

业务和技术是硬币的两面，干啥都有出路，路是自己走出来的。业务对公司有价值，对个人不能说没有价值，个人的价值依附于业务。但是你一个打工的，除非换公司不换业务，打工换工作那都是缘分随机的，大概率由不得你，要是一换，攒那么多年业务就打水漂了，要是坚持在一个公司，多几年应届生都倒挂你。技术可以帮助业务测试提升效率，技术也可以帮助自己不做测试，技术攒下就是自己的，换到哪都是自己的。所以，两手抓，两手都得硬，就看自己偏重哪块，像我偏技术，业务带着脑子带着沟通带着笑脸，点点点就好
顺带一嘴，像研发岗位，经常自嘲自己 crud boy，技术？你自己的都写代码，也知道啊，技术其实也就那样。回到正题，楼主找工作别给自己种自己不行的观念，业务带着脑子一般都能干，门槛它低啊。面试自信点，干，别给别人传达你不行的情绪，也别让人觉得你心高气傲不想点点点。如果安了心做测试，就得两手抓。

现在的行情，适合苟着学，等行情转暖，再凭屠龙技出去抢食。学啥好像并不重要，重要的是在那个方向沉下心来沉淀。。。嗯，我也是这么劝自己的

摆地摊

jmeter 官方文档原文：
https://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html

There are some basic limitations for distributed testing. Here's the list of the known items in no specific order.
......
A single JMeter client running on a 2-3 GHz CPU (recent CPU) can handle 1000-2000 threads depending on the type of test.

答案是否正确这个如果是重点，那问题可能要细化，比如问题没有给出机器配置（CPU 频率内存大小操作系统版本之类）。另外把限制改成 5000、80000 这个，确实很有逻辑（不排除你在抬杠，AI 回答方向到 linux 最大线程数了）。本帖主旨是提出好的问题很重要，这 AI 回答的水平已经超过觉得大多人了。我对 AI 的态度不管它菜不菜有没有缺陷，目前看它对我学习知识很有用，超过搜索引擎。

我个人对官网建议的理解做下补充：
1、该建议出现在分布式压测中，我一开始忽略了，所以需要考虑网卡带宽在压测时的瓶颈，主要提现在分布式压测客户端和控制端之间网络通信（很久没用了，理论上压测期间这种通信只少量允许，压测完结果再统一上传合并才合理），压测机和压测对象服务器之间的网络通信，这个我还比较模糊，没有具体数据给出，“depending on the type of test.”；重 IO 的带宽瓶颈明显，轻网络 IO 的线程数自然会多，具体机器具体压测场景具体分析。

2、AI 回答的线程创建、线程状态同步、线程调度切换和中断对系统资源消耗没有什么毛病。

3、最大线程数的建议是不是伪命题，你拿自己的机器亲自校验下不就知道了。

PS：如果对该建议的底层原理给出量化性分析的原因，可能够写一篇硕士论文了。我现在是不会的。如果有大佬看过，欢迎补充啊。

36，入行 8 年，虽然在职，但每日为今后不能继续打工而焦虑得不行，拼命学底层（爱好）又时常疑虑（一个测试学这么深干啥，转开发又没人要），同时调研着各种失业后不能打工能干的事~~想躺躺不平

CSAPP——打脸系列

给我开个个审核权限，我可以帮忙

大佬是怎么做到自己一个人，上线问题比找的 2 个人还少的。这就很强。

调度机不参与压测吧，这个数据看起来没有收集到其他机器的数据……还是配合下机器的 TCP 监控定位下问题，按理吞吐差距不应该这么大

请把请求的配置贴出来，还有压测思路说一下。

开发写了给垃圾同步机制