配合 Throughput Shaping Timer 吗？我看这里目标还是 RPS 的控制

语言只是工具，多语言在初期更多的是锦上添花，附带的可能还要学习性价比的降低。建议在掌握了一门语言的情况下去学习如何使用如何适用，变现能力才是价值的体现。
楼主现状可以去学习下测开的一些核心功能，比如框架啦脚本啦平台啦工具啦啦啦啦的，暂时不建议再去多学一门语言；python 对测试来说也够用，所谓的竞争力高低对你现状也没多大影响，况且 python 竞争力也不低啊

两个格式目测看来是一样的啊，只是第二段存在较长的单条信息并进行了换行

拿来吧你

首先你得会写而且比目标代码写的好才能发现问题

是否可以借用执行路径的用例加载模块，对加载后的结果进行解析，这样会简单些，也可以复用执行的一系列前置功能

这 tm 都是脑子有泡吧，那以后发现的 bug 是不是都得追责，直接别测了，测出来的不是 bug 是锅。

拍脑袋定时间就是开发计划人力的 1/2，另外就是楼上所言，一定要固守住的底线：未转测不算人力、转测质量差导致打回不算人力、出现验证阻塞问题导致所有需求无法进行测试不算人力、各种非测试问题导致的空档都不算入测试人力内。
一句话，该干干该顶顶，守不住底线就老实的自己把锅背上吧，不用等着别人甩了

多谢，一直还没点过这个。

想的太浅了，要么是你低估了常态化代表的普及范围，要么你看低了远程带来的巨大影响，最简单的一个点就是：远程办公常态化后你让房地产怎么办？

公司总共几个人？搁我直接干他

测试环境发现的问题能叫问题？那叫 bug！追责是什么鬼？让他打开麦克风与我交流
延伸下，如果是测试环境搭建不合规导致与线上不一致进而出现线上 bug 就有点问题了

线上出了问题需要确定具体原因，如果是测试执行漏测，那就是测试的问题。如果是测试设计还可以用评审分下锅，如果是极端异常场景或极复杂场景可以体谅，其他原因则直接刚正面！
帖子内容就没看明白啥意思了，自己环境是什么环境？你这句话实在让我费解啊

实例代码能否发下
看下他们的 id 空间是否为同一个

拜读一番后感觉你应该大概也许可能是想讲点偏场景类 (配置检测) 的测试方法，最后却讲成了用例数据的传入处理方式

买个房子买个车吧，再结个婚生个娃

饿滴轻

开摆！

我更想了解下楼主是经历了什么才能提出这么个问题

综楼上所述，小作坊就努力活的更久完了，别瞎折腾，容易 godie

下面请楼下发言:

祝社区红红火火、大吉大利、圆圆美美、早生贵子

然后呢，首字母不同。

让我们换个思路，能否推动所有测试接口对 json 的兼容

开题立意：我不赞同楼上的观点，回归可以更全面，但是不能冗余
首先，我们确定下这个问题的性质：这是一个误操作事件，是开发人员工作失误导致的问题，与我们本次需求更改无任何关联关系 (这点待楼主确定，我只是说个场景)
然后，我认为此类问题无法拦截、也不该由测试去负责擦屁股，至少职责上是的。（）

楼上的回归测试方法是大部分人在面对此类结果 (非源头) 时的第一反应，可是我认为回归测试不该是如此的。中小系统或者具备自动化回归的情况下，我们可以这么去做，那大型产品呢？较频繁的版本迭代呢？难道我们每次都要 all in 吗？
回归测试核心是针对需求变更对其需求流程、需求关联功能、流程周边功能，这个范围已经足以达标性的保证本次需求的质量管控范围，如果本次存在范围外的需求外变更，我认为测试是不需要为其进行额外负担的。

当然我们测试人都是很有责任感的，所以也就有了本帖的存在，也就有了同行们对解决所有问题的热忱，但是如果真的线上出现了此类原因导致的问题，我同样不想各位因此背锅因此自疑。注：楼主的举例问题是否可以监控到 excel 的变更情况，有的化可以在转测时对照需求比对下表格的改动是否有出入，没有监控的化那。。