谈谈对测试技术的一些看法~

最近没前面那样一天更几篇文章了，挺丧的， 可能是之前弦绷的有点紧，现在有点受不了了。 所以突然就泄了气，每天忙完工作的事后就躺在家里打游戏。其实感觉每年都有一段时间是这样丧的。所以我自己其实并不是特别努力的类型，我没办法一直绷着弦的去卷，到了一定程度我就泄气了，而且是脑子放空的那种状态，就是什么都不想去思考的状态。前面看了一个关于吐槽的帖子，所以想聊聊自己的一些想法了。

先说一下总体观点

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

比如：

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

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

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

再说一说技术能力

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

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

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

我认识的一些技术能力还可以的测试人员，薪资待遇都挺不错的，在一线城市都是大几十万年薪的，因为这样的测试人员确实挺稀缺的。即便是我一个已经 43 岁的前同事，也在去年拿了 70W 的 offer（外企）。这些硬技术能力是无关是否能造什么轮子的。这就是测试这款产品的硬技能。我在网上碰到好多同行都会问那些年薪几十上百万的测试人员是怎么做到的，这就是答案了。

总结 

说了那么多，其实软件测试要学的东西都摆在那里了，剩下的只能靠自己去学习，当然有人帮你会轻松很多，我之前为了学点技术真的吃够了苦，主要还要看人脸色，问多了别人也就没有耐心回答你了，所以碰到良师益友是一件幸运的事情。

 “因为淋过雨，所以总想替别人撑伞”我特别喜欢这句话，希望与君共勉~

尾声

好了就写这么多吧，最后感谢每一个阅读我文章的人，一点小心意，虽然不是啥值钱的东西，需要的话直接拿走： 

上面是我收集的一些软件测试资源，这也是全网最全面最完整的软件测试资料库了，在这个过程中帮到了我很多。如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以点击下方小卡片免费领取