职业经验 测试转研发的一年总结

卡农Lucas · 2021年11月07日 · 最后由 卡农Lucas 回复于 2021年11月11日 · 5426 次阅读

今天不连载了,另外原谅我开篇会写一些 “废话文字”,目的是交代一下过去以便于更好的理解现在。

感悟

不知不觉转型纯业务 JAVA 后端研发已经接近一年了,我记得整个零售产品技术部测试转研发的也只有我一个人。那时也正是双十一之后,因为彼时我在交易域,需要坚守完大促的最后一班岗,保障大促平稳度过。

在此,我也感谢一下我之前的老板,以及现在的老板,感恩他们给予卡农 Lucas(本人)同学在职业选择上的指引和帮助。毕竟,在我和恒温这个年纪,跨领域转型是需要极大的决心和毅力,毕竟开发和测试是两条赛道,即便是纯测试平台底层基建的同学,没有纯业务的实战,同样会面临严峻的考验。

我之前一直从事测试效能平台的研发,在京东的代表作是云测平台,底层是基于 OpenSTF 做的二次开发,我还在社区创建了一个 STF 组,但是很遗憾,随着我转移方向,对云测技术的探索也画上了句号。之所以换个赛道,是因为我需要更多更广的技术积累,而微服务、大数据、云原生、流计算、并行任务、检索等在 150 多号人的测试团队里是很少用到的,而且用什么技术、采取什么架构也缺乏有效的评估。另外一个因素是走出去,看看大厂都在玩什么,虽然我参加了很多技术论坛、分享会,但总感觉很多内容飘忽在上不宜落地。

赛道

换个赛道后,视野确实拓宽了。这里还有个插曲,因为来本地生活之前,我本来是想去蚂蚁紫嫣老板那里,在此也感谢一下紫嫣总。后来今年年初又转岗蚂蚁。最后在经历过一番思想都斗争后,选择留下来做业务开发,希望在还能够奋斗的岁月里挑战一下极限,梦想着有朝一日,对梦想着。

拓宽的视野体现在以下几个维度:

技术维度:

  1. 接入了几乎所有中间件,包括 HSF、任务调度、限流、消息队列等
  2. 接入了 blink 流计算,踩了流计算插件的坑。
  3. 接入了 SLS 日志存储,由于 blink 管 sls 速率过快,踩了限流的坑。
  4. 接入了监控、运维、日志、告警等一些列基础平台。
  5. 接入了数据开平台,对数据开发有了一定认识。

平台维度:

  1. 接触了流量回放平台。
  2. 接触了端到端插件平台。
  3. 体会了集团持续集成的强大。

业务维度:

  1. 熟悉了集团整个交易链路,涉及商户、商品、营销、库存、交易系统、支付等。
  2. 熟悉了稳定性、资金安全、红蓝演练、废单演练等。
  3. 参与了重大项目奖。

但这里有几个点:

  1. 测试工具维度业务逻辑不复杂,不需要过度的设计和抽象。
  2. 平台维度,能够发挥的空间非常有限,夹缝里寻创新。毕竟在集团你能想到的东西都有现成的平台,重复造轮子是一种资源浪费。但是很遗憾,已有的轮子并不能满足每个 team 的需求,都是按照自己当时的情况构建和开发的,缺乏扩展性。但如果共建,就意味着巨大成本和人力付出。
  3. 业务维度,测试站在最底层,对于架构设计的理解是欠缺的。很多好的工具和平台,是在开发过程中造出来的,不参与其中,不知创新的点。现在也在提倡研发效能,如何提升?

起初我的动力是想成为研发的同时可以洞悉系统的创新之处,辅助或横向输出可以提效的框架或平台,现阶段疲于业务代码的奔命中。当然,每个人的情况不尽相同,对于那些到哪都能发光的同学我送上一句诚挚的问候,“Respect!”

高阶知识的熟练程度

高并发场景使用少,毕竟服务与一个测试团队 200 以内的,并不需要什么高并发设计,即便 200 个人同时访问,两台机器扛起来绰绰有余。而这正是测试工具平台所不具备的。

