职业经验｜我在阿里做测开

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

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

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

当然知乎上有类似问题的帖子，大家也可以看看：测试开发是什么？为什么现在那么多公司都要招聘测试开发？

我在阿里做什么

1.阿里测开类型

大家可以在招聘网站看到阿里巴巴开放的质量岗位基本上都是测试开发岗，而入职后具体从事的工作内容是要视你面试的团队而定(面试过程会告诉你大概的工作内容)。据我了解，阿里的测试开发可以分为两类：

一种是纯技术型的，专注质量工具和各种“神器”的开发，他们服务于业务团队，旨在解决业务测试遇到的各种难题（比如测试有效性、流量回放等。这里分享一篇南门大佬的文章《阿里研究员：软件测试中的18个难题》）。
一种是业务测试+技术专项，基本上7/3分，偶尔业务量重的时候10/0分（当然了，团队内部的测试人员技术水平有高低，而技术相对较好的同学可能业务量稍微轻一些），因为深入一线做业务测试是发现各种测试难题的先决条件，而解决业务测试难题往往要借助于技术手段，所以技术专项由此而来，而专项课题一般来自于团队内部测试人员遇到的测试难题。

2.我在阿里的工作内容

我所在的团队是有承担业务测试工作的，研发/测试比大约在4:1。我们测试团队每个成员单独负责一块业务测试还兼做专项，例如提效工具/机器人、线上巡检工具、测试覆盖率的课题等。

业务测试就是功能测试，不外乎点点点。当然基于技术架构不同，阿里更鼓励测试左移和右移。左移如参与code review（7有硬性要求）、异常测试等；右移如关注线上监控、应急这些。（安全、性能测试这些都有专门的团队做，你只需提工单即可）
接口测试用例开发，一般是在测分后提测前开始编写，利用团队自研的接口测试框架开发接口测试用例，除了增量测试用例，还要维护存量测试用例。

写文档。入职以来文档统计数据显示我每天至少有一篇文档产出，而我竟然毫无察觉。
对外提供支持。对兄弟域联调&提供造数等工具支持

协调&沟通。不得不说在阿里做项目的沟通成本是比较高的，因为你的兄弟域可能分布在"五湖四海"，甚至是国外。如果你是主测，那么你就要负责全链路质量保障的责任，协调&沟通各域的测试同学的测试进度、项目风险；上线时候要紧盯线上监控和报警等问题。
技术专项就是我上文说到的，课题来源于测试过程遇到的难题。例如如何证明你的测试是有效的？如何尽可能快的监控到线上报出的问题？

3.重复造轮子问题

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

首先告诉你结论，确实是在重复造轮子，而且我认为是必然的。

我入职至今，已经接触（使用）多达3个接口自动化测试框架，这么多框架的由来也是有原因的，例如旧框架升级成本高，导致老业务的自动化测试用例没有完全迁移到新测试框架，进而要维护多套测试框架的用例；还有就是我们经常涉及到跨域测试(补位)，而不同域有自己的一套测试框架，所以你也要掌握。但是我对重复造轮子的态度是中立的，并不反对，我们应该从多方面看待这个事情。

从阿里自身业务架构看，阿里的产品业务复杂度高，技术实现架构是微服务，不同业务模块(也称为域，例如资金、金融、支付等)是不同的测试团队负责，各域间既是合作又是竞争的关系。

从业务全链路角度看，各域是相互合作的，协同保障产品质量，缺一不可，任何一个域出现问题最终都会影响到用户体验。
从团队角度看，各域又是相互独立&竞争的。这是因为各域的老板（一般是8）是不同的，而不同老板对团队的管理策略可能是不同的；团队间要比拼KPI，因而也有一定的“竞争”关系（哈哈，这也可能是大家常常挂在嘴边的“内卷”吧）。

各域间的质量要求可能不尽相同。例如资金域，对资损是0容忍的。因此各域间对业务质量保障采取的测试策略和方法可能略有不同。

当然从侧面说明阿里的质量基建建设已经比较完善了，在国内已经是top级别了，毕竟经过了20多年的发展。
从测试(特别是小P)自身看，我认为技术产出相对业务产出显得更重要。因为做好业务测试是基本工作，话说人无我有，技术产出对于衡量团队成员间绩效就显的非常重要了（不可否认一部分轮子确实生而为绩效）。

客观来看，正像国家提出的“大众创新，万众创新”的口号一样，提供一种竞争氛围也许是一件好事，黑猫白猫捉到老鼠就是好猫。也正是众多轮子的存在，才衬托出最终“赢家”的可贵。

当然了，重复造轮子的缺点就是人力资源的浪费，对于公司来说是一种用人成本损失，我相信国内的大厂或多或少都会有类似的问题吧。

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 二分查找算法

5 BFPRT（线性查找算法）

6 DFS（深度优先搜索）

7 BFS（广度优先搜索）

8 Dijkstra算法

9 动态规划算法

10 朴素贝叶斯分类算法

3.有所专长(亮点)

前文说到过的一个道理，人无我有。在大家都掌握相同“技能”的前提下，你能做的更深入或者有别具一格的idea，则这就是你的亮点。例如擅长性能测试、擅长效率工具开发、擅长平台搭建等。当然这个因人而异，视各人兴趣点而定。

4.多利用技术手段解决业务问题

我认为这个是最重要的。纵然你掌握上述能力后，但是缺乏运用技术解决实际问题的能力，仍然是纸上谈兵。正如第2节所说的，测试开发岗位职责都要求解决复杂问题的能力。而我在面试中问到的最多的问题就是为什么做这个东西？你这做的东西解决了什么问题？后面我会附上面试经验分享，里面包含所有面试题目。而如何提升解决问题的能力，第一步就是要善于发现问题，这就要求工作中大家保持怀疑心态。

3.3“创新”意识

不可否认创新是属于少数人的专利。但是并非大多人不能创新，作为普通大众的我们可以二次“创新”，将前人作出的成果二次创新运用到我们的业务中并解决一定的问题，我觉得对于普通人来说这就足够了。

如何保持开放心态？建议大家多参加测试沙龙和论坛，业界比较专业的测试论坛如：每年两场的MTSC大会，议题质量是相当高的，基本都是BAT议题占了半壁江山，可以说BAT的议题成果就是国内测试界的发展标杆和方向（虽然BAT的议题可能是别人玩剩下的）。此外，关注各大厂的技术公众号，多看看他们发的文章提升眼界。