在当今高速发展的移动互联网 + 云优先的时代，到处充斥着不可预知的变化，有的来自于客户需求的变化，有的来自于市场环境的变化，面对着这些变化，给企业在市场、渠道、产品、服务各方面都带来了一系列新的挑战，每个成功的企业都在培养打造快速适应这种变化的能力。对于企业的产品研发部门来说，面对着愈发不确定的客户需求，快速并高质量地完成开发工作，使需求早日上线，尽早收集市场反馈，优化产品和服务，是研发响应市场变化的基本原则。但在追求产品快速交付上线的同时，质量底线是每一个成功的产品必须要坚守的红线，这也意味着研发团队在提升产品交付速度的基础下也要同时保证产品质量，而要求保证产品交付效率的同时又要持续保证产品质量，自动化测试引入是一种行之有效的保障实现手段。

在三月中旬，笔者的新书上市了，关于新书的介绍，可查阅：重磅消息 |《自动化测试实战宝典：从小工到专家》隆重上市！ 本书主要以自动化测试技术为主线，基于 Robot Framework 框架来展开介绍如何在实际工作中开展自动化测试工作。当前移动互联网行业的测试工程师有非常多的测试工具、框架和技术可以选择，但不得不说即便是在这工具泛滥的环境下，Robot Framework 框架仍然是其中的佼佼者，它是一个值得推荐给大家深入使用的优秀开源测试框架，既保证了在初级入门时，快速帮助团队完成自动化测试任务，又能在深入研究时，学习到优秀开源框架的设计理念，提升自身技术能力。

准备写这本书之前，其实内心还是挺纠结矛盾的，毕竟最近两三年一直都是从事研发管理的工作，对技术的钻究上已经无法全身心投入了。如果是已购书的读者，从作者介绍中，读者能获取到一些我的个人从业经历。回顾过往的几家工作经历：刚毕业的第一份工作在一家台资企业，呆了不到一年左右，这份工作给我最大的收获是：认识到职场和学校的环境差异，职场更讲究自己要对自己负责，自己不努力谁都帮不了你，以结果为导向。(这句话也送给那些即将毕业或刚毕业不久的读者，也适用那些在职场工作几年但仍在迷茫的人)

第二家公司，由于工作本身比较积极主动、肯担当，加上自己平时喜欢捣鼓一些新技术，在入职不到半年就晋升为部门主管（划重点：笔者毕业不到一年半，就已经晋升为测试经理）。这份工作开始阶段，移动互联网的浪潮还未真正开始，至少这个期间还没有明显感知到行业变化的冲击，当时市面上比较主流的测试工具还是以 QTP、LoadRunner 这些为主，当时如果能很好的结合 QTP 完成产品的自动化测试，就已经相当厉害了（从现在的技术视角来看，之前的那些工具还是弱爆了）。由于第二家公司做的是偏传统行业的产品 (属物联网类的产品)，产品类型覆盖了 Web 端、PC 端、硬件嵌入式类的产品，在带团队之余，自己也会主动去学习接触一些新的技术，这个状态持续了三年。这份工作的末期刚好处于移动互联网快速发展的阶段、期间行业涌现出了很多优秀的后起之秀工具，比如 Selenium、Appium、Jmeter 等。但由于公司产品形态的原因，这些工具技术并不合适当前的产品，带着英雄无用武之地，要与时代接轨拥抱移动互联网时代的心态，即便在当时研发老总抛出高薪的诱惑，仍然毅然决定选择离开了这家公司。

在第三家公司（酷狗音乐），由于对技术的热衷和追求，从管理岗转型测试开发岗（纯技术岗），在这家公司工作期间，可以说是我技术成长最快、最大的，在所负责的事业部门，先后主导过后端接口自动化、App UI 自动化等项目，并参与持续集成系统、测试平台等系统的开发建设。也正是在这份工作期间，接触了 Robot Framework 框架，说来也挺有意思的，在引入接口自动化测试之前，当时事业部现状是各个产品线测试工具太过于杂乱，有 Postman、Jmeter、Unittest 等用的五花八门，为了便于整个事业部各产品线接口测试的统一管理和资源复用，研发 BOSS 下定决心要坚决把接口自动化测试做起来，在我们处于技术选型期间，还是研发 BOSS 将 Robot Framework 框架推荐给了我们。刚开始接手 Robot Framework 框架，其实我内心是抵触的，因为当时的我认为通过直接编码或采用类似 Pytest、Unittest 这类框架来组织测试用例，效率上会更快捷。但是当我真正深入使用了 Robot Framework 框架之后，它的一些优秀特性深深的吸引了我，也是得益于它在酷狗音乐工作期间落地了很多优秀的测试实践，包括后续的 App UI 自动化。通过它带来的一些成功实践，打开了我看待问题、解决问题的角度和深度，期间我也做过很多其它的一些测试技术实践，并且申请通过了 9 个国家技术专利（当时在酷狗音乐，申请通过的专利奖金还是不菲的）。