大数据量场景机会很少用,如何快速高效的在几万条、几亿条、几百亿条数据中查询,也是很少用到的,即便数据全在 ADS,
稳定性的保障,包括系统稳定性和业务稳定性。你以为你判空就够了,空指针无处不在。
八股文的掌握程度。

顶层设计抽象的能力:

  1. 如何高效快速的完成需求,并支持可扩展,这是测试工具和平台所不太关注的,毕竟产品的复杂度在那。
  2. 如何做好建模,领域建模,数据建模,业务建模这也是需要在实践中总结的。好的建模和设计,可以提升效率。
  3. 往往忽略统计、报表类需求的建模,这类需求的特点是数据是实时、非实时及伪实时的,字段不在同一张表里甚至字段需要通过第三方接口取,毕竟网络开销是昂贵的。

框架的熟练程度:

1 对于 spring 全家桶的熟练程度一开始肯定不高。

  1. 框架的抽象封装能力在前期也是需要提升的方向。
  2. 框架的整合能力也需要提升。

其他杂项:

  1. 测试可以怼开发代码差。
  2. 开发相对于测试需要背负更多的责任和义务。
  3. 尤其设计的时候,需要全方位考虑到所有可能的问题,并找到解决方案,尤其需要第三方配合的,不提前识别出风险,对方大概率毙了你的需求。

一个小小的结论:

  1. 35 岁以后转开发,慎重;能力 OK,没问题;一般还是留在测试岗位或测开岗位或 SRE 团队。
  2. 30 岁转开发,如果有一定技术积累,我觉得没问题。3 到 5 年的时间追赶会让你有本质的变化。
  3. 如果技术一般就老老实实干测试。毕竟一个测开的开发能力,普遍在 P5 开发的水位线。
  4. 开发可以降维做测试,我非常同意这个观点。前提是质量意识比较好的开发。除了方法论,但这些方法论一个月就可以掌握。另外,互联网产品 95% 都是等价类(思维导图),之所以还留 5%(我本来想说 99%),是因为可能确实其他领域需要什么因果关系呢。

最后:

测试转开发真的不容易,需要付出比别人更多的努力,而且要忍受一段时间也可能是很长一段时间的寂寞,人们都渴望被重视,但你现阶段是爬坡阶段,接受现实,无论结果好与坏坚持总有回报。

创作不易,劳烦各位看官点个关注,感谢诸位的支持。
(完)

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

需要有一定积累和产出,先在自己的组内得到大家的认可,组织内部还是有一定认可度的。但是转了之后竞争升维,调整好心态。

大佬好,同事好,想请问集团内 测试转岗研发,面试的时候认可度高么,

叉叉敌 回复

测试天花板是比较局限,不过看机会。
纯业务测试生存空间会被进一步压缩。
测试研发比也会压缩。
测试根据风险进行投入,比如交易链路投,其他非关键链路不投测试资源,有问题再打补丁。

自己过得舒服就好。这也是一种生活,工作在人生中才占多少?还有那么旅游,看书,购物,娱乐呢。

jinglebell 回复

尽最大努力,其他交给天意吧。加油。

有一个想法不一定:

  • 测试的天花板还是比开发要低。
  • 纯测试的门槛也低,
  • 看全球大厂,目前微软和谷歌都没有测试岗位了,都是效能提升之类

向大佬学习,本来准备立个 Flag 的,还是算了,哈哈

先阶段没有什么想要努力的动力,只想着拿个够自己生活的工资,多少在存一点。之后打算回家养老去了。现阶段不知道该干什么了。

大佬好,今年 30,但已经明确自己不是做开发的料,安安心心测试,天花板测试总监吧。也许未来会偏项目管理也说不定,但肯定不具备转研发的条件。
1.技术上简单的 CRUD 和自动化接口框架搭建,各种工具杂七杂八有接触和些许实践,最多也就是个初中级测开,理业务开发差距还是不小。
2.兴趣上对代码不反感,有用的时候就去研究,但平时缺少自驱学习,自己能明白自己的短处,也是种自知之明吧
😅 😅

开普敦人 回复

开发不适合我。。。以前在学校有做过开发类的活,明确了自己兴趣不在这块。

JoyMao 回复

客气了。赛道不同,每个垂直赛道都可以成为优秀的人。加油。

