前言

已经忘了有几个月没更新文章了。最近挺丧的， 感觉可能是之前弦绷的有点紧，有点受不了了。 所以突然就泄了气，最近书也没怎么写，忙完工作的事就是躺在家里打游戏。其实感觉每年都有一段时间是这样丧的。这也是为什么我说自己其实不是特别努力的类型，我没办法一直绷着弦的去卷，到了一定程度我就泄气了。而且是脑子放空的那种状态，就是什么都不想去思考的状态。 连打游戏也必须是那种无脑的，本来前几天买了奶刃 3 的卡带（哦对了，3 代不能叫奶刃了 ，得叫平刃）但怎么都玩不下去了， 没有心思体验剧情，也没心思去学那超级复杂的战斗系统。所以又翻出死亡细胞，哈迪斯和无间冥寺在那里砍砍砍，不怎么需要动脑子的那种。 之所以今天突然想写点东西了， 主要还是看了 maimai 里吐槽 MTSC 的那个职言被人转到社区里讨论的帖子（链接：https://testerhome.com/topics/34288）。所以想聊聊自己的一些想法了。

先说一下总体观点

从 maimai 上和社区的帖子中，我好像又看到了技术与非技术之争的影子。曾经这个话题在整个圈子里讨论的非常火热，双方各执己见，争论不休，谁也说服不了谁。 但好像跟技术与非技术之争又有些区别。可能是随着这几年招聘市场上对测试人员的技术能力要求的越来越高有关系，技术与非技术之争渐渐消失了，大家都默认了做测试要想发展的好，那就需要比较好的技术能力。所以我说现在的争论跟之前好像也是有区别的。现在大家可能已经承认了技术能力的地位，但还是有好多人认为现在圈子里玩的技术都是不能落地的，纯炫技的东西。 所以虽然争论的点跟之前有所不同，但我个人感觉本质上还是带着对技术的歧视色彩。好多人都觉得技术并不能很好的服务自己的业务。 我没事逛 maimai 的时候其实也看到了很多测试同行的吐槽。比如：

• 现在测试要求越来越高了，也越来越卷了，要求会自动化，会性能，会这个会那个的。 单纯点点点难道没机会了么？
• 面试造火箭，进来拧螺丝。 面试的时候要求这个那个的。 进来以后不还是点点点么。
• 现在公司里各种造轮子，但都是在自 high，并没有为业务解决多少问题。都是为了晋升为了汇报，并没有解决多少业务问题。

讲道理上面说的这些情况确实存在，尤其是最后一点，我本人确实也有感触，我在被强迫使用公司内部的一些轮子的时候，其实也挺难受的。大家吐槽圈子里的各种大会，也是觉得现在圈子里玩的技术也都是属于这个性质的。但其实我们还是不能一杆子打死所有人的。我自己对这些事也有一些看法：

• 我们要承认圈子里确实有这种情况，但也不能因此一杆子打死所有人。这世道上还是有很多人在认真的使用技术服务业务的。我们不能因为一些个例就否定了所有人。而且有些时候我们觉得某些轮子是扯淡且无用的。很可能只是因为我们不懂这个轮子的使用场景。毕竟每家公司有每家公司的特殊情况。这个东西在我们眼里可能没什么价值，但是放到人家的场景里，可能就是有用的。
• 技术服务于业务的探索是很困难的，它就好像是做一个产品一样。稍有偏差可能落地效果就很不好。我成功过很多次，失败的也不算少。 不能因为失败的案例，就放弃，就否定。
• 从大家的吐槽里可以看出，虽然大部分人没明说，但其实都表达出了市面上这些技术那些技术的并不能很好的帮助业务。前几天我好像刚在 maimai 上刷到有人吐槽搞自动化没什么收益。这种现象也存在，也许业务不适合做自动化，也许团队的能力不足以支撑稳定的自动化项目，也许工作更偏向 C 端更偏向业务流程，工作中用不到什么技术能力，这些现象都存在。但相信大家现在应该都会认同一个现实，技术能力是大部分测试人员面试，晋升，涨薪最有效的途径。如果你想拿到更高的收入，更高的级别，就需要提升自己的技术能力，这个就是现实吧。而且在这个行当里，还是有非常多的技术型产品的，在这些领域里没有相关的技术能力，你是连测试用例都写不出来的。因为在这里技术就是这个产品的业务。即便抛开造轮子这点不谈，不学习对应的技术你确实写不出来测试用例。 就好像要你测试一款 IDE，如果你连代码都不会写的话，那怎么可能设计出测试用例来呢。

再多说一说技术能力

上面我提到过，在刷 maimai 的时候还是能刷不少人话里话外对技术的质疑。 我觉得这是很可怕的。 因为不论在研发圈子，运维圈子，甚至在产品圈子里，都很难能见到大家对技术的质疑。 有些产品经理为了能够设计出好的 B 端产品，都在认真的学习一些技术概念和流程。好像只有测试这个行当里的人，却总是质疑自己的岗位跟技术没多大关系。我觉得这才是最可怕的，因为打从内心就否定技术价值的群体，注定是没办法在这条路上走的更远了，尤其在现在整个招聘市场上对测试人员的要求越来越高的背景下。

