7年测试经验分享 —— 我在 Z 厂的6个月工作总结，送给迷茫中的你

Posted 2023-04-05 小码哥说测试

▌背景

不知不觉去 Z 厂已经半年了,恰逢前几天成转正述职,趁着这个机会,做个阶段性总结。

▌工作职能变化

Z 厂前: 在一家 K12 教育公司 (简称 S 厂),定位是测试开发岗位,主要负责效能工具研发、自动化、服务端压测、测试环境治理,带 5 人小团队.S 厂的测试和测开分发的,测开不负责业务,所以到最后会感觉到脱离业务比较多,S 厂离职后面试很吃亏,比如: 美团、阿里、便利峰,技术能力没啥问题,主要是简历中无法体现所负责的业务价值。

Z 厂: 目前负责某个业务线,10 人团队左右。Z 厂目前没有专职工具测开,只有业务测开和外包测试。

主要工作内容: 业务线质量把控、过程改进、提效自动化、横向工具建设、团队管理。

Z 厂的测试质量保障体系是专业的,测试左移和测试右移都做很好。业务线的 QA 能力都很强,包括业务能力和工具开发能力。很多平台都是基于业务痛点研发出来,扩散到整个质量保障团队。

▌认知的改变

在 S 厂没有一套完整的测试质量保障体系、沉淀的也少。包括我自己做的东西也是比较散点的、不成体系。

比如: 自动化框架研发,是否能帮助团队提高效率。平台化建设,是否能解决 QA 的痛点。从来没思考过一个好的"测试质量保障体系"应该具备什么? 我们所过的工具价值是什么?

Z 厂,对于业务线测试负责人,需要能梳理并制定当前负责业务线的"测试质量保障体系"。考察分析现状能力、排队问题能力、拆节问题能力。"测试质量保障体系"绝对不是所有都可以用自动化或者平台化解决的,很多还是需要靠人来保障,包括: 沟通、协作、沉淀。

▌能力提升

介绍下从不同方面的"能力提升"

1.发现问题能力

上面这张图,入职半个月基于痛点梳, 可以参考: wiki 文档、线上事故、用户反馈.只有发现痛点,方可制定有效的方案。

2.解决问题能力

• 提出问题: 在工作经常见过,吐槽内部某个工具或者自动化框架不好用,但是往往就无下文,缺乏可优化的方案,并改进问题

• 找到适合的人: 提出问题需要找到问题的接口人或者 on call 群,切勿把问题抛到大群

• 方案落地: 找到对应的人,并且诉说痛点.解决问题不一定是自己,让系统接口人帮忙解决,也是一种可落地的方案

• 问题闭环: 提出问题后,一定让对接定一个 DDL 完成时间放到备忘录中,定时 check 结果

3.业务能力

1. 产品规划

一般业务团队,从业务线负责人规划全年 OKR,然后拆解到每季度 OKR.产品是研发和测试的上游,提前知道产品规划,可以更好根据业务特性制定保障手段和人员储备。

2. 产品指标

产品规划,一般是基于数据指标为导向,比如 XX 提升多少日活、XX 提高多少订单转化。

3. 产品架构

在了解业务一段时间后,梳理一份产品架构图.好处是了解产品逻辑、业务边界。

技术方面,了解端到端的架构设计。

4.技术能力

客户端稳定性建设

客户端专项能力

代码能力

业务线后端 go 语言偏多,也简单学了下 golang,代码逻辑能看懂并且代码在本地搭建完成,研发提交代码后,基本上也会看下 code diff。

QA 自己写的后端服务是 java + springboot 这一套,以前是走 python + flask 这一套的。不过 QA 写的平台都没啥太难的业务逻辑,接口增删改查比较多,数据库交互 mysql、redis 到头了。

vue 这块,用组件比较多,包括数据监听、数据计算、路由跳转,promise 的一些使用。毕竟不是专业的前端,写页面够用就行。

5.管理能力

