可能发展真的太快了吧，或者大家太卷了，楼主这种能力都找不到工作了。
先抛开非统招/专科简历筛选就过不了这个事情不聊，就聊聊能力层吧。
现在对 QA 的能力要求确实也太复杂了一些：

1. 干活能力。测试流程 + 测试基本功 + 基本的 coding 能力。接口测试 + 性能测试由于工具太成熟了，学习成本低多了，上手很快不值钱了。相反测试流程 + 测试基本功是个人素质综合能力的表现，更值钱了。
2. 提供解决方案的能力，或者说是执行力。遇到什么需要执行的，没有任何的能力障碍，直接搞定。这方面也很大，软素质和硬素质都要求非常高，精通这一层是 P7，小概率 P8。
3. 发现问题的能力，或者说是找活的能力。现有的所有，是不是完美的，问题在哪里，是不是需要解决，怎么解决，收益是什么，需要多少人手，多少时间搞定，遇到阻塞是不是都可以搞定。P8 的基础。大家都跟你混饭吃了。
4. 再往上，多少有点儿玄学了，靠命。

说回来吧，我觉得楼主发帖有点儿愤愤不平，怀才不遇的感觉，但是以我看，也可能是路走偏了，技能树都点在普遍存在的工具上，缺少亮点（github 项目也没有），真假也难辨。也可能是简历写的不好，没有说清楚自己能干什么。非统招确实难，至少 3 年前，就对非统招不友好，至少我司举例，只能是外包/vendor。

我来 B 之前，感觉和你的心情有点儿类似，不知道怎么提高自己，或者不知道自己真的缺啥。当然现在也不是很知道缺啥，就谈点儿想法吧。
我认为我能来这里，主要是几点：1. 学校学历达标。2. 带过人，带人的经验其实很 2，但是岗位其实不需要什么带人。3. 技术过硬。4. 沟通达标。
不知道你处在什么阶段，可以尝试打造自己的亮点。
来到这边之后，发现弱项逐渐暴露：1. 不懂业务测试，甚至缺乏业务测试的自信心，业务测试是一个非常大的范畴，当然也是一个无底洞/绞肉机，很多人不愿意做业务测试，我身边也有很多，但是我认为可以不愿意，但是要懂。要做到懂，其实非常难。2. 总结能力差，知识扩散的能力还不够。知识自己能懂，但是不能太快的传播给别人，表现就是不会写文档，不会画架构图，不会写 PPT。3. 不太会 push/推进。这个问题其实也非常大，需要非常综合的能力。我当前认为最重要是发现问题的能力，还比较浅显。4. 沟通能力，怎么能把一个事情讲清楚，把自己真正想说的表达清楚，让别人接受。
每个人的情况不一样，我就是简单说下我的情况。
我之前迷茫的时候，就去大厂面试，被虐，就知道自己缺啥了。或者进了之后，也知道自己差哪了。

年假不会吧，比如抖音是法定年假 + 福利年假，休息是没问题的，不休息也能换成钱（法定年假 1 天换 2 天工资，福利年假 1 天换 1 天工资，1 天工资大概是月薪/22.5）。不相信 360 是因为这个干人。

借楼，一个公司的，可以单 M 我内推，多试试几个部门。
谢谢楼主了。

1. 必须一本。
2. 必须懂代码，能写能读。代码比较泛，能读就是所有的代码都要能读，包括但不限于 go，java，python，shell，注意是所有吧，至少超短时间内都要能读。能写其实对所有的也是要能写，至少是仿写。所以建议刷题。
3. 必须有执行力。超强的执行力。
4. 基本必须要有职业规划。
5. 加班不抵触。 然后单 M 我，我内推你。

面对 35 岁门线，我的选择是来头条 996。

非大佬，混饭吃。

20、你有公司代码的权限吗？
当时回答：如果我问开发要的话，他们会给的，像我现在测试小程序用的是微信开发者工具测的，都是让开发把代码打包过来

公司代码权限是要主动要的，测试需要看开发的代码。直接回答天天看代码就完了，面试官才好深挖看到过什么问题，codereview 之类的。