可能我最近 7 年都是在 B 端业务中工作，所以在评价一个测试人员的能力的时候，技术能力在我心中的地位更为重要。因为 B 端业务中有非常多的产品不是给普通人用的，它们被设计出来给一些专业领域中的专业人才使用。所以抛开研发人员不谈，产品和测试都需要掌握该领域内的专业知识才能工作。当然这些专业知识中不全是技术的，这要看产品形态了。比如我去年跟一个在平安保险工作的同行聊天的时候，他就是专门测财务系统的，当初为了能测试这个业务还专门去考了会计证书，这里会计虽然不是咱们传统意义上的技术能力，但其实也是相当专业的知识了，与 C 端给普通人用的 APP 是完全不一样的，需要测试人员有相当的专业功底。而我的一个前同事（算我半个徒弟吧，毕竟不是汇报给我的，我只是教了她一些东西）。对 docker 和 k8s 非常感兴趣， 在范式的时候跟着我在 k8s 下做混沌工程。后来离职以后去了 vmware 去测试那里的公有云 K8S 产品去了。这个岗位其实很难招，因为需要测试 K8S 本身，那就需要对 K8S 非常了解才行。而 K8S 的复杂度和学习难度在业界是有目共睹的了，在测试圈子里很少能碰见对 k8s 比较熟悉的人。 在不少地方都是让现有的测试人员赶鸭子上架 -- 硬上。结果其实挺明显的，各种各样的漏测和生产事故。

这样的事情其实层出不穷，我自己最近也是深有体会。因为最近这一个月我都在测试我们产品的高可用，而由于我们的产品底座使用了公司研发的商业化 K8S 产品，所以其实我们主要依赖了该 K8S 产品的高可用能力。而这个 K8S 产品有对应的测试团队来负责，所以理论上其实我们的高可用测试应该是可以很快完成的，毕竟兄弟团队已经测试过了。但实践过程其实很不顺利，我大概报了 40 多个高可用的 bug，其中有差不多 30 个是给这个 K8S 产品报的。一番沟通下了解到该产品的测试人员其实并不是很懂 K8S，所以很多 case 没有想到。后面沟通着沟通着就变成我直接跟该产品的研发团队对接了，他们很多时候直接提测给我来测了。所以其实在 B 端产品，或者 C 端非常底层的产品中。测试人员之间的技术能力差别影响的还是很大的。

所以其实我认识的一些技术能力还可以的测试人员，薪资待遇都挺不错的，在一线城市都是大几十万年薪的，因为这样的测试人员确实挺稀缺的。即便是我一个已经 43 岁的前同事，也在去年拿了 70W 的 offer（外企）。这些硬技术能力是无关是否能造什么轮子的。这就是测试这款产品的硬技能。我刷 maimai 的时候好多同行都会问哪些年薪几十上百万的测试人员是怎么做到的，这就是答案了。 所以我总在写文章的时候跟大家说有机会尽量去 B 端业务试一试，C 端大部分的测试岗位确实技术属性较少，业务也都偏简单。

再多说一说轮子的事

我相信在很多公司里都会存在不少为了晋升，KPI 和汇报搞出来的轮子，而且这些轮子并不好用。我只能说我们控制不了这个情况。我们只能控制自己，不要加入到毒瘤大军中去。而且其实也有不少轮子是挺好用的，我们还是需要理性看待。 轮子的出现往往是因为特定的土壤，有些我们觉得匪夷所思的轮子，其实可能是因为对应的环境就很匪夷所思，大会中讲师们介绍的轮子也都有其特定的土壤，我们了解一下思路就可以了，如果对自己有帮助就可以实践一下，如果没帮助也不用过于愤怒。 工作就是解决一个又一个问题的过程，而在解决这些问题的过程中，我们势必会造出一些轮子来辅助我们工作，这是必然的结果，我们要理性的对待，不可过于排斥。造轮子的过程其实就是我们对于问题的总结与解决方案的沉淀。这是提升技术能力非常有效的手段。

我其实挺鼓励大家造轮子的，这是一个主动探索的过程。最后轮子很可能是落地失败的，但这不要紧，关键的是你一直主动在探索的这个过程，会让你成长的非常多。尝试的次数多了，总会有非常成功的轮子的。而这些成功的轮子以及在造轮子的过程中会给你带来非常大的成长。也会为你的简历增色不少。 相信我， 这比你什么都不做要好的多的多。当不停的思考解决方案已经成为了你的习惯以后，你整个的职业生涯就会变得不一样的。

尾声

好了就写这么多吧， 开始写东西了也代表了我不能这么丧下去了。 这周开始恢复写书，恢复更新。