赞
踩
周四周五的时候趁着最近项目刚忙完有点时间,在公司花了半天的时间把极客教程茹炳晟老师的软件测试52讲80%的内容看完了,其实一开始看到是2018年的课程会觉得这个里面讲的理念是不是已经过时了,或者是对于自己从业测试多年来讲,讲的东西会不会太基础了,一开始看的还是挺细的,后面部分内容我都跳过看了,但是还是有一点收获的,最令我深刻其实不是说的关于软件测试的理念方法工具这些,而是其中一句话:也许你觉得测试是一件入门门槛较低的工作,但是任何一件事情,如果你想把它做好,做到极致,其实并不容易。
这个观点让我还是蛮有感触的,也是对于最近的职业迷茫期些许能起到一点点小小的启示作用。为啥看这个教程,一个原因是因为在阿里也有三年多了,好像接触到的测试理念都是阿里内部的一些关于测试的理念,公司ATA 上也蛮多各种卓越工程,资损防控,全链路自动化压测,流量回放等,可能算的上是比较前沿的测试技术了,但想看下其他业内公司腾讯对测试的一些理念是不是有比较创新的地方,或者看看从一个做到了行业专家角色的测试是怎样看待测试这一个职业的,所以还是认真的看完了这个课程 。
课程从测试的基本理念到GUI 测试,微服务下接口测试,性能测试以及到如何成为一个合格的测试架构师,这个测试架构师的角色还是比较少听说, 在公司内部都是按等级划分了,P6-7-8-9 ,但是P6、P7基本更多的focus 在技术领域,8以上就是全局视野的管理了。但是这岗位级别的划分其实也会让自己些许迷茫,达到了一定的级别,就是一个好的测试工程师了吗?岗位级别真的代表能力吗?还是只是公司平台给你赋予了极大的光环?对于文章说的测试架构师的角色定位,感觉好像还get 到了一点后面工作的新思路,至少站在巨人的肩膀上,已经有人帮你去试错过了,或许你也应该多去尝试。 想从几点来说下自己对于测试的一些理解,对于第一篇关于测试的文章,我想,面向的对象还是我自己吧,谈不上分享,更多是对内剖析~
一直在我对测试的认知里面,质量和效率是相辅相成的,如何通过花费更少的时间成本人力成本去保障项目更快的测试完成并且交付上线没有严重故障,这个是基本点。所以在这个过程中,我会想要通过一些高效的手段去把一个需求测试快速测试完成,而测试工程师的核心要做的事情是运用自己掌握的开发能力去解决如何去测试每个不一样的业务项目需求,从业这么久,做过的相关业务有云计算平台相关,C 端用户量级过亿的交易链路,B 端用户量级并不多但是链路及其复杂难以理清的跨境供应链方向,还有就是接触有半年时间的金融资金链路相关的测试,可能相对于开发工程师,测试对于一块业务的熟悉会更加快一点,因为开发工程师可能需要更加聚焦他自身负责的某一个模块,但是在测开1:6 以上的团队里面,测试需要从这个团队的负责的业务视角去熟悉业务,要不自己测试的需求,上线的时候其实是完全没底的。然而根据我自己的经验,快速熟悉业务的一个重要手段看代码,去理一遍应用的代码,任何产品文档业务大图都会过期,但是代码是线上正在运行的,这个绝对最新。
但是这个观点其实在我在阿里的时候感觉有了一些不一样的认知,对于测试来讲,我们需要从全局视野来把控整体的交付质量,更前沿的方式应该是测试左移,问题越早暴露越好,但是这里面就存在了一个自上而下管控的过程,如果一个开发团队的leader比较关注团队的开发质量,左移这个事情会比较好推一点,否则就会举步维艰,意识没有贯彻,开发和测试实际上是对立的,开发同学会觉得测试只是把更多的事情推给了他们来做,就会第一时间是排斥的。所以如何让开发去提升代码提测的质量,一方面靠人的主观意识,一方面需要开发leader的配合,这里就会有个pua了,测试的角色就是去拉通各方,质量意识的贯彻也是重要一part ,但是我依然觉得,当你需要让开发同学去配合你做一些事情的时候,虽然项目工程的每一个环节的负责人员都需要为交付质量买单,但是更多的是,大家会潜意识的认为,代码上线质量的好坏,测试应该负主要的责任,这就是为什么每次线上出了问题,开发第一反应就是:测试怎么这都没有测试出来?然后就开始了测试开发的极限拉扯~
我是一个不太喜欢去push 别人做一些别人不想做的事情的人,但是工作需要,好像经常需要去推动一些事情,即使这个事情自己本身是不太愿意做的,例如推一些标准化测试的流程,名义上是为了规范各个测试开发节点,从提测冒烟,功能测试到预发布灰度验证这其中的一系列事情,而我更愿意做的事情是如何通过快速使用一些工具来为测试开发过程提效,例如自动化,造数脚本以及开发一些工具来辅助测试,但是这两者其实也是会产生冲突,是通过借助团队的力量去推动一些事情还是通过自己手把手去做一些提效的工具来解决实际问题,可能前者会带更容易带来成效,但是后者能更令自己具有成就感,也能感觉到自己在这个过程是有进步的。现在能听到的最常听的一句话就是:做工具要贴合业务,为业务质量负责,并且还要会运营,才能收到最大的效果,确实是这个道理,但是实际上就是经常业务需求时间占据了大部分,所剩的时间要投的重点往往顾此失彼,然后人会更加容易花费时间去先做自己擅长做的事情,往往最后难的事情没时间没去做了,此时来到了职业迷茫期。
发现自己很容易就会对自我进行pua ,一个很大的问题点就是我自己能够做到的事情,往往我会觉得这么简单,也没啥好说的,导致了可能不太会对自己产出进行的过多解读,觉得自己做的这个事情实际带来了怎样的改变。然后这个就很容易在年度review 的时候也不会过于强调自己做的事情带来的结果影响,每当听到同一件事情,别人可以自信满满的说出这个事情带来了怎样的产出成效时候,我当时的心理就是:还能这样说???!
其实感觉自己这个这并不是一个好的职场心态,并且这个问题也让我这一两年的工作状态不太好,有点无力感,因为我好像从内心排斥这种强行把一件事情加入过多成效收益的做法,但是这也导致了可能我自己也讲不出来,自己忙忙碌碌工作了一年带来的价值是什么,我会认为我的工作没有价值,然后就会丧失了对它的热情,变得没有那么认真积极对待自己的工作。深入分析了下产生这种心理的可能原因,灵魂自我三问:(此处想到个梗:吾日三省吾身,吾有(没)错 ~)
这个确实是需要改变一下,在做一件事情的时候,需要先花时间想清楚为什么去做这个事情,期望这个事情能够带来的收益是什么,今天看了刘润一个公众号的文章,里面提到怎样提高效率的方法,真正能提高做事情效率的,不是如何从17分钟里面省出17秒,而是如何用17分钟省出17个小时。意思就是你要在17分钟里面做一个决定,接下来17个小时做的事情,到底值不值得做?这就是选择。
人都是倾向于去做一些自己擅长容易做的事情,在忙忙碌碌中觉得自己努力了,也学习了,然后就会去有意无意忽略一些其实更应该优先要做的事情,走出这一步是比较痛苦的,因为做不容易的事情,会面临受挫,打击,无法解决问题带来的挫败感,像我自己,我就会容易在开发前端或者是后端代码的时候,写前端可能还好,百度一下好像总能解决,但是后端就涉及到要掌握更广的知识面,包括技术方案设计,怎样避免写垃圾代码,遇到一直卡在的问题,就会比较急躁,也很难静下心来想方设法去调试,一方面由于自己技术水平有限,一方面也会由于交付时间压力,所以这个时候就更容易产生对测试这一岗位的质疑,明明是测试开发,但是实际工作时间,80%以上都在测试业务需求,20%在开发,又要各种前端后端架构都要会,时间无法合理安排,就会恶性循环,觉得这一行业啥都要懂点,但是啥都不精通,就会觉得工作没啥干劲了。究其最根本的原因,其实还是归因于自己,过去的时间里,没有好好沉淀 ,种一棵树,最好的时间是十年前,其次是现在。开始自行pua了。
自我反思,其实除了工作时间,当自己能够静下心来去真正学习的,一般都是要跳槽的前几个月,那段时间会比较急于求成,也会快速去理解背一些面试需要懂的知识点,但是除此之外,好像若非工作用到,很少会去主动构建自己的知识体系,总觉得好像学了也用不上,学了也没有项目实践结合,并且经常觉得学习需要结合实际项目操作一起,若没有用到,其实学了的作用也不大,很多时候总是一边百度一边解决问题,这不是一个好的习惯,太缺乏耐心了,并且还由于自己各种生活其他的事情分心,没法能够安静下来真正去让自己对本应掌握的知识融汇贯通,学习应该是一件持续的事情,而非功利的只是面试需要。最近火热的AI 技术兴起,感觉具备持续的学习能力,不断加强自己的理解能力,才不至于过于落后,等回过神来,为时已晚。
开发工程师通常是“深度遍历”,关注的是“点”;而测试工程师通常是“广度遍历”,关注是“面” 。
回到极客教程里面老师对测试这一角色要掌握的技能的上面的解读。 这一个其实有点解答了我关于测试开发做啥都不精通的疑惑点,从小到操作系统,数据库,网络协议,大到网站架构设计,容器设计,云计算,大数据,人工智能等,其实这是一个不断在项目中,学习中累积的过程,而非我之前理解的测试开发,开发能力其实占据了这一个角色非常大的比重,当然,它确实非常重要,但是除此之外,应该站出来,从更广的视野来看待这一职业岗位必备的技能,突然之间觉得自己还有很多很多东西需要去学习,需要去总结,也许一年多以来写读书总结公众号的习惯能够帮助我去把这个总结的过程沉淀出来,想起了一句话,因为相信,所以看见,事情总是开始去做了,才会有持续的进展及拓宽的可能,也许我要做的,就是需要坚定一下决心而已~
希望自己能够成为一名合格的测试开发工程师,自己能够发自内心去喜欢自己的职业,也许半年,一年时间太短,那么两年,三年,五年呢?总能做到点什么吧?
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。