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