####
感谢解惑，我理解是不是这样：假设我设置 Synchronizing Timer 为 100，1000，然后线程数设置了 100，执行 1 分钟。
实际执行起来的话，结果是不是第一秒执行 100 并发，如果 1 秒内有 50 个响应，那下一秒就是 50 并发这样？如果我设置集合时间大一点，比如 10 秒，就可以保证尽可能都是 100 并发持续了？

一直不太理解这个 Synchronizing Timer 的用法，这俩参数都干嘛使的，看不出来效果。比如我设置 100，10，整个线程组执行 60 秒。是说 100 个线程一起发送请求，这个 10 毫秒的延迟不知道干啥的，然后等这 100 个请求响应都回来了，再发起下 100 个请求，这样吗？

我认识一个朋友，他说他朋友日薪一爽，不管你们信不信，反正我只是听说而已（为什么那个人不能是我呢）

上论坛看精华帖，搜公众号测试开发关键字，总会有你需要的

实力劝退

前排留名！今天是2021年6月28日

反智？

京东 app 是支持异地登录的，可能你之前的设备登录了京东，然后被中了木马，捕获了你的信息。
另外就是现在的电商 app 产品毫无职业道德，一位地引导你开白条，免密支付什么的这种非常大安全隐患的功能，然后又用法律漏洞之类的把风险转嫁给用户本身，可以说流氓之极了

测试报告，计划啥，有些上市公司审计可能会查，作为流程的存在。如果可以自动生成减少美化，标准化的时间还是挺有价值的，更大的价值应该还是测试用例管理/生成/测试数据构建这些一线点工最需要的东西吧

我们调研了俩礼拜，试用了俩礼拜，然后决定弃用了，坑太多

不一致是肯定的啊，服务器是有处理时间的，不可能你发 100w 个请求，他就能返回 100w 个结果，超过一定程度，服务端很可能就不处理了或者进入排队队列了

感觉这个兑换券的状态记录有问题啊，下单待支付时，券的状态应该是锁定，这时候去退款，锁定中的券要么被拦截，要么就要先取消待支付的订单，再进行券的解锁，这里面应该是服务端的锅

旱的旱死涝的涝死……看见没，这就是测试管理的烦恼~35+ 的归宿就这，就这？

也可以加入 testerhome 社团：测试开发方舟号

看这个啊，你想要的都有，跟着抄就完了

想请教一下老师，这个报错是因为我的参数传的不对么？

机械手。。。我感觉有种回到原始社会的感觉

和自己和解，既来之则安之

挖坑不填……鞭尸万年额

这个事情需要解决一个拷问：
开发：这个我可以升级，但是谁能保证升级了之后原来的代码没问题，你来测试吗？测试了说没问题我就升级。排期吧

其实可以看到，只不过楼主不是你

人肉真机，是 100 台么？怎么测试的呢？我是用 jmeter 调用进入直播间接口的方式，持续了 5 分钟，准备了几万个账号，然后看了一下单台服务器 tps 在大概 300 左右

排查了一下，问题应该出在这个命令：
注释掉后，不会有这个问题，但是只要在返回体这个 tab 下发送请求，就必然会报上述错误

想问问，楼主有房车贷娃的压力么？

——你这个问题的底层逻辑是什么？顶层设计在哪？最终交付价值是什么？过程的抓手在哪？如何保证回答闭环？你比别人的亮点在哪？优势在哪？你的思考和沉淀是什么？这个问题换成我来问是否会不一样？你的独特价值在哪？
抱歉，我真的回答不了这些问题