23、你目前接口自动化脚本的覆盖率是多少？
当时回答：公司的接口有点多，我目前只针对主干流程的接口写了脚本，这些模块占全部功能的 20% 左右吧

多是正常的，写不完是正常的，要回答出现在的情况，未来的计划，带来的效果，遇到的困难等。这太轻描淡写了，没有共鸣。

面试官想看到的，都完美的回避了

革命尚未成功，同志仍需努力！996 就完了！

设计时为什么不结束之后再传给 master?
回答：就是为了实时看到压测结果，即便是非 gui 运行，脚本也会打印实时结果的，这个结果相当于是汇总的。

还有这块代码再源码的哪个类哪个方法里，知道的大佬，麻烦告知下，谢谢
回答：非大佬。本身是使用 rmi 的方式调用的，没有什么特殊类或者方法来做回传的事情。
org.apache.jmeter.engine public class DistributedRunner 去看看这里的代码，最终的 engine 也是 StandardJMeterEngine。

这样会导致压测的时候网络带宽占用过高
回答：这个不想解释为什么，懂的人自然懂。要修改这个问题，必然对 Jmeter 进行大的修改。

确实很充实，做的工作很专，赞👍！

如果能量化，就是优秀的。

也是分情况的，如上面说的，要详细的问一下场景如何，才能做判断。
不过一般的，很简单的给查询结果做一个缓存，基本是没啥问题的。现在各家公司也都知道 redis 集群是提高性能的主要手段，带宽，集群方案，内存容量，隔离切分都是没啥问题的，公司层面就会注意这些基础设施的建设，redis 集群的支撑能力到几百万的 QPS 没啥问题。
你回答中也提到了，可能存在偶发的高峰，那么面对削峰，MQ 也是一种方案。MQ 比如 kafka，性能更是厉害了，几千万的 QPS。你们开发在技术架构选型的时候，相信已经思考了相关的取舍，建议你和开发仔细探讨一下，会有收获。

redis 缓存的核心问题是数据双写，其它细节可能是大 key，带宽消耗，失效时间设置，命中率，如果都没有问题，就是很正常的优化。

如果要给 Jmeter 写插件，可以去看一下 jmeter-plugins-for-apache-dubbo 源码即可，还是挺有借鉴意义的。当然直接看其他的插件源码也可。
如果是要给 Jmeter 修复 bug，比如，拓展其核心的能力，这个需要看 Jmeter 的源码。
如果是要给 Jmeter 修修补补，但是不想改 Jmeter 的源码，可以看我的开源实现方式。

性能测试分两种，容量测试和压力测试。（当然高楼是说性能测试其实就一种，不用分那么多，我这么说是便于理解）
你的问题，看起来你是把这两者混在一起了。细看你的要求更接近压力测试。
我遇到的 90% 吧，Jmeter 的的范畴，剩下的，最应该用流量回放的方式搞，但是还是使用了 Jmeter 搞定。

那测试到底还需不需要做功能测试？可能在很长一段时间内仍然是需要的，但那一定只是日常工作中很小一部分。
不评论了，学习了。

已经是老回复了，我也是复习了一下前因后果之后，很费时间。
我之前确实理解错了。
19 年 8 月的时候，我还是支持自研接口自动化平台的（当时我也在写这些），而到今天，我几乎是反对自研接口自动化平台了（主要是性价比不高，同时测试有其他更重要的自研工作）。
我的立场已经变了。
希望虫师未来能分享更多的知识，感谢。

优秀的产品经理，比如周鸿祎，乔布斯这就不说了，已经是传奇了。网上比较火的可能是张小龙，俞军，姚晓光（游戏不知道算不算），这些有访谈记录。然后一些接地气的，比如苏杰。去看看这些人的东西，你会对产品经理有比较多的认识。
普通人眼中的好的产品需求文档，和产品人眼中的好的产品需求文档，标准是不一样的（不排除有捧臭脚的）。同时产品经理的工作是很长的一段链条（产品的生命周期），有很多工作，你不能只看其中的一部分就否定人家的能力。
或者说，优秀的产品经理，已经上升到决策层，你想遇到，可能也自己也够不到那个层次。
就别和普通人聊什么增长了……你找错人了。

