我为何从测试转测试开发,并坚持了10年?

　　

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

　　

　　我为何从测试转测试开发,并坚持了10年?”> 　　 　　</p> 　　<p> 　　记得刚入行那会,我的标题是自动化测试工程师。那时对这两者的区别还没那么明显,面试时候两者的问题也都比较类似。当时招聘“会写代码的测试人员”比较偏向称之为“自动化测试工程师”,不过现在很多企业的招聘都变为“测试开发工程师”了。 　　</p> 　　<p> 　　究其概念,其实自动化测试工程师更偏向于业务方向的效率提升,而测试开发则更偏向于基础架构方向的效率提升。打个简单的比方,测试开发工程师产出的框架可以认为是父类,自动化测试工程师按业务线不同,可以理解是继承自父类的不同子类。 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　测试开发,最早起源于《谷歌软件测试之道》这本书,里面第一次提出了一组在测试(软件工程师)。不过不同的公司称谓也不一样,像国内很多时候还是统称为QA。 　　</p> 　　<p> 　　那么设置具体在做什么呢?在我看来,设置偏向于测试部门的基础架构开发和流程的设定,比如前面说到的自动化底层框架搭建,或者改写一些开源的类和方法,去提供给组内其他的测试人员使用,再比如,我们所熟知的蔡先生,单元测试或集成测试的覆盖率统计,以及自动化部署发布的脚本,都可以归到测开的工作范畴里;还有,我们常说测试也需要新技术的引入,现在常见的码头工人跟k8也在逐渐普及到测试团队,因为测试最大的一个障碍是“测试环境众多”,而容器化可以很好的解决这一点。 　　</p> 　　<p> 　　当然不同的公司情况多有差异。一般来说,越是大型的企业,它的测试流程越规范,测开的作用也就越明显,对应的产品测试效率,也就越高。 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　我相信现在很多测试工程师,其实都有足够的共鸣,就是“我们不是测错误的,我们是产品的质量保障员”。但是很多不成熟的企业和团队还是会有误区。比如,bug数目确实可以代表你工作的产出,但如果你的团队或领导把bug数目作为唯一指标,我觉得你是时候考虑跳槽了。质量保障,在我看来涵盖很多东西,是一个很庞大的概念,大概可以包括四点: 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　现在很多都是敏捷开发模式了。在需求评审阶段,测试同学参与并对需求或产品有一定的理解和初步的测试计划 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　开发代码的规范度,基础代码的走查,监督单测覆盖率的稳步提升,毕竟基础决定上层 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　确切可以拆分成服务接口的测试/前端UI测试/性能测试/稳定性测试/系统集成测试/回归测试,这一点可以说是测试同学交叉最多的地方。 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　协同制定灰度发布策略/规范线上的操作/了解用户使用过程中常见的风险点/制定止损策略 　　</p> 　　<p> 　　简单来说,测试保障质量、质量决定产品。测试应该是对需求,对产品逻辑最最了解的那个角色,所以,只要关于产品变更的,测试同学都应该下意识去跟进。 　　</p> 　　<p> 　　而以上的任何一点,都可以深究,去做的更好。 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　我相信再牛逼的测试开发,也要从业务抓起,你不了解业务,不了解一些开发代码或者的话,有些东西也是扯淡。业务测试在我看来一点都不低,反而是一个很考验人的事情。不管是测试工程师也好,测试开发也好,我们都是工程师,都服务于产品。既是工程师,就该有工程师的素养,我认为完成一个好的测试任务,大概需要同时做到以下几点: 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　我们是产品的最后一道关卡,我们对产品发布与否有绝对的话语权,同时,我们也要对自己的测试结果负责。 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　现在很多产品链路都很长,这就需要测试同学主动去塑造自己产品的大局观,而不局限在某个单元的测试,不考虑全局,有时会造成致命的线上灾难。 　　</p> 　　<p> 　　 　　</p> 　　<p> 　　如果开发流程足够规范的话,有完整的日志系统,其实定位问题并不难;我们每发现一个错误,都可以尝试去追溯它的根源,时间久了,你会对工程代码或逻辑摸的很清楚,这对你接下来的测试工作简直如虎添翼。 　　<h2 class=我为何从测试转测试开发,并坚持了10年?