有啊，我现在就在瓶颈了， 今年 36 岁了， 技术职级已经到了我能触及的天花板了。 现在我自己的感觉就是即便再去学技术，也升不到下一个级别了。 再往上升需要产出有足够影响力的东西，可能是跨团队甚至跨部门的东西，而这些东西不是单打独斗能搞出来的，需要团队和业务的加持，但我当前的业务和团队都不够分量。所以受业务限制，我即便再去学习新的技术或者再深挖当前的技术，都很难升上去了。 以前没太大感觉，觉得有技术哪里都行， 现在深刻的感受到业务和团队的重要性。

没专门学过性能，其实都是针对 K8S 和 linux 的学习以后，自然而然的就有排查思路了。 所以还是要熟悉我们测试的产品的原理才行。

这个是你微信么

我看大家还都是按照没有专职的性能岗位这样的思路来回答的，这个大家说的也都没错，我就不重复了。 目前的行情是比较看中测试开发人员的综合能力的，这也是为什么大家都劝你别在性能测试上下太大的功夫。 但其实我想换一个思路来看这个问题，其实要做好性能测试的话，本身是需要比较强的综合能力的，当你把一些复杂的性能测试场景玩明白了以后，那么也就练成了一身较为不错的综合能力了。当然如果大家认为的性能测试就是用 jmeter 这样的工具对某个接口施压统计出个 TPS 这类的指标的话，那就当我没说了，因为如果负责的场景就是这么简单，那确实练不出什么有竞争力的技能。

我用一个我带的姑娘做的性能测试场景举例吧。

• 首先她需要模拟的就不是并发量，而是设备数量。因为我们是一个基于计算机视觉的人工智能产品，所以对接的都是网络摄像头，不能用 jmeter，而是使用 ffmpeg+ EasyDarwin 来搭建流媒体服务器。针对测试数据也需要裁剪，拼接，抽帧，调整分辨率等工作。 这需要测试人员学习一些视频领域的东西。
• 她需要学习 K8S 和 docker，因为我们产品整体是基于云原生架构的，她除了要在日常工作中有操作 K8S 和 docker 的需求，也需要把她的流媒体服务器和性能测试工具等等部署在 K8S 中。需要了解 K8S 怎么管理资源的，怎么计算负载均衡的，怎么实施资源超卖的。
• 性能测试除了要测试性能瓶颈外，还需要进行容量测试。尤其是在云原生架构中，每个容器都申请了不同的资源（cpu，gpu，memory，存储），这些资源具体应该设置成多少需要经过严谨的性能测试。而云原生 往往伴随着微服务架构，所以这个姑娘往往要面对几十甚至几百个服务的资源用量统计，包括每种资源的 request，limit，平均占用，最大占用等等，并需要分析每个服务的资源设置是否合理。 这种数据收集和计算的 工作如果是人肉的那很显然是不能接受的。所以她需要学习监控系统的使用，在我们这里就是 prometheus，这需要对 promql 比较熟悉，通过编写代码来向 prometheus 发送 promql 来进行统计和计算。 这里除了要学习 prometheus 外还需要学习前后端的开发，因为我们这里是把这个监控能力平台化了。
• 再说容量测试里，如果涉及到了一些存储系统，那也需要评估出需要申请的存储量，比如我们最近在执行的性能测试里包含了 ES 组件，这里需要测试出 ES 在 我们的业务下需要支撑多少数据量，在该数据量又下能支撑多少 qps。这就需要她对 ES 有一定的了解，需要学习 ES 官方的压测工具 esrally 的使用。

以上是我们这里这个妹子需要去学习的技术点，这样她才能完成她的性能测试工作。 而如果是我 曾经带过的另一个组（他们测试大数据产品的），那里的性能测试则是需要模拟大规模数据的场景 。所以他们需要学习 spark，hdfs，异步 IO 等技术。这个细节可以看我之前写的帖子：https://testerhome.com/articles/31471