槽神 回复

我觉得很厉害了,不知业务复杂度如何,可以尝试挑战一下。

佩服啊,年纪差不多,看看我自己只能一声叹。
工作已经变成了大杂烩:除功能测试、工具、自动化;还兼数据爬取、帆软、安全测试...
感觉自己啥都做,但都不透,迷茫....

乾行 回复

对的。

陈恒捷 回复

大佬 你也可以转开发的!

槽神 回复

对于大多数人,都不要用自己的短板 PK 别人的长处。

我 30 开始兼职 CRUD,到现在(37)还是 CRUD,只不过变成了需求、架构、设计、建模、前后端都能自己搞定的 CRUD,佩服楼主的魄力,这么大年纪……

交易我不敢当,不敢回答你,体系是个很庞大的概念。贯穿整个软件项目的生命周期。
我只能谈谈我做过哪些事情:

  1. 常规的需求评审,正向、逆向、履约(我主要是正向)
  2. 提测质量的监督。(工具平台支撑,比如发提测单)
  3. 全链路监控(接的星环运维)
  4. 流量回放做回归(中间件隔离)
  5. 全链路压测。
  6. 资金红蓝军攻防演练(就是 monky 注入)。
  7. 废单演练。
  8. 提效工具、造数平台的开发。
  9. 发布、回滚监控。

第二个问题,转开发的建议。

  1. 工作两三年有机会就转。
  2. 30 岁以前想搏一搏,转。
  3. 30~35,有 P6+ 开发能力,转。
  4. 其他,做好测试,天花板测试总监。

谢谢

绵绵不绝 回复

客气。

Stone 回复

多谢

Halo 回复

大佬好,同事好。

客气。生存与挑战。

Mingway_Hu 回复

可以

客气

恒温 回复

多谢张老板。

乾行 回复

恩。

Respect!

同事您好

前辈真的太强了,35+ 能有这个魄力和” 折腾劲 “真的是太强了

世上无难事,只怕有心人。
向老哥学习👍
不知可否公众号互相加白名单,想转载一下让更多的同行看到😄

卡农Lucas 回复

前辈客气了,我还有很多需要学习的,称不上大佬。

陈恒捷 回复

感谢恒捷大佬。
现阶段跟你看到基本差不多,测试团队主导研发效能,通过各种质量、指标进行度量。
目前的体感就是交付效率,基本一个需求两周上线,一周代码写完,3 天联调和测试,后续验收和上线。

因为疲于需求迭代,我不一定说的对。

  1. 架构、设计能够给出相应的建议,可能开发确实没想到,通用性设计的考虑以及性能方面。
  2. 因为都在预发测试,所以测试环境数据构造就显得颇为关键。测试环境最好基本要解决低级问题再上预发,要不影响其他人。
  3. 辅助功能的开发,比如人员信息查询,这个要问开发,开发也应该相信测试(最好要快)。
  4. mock 的功能,测试给第三放接口 mock,那是真的太赞了。
  5. 账号映射等功能,比如角色类的代码,可以开发映射功能,提供不同身份人员的视角查看数据,可以通用到所有组织。
  6. 能帮我修一些 bug 和功能,监控、告警、核对等,不是开玩笑,是真的。

请问关于交易链路您们是怎么保障质量的呀?还有您对业务线的测试想转开发有啥建议和思路吗?

加油,前辈~

测试与开发主要是分工不同,随着行业的发展,测试、开发都需要懂代码。
开发、测试沟通过程中为了避免对牛弹琴,测试至少需要对开发用到的技术了解一点,深入一点更好。

点个赞,能在比较大的年纪且测开已经有一定成就的情况下,转开发并坚持下来,Respect!

业务维度,测试站在最底层,对于架构设计的理解是欠缺的。很多好的工具和平台,是在开发过程中造出来的,不参与其中,不知创新的点。现在也在提倡研发效能,如何提升?

对于这个点,个人也有同感,我们常看到的研发效能提升,我个人理解更多其实只是做质量赋能和测试阶段的提效,对于研发流程里面实际耗时最长的开发阶段,提效可能不是那么明显。想问下楼主目前接触开发后,对这个点有什么新的想法可以供测试同学参考不?

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