分三个子方向,交给合适的同学,关键节点结果。

明确考核指标,过程指标: bug 规范、项目状态流转,结果指标: 线上事故、漏侧率。

6.leader 能力

Z 厂的文化,是喜欢从业务团队内部孵化一套流程和工具,内部先落地并能扩大影响力到其他团队。

这里就是涉及和其他团队的共建或者协作,如果想主 owner 这个项目,必须要体现 leadership。在这个项目中,你来定方案和计划,让其他参与人向你回报进度,并且最后能拿到结果。

7.文档能力

• 业务文档: 对业务上的逻辑理解,梳理出来落到 wiki 上.工具的使用教程,写到公共目录,会极大提高自己包括组员的工作效率和认知

• 技术文档: 数据分析、解决背景、方案调研、方案设计、落地预期

• 阶段总结: 项目总结、项目复盘、OKR 总结

8.沟通能力

• 业务沟通: 日常和产品、研发的沟通,拉会必须有参会背景和会议结论

• 团队内沟通: 日常 ONE ONE,基于某个问题沟通.沟通是否有 feedback,对方是否明确了指令

• 跨团队沟通: 简单阐述问题背景,对方需要怎么配合、业务边界划分

9.复盘总结能力

复盘不是一种形式,而是更好的避免问题再次发生

• 问题阶段: 注入时间、发生时间、止损时间

• 改进措施: 明确到人和 DDL 时间

很多复盘都是催生出 QA 的后续保障措施,比如服务端接口返回某个字段为空,导致客户端崩溃。

QA 可以进行线上监控巡检、客户端可以做接口健壮性测试。

另外就是项目异常复盘,比如项目 delay、需要变更多、提测质量差,可能不会影响结果,但是需要得出改进措施,才能让项目有更好的质量保障。

▌小结

从 S 厂的全职测开到 Z 厂的业务测开的变化,无论从岗位、方向、能力都有很多变化和提升,越发认为测试人员往后发展,综合能力必须要强,才能有更好的发展。

---

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….

1024 谈来蚂蚁集团这几个月来的一些感受

一、背景

1024 程序员节到了，作为程序猿总应该在这个日子写点啥。

转眼已经来蚂蚁集团四个月了，借着这个机会谈谈这几个月的感受。

二、时间线

曾经在本科学计算机的时候，阿里有一个活动，写给十年后的自己，当时写的其中一项就是，十年后最高理想就是能够在阿里巴巴工作。

研究生毕业之后，校招进入网易，和阿里巴巴滨江园区一街之隔。

后来从网易进入了有赞，在有赞工作的这段时间感觉自己成长了很多，在有赞能够了解电商的典型场景，能够使用常用的中间件等。在有赞也接触到一些比较不错的靠谱的领导和同事，如 HUB、余晖、李浩然、毛积峰等。在有赞也有幸成为了一名面试官，面试别人同时也提升自己。

2021 年 6月 18 日 正式离开了工作了两年多的有赞。

2021 年6月 21 日正式入职蚂蚁集团，在某种程度上蚂蚁还属于阿里，也算是一种圆梦。

经过三个月的试用期，顺利转正，试用期中的一些技术分享和业务开发得到了认可。

在工作之余，也尝试参加一些公司的比赛，也得到了一些正向的反馈。

最近公司也举办了 1024 程序员节盲盒抽奖活动，抽得一份游戏机。

三、感受

3.1 更多的人愿意去做"正确的事"

虽然网上会有一些人对蚂蚁，甚至阿里的人产生一些质疑，有些可能是个别现象，很多是言过其实，以偏概全。

虽然也会有些同学代码的风格不是特别好，代码的质量也不是特别高，甚至对代码似乎也没有太高的追求，但这部分同学的比例相对较少。

就我亲身体会来说，相对而言，在蚂蚁相对来说有想法的人，对代码有追求的人更多一些。

这和招聘的机制也有很大关系，校招大多数都是国内外名校的学生，社招对背景和能力也有较高的要求。

