不是这么算的,这块的概念你没搞清楚。先查一下,什么叫实际并发数?
同一时刻同时登录的用户数 != TPS * 响应时间,这个公式完全不成立。
严格意义上的并发用户数:指与系统建立连接,并对系统发起请求,对系统造成压力的用户;
注意:并发用户数不能完全代表对系统的压力,比如 100 并发用户与系统建立了连接,每秒发一次请求,每 10 秒发一次请求,这两种行为对系统的压力是完全不一样的。
可以通过查询 被测服务器有多少来源于压力机的 IP 与服务器建立了连接,来计算真实并发。
你的推测有一定可能性,但是原因可能如下:
(1)被测服务最大连接数限制导致(这个可以查看一下当前连接数是否达到了最大连接数);
(2)被测服务资源有限,无更多资源分配给新建连接数导致;
(3)压力机资源限制,导致无更多资源分配给并发线程;
实际并发数是怎么计算出来的?
简单来说,
并发数:可以理解多少个并发用户,比如 200 并发数可以理解为有 200 个严格意义上的并发用户;
TPS: 每秒成功处理的事务数,或者每秒处理的接口请求;
为什么你的案例中,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 万办理的,现在应该便宜很多