职业经验 我在阿里做测开

知無涯 for 新潮测试技术 · 2021年09月15日 · 最后由 知無涯 回复于 2022年05月26日 · 40931 次阅读
本帖已被设为精华帖!

本文是《聊下自己转型测试开发的历程》的下篇,上篇讲述我的职业历程,这篇讲述我在阿里工作一年对测开岗位的体感以及给想转测试开发的朋友一些建议:如何转型测试开发。

1 我对阿里测试开发岗的看法

对测开岗位的理解:测试开发仍属于 “测试”,测试工程师侧重 “被动” 的质量保障,即通过常规的测试手段保障业务质量,但随着公司业务场景的复杂以及研发周期的不断缩短,这种传统的质量保障手段已不能满足新研发模式下对产品质量的要求,如何在活多人少的情况下保障高质量,这就需要测试人效的提升(同样的时间做更多的活)和化 “被动发现” 为 “主动出击” 提前发现问题的能力。如何做到这些就必须借助于技术手段了, 而这也就体现测试开发中的 “开发” 能力了。但测开最终的目标仍是质量保障,所以我认为测开仍属于测试。
当然知乎上有类似问题的帖子,大家也可以看看:测试开发是什么?为什么现在那么多公司都要招聘测试开发?

我在阿里做什么

1.1 阿里测开类型

大家可以在招聘网站看到阿里巴巴开放的质量岗位基本上都是测试开发岗,而入职后具体从事的工作内容是要视你面试的团队而定 (面试过程会告诉你大概的工作内容)。据我了解,阿里的测试开发可以分为两类:
一种是纯技术型的,专注质量工具和各种 “神器” 的开发,他们服务于业务团队,旨在解决业务测试遇到的各种难题(比如测试有效性、流量回放等。这里分享一篇南门大佬的文章《阿里研究员:软件测试中的 18 个难题》)。
一种是业务测试 + 技术专项,基本上 7/3 分,偶尔业务量重的时候 10/0 分(当然了,团队内部的测试人员技术水平有高低,而技术相对较好的同学可能业务量稍微轻一些),因为深入一线做业务测试是发现各种测试难题的先决条件,而解决业务测试难题往往要借助于技术手段,所以技术专项由此而来,而专项课题一般来自于团队内部测试人员遇到的测试难题。

1.2.我在阿里的工作内容

我所在的团队是有承担业务测试工作的,研发/测试比大约在 4:1。我们测试团队每个成员单独负责一块业务测试还兼做专项,例如提效工具/机器人、线上巡检工具、测试覆盖率的课题等。
业务测试就是功能测试,不外乎点点点。当然基于技术架构不同,阿里更鼓励测试左移和右移。左移如参与 code review(7 有硬性要求)、异常测试等;右移如关注线上监控、应急这些。(安全测试都有专门的团队做,你只需提工单即可)
接口测试用例开发,一般是在测分后提测前开始编写,利用团队自研的接口测试框架开发接口测试用例,除了增量测试用例,还要维护存量测试用例。
写文档。入职以来文档统计数据显示我每天至少有一篇文档产出,而我竟然毫无察觉。
对外提供支持。对兄弟域联调&提供造数等工具支持
协调&沟通。不得不说在阿里做项目的沟通成本是比较高的,因为你的兄弟域可能分布在"五湖四海",甚至是国外。如果你是主测,那么你就要负责全链路质量保障的责任,协调&沟通各域的测试同学的测试进度、项目风险;上线时候要紧盯线上监控和报警等问题。
技术专项就是我上文说到的,课题来源于测试过程遇到的难题。例如如何证明你的测试是有效的?如何尽可能快的监控到线上报出的问题?

1.3.重复造轮子问题

也许你会问,都在做专项、做测试平台?是不是在重复造轮子?

