入行测试开发，马上就要10年了。创业公司待过，大公司也待过，工作这一路走来，一些心得，转变，职场体会，早就想写出来分享一下。这个历程包含了技术的提升，工程师的素养和对这个行业的点滴感悟。

自动化测试vs测试开发

记得刚入行那会，我的title是自动化测试工程师。那时对这两者的区别还没那么明显，面试时候两者的问题也都比较类似。当时招聘“会写代码的测试人员”比较偏向称之为“自动化测试工程师”；不过现在很多企业的招聘都变为“测试开发工程师”了。

究其概念，其实自动化测试工程师更偏向于业务方向的效率提升；而测试开发则更偏向于基础架构方向的效率提升。打个简单的比方，测试开发工程师产出的框架可以认为是父类，自动化测试工程师按业务线不同，可以理解是继承自父类的不同子类。

测试开发到底在做什么

测试开发，最早起源于《Google软件测试之道》这本书，里面第一次提出了SET(Software Engineer in Test)。不过不同的公司称谓也不一样，像国内很多时候还是统称为QA。

那么SET具体在做什么呢？在我看来，SET偏向于测试部门的基础架构开发和流程的设定，比如前面说到的自动化底层框架搭建，或者改写一些开源的类和方法，去提供给组内其他的测试人员使用；再比如，我们所熟知的CICD，单元测试or集成测试的覆盖率统计，以及自动化部署发布的脚本，都可以归到测开的工作范畴里；还有，我们常说测试也需要新技术的引入，现在常见的Docker跟k8s也在逐渐普及到测试团队，因为测试最大的一个障碍是“测试环境众多”，而容器化可以很好的解决这一点。

当然不同的公司情况多有差异。一般来说，越是大型的企业，它的测试流程越规范，测开的作用也就越明显，对应的产品测试效率，也就越高。

质量保障的终极任务

我相信现在很多测试工程师，其实都有足够的共鸣，就是“我们不是测bug的，我们是产品的质量保障员”。但是很多不成熟的企业和团队还是会有误区。比如，bug数目确实可以代表你工作的产出，但如果你的团队或领导把bug数目作为唯一指标，我觉得你是时候考虑跳槽了。质量保障，在我看来涵盖很多东西，是一个很庞大的概念，大概可以包括四点：

1.正确的流程

现在很多都是敏捷开发模式了。在需求评审阶段，测试同学参与并对需求or产品有一定的理解和初步的测试计划

2.基础的质量

开发代码的规范度，基础代码的走查，监督单测覆盖率的稳步提升，毕竟基础决定上层

3.业务的覆盖

确切可以拆分成服务接口的测试/前端UI测试/性能测试/稳定性测试/系统集成测试/回归测试，这一点可以说是测试同学交叉最多的地方。

4.产品终端的保证

协同制定灰度发布策略/规范线上的操作/了解用户使用过程中常见的风险点/制定止损策略

简单来说，测试保障质量，质量决定产品。测试应该是对需求，对产品逻辑最最了解的那个角色。所以，只要关于产品变更的，测试同学都应该下意识去跟进。

而以上的任何一点，都可以深究，去做的更好。

工程师文化

我相信再牛逼的测试开发，也要从业务抓起，你不了解业务，不了解一些开发代码或者的话，有些东西也是扯淡。业务测试在我看来一点都不low，反而是一个很考验人的事情。不管是测试工程师也好，测试开发也好，我们都是工程师，都服务于产品。既是工程师，就该有工程师的素养，我认为完成一个好的测试任务，大概需要同时做到以下几点：

1.对测试结果负责

我们是产品的最后一道关卡，我们对产品发布与否有绝对的话语权，同时，我们也要对自己的测试结果负责。

2.测试到最终场景

现在很多产品链路都很长，这就需要测试同学主动去塑造自己产品的大局观，而不局限在某个单元的测试，不考虑全局，有时会造成致命的线上灾难。

3.对日志敏感，能够精准定位问题

如果开发流程足够规范的话，有完整的日志系统，其实定位问题并不难；我们每发现一个bug，都可以尝试去追溯它的根源，时间久了，你会对工程代码或逻辑摸的很清楚，这对你接下来的测试工作简直如虎添翼。

4.对相似问题和漏洞的归纳

不管是前方客户的问题，PM发现的问题还是自己的bug库，经常归纳可以节省很多时间，会让你对自己的工作产生一种“直觉”，但这种直觉有时很准哦。

面对不同的产品该怎么办

开发技术或框架可能是通用的，但测试可能会随着产品形态而产生“独特”的调整，我称之为“测试形态”。比如，现在的人工智能测试，因为每次模型迭代，测试所需的数据量很大，你用传统的并发去请求可能就不行，那你可能就需要学一些分布式技术；再有就是云服务测试，这种绝大部分是纯后端服务测试，或者SDK测试，没有前端去assert你的预期，那么你就需要足够熟悉curl命令，网络命令等，甚至去生成一些shell脚本，来执行你的测试请求；还比如手机端的测试，那它的兼容和稳定性呢怎么保证，则又是一门学问；最后还有比较火的智能硬件，盒子啊TV啊这些，怎么保证它的质量，则又是另一种路子。

但，归根结底：测试思想不会变，以不变应万变。

总之，测试是一门大学问，它入门门槛并不高，但是越深入，你发现自己了解的越少。作为一个职场人员，不随业务转变而转变，有自己的沉淀和技术底子，才能更长久。而测试开发这个行业，鄙人认为未来也会愈加重要，它是衔接产品/测试/开发的一根纽带，它在背后默默支撑着整个测试体系有条不紊的进行，某种程度上说， 算是一个隐者吧。