搜狗质量部 [年终总结] 2016,写在农历鸡年之前

airfer · 2017年01月24日 · 最后由 airfer 回复于 2017年06月08日 · 136 次阅读
本帖已被设为精华帖!

前言:

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 15 条回复
seveniruby 将本帖设为了精华贴 02月02日 20:15

加精理由:总结清晰 工作内容和技术具备行业参考意义

好棒!要向楼主多多学习!!

#4楼 @thanksdanny 大家相互学习😀

哇塞

小目标很好👍

一次性交付向测试服务provider转变,这个厉害

026 2016年 总结帖集合 中提及了此贴 02月08日 14:10

不明觉厉!测试界的大牛真是多如牛毛啊!😀

我来支持一个

#11楼 @simple 你们组的兄弟?

#13楼 @xiaoyaoke 我们qtest部门的

加油!

能否分享一下 kafka消息队列的测试知识 ? 谢谢啦

airfer #17 · 2017年06月08日 作者
askaneverend 回复

当时主要还是功能测试,部门开发了一些辅助工具,来完成数据写入和读取,主要来验证数据流程的正确性,没有涉及到性能方面。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册