前言

这两天看到了大家对于大会的一些反馈， 大家讨论的都挺激动的。 有些同学觉得大会上的东西太高精尖了自己借鉴不了，也不适用自己的公司， 看了议题后还是没有思路怎么开始搞自己的东西。 所以我今天想分享一下我之前还是个菜鸟的时候， 是通过一些什么机遇来提升自己并开展工作的。 希望对大家能有个借鉴的作用吧。

1.0 时期

16年3月1日进入新公司，我是全公司第二个 QA，工号 28。 话说第一个 QA 姐姐现在也离职了，也就是说我现在是质量部最老的老古董了 (有人喜欢到我这来考古，打听当初的内幕 )。 其实我来的时候也是点点点。 因为那时候公司才刚成立 1 年， 就是个小作坊，产品功能都没多少，哪用的着什么高大上的测试技术。 所以有一段时间我也主要就是做点点点的，一边点点点， 一边学这个学那个的。 业余时间就在社区把学习到的和之前用过的东西整理一下开始写文章了。 那个时期写的东西就是一些小工具小框架什么的。

2.0 时期

后来产品从 1.0 升为 2.0，其实就是整个变成个新产品了， 业务流程和研发架构都是新的。 但其实也是小作坊， 我记得一共好像也只有 5 个模块组成一个产品。 那时候遇到一个问题是测试环境搭建很困难，所有人共用一个环境，是每个模块的研发上去部署自己的服务这样的形式，挺痛苦的，然后当时一共好像也就 30 几个人还包括了行政财务，根本不可能有运维和 devops 的，而我以前没接触过环境部署的东西， 所以就十分有动力的跑去搞。 我记得 15 年的时候我还在 58 到家，当时研发总监 (沈剑) 聊天的时候就说去各种大会上大家都在聊 docker， 跟我关系挺好的一个专门搞运维的同事也老在念叨 docker。 所以我也就去学 docker 了， 打算用 docker 解决环境部署的东西。 也就是说其实不是我有什么技术眼光， 选择了个什么正确的方向， 实际上我当时就是追个潮流。 我挺喜欢追研发的技术潮流的，追潮流这事吧就算是我的方法论吧 也算是当时让我蒙中了，之后 docker 和 k8s 大火，连我们公司产品在 3.0 的时候也全面迁移到 k8s 架构上了， 这让我学的东西都有了用武之地， 当然这都是后话了。 好在当时其实有个研发也是会用一点 docker 的， 所以请教请教他 + 我自己自学， 就开始给每个模块写 dockerfile 做镜像， 大概搞了 2 个礼拜？ 具体时间记不清了， 好在模块少， 没用多少时间就弄出来了。 编译->打包->部署 一套下来可以启动很多个环境了， 当时我特丧心病狂， 仗着产品小不占多少资源 + 机器多 (5 台 40C 物理机)+ 团队人少，我就至少给每个人都部署一套独立的环境，奢侈的有如暴发户一样，到 2.0 时期最后面同时抗了 60 来个环境。 那个时期我写了有关 docker 的文章。比如：

这时候我就有一部分时间搞 devops 了, 只能说我挺幸运的， 有机会能做这些东西。 然后其他时间还是做测试， 当时产品开始卖出去了， 特性开发的越来越多，大家也开始加班了。 但是全公司 QA 一共就 4 个，能干活的也就 2 个半。 为了提升效率所以开始搞 UI 自动化测试， 因为之前没做过 UI 自动化 (在 58 到家的时候就玩接口测试了)， 所以也是开始自学的路，只不过我又开始了跟潮流，在 github 上开始搜哪个 UI 自动化框架的 star 多。 最后挑了 selenied+grid+allure， 因为我有 docker 的底子，所以 grid 也是用 docker 照着 github 上的文档搭建的，之前学的东西就又用的上了。 然后这个时间其实做的事情也不高大上， 不管是产品还是测试技术都是小作坊式的。 我每天的活就是维护环境 + 测试 + 写 UI 自动化。 这时候写的文章也多是跟自动化测试相关的。 比如：

