测试这碗饭,现在是越来越难吃了

共 2905字,需浏览 6分钟

 ·

2020-10-11 20:38

我是一名测试工程师,今年10+岁了,游走在产品研发线上,与产品小妹、开发小哥、运维大叔一起维护着研发世界的和平,我的主要技能就是究其一生使出浑身解数与bug斗智斗勇,保障产品的质量,可是这10年来我走过的路并不平坦……

测试萌芽

这是200X年到2010年之间的混沌时期,我差不多就是在这段时期出生的,刚出生的时候我还不叫测试工程师,我的主业还是研发,偶尔辅助做做测试的活,后来得益于互联网的发展,各种国外先进研发思想的流入,产品体量和复杂度也越来越大,用户的体验需求越来越强烈,我们的研发流程也规范起来了,测试思想终于从混沌中萌芽并走向正规……随着瀑布模型(如下图)开始盛行,研发线上需求、设计、开发、测试、实施/运维大家各司其职,其乐融融,我也正式有了自己的title:测试工程师。

测试初期

这段时期大概是在2010年到2013年左右,这时期我已经可以名正言顺的打着测试的旗号,拉起队伍,编入研发大队中,对外我们一般叫xx软件测试部/xx测试组,我们的工作主要是打中后期,前期需求调研和分析完后,输出需求文档,这时我们测试小队就开始介入,从测试的角度对需求文档进行评审,评审后我们就开始测试设计,针对需求文档编写详细的测试用例,等开发编码完成提测后,就依照测试用例做功能测试执行,基本上就是大家熟知的点点点操作,后来互联网的发展更快了,用户的需求也随之变化越快了,研发大队的领导说:我们现在的研发模式有点慢哇,一个需求做半年,才刚上线客户需求又变了,咱们又得需求变更……然后研发模式就开始向更快更好的方向发展,期间出现了V模式W模型(如下图):

这样测试的范围和边界就更加清晰了,但是测试的工作量也随之增加了,天天加班点点点bug还是捉不完,慢慢感觉到体力不支……

自动化为王

这时期大致可以从2012年或更早一点点开始,一直延续到现在,不过自动化为王的全民高潮期大概在2014-2016年的移动互联网高潮期,各个公司的情况可能跟自身测试技术的发展情况而有差异。经历过前期的成长和移动互联网的发酵,PC和Web端之外,还有移动端大行其道,面对这么多平台的兼容性和适配测试,这种重复点点点劳动已经让我失去了测试的乐趣,麻木的大脑只剩下手还在机械的点点点了,突然有一个声音在测试界炸响:为什么不把一部分工作交给机器来自动化测试?于是全民自动化时代开始来临,各种自动化测试框架和工具先后引入我们的测试舞台,经过实战洗礼验证,Web端留下了著名的Selenium自动化测试框架,移动端Appium、Robotium、UiAutomator、Monkey等百花齐放……各大公司开始把自动化测试作为招聘的技术指标,把自动化测试覆盖率作为测试的KPI,各大培训机构也大力跟进宣传和鼓吹,一遍热闹祥和!测试界大家都在积极学习自动化测试技术……

冷静期

学过了自动化技术,我现在走路都带风,开发路上叫我都不应,我也是会码代码的人儿!以前天天点点点,现在我天天写自动化代码,甭管什么项目,功能测试搞完就开始上自动化测试,自动化测试线性代码写的飞起,一顿操作猛如虎,发到线上二百五。各种测试指标都做的贼漂亮,为啥线上bug还那么多,甚至还没以前纯点点点时代的好,该背的锅还是得背,总结会上认真反思后,大家都冷静下来了,自动化测试的效益并没有体现,自动化的稳定性欠佳,脚本的维护占据着大家的功能测试时间,导致顾此失彼,这时候我开始分析什么功能点或者业务场景适合自动化测试,只做适合的,脱离业务的自动化测试就是废柴,业务测试为主,自动化测试为辅,慢慢的摸索出了冒烟自动化测试,回归自动化测试,稳定性自动化测试,兼容性自动化测试……

互联网需求和流量暴增之后,大数据、分布式、微服务架构等概念又开始横行,各种RPC通信、模块化测试、数据链路测试、docker容器化技术、mock技术……让人头大,测试越来越难了,让我静一静……

专项崛起

自动化测试回归了它正确的用途,又让我腾出了一只手,于是我又有时间去研究去深入学习了。突然资本寒冬来临,以前站在风口起飞的猪很多都摔得挺惨,公司面临业务收缩和人员裁减,研发线上诚惶诚恐,该来的还是得来,首当其冲的没有意外就是测试,谁让咱不是直接产出方呢!留下来的我也要尽快表现,体现测试的最大价值,所以按照金字塔理论(如下图)我要深挖测试的深度。

于是我开始研究接口层面的测试,以及各种性能、安全、兼容性、稳定性、服务器等专项测试。以前需要开发提交80%以上的功能代码后才能提测,现在通过接口测试的方式,在一个模块或功能点做完后就可以提前介入测试对应的接口了,这个我称它叫测试左移。以前的性能测试有专项性能团队来做,现在人员缩减都得自己搞了,针对某些接口做专项性能测试,一开始我选择用开源的Jmeter来做,可图形可二次开发玩的很欢快,后来深入原理后发现自己写多线程模拟也是一样……发现接口测试的简单直接后,我把自动化测试的重点放到了接口测试,针对接口开始设计自动化用例,做成稳定性和可维护更高的接口自动化测试。尝到甜头后,测试环境已经不能满足我的胃口,我开始把注意力转向线上环境,通过线上接口和服务监控,对线上服务做可用性和稳定性监测……这个我称它叫测试右移。

测试开发之道

随着时间流逝,我逐渐把测试的触角伸到了研发流程的各个方面,这时我感觉到自己的技术储备开始不够用,边学边用,小步快跑,我不再想处于等待提测的状态,想努力打通整个环节,让测试始终贯穿其中,所以我就开始将测试的各个环节集成到研发平台中:

持续集成(CI):集成代码编译打包Jenkins服务,代码提交自动触发编译打包;

持续测试(CT):集成自动化测试平台,代码提测冒烟测试不过关自动打回,发布之前跑一边自动化回归测试;

持续部署(CD):与线上环境打通,代码包部署支持一键灰度发布,A/Btest,告别通宵发布的噩梦;

持续监控(CM):集成线上测试监控服务,异常告警、智能降级与恢复一步到位。

打通了上面的全流程平台建设,感觉就像打通了人体的任督二脉,我开始走向测试开发之道:以业务测试为辅,技术测试为主,自动化测试、专项测试、测试工具开发、测试平台开发、测试/研发流程优化……都是我的工作内容,我现在不仅仅是为质量保驾护航,也是为产品负责!

下个10年

就目前普遍国内公司的测试技术发展和进度,测试开发的极限还远远不到,下个10年还有得玩~只是测试这碗饭,现在是越来越难吃了!


测试开发栈

软件测试开发合并必将是趋势,不懂开发的测试、不懂测试的开发都将可能被逐渐替代,因此前瞻的技术储备和知识积累是我们以后在职场和行业脱颖而出的法宝,期望我们的经验和技术分享能让你每天都成长和进步,早日成为测试开发栈上的技术大牛~~


长按二维码/微信扫描关注


欢迎加入QQ群交流和提问:427020613

互联网测试开发一站式全栈分享平台


浏览 24
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报