在第四家公司，做的是研发效率提升，加入这家公司其实是一个很偶然的机会，当时无意间恒捷 (TesterHome 社区管理员) 联系上了我，交谈了一两次之后，觉得大家的想法理念一拍即合，所以很快就同意加入（对于职场，能有一个志同道合，理念想法相当的人并肩作战很重要）。其实大家当时的想法很简单，就是想一起通过技术的手段，提升研发的效率和质量，起码是真心想要做成一些事情。由于某些原因，呆了一年多就离开了这个团队，对于我来说"抛弃"恒捷还是有些愧疚的，虽然进来之后，建设起来了测试平台、CI 的一些能力，但终究觉得离我们当初的雄心壮志还远远不够。

最近的一家公司，算是又一次从技术转向管理，而促使我写这本书的初衷，也是最近一两年，感受到越加明显的一个行业不良现状：“测试人员能力的两极分化太过于严重”。一类是行业小白，这里说的小白，并不一定指的就是刚毕业或刚跨入这个行业的同学，更多指的是测试思维和测试技术一直处于小白状态。即便是有些工作了很多年的同学，仍然有很多一直处于手工测试点点点的工作状态中、他们不主动或者不愿意去理解业务架构、技术架构，甚至根本没有想过通过提升来改变这种工作状态。在几家公司中，我也面试过很多人，这类不求变或者说不求突破的纯手工功能测试的群体并不在少数。说这些话，虽然可能会刺痛一些读者，但我还是希望通过把问题真正抛出来，让大家去正视直面自己的不足，只有敢于正视不足，才有可能克服解决这些不足，也只有这样才能变成更好的自己。除了一类是行业小白，另外一类则是行业大师，这类群体的占比是极为稀缺的，也是软件行业最为抢手的一类人。这类人无论从知识的广度还是深度，都可以媲美开发架构师的能力，甚至有些还会超过开发架构师的水平，因为测试作为一个 “高危职业”，它需要比产品经理（或 SA 需求分析）想得更全面，要比开发更懂需求，要能读懂甚至能修改开发的代码。这个观点和《Google 测试之道》一书中提到的一条理念很相似，在 Google 他们对测试工程师的定位是这样认为的 “如果一个测试人员业务能力不比产品强，编码开发能力没有 RD 牛，你怎么能发现他们的问题呢？这也足已说明产品的测试质量工作，绝对不是随随便便就能做好或者谁都可以胜任的。

前面介绍了作者的从业经历和工作过程的一些感悟，希望对正在读文的你，有一些启发和帮助。

本书的写作目的并不是为了简单地告诉读者如何使用一个自动化测试工具，这并非我的初衷，我希望读者在学习本书的内容后能提高综合的技术高度与宽度，从而摆脱简单的手工测试，向成为一名新时代的优秀测试工程师道路迈进。如今移动互联网的技术和知识迭代都是非常快的，技术栈也涉及比较广，建议读者在学习本书的内容同时要自己学会 Google 相关技术的官方文档，构建一个属于自己的知识体系，从而有一个系统全面的理解，千万不要指望在书中找到所有的答案，这个在移动互联网时代是不现实的。

为了尊重社区规定，新书就不在这里贴图了，感兴趣的同学可在我的测试开发学苑中自查。

正所谓：“授人以鱼，不如授人以渔”。互联网行业的工程师就好比运动员，要想在竞技场上获胜，需要在训练场里长期刻苦地练习技巧，想要成为一个不被时代抛弃的技术人，就需要不断的更新迭代自己的知识体系，加油同学们，共勉！