这个需要跟开发坐一块看日志，心跳请求频率，开发那边都是有要求的，频率不一致就认为你这个连接不活跃了，服务端可能就断开了

上代码看看，你可能少了一个心跳的请求

明日继续更新第三章哈

约……叔叔我们不约

想看我就接着编

排版看着有点点难受。但是意思我明白了，感谢分享。看看，这就是很多年轻人一直卷来卷去梦寐以求的管理岗的感悟，这是你们想要的体验吗?因人而异吧，反正我感觉我在这个位置上会很难受，不适合我

死活不就是一句（chong) 话 ($) 的事么

二位大佬。。。。

返回值解密，也可以写在你这个 debugtalk 方法里啊，在一次测试执行中，这些变量都可以通过 extract() 或者是 runcase export（）这样的方式导出变量，直接用的，不明白你的问题点在哪里

我也遇到过这种场景，给你提供 2 个思路吧，一个是我最开始用的蠢办法：你这 return 的是 3 个参数，那你就写 3 个方法，分别 return 这 3 个结果。第二个办法是我找大佬问的：你在这个函数里定义一个入参 args，然后根据这个入参返回相应的 res_token,res_messge。

别投了，群主代码丢了，电脑被修空调的搬走当风扇去了，至少俩月

35 岁是个坎儿，这不是随大流的想法，这是资本的桎梏，也千万别被这个定义限制了自己的思维。

没明白，为啥会获取不到？你一进页面不是就会请求一个类似用户 list 的接口么，id 应该就在这个接口里啊

p2p 还活着？？？

from xxx import Testcasexxxx as ” 非 test 开头的 xxxx“
执行的 step 用 Runtestcase 那个方法就行了应该

感谢恒捷的解答。我这个问题问的不够明确。500 用户并发请求一分钟，实际的场景应该是我们的老师要上线上课了，大量用户登录并进入教室的场景，需求应该是不崩，且响应时间在几秒内吧，比如，5 秒？第二个问题，我问我们的开发应该是没有这种冷库机制，可能有分库分表的设计，但是我们的用户 id 都是递增生成的，我并不知道具体的分库分表逻辑

那如果要满足” 500 用户并发请求 1 分钟 “这种场景，是不是本身就是一个伪命题呢？毕竟请求虽然发出去了，但是并不是同时返回的？
另一个问题：
在不考虑缓存的情况下，我用同一个 userId，100 个线程同时请求登录接口，和 100 个不同的 userId 同时请求登录接口，制造的压力效果是一样的吗？

####
感谢解惑，我理解是不是这样：假设我设置 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 产品毫无职业道德，一位地引导你开白条，免密支付什么的这种非常大安全隐患的功能，然后又用法律漏洞之类的把风险转嫁给用户本身，可以说流氓之极了