总之就是其实负载的性能测试场景搞下来，也是会练成一身不错的技能的。但严格意义上来说， 这里面很多技能确实不算是性能测试技能。这个就看大家怎么看待这些事了，我个人觉得重要的不是性能测试本身，而是通过性能测试能学到什么，就像我聚的例子，我们这的这个姑娘就算以后不做性能测试了也没问题 ，因为她通过这份工作学到了 prometheus，k8s，docker，前后端开发，视频处理以及部分中间件，所以他换一家公司去做别的工作也没有问题。最后我想说的是分析系统性能瓶颈并给出优化建议这事对于测试来说不太现实，现在软件架构复杂到了已经轮不到测试人员指手画脚了，最好别妄想能指导专业的软件架构师做事情。专业的事情留给专业的人做就好。

我已经不在范式了~~ 目前在腾讯， 我们这现在没有集团 hc 了~ 只招西安的~ 现在行情难啊

我个人是不太会写简历的（我没经过编写简历的培训），所以我写简历挺随意的。 我的思路一般都是在想 -- 如果我是面试官的话， 一般我想从简历里知道什么东西。所以我一般都喜欢简历里直接去写我最擅长的东西和我认为我做的最重要的，最能体现我价值的项目，并且我会把这个项目的技术会较为详细的写一下（目的是希望突出项目难点）。 因为我在做面试官的时候，其实很懒得看那么长的简历的， 尤其是为了凑字数而写的各种流水账我是很不喜欢看的。所以我做面试官的时候希望候选人的简历是能直接看出他最擅长的东西是什么的（要是流水账太多我就会弄不明白他到底擅长什么），我写简历的时候也会把那些不重要的直接忽略掉不写（工作 10 几年了，要是都写那得多少页）。

我这里贴一段我简历中的一部分， 大家可以讨论一下， 我的简历带有我强烈的个人风格， 其实我也不知道这么写是不是比较好。

我的简历里， 基本上就是 3,4 个这样的项目撑着，其他的基本就不写了，或者在个人简介里一笔带过。 我的想法其实就是不想让一大堆的东西晃到面试官的眼睛， 让他迅速的知道我擅长什么（写太多了，我估计面试官就不知道我到底擅长啥了，或者直接就不想看了）。而且东西写多了，还有个缺点就是面试官一下子就跳到了那些没什么亮点的东西上去问， 那就更不好了。 所以我的习惯就是只要我写在简历里的，就是有亮点的。

如果实在有太多的东西想要点缀上去， 我的习惯是放在个人简介里：

哈哈哈哈， 有那味了。

欢迎大家加入

感觉老板喜欢推敏捷， 其实还是想迭代速度快一点吧， 不想搞几个需求就拖那么长时间， 毕竟市场如战场。 其实老板心里也知道在这个阶段质量不是那么重要，别有严重的 bug 或者 bug 别太多就行，还是抢市场更优先。 哪天老板开始抓质量了，那就说明要么是之前有点玩脱了，质量有点看不下去了。 要么就是客户的数量已经到一定程度了， 必须要开始抓质量来稳用户了。 要不然以 TOB 产品的特点，质量不好的话光是给各个版本打补丁都会被玩死的。

嗯 ，外企确实也受影响了， 微软和谷歌都有裁员的新闻， 前几天跟朋友聊天， sap 也开始裁员了。 在 vmware 的同事也说 hc 比较少。 但应该还是会有坑的，可能就是很少。在范式的同事已经有 3 个去了 vmware 了，大概也就是年前有个同事拿到了 offer。 所以先学起英文做个储备吧，就算以后不去外企，也可以用来辅导孩子的英语。

从上周开始学习英语了， 每天在地铁上听 BBC， 也买了个老友记精讲课程学听力和口语， 好在之前有点底子，12 年左右的时候在硅谷呆过大半年，所以学的不算很吃力。今年 36 岁了，因为国内市场对大龄 IT 人员的不友好，所以我也在焦虑 40 岁以后的发展。 初步的想法是尽量延长自己的职业生涯，所以除了要学习技术外， 也开始学习英语。 为以后进外企做准备（外企不是很看重年龄，如果哪天被公司裁了，就可以考虑去外企试试了）。

感觉行业状态越是低迷， 就越不能放弃自己吧， 尽量的在茫茫众生中杀出一条血路。 当然也有人说以后外企什么样子还不知道呢，现在就花这么大精力学外语可能到最后毛用都没有。 我觉得也许会这样吧，很多时候我学习一样东西的时候其实也不确定以后是不是真的能派上用场。 但书到用时方恨少，等真到需要用的时候才开始学习就已经晚了。 所以我的习惯都是先学了再说，学总比不学要好，没准哪天就真用到了。