首先告诉你结论,确实是在重复造轮子,而且我认为是必然的。
我入职至今,已经接触(使用)多达 3 个接口自动化测试框架,这么多框架的由来也是有原因的,例如旧框架升级成本高,导致老业务的自动化测试用例没有完全迁移到新测试框架,进而要维护多套测试框架的用例;还有就是我们经常涉及到跨域测试 (补位),而不同域有自己的一套测试框架,所以你也要掌握。但是我对重复造轮子的态度是中立的,并不反对,我们应该从多方面看待这个事情。
1.3.1 从阿里自身业务架构看,阿里的产品业务复杂度高,技术实现架构是微服务,不同业务模块 (也称为域,例如资金、金融、支付等) 是不同的测试团队负责,各域间既是合作又是竞争的关系。
a.从业务全链路角度看,各域是相互合作的,协同保障产品质量,缺一不可,任何一个域出现问题最终都会影响到用户体验。
b.从团队角度看,各域又是相互独立&竞争的。这是因为各域的老板(一般是 8)是不同的,而不同老板对团队的管理策略可能是不同的;团队间要比拼 KPI,因而也有一定的 “竞争” 关系(哈哈,这也可能是大家常常挂在嘴边的 “内卷” 吧)。
c.各域间的质量要求可能不尽相同。例如资金域,对资损是 0 容忍的。因此各域间对业务质量保障采取的测试策略和方法可能略有不同。
1.3.2 当然从侧面说明阿里的质量基建建设已经比较完善了,在国内已经是 top 级别了,毕竟经过了 20 多年的发展。
1.3.3 从测试 (特别是小 P) 自身看,我认为技术产出相对业务产出显得更重要。因为做好业务测试是基本工作,话说人无我有,技术产出对于衡量团队成员间绩效就显的非常重要了(不可否认一部分轮子确实生而为绩效)。
1.3.4 客观来看,正像国家提出的 “大众创新,万众创新” 的口号一样,提供一种竞争氛围也许是一件好事,黑猫白猫捉到老鼠就是好猫。也正是众多轮子的存在,才衬托出最终 “赢家” 的可贵。
当然了,重复造轮子的缺点就是人力资源的浪费,对于公司来说是一种用人成本损失,我相信国内的大厂或多或少都会有类似的问题吧。

2 测试开发职位要求

想做测开,首先就要明确其岗位要求。不同公司对测开岗位的招聘要求是大同小异的,大家可以看下 BAT 发出来的招聘信息。
2.1BAT 测开岗位要求

BAT 对开发岗位的要求总结:

与国外测试开发(SDET)岗位职责的比较

