前言:

一直想抽出时间来把这一年所做的事情总结一下,但是每次开始写的时候又不知道该从何写起,毕竟一年经历了很多的事情。为了不在记述的时候产生跳跃感,我就按照时间线的顺序写吧,如果要先有一个概述的话,那 2016 算是稳中有升的一年~

前半年:

2016 年的前半年,主要还是在老东家 360 中渡过的。那个时候我从 360 支付平台转到 360 广告平台也有一段时间了,对广告平台的理解也慢慢的变深,主要负责的是 360 广告平台的 front 端的测试。测试的内容起先负责包括广告的展现打点、计费打点、打点信息校验、广告展现兼容性测试等内容,后来也负责了一部分 eapi 的接口测试、kafka 消息队列相关测试等内容。

在测试的过程中对广告平台的理解也逐渐深入,其实这相当于是一个打基础的阶段,毕竟相关业务的测试都是在这个基础之上的。测试的主要方式还是手动人工测试,除了看日志之外,很多功能的测试都是需要去手动完成,例如点睛投放平台相关测试,基本上靠人工,由于投放平台的界面变化较大,做 UI 自动化成本太高,任务又急,这个时候也只能靠人了。

当时我的 leader 是萍姐,反正从我转入广告平台后,一直都是萍姐带着我熟悉广告平台的很多东西,萍姐是一个很称职的 leader。即使后来我要离开公司,其实对萍姐还是有很多不舍,最后走的时候萍姐对我说的话,我现在也铭记着。其实在工作中遇到对自己有帮助的人都是应该感恩的,毕竟并非每个人有义务对你好,给你指导,在工作中遇到一个好的 leader 真的是一件很幸福的事情。扯远了,其实除了 leader 的指导帮助之外,更多的是靠自己去实践和领悟,别人教你的东西始终是别人,想把这些东西转变成自己的,只能靠自己多实践、多想、多问!

我对广告平台认识加深的过程,其实是在测试凤舞项目的时候,由于这个项目牵扯到方方面面,包括广告平台的物料投放、eapi 接口、消息队列、searchfront 引擎前端、query 检索端、index 检索生成、material 物料库、广告展现、front 打点等等。所以当这个项目测试完毕,我对于广告平台的认识也变得更加的深入,所以实践出真知不是没有道理的。但是由于引擎端的代码并不对测试人员开放,所以引擎端的处理逻辑对测试人员是黑盒,这在一定程度上也阻碍了测试人员的进一步深入。

其实前半年在点睛业务团队,也做了很多自动化的东西,包括打点的网页端展示系统、基于 Nodejs 的轻量级日志监控系统等,原本打算基于 ELK 技术栈来改进现有的日志监控,由于后来离职了,只对交接的人员大致讲述了下思路。其实到新公司之后,我也了解过我做的这些工具的情况,状况很令人心碎,这些工具无人维护基本上死掉了。我觉得这个状况在各个公司都存在,很多人觉得维护旧的工具还不如直接做个新的,重复的造轮子。后来想到之前的教训,我在现在的公司才更多的强调,开发工具的稳定性以及可维护性。我的目标是即使我离职了,我开发的工具也还可以运行 N 年。。。

总之2016 前半年更多的收获是在对广告平台的认识和理解,收获的是即使是做手工测试人和人之间的差距也可以很大,收获的是测试工具的根基在于业务,对业务了解不深,为了做工具而做工具得到的只能是失败。在离开 360 的时候,我自己的目标就是做一名顶尖的功能测试工程师。收获有很多,当然也有很多遗憾,遗憾的是对某些业务的深入程度还不够,比如 ESC 统计计费,还有就是没有加强自己的开发能力,业务虽然很重要,但是开发能力也很重要,不要顾此失彼。

后半年:

从老东家 360 离开之后,便来到了现在的公司,搜狗。其实之前对搜狗并不是很了解,我影响最深的产品就是搜狗输入法,其他的真不是很清楚,后来面试之前还好好的补了下课。来搜狗也有一定的缘分吧,记得有一次,我现在的 leader ZZ,在脉脉上和我随便聊了几句,感觉这个 leader 挺好的,后来就约了个时间过来聊聊,后来就来了搜狗,哈哈。我在搜狗这边也主要负责的是广告这块,只不过负责的内容对我来说正好是我之前不太了解的,之前在 360 的时候,负责的是搜索引擎之上的测试,比如广告投放平台;在这边主要是负责搜索引擎本身,主要是广告内容的检索、加载、展现、屏蔽等内容。这恰好是对我缺失的部分进行了一个弥补,毕竟在 360,我也接触不到引擎级的代码。

刚开始接手的时候还是有难度,毕竟我之前也没接触过。刚开始最让我吃惊的是,竟然在 1 个月之后要进行代码串讲,相当于要在 1 个月的时间对引擎的代码读一遍,然后理出思路,这对刚接手的我绝对是个不小的考验。除了看之前关于引擎的笔记之外,我师傅军哥,还有佳佳,都帮了我很多,毕竟要想在较短的时间内掌握更多的东西,还是要多向前辈们请教,搜狗的同事都很 nice,你只要问,同事都会乐于告诉你。

代码串讲之后,也就开始慢慢的接各种业务提测,在测试过程中就会发现,在熟知代码后,测试的逻辑也变的异常清晰。源码面前无秘密,这次我是深刻体会到了。测试也参与开发的代码 review,确实让测试快速的成长起来。熟悉了基本的业务后,就可是熟悉各种已经存在的测试工具、系统,我接手的时候这些测试工具都维护的比较好,主要是分布式测试系统,以及压力测试系统。每次测试完功能后,将这两个功能都跑一篇,进一步查漏补缺,有好几次 bug 就是在查漏补缺的过程中找到的。

我慢慢的体会到了,分布式系统以及压测系统的重要性,后来也慢慢的接手维护的工作。到现在为止,我们每次跑的全量 case 数据大约在 540 条左右,所有的提测任务完成后,在一定的时间内就会把 case 添加到 case 集中,这形成了一个正向的循环,测试人员也慢慢的从重复的功能性回归中解放出来。现在的分布式测试系统,以及压测系统,开发也会自己去跑,我们现在所做的慢慢由之前的一次性交付向测试服务 provider 转变。这是一个很好的现象。

到了现阶段的话,除了维护测试工具的稳定性,完善 case 集之外,更多的是对现有的工具进行改进,提升测试效率,提高生产力。为了缩短分布式系统的执行时间,我们引进了 docker,使用 docker 容器来作为基础单元参与调度,所有 case 的执行时间由原先的 20 多分钟缩短到 5 分钟。与此同时,为了管理 docker 容器,我们使用了 swarm 以及 shipyard 来进行基础容器编排以及拓展,并结合 ansible 来提升管理的效率。在压力测试中,我们正在整合现有的压测工具,使之平台化、通用化。

除此之外,我们还开发了新版的广告预览平台,开发测试都在使用,其实由一次性交付向持续交付转变,最多的障碍其实是在思维上。不管怎么样,我们都是在不断的改变自己,不断的利用新的技术、方法、思维来提高测试的生产力,这个方向总归是对的。

除了技术方面,如何让别人来分享自己的研究成果也是很重要的一方面,之前都是规定每个人都要进行分享,到后来很多同学觉得这变成了一个负担,分享的质量也有所下滑。分享结束后,如果没有参加分享的人可能只能通过看 ppt 来大致了解所讲述的内容,所以单纯的讲座效果并不如想象的好。现在部门内成立了技术影响力小组,老大让我负责,其实我有些诚惶诚恐,毕竟我自己的技术也很一般,只希望自己能近最大的努力把这件事情做好。大致弄了一个大纲,后续和 leader 去对一下,然后慢慢的把这件事做起来。

结语:

时间过的真的很快,一转眼 2017 已经来了。2016 年对我来说是成长和收获的一年,希望自己和部门能够在新的一年里越来越好!2017,加油干,撸起 50 亿!!!


↙↙↙阅读原文可查看相关链接,并与作者交流