赞👍！

你逗笑我了……文章作者是你吗……
好了，我严肃一些。
你的文章结论还行，一些我是赞成的。
爱用 locust 就去用，只不过我不推荐。
论单机的性能发起，去用 webbench。
复杂测试脚本，不嫌累就去用 locust，反正我不用。
逗笑我是因为，你认为 “个人感觉在报表方面，两个工具相差不是很大，都基本能满足工作需求”，有点儿搞笑，你如果能用 locust 实现出来和 Jmeter 性能测试报告相同实力的报表，真的，你就是业界翘楚，我为你单独写一篇，分析你写的源码报告。

还有在这挖坟的……我感觉你不是想怼我，而是自己对这些问题自己没有啥解决方案或者是知难而退了，借着回复我吐槽一下。
其实时代已经发展了……
了解一下阿里云效平台（测试管理部分，流水线部分）吧，你的想做的这些问题已经解决的差不多了，比如代码扫描，质量管理，报告自动化发送，消息推送，接口预警（卡点）都可以。bug 自动提交这东西不好做哈，毕竟还是需要人工确认一下，但是设置一个卡点是可以的。而这些，我认为云效平台结合 postman 都是可以做的……。而数据的可视化，是云效平台的卖点之一了。
可能你对测试要开发的平台没有太深入的思考吧，有些重要的平台是需要你说的 “有灵魂的编码” 的，不过你的举例不太好（具体啥平台我就不提了……不想替你思考）。
接口自动化测试平台就别再吭哧吭哧的自己研发了哈，比如一些这个社区内比较知名的开源的，好几个了吧，什么 httprunnerManager，Hitchhiker 之类的，都已经停止更新了哈，风向标比较明显。用些好用的开源的就行了（httprunner 是可用的我是支持的！）。

大家说的都挺好。
最近我发现测试的技术要求和开发的技术要求确实是真的不一样。
倒不是说我自己技术有多好多牛，而是说我在提升自己技术的路上，和开发提升自己的核心路线，不一样。
比如我最近接触了两种架构师，一种是倾向于框架各种使用的架构师，一种是研究底层的架构师。当然正常工作都是没问题的，就是人家的 “爱好” 不同，分享的东西不同。
而测试我自己的学习路线，相比之下，比较杂，比如我学过的（就是主动去了解的），或者测过的：网关，消息中间件，ES，数据埋点，监控平台数据上报，性能测试（工具使用和调优手段），项目管理，敏捷，技术管理，devOps，springboot，python，中台，秒杀系统等。
就说研究底层的吧，比如我知道 CPU 有寄存器和高速缓存，我知道大概是做什么的，但是区别我是真的不如人家了解，再比如我知道有虚拟内存和物理内存的区别，但是来龙去脉是什么，我没人家了解，或者 docker 的 namespace，cgroup 原理，这都是底层的，我真没人家了解。
就说研究架构的吧，人家要不说，我不知道 Apollo 是什么，或者 Nacos，或者 ETCD 和 zookeeper，或者 zookeeper 和 Eureka 的区别，或者 Druid 和 HikariCP，或者 sharding-sphere，或者 skywalker，可能我听都没听说过，名字我都要百度去查。
有些架构师是 C 语言出身的 Java，有些是 Java 和 Go 都会的，而我最多会个 Java 和 Python（人家 Python 也会），很尴尬。
那么我要测试这些东西，我听都没听说过，我还要评估人家的水平，那这活我是干不了的。
我越来越发现吧，测试工作做到上层，一个测试是要 “服务” 很多种类的架构师的，那么这时候你告诉我测试技术不重要……我真是有点儿呵呵了。
对于测试技术这事儿，我也很烦，因为我都不精，太杂了，技术栈不明确，唉唉。

这个纯前端的我也不了解哈~并且我也 2 年左右没看过这个项目了。
另外我不建议重构哈，除非你也是为了 KPI。

可能是 KPI 项目哈。有点儿可惜。