ITPub博客

首页 > 自动化运维 > 大规模网络运维 > 我为何从测试转测试开发,并坚持了10年?

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

原创 大规模网络运维 作者:博为峰网校 时间:2019-07-18 17:33:13 0 删除 编辑

入行测试开发,马上就要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啊这些,怎么保证它的质量,则又是另一种路子。

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

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

欢迎加入 51软件测试大家庭,在这里你将获得【最新行业资讯】,【免费测试工具安装包】,【软件测试技术干货】,【面试求职技巧】... 51与你共同学习,一起成长! QQ                     群:                    755431660


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31407649/viewspace-2651030/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2016-11-02

  • 博文量
    201
  • 访问量
    147124