首先你应该测出 1000 个线程所产生的 qps，纠正一下，我前面描述有误，rps 应该为 qps，也就是测试出 1000 个线程每秒能发送多少个请求，假如你的 CPU 特别垃圾，1000 个线程只能产生 100 个 qps，那你的 CPU 负荷太高，线程可能处于任何状态。假如 1000 个线程产生的 qps 远远大于 100，那说明 CPU 负载有余，那性能瓶颈在服务器，线程大多在等待服务器响应

Tps 是服务器每秒处理的事务数量，跟多少个线程没有任何关系。多线程只为了产生更大的 rps，而 tps 不可能大于 rps。多线程并发在单核 cpu 上其实是交替执行的，只是切换时间很短，以纳秒计，所以看作是同时运行，这称为并发。还有一个相似的概念叫并行，必须不同的线程运行在不同的 CPU 核心上

我是把协议解出来，修改再发送。服务器返回的重要参数先做记录，需要发送的时候替换录制的参数

不知道你们开发能力怎么样，我倒是有个工具可以用来压测 websocket 的游戏，是需要用 lua 脚本来开发的，需要自己解析 websocket 封包，不过有现成的库，还要处理登录，报名参赛，学会使用还是有花些功夫的

自动化这个词太宽泛了，你得想好你用自动化做什么测试，仅仅是功能测试的话多开几个浏览器就可以了，无需大费周章。如果想模拟大批量用户那需要使用服务器压力测试工具，首先要明确项目使用什么协议，http(s) 还是 ws(s)，长连接还是短连接。然后选择合适的工具，工具选好了，还要根据项目处理登录逻辑，报名以及比赛得逻辑。

干开发和运维的活有利于，有利于从测试的角度，优化流程，整合资源。眼界离不开测试环节，做得东西也就是想着怎么用代码替代点点点，眼界放宽了，能做的东西更多

直接通过流量录制回放，模拟 5w 个人不就行了，数量级又不大，简单粗暴一点

http 与 https 的区别就是 https 多了一层 TLS 加密，默认端口从 80 改为 443，没什么好神秘的。不过可以补充一下，服务器如果使用 openssl1.1 版本的话，在 ssl 握手阶段可能导致程序崩溃，这个版本存在 bug

理论是好的，实践成本太高

没有经历 1、3 阶段，直接 2、4，正在向 5 努力。低门槛并不容易，即使我把框架接口封装得再简单，实际使用过程中还是需要这种知识来解决各种难题，所以目前我得框架只有我一个人会用

写得很好，但是抓包没必要再解析成 json，用例一边执行一边解包就可以了