我当时对自动化测试的要求跟很多人不一样， 我不为了用自动化找出多少 bug，我就是想节省时间。 TO B 的产品发一次版就得执行好几轮全回归测试， 所以我的原则就是即便这个流程出 bug 的可能性小，那我也自动化， 为的就是我自己不用再手动执行一遍了。 当时行业里对 UI 自动化的声讨很严重， 感觉搞 UI 自动化就好像会被所有人当傻子一样。 连我领导都说要多搞搞 API，但我还挺固执的。 好在领导也不是很在意， 就随我和我同事弄了。 到现在我们一个产品线的 UI 自动化已经到了 2000+(具体多少已经不清楚了)， 手动跑的话要至少一周才能跑完一次全回归测试， 现在一天就跑完了。

阶段性总结

直到这个阶段，不管从团队也好，产品也好，还是我个人也好。都还是不成熟和小作坊的状态， 我自己会的东西无非也就是用 docker 搭个测试环境的这种初级水平， 然后就是玩玩自动化，现在回头看看那时候的自己， 也就是个小菜鸟。 而偏偏那时候写文章的时候还挺狂的，觉得自己还挺厉害的，动不动就很嚣张的感觉自己多厉害一样， 现在想想还挺好笑的。
不过看看这个时期其实也挺走运也挺重要的。 UI 自动化上的积累弥补了我以前没有的技术栈， 并且积累的大量的自动化 case 为我节省了很多时间， 我后面之所以有那么多时间研究新技术也是因为这个，并且后期好多测试类型其实依赖的基础是先有个完善的自动化测试体系才能跑起来，这个时期做的好多事都是给以后打基础了。 而接触 docker 技术这个事直到现在看我都觉得是我职业生涯中最明智的一个技术选型了， 它直接影响了我个人和我们团队之后的技术发展。 不过说明智什么的也挺那啥的，因为说那时候的选择多明智多高瞻远瞩都是扯淡的， 这都是我们回过头来从上帝视角反推得出来的结果， 实际上当时我懂个屁啊，完全就是追潮流的心态才选了 docker。 只是我很走运的 docker 不仅没死掉还带火了容器生态和 go 语言。

有很多同学说我再小团队，没人教没人带也不知道怎么发展。 那我们从上帝视角回头看的话，其实我当时也是没人教没人带，也不知道应该往哪个方向发展， 只是我当时没心没肺的也没想那么多， 就是一心解决现在碰到的问题， 属于误打误撞的在解决问题的路上锻炼出了一些技能。 所以我后来总说什么拜师傅，参加培训班，参加沙龙大会， 都不如你在自己的工作里学习锻炼来的好。 所以我建议如果你现在还是没头没脑的很迷茫的状态， 那就多在自己的工作里看看能做些什么事吧。

后 2.0 时期

为什么是后 2.0 时期呢， 也就是我们产品 2.0 的后半段 ， 后半段测试遇到了瓶颈， 因为公司对质量要求的越来越高了， 不能像以前那样只测试个表面。 而我们的产品业务是很复杂的机器学习业务， 也就是说想要更深入的测试必须要懂机器学习, 懂 AI， 这个是业务知识的不足导致的瓶颈。 所以当时就逼着自己去看吴恩达的机器学习课， 估计学了有 2，3 个月吧。很痛苦 ，因为我基础太差了，一开始就感觉跟听天书一样， 真是太特么的复杂了。 不过也亏了这么死扛了 2，3 个月， 学到的东西终于能让我理解产品的设计以及怎么能更深的测试了，也了解了产品的售卖模式， 到客户那怎么做 POC, TOC 什么的， 总之在懂了机器学习以后，感觉模糊的世界一下子就晴朗了起来。 这个时期写的多是一些机器学习的文章。 比如：