可能会有这方面的因素吧。 总结一下我最这一年的技术积累也变少了。 不过我最近没写帖子的原因是因为正在写书。。。实在抽不出时间写帖子了。

这个事怎么说呢。 测试一个产品的前提得是能理解这个产品，成为这个产品的用户对吧。 如果都没有能力成为这个产品的用户当然也就没法设计测试用例了。 就好比一个人作为车场的质检人员。 但是他本身不会开车，也不懂车里的任何设备。那是测不了的。 不管设计这个车的所谓的产品经理有多强， 他也没办法能让一个根本没开过车的人能测试的了这辆车的。

同样，B 端的产品也是这样的道理。 就拿我现在负责的产品来说。 主要是分为两种产品，一种是基于 K8S 的商业化云产品，一种是基于深度学习和机器学习的 AI 平台。这两者都不是给普通人用的。前者需要测试人员懂 docker，k8s 这些虚拟化领域的专业知识， 后者需要测试人员懂得人工智能的基本业务流程。要不然是测试不了的，你连产品经理在说什么都听不明白的。

那我后面还真 要高低买个 p5 玩一下了。

那好像比较适合现在的我啊。后面我还想 看看 p5 啥样。 看开端的时候卢迪说 p5 天下第一。 我想感受感受。 虽然目前 我玩的游戏里还是塞尔达最好

哈哈哈哈哈哈。 我看你最近 还是在玩怪猎么。 我刚买了奶刃 3，但是玩不进去。 感觉 switch 后面有好多好游戏啊。 P5 也要移植到 switch 了。

这个分情况的。你看到的互联网大厂里一些 QA 分享的各种平台和轮子都是个例。 能有机会去做这些事情的毕竟是少部分。 大部分人还是把精力都放在了业务测试上的。而 C 端业务大多是给普通人用的，所以技术含量偏低。 而 B 端业务大部分是给专业人用的。所以即便不去造一些平台和轮子。其专业技能的要求也比 C 端的大部分岗位要高

其实讲道理，我觉得我给的建议可能不太有用 ，咱们的经历相差太多了。 这种情况下给你的建议可能都是不适合你的。 有些时候真得是自己想通了，开窍了最重要。 其他人的建议大多数都帮不上啥。

直觉上，应该是楼主的学历拖了后腿了。 如果是本科毕业的话，懂得这些东西在深圳 12K 确实低了。 最近其实应该各个大佬都不会建议你跳槽吧。 现在的大环境太差了。

嗯嗯， 你这样的心态我觉得挺好的

你问的这几个问题我觉得我也答不好。 其实我很少去思考这些问题。我都是把眼下团队里的问题解决掉就好。 我很少考虑什么自动化的本质是什么这样的问题。 我只要判断自动化是不是在我当前团队里有用的， 有就搞， 没有就不搞。

测试

因为丧。 所以现在有点不务正业~~~ 好久没写书了，也没啥动力学习，工作上一忙完就打游戏了。 而且还必须是打不用费脑子的游戏， 我最近真的是大脑疲劳了。 奶刃 3 买了以后仍在那碰都不想碰。 那个复杂的战斗系统和剧情太烧脑。

我没说你啊。 我说的楼主是 maimai 里发帖子的那个楼主

最近有点丧， 一直没管工作之外的事。其实很早之前我就在 maimai 上看到这个职言了，当时我还发群里给恒温他们看。 但我们一直也没管，毕竟人家有发表自己看法的权利。 那现在我来说一下自己的想法吧。

关于过于极端的观点