1.自动化用例开发
精通项目语言(Java、Javascript、C# )
与开发人员协作 review 单元测试和集成结果以进行覆盖率分析
设计、开发、执行和调试自动化测试用例和脚本
2.CI/CD
为高质量的自动化可交付成果创建分支策略
持续集成,将自动化脚本集成到 CI/CD pipeline。
3.测试框架
为团队测试框架选型
使用不同的自动化工具和技术提高自动化效率和覆盖率
4.质量度量
设计实时自动化仪表板以衡量构建质量并向敏捷交付团队提供反馈

综合比较下,国外对测开要求和国内的差别不是太大,建议大家可以参心仪公司的招聘要求准备,哪里不会补哪里。当然了,一定要有项目基础哦。

2.2 测开 VS 测试薪资对比

直接看图对比已经比较直观了,测开和测试工程师薪资之间差一个测试工程师。

2.3 职业发展前景

测试开发岗位增速是测试工程师岗位的将近 4 倍,预测未来仍会保持高增速。现阶段来看,测试未来是就是测试开发!

3.测试工程师如何转型测开

3.1 摆好心态&开放眼界
我始终认为 掌握技术最重要,title 不重要。测试工程师和测开只是 title 不同,工作内容并没有明确的边际,这个完全取决你对测试的看法!有可能一些公司的测试工程师做的是某些公司测开的干的活,而一些公司的测开可能做的是某些公司测试工程师的活。就像我在字节时候,title 是测试工程师,工作内容是业务测试 + 接口测试平台开发 7/3 分。而在阿里则也是差不多(甚至阿里的业务还更重些)。对于我来说两家公司的工作内容是没什么区别的,只是 title 不一样而已。
对于想转测开的测试工程师建议:调整心态,不要以 “测开” 唯是,提升自己的技术能力才是重点,要养成持续学习的习惯,多接触一些知识,拓展自己的眼界,在业务测试过程养成 “偷懒” 的习惯,多思考自动化手段减少手工测试工作。

3.2 夯实基础&运用技术

1.编程能力要过关
至少精通一门语言。而且使用该语言开发过工具或平台最佳。一是测开面试通常要编程写代码,这个是门槛。二是有开发经验能侧面证明你对开发语言的熟练程度。
至少掌握一个开发框架。例如 spring boot、flask、Django 等。

2.基础算法要熟悉,学习的同时建议结合 LeetCode 练习。
1 快速排序算法
2 堆排序算法
3 归并排序
4 二分查找算法

3.有所专长 (亮点)
前文说到过的一个道理,人无我有。在大家都掌握相同 “技能” 的前提下,你能做的更深入或者有别具一格的 idea,则这就是你的亮点。例如擅长性能测试、擅长效率工具开发、擅长平台搭建等。当然这个因人而异,视各人兴趣点而定。
4.多利用技术手段解决业务问题
我认为这个是最重要的。纵然你掌握上述能力后,但是缺乏运用技术解决实际问题的能力,仍然是纸上谈兵。正如第 2 节所说的,测试开发岗位职责都要求解决复杂问题的能力。而我在面试中问到的最多的问题就是 为什么做这个东西?你这做的东西解决了什么问题?后面我会附上面试经验分享,里面包含所有面试题目。而如何提升解决问题的能力,第一步就是要善于发现问题,这就要求工作中大家保持怀疑心态。

3.3“创新” 意识

不可否认创新是属于少数人的专利。但是并非大多人不能创新,作为普通大众的我们可以二次 “创新”,将前人作出的成果二次创新运用到我们的业务中并解决一定的问题,我觉得对于普通人来说这就足够了。
如何保持开放心态?建议大家多参加测试沙龙和论坛,业界比较专业的测试论坛 如:每年两场的 MTSC 大会,议题质量是相当高的,基本都是 BAT 议题占了半壁江山,可以说 BAT 的议题成果就是国内测试界的发展标杆和方向(虽然 BAT 的议题可能是别人玩剩下的)。此外,关注各大厂的技术公众号,多看看他们发的文章提升眼界。

3.4 我的阿里测开面试题分享

我把三轮技术面的题目(不完全统计)分类整合到一起了,大家凑合看。
技术题
了解多线程吗?了解 Python 的 GIL 锁吗?
说一下进程和线程
进程间通信的方式有哪些?
说一下什么是乐观锁和悲观锁?
AOP
什么是 IOC?
list 和 map 相关
解释一下工厂模式?
内存泄漏
会做性能测试吗?容量测试/稳定性测试?
Python2 和 3 的区别?
DNS 解释一下?
用户名、密码、验证码哪个校验顺序?
Linux 根据进程查端口/端口查进程
常用的 Linux 指令?
排序算法
围绕工具开发
工具是如何开发的?
为什么要开发这个工具?
公司内部没有类似平台吗?
效能工具包含哪些?举几个例子?
介绍一下自研的接口自动化框架?
有哪些模块组成?
相比其他框架有哪些优势?缺点有哪些?
介绍一下框架的代码生成模块是怎样实现的?
使用你的框架测一个接口需要做哪些步骤?
接口的断言怎么做?
接口测试带来的收益?
testng 和 junit 优缺点
造数据工具,如何开发、提效多少。
大数据测试
怎么测试数据的准确性?
算法测试
项目经验
算法测试做哪些工作?
如何进行算法评测?
不同的算法类型,评测标准是不同的
介绍一个最近的算法测试案例?
如何选择测试集?测试集的特征如何选择?
说一些算法测试发现的 badcase?
如何保障算法质量?

编程题
线程交替打印奇偶数
最长回文子串

项目经历
介绍一下负责的项目?
针对老系统(有很多僵尸代码)如何保证质量?
做过的项目遇到的最大风险点?
怎么保障项目的质量?
如何处理紧急需求?
项目的迭代方式?
说一下最近项目推动成功的案例?
说一下自己人力分配?

持续集成
了解 CI 吗?解释一下 CI
如何衡量测试用例质量?
说说你对测试的理解?或者说质量的理解?

团队管理
团队管理上有没有什么难点?
你期望一个怎样的测试团队?
团队的测试开发比是怎样的?
如何衡量全职/外包比例?
外包的忠诚度如何保障?
你能为团队带来什么?

HR 问题
为什么跳槽?
为什么选择阿里?
前几家公司收获
有什么问题要问的?
工作中最大的挑战(最大挫折),如何克服的?
最大的有点和缺点?各自说一个?
未来的职业 3-5 年发展规划?

内推福利

社招需要内推的可以直接联系我 or 私信我(VX: ISTE1024)

往期文章推荐
https://testerhome.com/topics/30291

PS:文中观点仅代表个人意见,如果有说的不对的地方,各位同行大佬还望包涵和指教。

共收到 47 条回复 时间 点赞

怎么算是精通 JAVA 呢

知無涯 · #2 · 2021年09月15日 Author
仅楼主可见
Mingway_Hu 将本帖设为了精华贴 09月17日 14:16

需要掌握一门前端语言吗

豆芽 回复

肯定是多多益善呀。虽说现在确实存在很多低代码平台,但是要是写页面稍微复杂点的交互,还是需要一些 js 基础的

谢谢楼主的分享~对新人很有帮助,最近在看谷歌的测试书,在他们的质量团队里面,测开和测试工程师都是同等重要的,但也和国内一样,如果不考察代码,找到的测试工程师很难胜任职位要求。所以我觉得还是不要给自己设限,多学点技术总是好的。

4:1 的研发测试比例,如果一周一个版本,做业务测试基本上都是饱和的(包括回归测试),除非有外包

Eward 回复

确实有外包。会让外包做一些测试执行和一些杂而散的事情

beishang 回复

多多加油。很高兴能帮到你,如有问题可以找我沟通。

仅楼主可见

大厂业务测试基本都给外包了吧

知無涯 · #14 · 2021年09月23日 Author
仅楼主可见

标题哗众取宠

Ikaros灬 回复

基础原理都知道,手撕算法源代码,各类实现方式,拓展都用过且记住了并最终能归纳表达出来

4:1 这个还挺意外,我以为得 6:1 以上

测开其实就是开发,能写各种测试工具和平台的大佬开发水平不会差。大佬写好了工具,非功能测试(如稳定性和性能)就可以从业务上来测试这些指标了。

dia 点个赞

Ikaros灬 回复

https://testerhome.com/topics/30722#reply9
不看答案能全答出来,基本你就是精通了

21楼 已删除

关于侧开,还蛮全面的

现在觉得测试这个赛道是越来越不像样了,或者说,越来越觉得没必要专门的测试岗,或者更小的业务测试团队

汇荔君 回复

也是要求越来越高了

仅楼主可见
仅楼主可见

总结:测试,开发,运维技术栈我全都要😉

对头。阿里土话 既要又要还要。。。👍

知無涯 · #29 · 2021年10月23日 Author
仅楼主可见

小公司测试开发比一般开发要求高了,往往面对的问题是:

  1. Devops 各种平台集成,什么 gitlab,k8s,jenkins,jira, 需要很快的学习能力
  2. 不管工具还是平台需要走产品化路线,所以你需要自己有想法,又了解日常测试需求和潜在需求,才可能好样
  3. 基本上可能需要全栈了,前端后端,js,java,python,typescript 估计都需要,搞不好还需要点 golang 之类的
  4. 最后平台需要有数据追踪,分析的能力,所以又需要建立点指标系统,那么数据分析什么 ETL/数据可视化多少又需要了,这是需要点数仓基础支持,可能还需要点大数据周边的一些能力
  5. 推广能力/优先级设定能力, 说的直白点就是 PPT 的能力,和说服别人的能力

所以做起来很累,小公司一般基础设施不太好,大公司可能也很累,系统繁多而复杂,各个组都是小山头,沟通很费劲,另外每个组的惯性思维方式也不一样,谈需求的时候需要尽可能的适应不同的说法,抽象不同说法里面的共性。嗨,苦苦苦。。。。

simonpatrick 回复

赞同。

知無涯 [该话题已被删除] 中提及了此贴 11月13日 17:30
知無涯 接口自动化测试框架建设的经验与教训 中提及了此贴 11月13日 17:36

羡慕了有 4:1,我现在 7:1😖 😖 😖

技术进步太快了,想开发测试工具来着 没有思路

13:1 的路过

嘿Neal先森 回复

😀 公司顶梁柱

2:1 路过

大佬你好,1.2 中提到接口用例开发是在测分后提测前,测分后是什么意思呢

L 回复

测试分析评审

知無涯 回复

啥顶梁柱哦 白菜价 还不如应届

仅楼主可见

😂 batm,b 就是字节了,百度表示很尴尬

写得挺好

哎,测开的叫法就如同肉夹馍的叫法。是担心叫成开测的话变为动词么?

batm 百度 阿里 腾讯 美团???

我觉得我有了新发明 现在出现了个缩写是 bat.md

bat.md 可以表示一个文件,也可以表示 百度、阿里、腾讯、美团、抖音。

一直老感觉 batmd 那里怪怪的,直到我用中文输入法打出来之后貌似能看出来痕迹和端倪。

楼主总结的非常到位,前阿里 - 优酷小伙伴,在此自愧不如,佩服佩服~

熊逸 回复

👊

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