推荐看一下茹炳晟的极客时间上的课程：

给的时间和资源，可能导致测试跟不上项目进度了

为啥会出现这种情况啊？难道是为了对抗拼多多，导致人力不够？

欢迎云大

哦哦，那应该是库方法更新了导致的吧，毕竟这代码两年前的了。
辛苦将替换代码留言一下，我在文章中更新一下，避免误导了后面的同行

看看 logcat 的报错

可以问问这位哥 @saii ，https://testerhome.com/topics/24122

嗯嗯，适合一条路走到黑的，都是那种能长期坚持、终身学习的牛人，只适合极少部分人。
关于 50 岁以后在干嘛，这个确实看不到。能看 3～5 年就很不错了。
把当下的生活和未来 3～5 年的事情想清楚，我觉得就会过的很不错。

要是能有很好的社会福利和躺平的资本，我会选择半躺活着。
半躺不是放弃了自我提升，而是没有那么功利性了。其实在公司也是，对人的能力要求不只是要求技术，更多的还是格局、沟通、执行能力。
不管有没有资本躺平，我觉得还是要有提升自我的心。
目前的环境，只能说，努力提升自己，只是为了让自己多一些选择而已。

首先，只想说，往大了说，对于国家不同的发展阶段，对于劳动人民的制度是不一样的。
其次，如果有拒绝躺平还能好好生活的能力，马上去做吧。如果没有躺平的能力，还是努力吧。
最后，楼主只是举了技术升级的一些例子，同理，对于专业人士来说，不管你从事什么行业，只要是非体制内的商业机构，提升专业技能才是王道吧

完整的压测实践及问题解决思路，赞

刷新率和 FPS 是两码事，刷新率表示可支持的最大 FPS。但是实际的 FPS 是由产品决定的，比如产品场景只需要 30FPS 即可满足渲染要求，那开发后就只有 30FPS。

我觉得理想状态就是，没有测试这个岗位，质量分布在项目全流程中。
左移右移只是在向这条路前进而已。

看抓包也没报错，难道是我网速问题?

图片不显示了

好难啊，感觉只能把测试用例，在业务复杂度上，完善到极致

不是这么算的，这块的概念你没搞清楚。先查一下，什么叫实际并发数？

同一时刻同时登录的用户数 != TPS * 响应时间，这个公式完全不成立。
严格意义上的并发用户数：指与系统建立连接，并对系统发起请求，对系统造成压力的用户；
注意：并发用户数不能完全代表对系统的压力，比如 100 并发用户与系统建立了连接，每秒发一次请求，每 10 秒发一次请求，这两种行为对系统的压力是完全不一样的。

可以通过查询 被测服务器有多少来源于压力机的 IP 与服务器建立了连接，来计算真实并发。

你的推测有一定可能性，但是原因可能如下：
（1）被测服务最大连接数限制导致（这个可以查看一下当前连接数是否达到了最大连接数）；
（2）被测服务资源有限，无更多资源分配给新建连接数导致；
（3）压力机资源限制，导致无更多资源分配给并发线程；

实际并发数是怎么计算出来的？

简单来说，
并发数：可以理解多少个并发用户，比如 200 并发数可以理解为有 200 个严格意义上的并发用户；
TPS： 每秒成功处理的事务数，或者每秒处理的接口请求；

为什么你的案例中，200 个并发，TPS 只有 78？
表面原因

• 从表面来看，就是因为你的登录接口响应时间达到了 1961ms。
• 举个更简单的例子：用 1 个并发用户，请求登录接口，如果接口响应时间为 2 秒，那么 TPS 就为 0.5； 如上所示，200 并发 TPS 只有 78，是因为你们服务性能不足导致；

当然也有其他原因会导致实际并发小于设置并发的情况：
比如压力机性能限制，无法支持 200 个并发线程，就会导致，你设置了 200 个并发用户，实际资源只启动了 100 个并发线程运行。

所以，TPS 与并发用户不一定总是线性关系。

哈哈，是，还挺喜欢产品的东西的

看漏测的部分，是因为用例设计不全面导致的，还是用例全面测试时候遗漏了？
如果用例不全面导致，积累经验，补全用例；
如果用例全面，因人力不够导致漏测，就严格按照 case list 测试，避免漏测。同时，跟项目组申请更多的测试时间

考验一下离开社区的日子，大家有多不适应