测试终究是思路为主，何必拘泥于工具，舍本逐末啦

升职加薪走上财富自由之路！

感谢您的回复
关于这个我也有查看，但是是没有勾选的，而且 max 也有后续线程记录，所以也不会是因超量导致的不予记录
我仔细观察了下过程，发现该 max 出现的那一刻有记录，但是随即便消失了

请教个问题：
responses over times 查看会记录每一个线程的响应时间吗？
近期发现聚合报告内记录的 max 与 res 内记录的最大值不一致

除了书面 offer，其他都是扯淡

杭州房价稳定

是啊，测开与开发的区别可能就是服务对象不同

说实话，我觉着可以去掉 “开发”，只说测试。。

多谢指教

太窄了把，怎么可能只专于 crud 呢，大部分情况下 crud 还是属于被二次使用，而非主体

太宽泛了老哥

是滴！

用 Java 的都是测试工作前就会的，用 Python 的都是测试工作后学的
---ps：我选择用工具

以客户需求为准条，以服务公司为准则，以牺牲自己为准绳，以质量速度为义务，合起来一句话就是：有没有干过开发转测拖时间，上线时间还提前的工作经验

对，两种场景区分执行，可以减少影响

我这里的登录就是打卡，是我表达不准确
我都意思是：从打卡到打卡后的其他操作为一条线，打卡后的再次打卡 - 这类操作为一条线
前面的是可以形成流水线的，后面的场景则大多为零碎的场景，这两种场景可以区分以 msg 进行校验，这也是一种减少脏数据影响的方法

如果就这个问题而言的话，是两个不同场景，需要使用两条用例来进行覆盖，已登录和未登录的情况下肯定是不同的 msg
---状态不同理应返回的 value 也会不同，我说的顺序是以不同 msg 来做区分，不同前提做区分，以此例来看可以将未登录和已登录做不同的场景前提，分开执行其用例或者对执行逻辑做修改

全面详细具体

使用 code 肯定是不足的，使用 msg 的问题可以考虑不同脚本顺序下对应的不同 msg，以此做断言
--断言的使用还是需要接口响应的具体区分来做前提的，不然就是很容易出现这种响应结果无法区分具体原因或者具体正确性的情况

wait

你给他说说测试的技术域和一些招聘信息就完了，操了！现在的公司是人不是人都要求全栈！！！

顶！

济南在招吗

base 发下，这就去买房入驻

当你不知道某个位置需要干什么的时候，去面个几次就清清楚楚了