怎么说呢，我一直觉得国人非常容易陷入某种特别极端的观点中，从这个职言中其实可以看出来楼主和部分其他人已经陷入了什么观点都听不进去，只认为自己是对的这种极端情绪中了。 之所以说极端，是因为好多人都觉得社区的大会全部都是落不了地的平台轮子，就没有一个是有用的。 这话明显就太极端了。老实说关于炫技，落地困难的情况有没有？那肯定是有的，要说一点都没有我相信社区自己也不信。 但讲道理，所有议题全是炫技和无法落地的东西。 这话说出来，不觉得莫名其妙么，我也不怕得罪人，有些议题觉得无法落地可能确实是过于偏门了，也确实有讲师为了体现技术含量而过于设计了，但有些时候可能单纯的就是你没听懂这个议题，你不懂的东西当然觉的无法落地。就是我参加议题评审的时候，遇到不属于我所在领域的议题的时候，我一般也都是闭嘴的，这些议题在我看来也没办法落地，但这只是单纯的我不懂，人家 PPT 里讲了一堆视频领域的指标，我以前压根就没听过，这是很正常的事。而且炫技这事有这么不能理解么？咱们出去面试，在公司搞晋升搞分享，哪个不炫点技？搞一些平平无奇的东西面试能成功么？晋升能成功么？大家问问自己，自己去面试和晋升的时候，是不是也得挑技术含量高的说？所以讲师出来分享议题的时候，稍微包装包装，挑一些有技术含量的东西来展示展示自己的能力，这个其实无可厚非。大家还是不要过于双标，严于律人，宽于律己。

关于无法落地

关于能不能落地这事其实很主观的，上面我也说过确实有议题和讲师为了炫技搞了一些过于设计的东西。也有些议题很冷门，很小众。 但其实大部分时候，对于我来说，能不能落地的前提在于我是不是已经涉足了这个领域了， 是不是在这个领域里已经积累到一定程度了。 也只有我自己在这方面有很长时间的研究后，我才能分辩出这个议题是不是靠谱，在落地过程中会有什么重点的困难， 这些困难讲师有没有说到。 我在评审议题的时候，遇到我擅长领域的议题都是能看出来讲师是不是在胡扯的，甚至我能判断出来讲师是不是真的做过这块内容，是不是在拿其他人的成果在这里充数。 因为外行人是蒙不了真正在这方面研究过几年的专业人员的。这一次议题评审的时候有个测试 AI 产品的议题，我一上来就说了这个人应该不是专业做 AI 的，他 PPT 里的内容都是拿别人做的东西拼凑出来的，思路非常混乱，而且关键的问题全都被他回避了。 只有拥有这样一些该领域的专业能力以后，很多议题才对我来说是可以落地的。 因为听议题听的是思路，而不是实现方式。如果大会对讲师的要求是在 40 分钟内让 0 基础的人能回去直接落地的程度，那就没讲师能通过审核了，因为那得是神一样的语言精练能力啊。 大家想想，学生时代的时候学个 java 还得一个学期的时间呢， 要是谁能 40 分钟讲一遍就能让学生自己去实践项目了。那培训机构就可以都倒闭了。 很多时候当你有这个能力基础的时候，真的是听一遍思路就知道怎么回事了。 你就可以判断出来这个议题对自己有没有价值， 我回去以后要怎么针对这个思路来定制化我自己的场景。

最后说说关于听大会的姿势

• 首先对于任何一个人来说，大会中的议题中绝大部分对你都是没有什么用的。 这一点我觉得大家要达成共识。就像对于我来说，AI，大数据，容器，混沌工程之外的所有议题对我来说都是看个热闹。为什么？ 因为不管讲的多好我也用不上，我就没那个需求。 大会一定是尽量包含更多领域的内容的，所以预期上还是要管理好的。
• 尽量挑自己擅长的领域内去听。不要因为这个技术比较新就去听， 因为去了可能也是听的云里雾里的。真的，很多议题我都觉得如果不是专业人士，去听了就是浪费时间的，吸收不到什么有用信息的。
• 一定要预习，你想听这个议题。在事前就去搜这个议题的相关资料，否则就还是听的云里雾里的。真的就是除非你在这个提议场景里本身就非常专业了， 否则在没有准备的情况下去听，肯定是效果很差的。 换谁也不可能在 40 分钟里把前因后果全都明明白白的讲清楚的。 讲师在分享的时候，有个预设条件就是很多基础知识听众是懂的。 比如要是我去分享混沌工程的东西，那我一定预设听众起码对一些开源的故障注入工具，以及 docker，k8s 还有一些通用的高可用设计是了解的。否则光是讲一个高可用设计中的数据同步这么一个小点，你给我 40 分钟我可能都讲不完。