问题已解决:
新版的 sshd 服务，配置文件中，退出 ssh 后，默认配置会杀死当前控制组里面的所有子进程，修改策略即可,退出 ssh 的杀死程序（KillMode）
有如下策略：
1、control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
2、process：只杀主进程
3、mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
4、none：没有进程会被杀掉，只是执行服务的 stop 命令。

查看/lib/systemd/system/sshd@.service 文件，保证内容与下面的一致，尤其是 KillMode=process，如果没有这一行，请自行追加
[Unit]
Description=OpenSSH per-connection server daemon
Documentation=man:sshd(8) man:sshd_config(5)
Wants=sshd-keygen.service
After=sshd-keygen.service

[Service]
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=-/usr/sbin/sshd -i $OPTIONS
KillMode=process # 追加这个配置
StandardInput=socket
重新加载配置并重启 sshd 服务
systemctl daemon-reload
service sshd restart

最大线程数应该由基准测试（单并发能达到的最大 TPS）的结果来定。

大佬才有年度总结。我一年每天做一样的事情，没法总结。

应届生都这么卷了，8 年老油条感受到了强烈的危机感了。

突然发现，我就随便吐槽了几句也能上榜，醉了！！！

命题高大上，实际落地效果并没有想象中的好。

什么开发 一天就写 200 行代码？

普通的测试人员有几个会用到前沿技术啊？
尤其是点点点，业务才是重点。
而且就自动化测试目前来说，也做的并不够好。

AI 测试？那让点工都失业？

什么都比开发强，干的被开发多，拿的比开发少，图啥啊！

建议你们直接去 211,985 校招。

一般 UI 自动化不会做全量的业务吧。
我们公司一般是接口全量，UI 自动化只做关键业务和 TOP 业务。

如果确实用例多，除了增加执行机器外，还可以优化下框架代码，脚本代码，比如减少初始化操作时长，提前处理测试数据等等

这不完全是开发的问题吗？你们既然可以测到问题，那么由此产生问题的原因难道就没有推着去解决呢？还能反复因为代码合并的问题导致缺陷不断？

出去多面试吧，领导要是觉得你值得留，就会给你涨到外面差不多的工资，如果不留你，你就直接去外面看看吧。

换不起~

实际上，公司层面不管是领导还是开发都觉得既然你要做自动化就应该自己解决所有自动化过程中中遇到的问题，比如验证码识别，双因素登陆校验，文件上传下载。尤其是自动化需要运行在生产环境中的时候，执行 UI 自动化过程中需要解决太多棘手的问题（测试数据，业务回滚冲正，验证码，短信等）。

开源么？

正常的测试都是手工 + 一点点自动化 + 一点点性能，我想没几个公司会有能力专门养几个工资比开发还高的测试测试去专门搞那些花里胡哨的东西吧。

如果一开始就有能力做开发我觉得没人会选择测试。
时间太长就算技术能力高了又会碍于累积的多年测试经验不想换赛道。
我建议技术能力可以，学习能力可以的人可以往高级开发，架构师方面发展。
除了一些大厂，中小厂里的测试真的没啥发展前途，开发和你同一天进去，人家涨薪的速度可能是你 2 倍以上。

这样返回没问题，正常框架都是这么做的；
严格点，开发需要对这种代码层面的 Exception 堆栈进一步封装成可阅读内容，可以提一个级别低的漏洞缺陷：
漏洞名称：异常信息泄漏
漏洞描述：未自定义统一错误返回导致信息泄漏，抛出异常信息泄漏，错误详情信息泄漏
漏洞风险：后端接口服务在出现异常报错时，没有进行合适的包装便将所有信息返回给前端，通过抓包工具或者 Chrome 开发者工具可以查看这些异常信息，可能包含例如表结构，代码包名，业务逻辑等敏感信息，极大可能被黑客所利用。
漏洞修复建议：Java 后台对所有异常出错进行包装，返回合适友好的提示信息，禁止将异常中所有信息返回给前台。

不管是偏业务测开还是偏工具测试真的如同楼主所说的需要料理这么多方向的事情？

这个薪资是说工作年限为 0 也有可能拿到 12K 嘛？

他制裁他的，我依然用我的，他都制裁了，还担心他会告到我们？

frame 层有考虑到吗？

编程语言封了 还不是照用。