线程数跟接口最大用户数有什么关系。。。应该是测试 QPS，接口每秒能处理多少个请求吧

不能申请拿到 git 权限吗，申请个 reporter 权限就行，不然怎么做改动范围评估

感觉不如直接看 gitdiff 来得直观

其实内推和 boss 上自己投是一样的

并发数都不一样，导致时延高了，qps 肯定低了呀

如果产品和技术根本没有白名单的逻辑，不可能为了测试增加相应的代码从而增加风险

app 的 ui 自动化不是 appium 比较常用吗？

对学历要求是比较高的吗，比如 985211

现在起开始转型开发，小公司内部转开发也比较容易

有幸去过后端开发 7:1 测试的公司，每天都在发版，测不完也要直接发

平台对比纯代码肯定有不灵活的场景呀，我司还按照 Metersphere 的功能又开发了一套差不多的平台，不过加上了可调用 jar 包的功能，jar 包就是自己写代码逻辑了，相对灵活了一些。不过公司没有大厂规模和开发能力的话，建议直接用 Metersphere

为什么要用 500 个并发数，之前看过一篇文章说并发数应该跟 cpu 线程数相差不超过 2 倍。

我司就是这么处理的，哪个需求引入就是哪位测试负责（就算是 1 年前的需求都会追究），包括研发夹带私货这种问题（因为测试有代码权限，可以认为当时你没有进行 codeview），像这样的情况比你们更恶心呀。不过也不是测试全部背锅，相应的研发也是要负责的

fildder 拦截请求再篡改？

我意思是业务自动化体系才是最核心的，使用了什么框架是次要的

赞！这才是最有效的自动化手段。最近面试经常被问到是如何做自动化的，本人都是回答楼主的第 1、2 点，可面试官大都关心用了什么框架，我真是服了。

看着像是偏向开发的岗位

最简单的做法就是在测试环境压，jmeter 线程数一直增加，记录每个接口的最大 QPS

mac 就是不能玩游戏的笔记本，其他没啥很大区别

是不是集群压测影响呢，先试下单机器压测看看？

接口日志=服务端时延，jmeter 日志=服务端时延 + 返回到 jmeter 客户端的时延？

赞啊

测试环境的 mysql 慢查询日志确实很容易误报或者说不准确。另外，mysql 不是已经有 general_log 查询日志了吗，为什么不考虑直接处理日志呢

确实是，开发打的 jar 包挺多外部 jar 包。时间关系还是先用 idea 生成参数放到 txt 来做吧

自动化比较难发现问题是对的，可是楼主做到了 95% 的覆盖率就不一样了，当然这数据水分有多少就不知道了，就算路径、场景覆盖很全，但是断言字段不全也是一个遗漏点。然后一些 bug 是因为各种数据产生的，按照常规的自动化数据也是发现不出 bug。