周围的同学，更愿意“做正确的事”，通常不会因为嫌麻烦而去为未来埋坑。

在方案评审时，高 P 同学通常能够给出相对专业的指导意见。
在代码审查时，高 P 的同学通常能够在代码的风格、可拓展性和可维护性、安全性等方面给出比较专业的指导。

更多的同事愿意，对问题追本溯源。很多同事在使用二方接口之前都会尝试找到对方的源码，去了解其底层实现；在遇到问题时，都愿意去深入到源码中或者采用其他手段，研究其根本原因。

由于之前在团队中做过代码审查的分享，有幸被安排在团队中多承担一些代码审查的工作。发现大多数代码审查意见基本都能够得到认可和修改，对我来说也算是一种激励；通过代码审查我也能够更多地了解其他同学的业务，学习其他同学的评审意见，也是一个非常不错的学习交流的途径。

3.2 师兄制对快速融入帮助很大

网易、有赞和阿里都有类似导师或者师兄的制度。

虽然也听说过有些同学的导师不太靠谱，对带的同学过问不多，但大多数师兄都比较靠谱，起码我在这三家公司的师兄都非常有想法，有能力而且非常靠谱。

不清楚一些业务，不清楚一些平台等，他们有时间都比较乐意解答。

此外，即使是普通同事，咨询其熟悉的业务时，也都比较乐于讲解。

我自己也会尝试在代码审查或者周围校招同学遇到困难时给予一些帮助。

3.3 工具健全

公司内部提供很多工具，可以快速找到自己想要的文档或者源码( 和 https://www.tabnine.com/ 有些类似，但是更强大)，能够极大提高研发效率。

内网也有很多高质量的学习资源，很多文章质量非常高（文章质量可以和一些高质量的公众号，甚至极客时间媲美），看完收获满满。

各种平台和工具非常多，大多数场景都能找到可以使用的工具，甚至一种需求可以找到多个工具供你选择。

3.4 需要不断了解新的平台

最近有一个感受，很多程序员第一次接触新的技术时，都会有一些恐惧心理，会把它想的比实际更难。

在一个新的公司，尤其是各种技术比较完善的公司，选择比较多的公司里工作，需要不断学习和接入各种平台，就需要不断了解新的平台。

现在基本已经能够适应这种状态，多看看官方文档、多搜搜语雀、多看看内网其他同学相关的学习文档，多看看源码（如果有），多请教接入过的同学，基本都能够相对快速搞定。

3.5 方案设计需要考虑的问题更多一些

由于支付宝的用户基数相对较大，而且是 to C ，很多功能的访问量相对较大，如果出现问题被投诉的概率也会很大，影响相对也会更大一些。

在设计方案时，需要考虑的问题就会多一些，比如存储容量问题、出错处理策略等；对系统的安全性、稳定性、拓展性和维护性都有相对较高的要求。

3.6 需要更多地主动性

以前做项目，通常都是产品设计好具体的方案，给出相对明确的需求，而且公司可选择的中间件和平台也比较明确。

现在有些需求需要自己有更多地思考和主动性，有些设计需要自己去发挥一些创意，提出一些想法。可以选择的平台较多，需要自己去调研和决策。

3.7 工作节奏相对宽松

工作节奏和团队有很大关系，在同一家公司，有些团队可能加班较多，有些团队相对会轻松一些。

我们团队通常周三和周五大多数同事都会较早回家。

如果大家对蚂蚁或者阿里的岗位感兴趣，欢迎联系我找我内推。

四、总结

本文借着 1024 这个机会，简单谈谈自己来蚂蚁这几个月的一些感受。

以后希望自己能够坚持初心，多向身边优秀的同事学习，再进一步提升自己。

---

如果你对本文感兴趣，欢迎点赞、收藏加关注，你的支持和鼓励是我创作的最大动力。

如果你有其他想了解和交流的内容，也欢迎在评论区留言。