后半段遇到的第二个瓶颈是环境上的， 上面说我用 docker 搭建了非常多的测试环境， 但是团队变的越来越大， 环境越来越多， 一台机器扛不住了。 UI 自动化要用的 grid 也是一台机器扛不住了， 因为我们后来都是要几十上百的浏览器了， 跟环境混在一起部署机器就扛不住了。 我得把环境分摊到多台机器上去， 但是 docker 自己没这个调度能力，我写的工具是一个命令行工具， 安装在每台机器上， 研发和 QA 自己决定去哪个机器上部署。 这个方式的后果就是一堆研发可能集中在一台机器上部署了 (因为没人控制他们在哪台机器上部署，大家都是各自按自己的喜好或者内部自己商量好的)，然后这个机器因为环境太多就被挤爆了。。。那时候环境的问题导致我要花在运维上的时间越来越多。 所以以前埋在我心里的那个 k8s 的心又活跃了起来， 之前一直想学 k8s 但是一直没敢搞， 因为这个东西太重量级了，不敢随便就在公司里上， 当时也怕自己弄砸了，毕竟这玩意听上去就挺难的。 不过后来还是没心没肺的上了， 找了台机器就在那学了。 这玩意从头开始学到后来真的上了测试环境大概也花了我 2，3 个月吧， 跟上面学机器学习一个时间级了。 我记得光是部署一个单机的 k8s 就卡了我一个多礼拜 当时太菜了。 后来是终于在测试环境里上线了， 5 台机器的 k8s 集群，上面部署了 60 来套测试环境 + 浏览器集群。 然后我后面的工作就是一半测试一半维护测试环境。 当时写的文章也多是跟 k8s 和自动化测试有关的。比如：

阶段性总结

这段时间的成长还是本着解决工作问题而带来的成长， 当业务和团队发展到了一定的阶段， 以前的知识和技术就都不够用了， 所以我们要随着公司的成长一起成长起来。 然后这段时间也是业务能力和技术能力齐头并进的一起进步吧。 大概这从这个阶段开始， 我觉得我应该算是脱离了初学者行列了。技术上做的东西也不算是小作坊了，算是正经八本的有点规模了。 业务上也积累了一定的深度，为以后的发展打了一个好的基础。 好多同学都会有业务和技术之争的想法， 公说公有理婆说婆有理。 而我是怎么看的呢， 业务和技术都重要这种政治正确的屁话我就不说了。 我是觉得如果你呆在了一个业务很复杂的行业，并且你也不打算换行业的话， 那么业务是很重要的， 比如我再的这个行业，机器学习的业务本身就是门槛， 这个时候业务就是很重要的，重要性不比技术差。 但如果是一个 C 端的很简单的业务的产品，比如市面上常见的一些简单的 APP，或者你也没打算在一个业务上耗死，那么业务就是不太重要的，满足基本测试需要即可， 剩下的时间主攻技术。这个是我的建议, 因为你跳槽的时候，还是技术最能帮的上忙，技术也是最能带到下家公司继续复用的能力。 PS: 业务不是你能流利的使用产品就算是熟悉业务了， 还是要打通上下游包括商务，渠道，售前，售后，运营等等全链路的业务，了解全链路的玩法才算是熟悉业务的。

3.0 时期

产品升级到 3.0 后业务流程和研发架构又是翻天地府的变化， 业务上面对更大的场景和数据，涉及到机器学习的各种方向。 架构上全面拥抱 k8s， 以前是我把产品硬往 k8s 里部署，现在是 k8s 直接变成了产品架构的一部分。 微服务 +k8s 成为了架构上的主要基调， 于是我之前的每人一套环境的暴发户行为彻底破产。 因为以前才 5 个模块， 我怎么搞都行， 现在微服务了以后直接就是大几十个模块，资源一个比一个消耗的大， 产品已经经不起我这么挥霍资源了。 所以环境部署产生了新的变化， 恩~~ 拥抱变化吧。 由于产品彻底告别了小作坊式的架构，复杂度直接跳跃性的增长， 所以对所有 QA 都是有挑战的， 以前是就我一个人懂 k8s 就行了， 现在是研发 QA 产品都得懂才行。 全员大学习浪潮的赶脚。。。。由于产品用了很多 k8s 的很复杂的特性， 所以我也从 k8s 的使用者过度到了比较深入的研究的阶段， 从而扩展出了不同的测试类型。 比如高可用测试 (业内叫混沌工程或者稳定性测试)。 这个测试工具算是我从业以来写的最复杂的最难的工具了， 要比较深入的了解 k8s 和 docker 的原理， 要去研究一些 k8s 的源码，才能往 k8s 里注入故障。 所以学习的是 go 语言和 k8s 开源的 client-go， 再去了解学习一些 k8s 更深入的知识， 比如 sidecar，admission webhook，operator 等等。 这里算是也弥补了我 go 语言技术栈的空白。 所以这个时期写的文章大多是这个类型的。 比如：

