测试开发之路 聊一些对测试技术的看法

孙高飞 · 2022年09月16日 · 最后由 孙高飞 回复于 2022年09月26日 · 12137 次阅读

前言

已经忘了有几个月没更新文章了。最近挺丧的, 感觉可能是之前弦绷的有点紧,有点受不了了。 所以突然就泄了气,最近书也没怎么写,忙完工作的事就是躺在家里打游戏。其实感觉每年都有一段时间是这样丧的。这也是为什么我说自己其实不是特别努力的类型,我没办法一直绷着弦的去卷,到了一定程度我就泄气了。而且是脑子放空的那种状态,就是什么都不想去思考的状态。 连打游戏也必须是那种无脑的,本来前几天买了奶刃 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 和汇报搞出来的轮子,而且这些轮子并不好用。我只能说我们控制不了这个情况。我们只能控制自己,不要加入到毒瘤大军中去。而且其实也有不少轮子是挺好用的,我们还是需要理性看待。 轮子的出现往往是因为特定的土壤,有些我们觉得匪夷所思的轮子,其实可能是因为对应的环境就很匪夷所思,大会中讲师们介绍的轮子也都有其特定的土壤,我们了解一下思路就可以了,如果对自己有帮助就可以实践一下,如果没帮助也不用过于愤怒。 工作就是解决一个又一个问题的过程,而在解决这些问题的过程中,我们势必会造出一些轮子来辅助我们工作,这是必然的结果,我们要理性的对待,不可过于排斥。造轮子的过程其实就是我们对于问题的总结与解决方案的沉淀。这是提升技术能力非常有效的手段。

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

尾声

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 22 条回复 时间 点赞

测试

我问个几个问题啊。
1。
我最近问我徒弟,你怎么看自动化,自动化的本质是什么?
我徒弟经过 2、3 年的几家公司洗礼后,回答 “本质是压缩成本”。
你怎么看这事?最终技术会不会让测试只能留下极少数的人,剩下的多数都是点工。同时大部分测试技术只会在一线城市的小范围内存在。
2.
工业界,我个人认为核心在于解决未知和已知的边界。
因为我人在二线城市,技术能力整体偏弱,测试不添乱就不错了。
比如说偏预研性质的团队,有没有测试参与,如何参与?
3.
DEVOPS 可能是趋势。
我狭隘的会认为环境治理的本质还是资源调度,资源流转才是真金白银。
支撑业务,维护大环境肯定是非常有价值,我不太懂,所以想请教一下,在这块有没有什么例子可以证明测试在 DEVOPS 中起了哪些价值?我也想了解了解。

这几个是我一直有的疑问。。。

前段时间也看到帖子事情了,感觉就是人这一辈子会怎样从来都是自己事,总有人自己都不知道怎么活,却想要趋同所有人;活着就挺累了,还要去扯哪些大概率与己无关的事情

大佬,我最近也是很丧很丧,最后忍不住在社区发帖。
对于您这篇对技术的看法是完全赞同的,因为我知道,同样的人,有的 30 岁失业,而有的 45 岁还在如日中天。
社区转的 maimai 的那篇我只看了一部分,感觉就是没必要争论吧!你在山顶看到的是山顶的风景,在山脚下的人无法体会的。这个属于认知的问题了吧~

我是女的。比方说:有人的观点是,你找个有钱人结婚就好了呗!
我不争论,你觉得这样好你就按你的来~ 我觉得怎么好,我就按我的来,谁也管不着~

magicyang 回复

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

风子 回复

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

非常赞同大佬说的,测试的高级阶段肯定是需要技术的,另外,技术一定是服务于业务,多探索,哪怕失败了,没有落地,这个过程也是有成长的。
很多大而上的方案在很多小公司从一开始就知道是不可能的,小团队里,测试人员能做的以最小的人力投入和最高的效率解决项目中的问题,自动化绝不是目的和唯一手段。

感觉功能测试要走向细分专业化的道路才行,现在功能测试其实很水,特别是复杂一点的系统,根本说不上经验。你说的例子确实很好,要扎根一个行业对测试而言要靠谱些。

之前我的认为是 C 端产品测试技术复杂于 B 端产品测试技术。我自己是 B 端产品测试,看见转转 QA、美团 QA 那些实践都羡慕的不行。但 B 端的专业领域知识依赖性确实要比 C 端重一些。

ganker 回复

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

赞~同意文中全部观点

自从加了高飞老师的 switch 好友,我的日常变成了:高飞大佬上线了!那我也玩一会吧,大佬都休息了我还卷个毛。看到高飞大佬不在线,那我也玩一会吧,等他上线了我就不玩了去学习……噫,怎么天亮了?😂

言真意切

我去催饭 回复

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

孙高飞 回复

怪猎不费脑子……真的都是肌肉记忆,建议入手,斩斧耍起来真是愉悦感爆棚

我去催饭 回复

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

技术能力强不强,这个不能一概而论,还是要看你所处的行业的。

如果,你处在大数据、机器学习等领域,不会所处行业的专业知识,你是玩不转的;
如果,你处在金融行业、教育行业,那么技术就不是必需品了,对于业务知识的理解、行业的政策要求等,这些更重要;

不管技术与非技术,没必要分个高下,只看需不需要。

其实测试本就是属于研发的一部分,有些公司或部门连测试都没有,照样玩的转,不同产品不同阶段不同团队,质量都会有不同含义
B 端业务我比较少涉及,如果要求测试人员有很强的领域知识,是不是可以理解为,没有很强的产品经理帮忙解耦?术业有专攻,不否认测试拥有很强的领域知识有利于开展测试,但反过来看,非要测试拥有很强的领域知识才能测好,那要产品经理干什么?一旦陷入这种怪圈,整个团队都可能成为瓶颈,队公司是不利的,老板不敢换新人,老人摸鱼也不敢炒掉,谁会自讨没趣帮团队搞自动化?最后,劣币驱逐良币,这个团队的自动化能力只会越来越弱

孙高飞 回复

P5 超级好玩,不反感 RPG 游戏的话极荐,我之前玩 PS4,P5 和大镖客是我心中的并列第一。

狂天 回复

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

保卫战 回复

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

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册