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

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

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

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

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

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

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

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

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

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

人家写的确实比咱们的好，有他的吧，哈哈

可以把能想到的场景全部梳理出来，一个一个模拟出来，太多代表没有梳理，走一步比想十步更重要。毕竟模拟一个场景，就可以排查一部分 BUG；

监控体系足够强大，就可以直接定位问题了，不需要复现，或者可以 100% 复现。对于大部分公司没有那么强大，所以要 debug 多打印 log 来排查，不然黑盒下去，越玩越黑

看需求，如果已经解决了基础的工具和方案问题，可以搭建并推广，降低业务测试的测试成本，增加自动化能力，提高效率。

如果基础工具和方案都没有，搭建的平台就是个空架子，没有意义

网络波动（弱网）或其他客户端异常操作如关机、杀掉进程、接打电话等等情况时，会出现各种无法上麦、客户端上麦状态不同步、直播间不显示任何上麦者

声网的 SDK 也算业内知名的，不至于出现这些低级问题。
弱网对音视频 SDK 的影响，基本上就是音视频的质量影响，不会出现如上问题，所以推测基本上就是业务开发的代码逻辑问题，各种异常没有做处理。

让开发多打印一些 log，QNET 进行网络模拟，复线 BUG 的同时，关注 log 定位问题。

让开发多打印 log 吧，或者代码 review

大哥好，有啥问题，小弟不定时支持

一定跟设备端约定好可测性，从业务角度，梳理出来需要的模块或组件，让开发提供调用接口。后期才方便进行验证，自动化也好开展。

我们这边前期测试没有跟开发评估可测性，现在全黑盒，如果想要做点自动化，要同步跟开发的技术栈，现在是 RN，比较蛋疼

为什么啊？

我家的小爱越来越经常自言自语

那工资相对房价来说，挺合适了

对，那个更好用

我用 python2 安装的，去年安装成功并使用过一段时间

天津的行情说实话还真的挺不好的

我过几年也准备去广州看看，之前在广州工作过不到点 1 年，感觉还是很不错的。北京环境太恶劣了

只要有本科学历就成，大专学历现在不知道能不能办了

集体户口没关系的，需要的时候再买房落个人户口就可以了，可以灵活点。

可以花钱走人才引进的通道，我 18 年花了 4 万办理的，现在应该便宜很多

在北京买房，在天津办户口。以后有回旋余地，毕竟置换的话，北京的房子好卖多了，也相对保值一些，或者少跌一点

谢谢俊哥加精，写得还不够好，可以更全面点