当时为了更好的测试产品的高可用， 我也是跑去学 kafka，flink 这些东西， 其实就是为了研究怎么往里注入故障，毕竟我们产品还是用了这些东西的， 当时为了搞这种高可用测试，可是没少下功夫， 我觉得 18 年和 19 年这段时间我最满意的结果就是这个了吧。 业务上呢就是继续在做测试工作，写自动化测试， 这段时间除了 UI 自动化，也发展出了 SDK 的自动化和接口自动化。 底层我们也发展除了算法层的测试， 自研的各种中间件和数据库的测试。 算是在自动化测试方面也是全面发展吧。

阶段性总结

后 2.0 时期我啃下了机器学习业务和 k8s，我说自己是脱离了初学者行列，进入了正经八本的专业级水平。 那经过 3.0 时期我觉得算是勉强可以说自己是某个领域的测试专家了吧 (这么说自己总觉得有点不要脸呢 ) 。 对于能啃下高可用测试来说我还是满自豪的， 毕竟要做这个事情的前提是要把 docker， k8s， 各种中间件，还有产品的业务和技术架构都研究的比较深入才行。 不深入业务就不知道怎么评估故障影响， 不深入架构不知道往哪里注入以及注入什么故障，不深入 docker 和 k8s 不知道怎么才能把故障注入到产品里去，甚至没有完善的自动化测试体系的话， 在 TO B 业务都没办法来运行测试 (TO B 业务很多都是私有部署，没有什么线上，玩不了流量复制的套路)。这些都挺难的， 好在我有的是时间， 在公司积累了 4 年的时间足够我把这些弄清楚了， 所以我也说没事尽量别老跳槽~~ 老跳槽注定做的不深。 我记得之前我分享一个叫《十年测试开发》的议题（https://testerhome.com/articles/24971）， 单纯讲测开的职业发展的， 在那里我说过在测试领域里，基本上很少有学不会的东西， 只要你肯花时间砸进去磨，总有磨出来的一天。 有些同学问我是怎么做的，其实没什么诀窍，就是拿时间磨， 磨到火候了就行了。PS：在刚刚过去的深圳大会上， 丹丹和超哥都去分享了环境治理和混沌工程相关的内容， 对此我也是非常高兴的。 证明我们团队在这方面的测试技术上， 算是比较成功了。

4.0 时期

2020 年产品进入 4.0 时期， 我自己这边有个比较大的变化， 领导专门成立了工程效能部，让我去做 leader。 从此我基本告别了业务测试，专职做效能提升。 职能发生了非常大的变化，恩~ 拥抱变化么。 为了提升效能今年引入了很多门技术， jenkins pipeline 并与 k8s 整合， 普罗米修斯，cypress， mock server， jvm-sandbox， jacoco。 另外还拿 django 和 react 开发了一个测试平台。 不过这段时间就很少写帖子了， 主要是工作忙 + 看孩子 + 我现在真的变懒了 。 所以只写了关于 jenkins pipeline 的东西。 比如：

这段时间最痛苦的是思考， 因为效能的东西没人告诉你该怎么做， 需要自己来思考，尤其是这个效能不仅仅是为 QA 服务， 还要为研发，产品， PMO 服务。 所以我长期处于一种到处收集需求-》抓耳挠腮的想该怎么做-》尝试-》失败-》再思考尝试直到成功 的这么个状态。 不过好在这些我都习惯了， 之前也都是这么过来的。 心态上不在是以学习为重而是以解决问题为重， 要想办法优化整个产研体系。 比如设计研发的持续集成， 开发环境的治理， 出包质量， 质量可视化等等等等， 太多了。。。真的不太想写了， 就先这么地吧。 用的技术无非就是我上面提的那几个。 截一个测试平台的图吧。

