必然啊，能远程，谁愿意在一线用好几千租房子用好几万买房子啊

面试一句话：简历使劲吹，面试针对性准备

1.UI 自动化去触发点赞按钮
2.接口自动化去触发点赞接口
3.sql 自动去批量执行点赞
4.手动点赞 1w 下
5.数据库直接改成 9999
6.等等...

直接就文件 + 参数化就行，没必要想多么复杂

我知道老哥，我开始也以为是 qps，可是确定后说就是 TPS 前置。。。我当时第一想法也是，拿着结果做前置？？

已阅

#1 说的对
我的建议是直接全部覆盖沥青，解决现有和后续可能出现的板砖问题，全方位提高产品质量

是的，吞吐量定时器 +Throughput Shaping Timer，可是并不理想，而且 Throughput Shaping Timer 是作用于 RPS。
场景就是对 TPS 的要求，一开始我也想当然的和普遍的请求压力联系在了一起，可是了解后确定就是 TPS 的前置

看了下官方文档，关于吞吐量定时器内吞吐量参数的解释是：
Throughput we want the timer to try to generate(我们希望计时器尝试生成的吞吐量。).
只是给个期望值，而且还注明了一些影响因素：
Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.(当然，如果服务器无法处理它，或者如果其他计时器或耗时的测试元素阻止它，吞吐量将会降低。)

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

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

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

拿来吧你

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

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

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

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

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

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

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

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

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

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

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

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