上面是给研发做的 dailybuild 环境的页面， 算是又坐回老本行了吧，跑来写环境治理的工具了。 本来 3.0 时期开始研发那有 devops 团队了， 所以研发的环境我们是不管的。 但是 4.0 时期 devops 团队都走光了~~~ 我就只能又跑回来搞环境了。

最后的总结

恩， 怎么总结一下呢， 我们用上帝视角回过头来看我自己这 4 年多的成长还是有一些因素的。

• 公司业务的发展： 不可否认我吃了公司在业务上发展的红利， 业务和架构复杂到了一定的程度， 才能带来测试技术的提升。 否则没有复杂场景的支撑，测试技术是发展不起来的，学到的一些技术苦于没有应用场景也就是纸上谈兵了，就是那种深有屠龙之术但苦于根本没有龙的这种赶脚吧。 所以我觉得如果大家所在的业务都是长期发展不起来的话，还是尽快走人吧。。。。。
• 以解决工作中的问题为主要的提升路径： 虽然我当时没意识到这一点啊，我当时根本就没什么屁的高瞻远瞩的策略和眼光。 但是从上帝视角回头看， 其实我走的每一步， 学的每一个技术都是为了解决工作中的问题为目标的，然后就这么一步一步的走到今天了。 我认为这是最快的提升自己的方式了， 所以我老跟人说实在不行你换个公司吧 工作中要是没有什么问题让你解决那还搞个屁了。 这个是我认为最重要的一点， 要主动的去解决自己所在环境中还没有被人解决的问题， 什么是高手， 高手就是解决了足够多的问题的人。
• 一无所有才是机会： 接上一个点说， 需要提升自己需要有足够复杂的问题， 但如果你在的环境这些问题已经被解决了那就真的变成螺丝钉了，什么办法都没有。 我技术的一个重转折点就是 16 年的时候用 docker 搞环境部署。 但是如果当时公司有 devops 团队，或者但凡有个运维在。 那我当时很可能就接触不到 docker 了，因为当时要解决环境问题的这个动因可能就不存在了。 回顾我引入的这些技术， 那都是因为以前没有我才引入的。 所以对于我这种人来说，一无所有才是机会， 什么都有了才是噩梦。
• 磨时间： 要耐着性子花时间跟业务和技术去磨， 这中间可能会非常痛苦， 但是得扛下去，扛到后面就是柳暗花明。 尽量少用速成的心态来看学习这件事。 几天就能速成的东西不会成为你的技术壁垒。
• 追随潮流： 这个事怎么说， 我总结就是尽量不要跟大势对抗。 比如我当初跟随潮流搞 docker， 搞 k8s， 去看了一个大会的有人分享混沌工程后， 发现自己的产品也需要这种测试类型， 那就回来就自己研究。 看到普罗米修斯，jenkins pipeline 比较火，那也就自己拿回来用。 挑测试框架的时候就上 github 上搜， 哪个 star 多就用哪个。 参加了这么多大会，我向来都是听思路， 知道这个议题是做什么的， 大概做成什么样， 我自己的工作需不需要就行了， 其他的我也不听， 回来搞一套自己的就成。 怎么说呢， 我不是搞技术的， 我只是技术的搬运工， 我基本没有自己原创的技术，基本就是别人趟过坑的东西我才拿来用。 所以你看我 github 上没有任何一个开源项目， 我都是开源项目的伸手党。
• 技术情怀： 情怀还是要有的， 要有一颗用技术来解决问题的心。 要有一个追求新技术的心。比如 16 年的时候我明明可以用没有学习成本的虚拟机来搭建测试环境， 但我偏偏要用当时已经开始崭露头角的 docker 和 k8s， 比如我明明有 selenied 跑了 2000+ 的测试用例了， 但我再一个项目中就偏要用 cypress， 没别的，我就想试试 cypress 的效果到底怎么样。 比如有些工具可以用 python 或者 java 写， 但我就用 go 写，也没别的，我就想试试 go 语言的成色。 有些同学可能会说这样是不对的，这样耗费的成本太高了。 但我觉得让自己保持技术的更新换代是很重要的， 学习就是要变着法的折腾自己。
  

恩， 就说这么多吧， 写了一个流水账讲主要的东西， 其他细枝末节的实在懒得写了， 希望对大家有用。