《Google软件测试之道》目录—导读

内容提要
Google软件测试之道
每天，Google都要测试和发布数百万个源文件、亿万行的代码。数以亿计的构建动作会触发几百万次的自动化测试，并在好几十万个浏览器实例上执行。面对这些看似不可能完成的任务，谷歌是如何测试的呢？

本书从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的。本书抓住了Google做测试的本质，抓住了Google测试这个时代最复杂软件的精华。本书描述了测试解决方案，揭示了测试架构是如何设计、实现和运行的，介绍了软件测试工程师的角色；讲解了技术测试人员应该具有的技术技能；阐述了测试工程师在产品生命周期中的职责；讲述了测试管理及在Google的测试历史或在主要产品上发挥了重要作用的工程师的访谈，这对那些试图建立类似Google的测试流程或团队的人受益很大。最后，本书还介绍了作者对于Google测试如何继续演进的见解、Google乃至整个业界的测试方向的一些预言，相信很多读者都会感受到其中的洞察力，甚至感到震惊。本书可以作为任何从事软件测试人员到达目标的指南。

本书适合开发人员、测试人员、测试管理人员使用，也适合大中专院校相关专业师生的学习用书，以及培训学校的教材。

对本书的赞誉
Google软件测试之道
“James Whittaker长期以来一直都能准确把握测试领域的发展脉搏，在这个云计算变革浪潮汹涌的时代，不论对Google员工，还是对其他任何测试人员来说，这本书都是紧跟时代、保持竞争力的必读书籍。”

—— Sam Guckenheimer，微软Visual Studio产品及战略负责人

“Google一贯是测试领域的创新者——无论是对手工测试与自动化测试的结合、本地团队与外包资源的融合，还是近来开创性地用真实场景测试补充实验室场景测试等方面。这种对创新的渴望帮助Google解决了很多新问题，更好地发布了产品应用。这本书中，James Whittaker系统地描绘了Google是如何在快速发展的软件测试领域取得成功的。”

—— Doron Reuveni，uTest CEO及联合创始人

“这本书改变了游戏规则，从版本的每日发布到平视显示器（译注：平视显示器是一种飞行辅助仪器。飞行员透过座舱正前方组合玻璃上的光电显示装置观察舱外景物时，可以同时看到叠加在外景上的字符、图像等信息，方便随时察看飞行参数。这里指软件系统参数的集中显示面板）。James Whittaker把计算机科学的方法应用到软件测试领域，这将成为未来软件企业的标准。本书以平实而饶有趣味的语言风格描述了Google在流程和技术上的创新。对每个做软件开发的人来说，这都是一本不可多得的好书。”

—— Michael Bachman，Google AdSense/Display 部门高级工程经理

“通过记录Google测试工程实践中的大量奇思妙想，作者已经把本书打造成了现代软件测试领域的圣经。”

—— Alberto Savoia，Google工程总监

“如果你要在云端发布代码并尝试建立一套保证产品质量和用户满意度的策略，你必须仔细研究和思考本书中的方法。”

—— Phil Waligora，Salesforce.com

“James Whittaker在测试领域是很多人的导师和灵感源泉。如果没有他的贡献，我们在测试领域不可能拥有今天这样的人才和技术。我一直敬畏他的魄力和激情。作为业界巨擘，他的作品绝对值得每位IT行业的人阅读。”

—— Stewart Noakes，英国TCL集团总裁

“当James Whittaker在微软工作的时候我曾与他共事。虽然我怀念与他一起在微软的日子，但我知道他在Google会从事伟大的工作。这本书包含了各种创新的测试理念、实践案例及对Google测试体系的深刻洞察。任何对Google测试和质量技术稍感好奇的人，或有意发现一些崭新测试思路的人，都能从这本书中有所收获。”

—— Alan Page，微软XBox，《微软的软件测试之道》的作者

致中国读者
Google软件测试之道
It brings me great pleasure that the demand for this book was strong enough in China to make this translation possible. China is a major player in the software industry ，and I am pleased that some of my work is available to the millions of software professionals in this country. May your code have few bugs and many adoring users!

James Whittaker

“看到这本书在中国的需求如此旺盛，以及它的中译版最终付梓，真让我喜出望外，难以言表。在整个软件产业版图中，中国占据着非常重要的位置，如果说我的一些工作能给中国的软件同仁带来些许帮助，幸甚至哉。祝愿你们的代码少一些bug，多一些挚爱的用户。”

James Whittaker

译者序
Google软件测试之道
毫无疑问，在当前这个时代，处于浪潮之巅的伟大公司非Google莫属。很长一段时间以来，Google的技术一直被外界所觊觎，其所宣扬的工程师文化氛围也成为了许多工程师梦寐以求的技术殿堂，其内部的工程实践更是技术分享大会中最热门的话题之一。但迄今为止，没有一本书系统地介绍Google内部产品的研发流程与模式，包括开发、测试、发布、团队成员如何分工协作等细节，直到《How Google Tests Software》的出现，才使得我们有机会管中窥豹，了解Google技术神秘之处。这也是我们翻译这本书的第一个原因。

正如本书中所提及的那样，互联网的出现改变了许多软件研发的模式。许多曾经红极一时的传统测试书籍里提及的最佳测试实践，在当前的环境下，效率会大大下降，在一些极端的情况下甚至会适得其反。我自己就是一名测试工程师，从事互联网方面的测试工作，对此深有体会，也经常焦虑如何在制约质量和快速发布之间寻找平衡，所以，也特别想从一些主流互联网公司的测试模式中得到启发和借鉴，特别是想看一下这个世界上最成功、增长速度最快的互联网公司——Google，是如何应对互联网测试挑战的。通过翻译这本书，自己学到了更多感兴趣的知识。这也是我们翻译这本书的第二个原因。

James Whittaker在正式撰写本书英文版之前，于2011年1月在Google Testing Blog上尝试发表了“How Google Test Software”系列文章。当看到第一篇时我就被深深地吸引住了，第一感觉就是，太棒了！Google测试团队居然是这样组织的！之后，随着这个系列文章的逐一公开，Google也逐渐揭开了其神秘面纱，让我对其测试实践也有了越来越多的了解，但了解的越多，疑惑也就越多。不得不承认，这几篇文章就像正餐前的开胃小菜，它完全勾起了大家的食欲，仅仅依赖这几篇文章完全不能满足窥探Google测试体系的需求。在2011年11月的GTAC（Google Test Automation Conference）大会上，我见到了James本人，便聊起了《How Google Test Software》这本书，James一听到又有人在打探这本书的下落，乐呵得嘴都合不拢了，却卖起了关子来，只是说书快出版了。大约在2012年9月，这本书的英文版终于问世之后，突然接到李中杰（本书的合译者之一）的电话，问我为什么不去翻译一下这本书呢。之前虽然是兴趣使然，做过那几篇文章的翻译，但与翻译一本书相比，还是有些微不足道的。但几经转辗，还是机缘巧合地去做了这件事情，这也是翻译这本书的第三个原因吧。

最后要说的，也是最重要的一个原因。我原本根本没有这么大的勇气来完成这件事情。众所周知，James不仅是测试领域的泰山北斗，而且他颇具文学功底，语言诙谐幽默，妙笔生花，翻译他的书籍，让我诚惶诚恐，以至于焦虑得昼夜不安。但两位合译者，李中杰博士和薛明，他们的乐观与自信让本书的翻译得以完成。与他们两位的合作，幸福之感难以言表，所收获的也不仅仅是长知识那么简单，更有许多惊喜深藏内心。翻译别人的书，像是在反刍，再精彩也是在讲别人的故事，还是期待有朝一日，能够也有机会讲讲自己的故事。

最后祝愿国内的读者能够从这本书中有所借鉴，找到适合自己现状的开发测试模式。由于译者水平有限，错漏之处在所难免，若有欠妥之处，欢迎指正。

《Google软件测试之道》业界热评
Google软件测试之道
“Google的测试理念有什么与众不同？Google的快速开发、快速发布的秘密又是什么？《Google软件测试之道》将Google的测试、产品的发布变得没有那么神秘，本书系统地介绍了Google的测试理念、自动化测试技术、产品发布流程，以及测试团队的组成和测试工程师的招聘，是一本真心做技术分享的好书！”

—— 张南，Google中国测试经理

“读完本书，Google测试就像一副完美的测试画卷展现在我的面前。没错，我说的是‘完美’！测试领域一直倡导的诸多测试理念，如尽早测试、注重早期测试和评审、注重测试人员技能等，对于很多测试团队而言，是那么的理想化，以至于实施起来困难重重，而在Google都已化作种种测试实践，自然又现实。感谢译者的工作，让更多中国的测试人员可以从中借鉴Google测试的优秀实践。”

—— 邰晓梅，独立软件测试培训与咨询顾问、首届ChinaTest大会执行主席

“我2007年刚加入Google中国时，就被这家企业具有的测试文化深深吸引。Google内将测试推到上游的实践、内建质量的意识，以及优秀的自动化测试实践，无一不让我觉得兴奋。在担任Google中国区的测试负责人期间，我也多次向外界介绍Google的测试实践，希望Google的实践经验能够更好地帮助到更多人。James的这本书详尽地介绍了Google的测试体系与测试实践，是一本即系统又非常‘接地气’的书。很高兴看到人民邮电出版社组织将这本好书翻译成中文，相信每位读者都能从本书中受益匪浅。”

—— 段念，豆瓣工程副总裁，曾任Google中国测试经理

“这本介绍Google软件工程生产力的好书值得每一位软件测试人员和研发管理者拥有，我个人甚至认为这是软件行业十年难得一遇的好书，书中所描述的观点、测试人员的价值拓展和测试技术创新实践不仅对互联网行业的软件测试从业人员有着非常好的借鉴意义，而且也为其他行业的软件工程人员提供了‘新的翅膀’，让大家都能飞得更快、更高。正确的认知是一切成功的源头，也许你能很容易找到十个拒绝了解不同观点的理由，但你依然可以找到十个理由去接受不同的新观点，兼听则明会让你的工作更高效，自己做得更开心，过得更充实。”

—— 董杰，百度在线网络技术有限公司测试架构师

“软件测试方法会产生颠覆性的变化吗？未来还需要测试工程师吗？最近一年这样的话题被持续地讨论，我没有结论，但是我觉得与其喋喋不休地争论，不如让我们看看世界级的IT企业Google是如何做测试的。通过本书让我们理解了Google的测试理念，理解了Google的工程师文化，从中你能发现更适合你的测试方法！”

—— 贺炘，领测国际创始人

“这本书是我推荐读者了解敏捷测试思想和技术的第一读物，没有之一。这本书的内容全部来自一线实际经验，而非理论空谈。更为重要的是，它传递了一种非常重要的理性质量观，同时还对如何将这种理性质量观落地给出了非常具体的建议。”

—— 吴穹，敏捷咨询师（在敏捷测试、自动化测试方面有深入研究）

“对于互联网公司，在快速前进中保持高质量是一个永恒的难题，在去哪儿网内部，开发工程师、产品经理都需要参加测试，以此来提醒——质量是所有人的事情而不只是测试团队的事情，但是，依然有太多的质量问题和实施中的难题没办法解决。本书可以给那些关注如何在此困境中突围的人们很多启发。”

—— 吴永强，去哪儿网CTO

“感谢译者翻译了这本测试业内的经典之作，让国内的测试团队能够快速理解国际测试的发展并跟上国际节奏。我有幸先阅读了本书的部分内容，对Patrick Copeland在序中描述的测试变革的心路历程深有共鸣：招聘具备开发能力的测试人员难，找到懂测试的开发人员更难；团队的变革开发团队不接受，测试团队也不买账。同时，我们面临的挑战比Google更大，我们不仅要做好自动化，做好持续集成，做好测试工具，做好研发生产力，我们还要将测试技术与产品和业务结合，促进集团内产品和业务的发展。因此，与Google的测试人员相比，我们不仅要具备开发能力、测试思维，还要具备业务思维，能深刻理解业务所服务的客户需求及客户价值。做好工程，更要做好业务！加油！”

—— 夏林娜，阿里巴巴集团测试总监

“互联网快速响应变化的需求彻底颠覆了传统的软件开发和测试模式，敏捷、持续构建和开发自测等成为测试行业的热点话题。Google无疑走在测试变革的最前沿，并已经在互联网领域产生广泛的影响并拥有大批拥趸。Google的全新测试理念和组织形式非常值得国内的同行借鉴。”

—— 刘立川，阿里巴巴集团测试总监

“或许有人会质疑，互联网公司也可以有很好的测试吗？此书可能会改变他们的观点。第一，本书第一作者James Whittaker是一个在微软接受了最正统测试理念的人，又从互联网的视角解读测试，这让他的观点全面而具有说服力；第二，这本书的中文翻译非常出色，读起来像测试行家如数家珍。所以，我强烈推荐本书，Google的测试不一定是最出色的，但这本书是。”

—— 柴阿峰，测试圈儿里那个说相声的

“我和本书的三位作者在西雅图有很多交流，并曾经共事。James Whittaker 是软件测试界强有力的执行者、探索者和思考者。本书是他和另外两位作者在Google工作的全面、详细总结和提炼。他们从软件测试开发工程师、软件测试工程师以及测试经理三个不同角色出发，详细阐述了Google软件测试之道，给企业，特别是互联网企业在如何测试、如何保证产品质量等方面提供了很好的参考。同时开阔了我们的视野，让我们对软件测试的职责、手段和未来发展有所思考。”

—— Bill Liu，Software Design Engineer in Test, Amazon

关于这本书
Google软件测试之道
在Patrick Copeland最初建议我写这本书的时候，我有些犹豫，犹豫的理由后来也被逐一证实它们确实值得思考。人们会质疑我是否是写这本书的最佳候选Googler（他们也的确怀疑过）。有着太多的人想参与到这本书的撰写之中（后来也证实的确如此）。但更重要的是，我之前出版的一些书籍多数是给初学新手看的，像“How to Break”系列和《Exploratory Testing》，都是在从头到尾讲一个完整的故事。这本书并不是这样。读者可能坐着一口气读完，但其实它更适合作为一本参考书，一本介绍Google是如何完成大小规模不一的测试任务的参考书。我希望本书的读者是一些已经在公司从事测试工作的人，而不是一些初学者，他们会有一些基础，并会比较Google的流程与他们所使用的流程之间的区别，这样他们的收获更大。我憧憬着经验丰富的测试人员、测试经理、管理者能够随手拿起这本书，找一些感兴趣的话题，看一下在某些方面Google是如何做的。这可真不是我惯用的写作风格。

在此之前从没有写过书的两位工程师，为了这本书，加入进来共同努力。这两位都是优秀的工程师，他们在Google的工作年限都比我长。Jason Arbon的职位是TE（测试工程师），但他内心深处有着创业情怀，在本书“测试工程师”这一章中出现的许多工具和想法，都深受他的影响。我们有幸一起共事，并彼此从对方身上受益良多。Jeff Carollo也是一名测试人员，但后来转做开发了。Jeff Carollo是我见过的最优秀的那一类SET（软件测试开发工程师），也是少数几个我认识的那种可以写出“自动化之后就不用再参与”的代码的人之一，他的测试代码写得非常棒，可以独立运行不需要任何干预。我与这两位才华横溢的人共同写作，并在风格上尽可能地达成一致。

有许多Googler提供了资料。当资料中的文字和标题是同一个人的工作时，我们会在标题中把这个人标记一下。还有许多对Google测试发挥了深刻影响的人，我们针对这些人做了一些采访。这是我们能想到的最好的、让尽可能多的曾经定义了Google测试的人参与进来的方法，而不是搞一本由30个人合著而成的书。不一定所有的读者对这些访谈都感兴趣，但在书中可以很清晰地找到这些访谈的起止位置，以便选择跳过这一部分，或者专门找到这部分来阅读。我们同样感谢为数众多的贡献者，但如果有不到之处，也愿意接受任何批评。英语实在是一门贫乏的语言，无法用它描述出这些工作是多么地卓越和辉煌。

快乐阅读，快乐测试，祝愿你总能发现（并修复）bug。

James Whittaker

Jason Arbon

Jeff Carollo

献词
Google软件测试之道
献给Google、Microsoft和全世界给我启发的测试人员。

——James Whittaker

献给我的妻子Heather和我的孩子们Luca、Mateo、Dante和Odessa，他们一直认为这段时间我在星巴克工作。

——Jason Arbon

献给我的妈妈、爸爸、Lauren和Alex。

——Jeff Carollo

致谢
Google软件测试之道
我们想感谢那些不知疲倦地、致力于质量改进的Google工程师们。同样，也非常感谢Google开放的工程和管理文化，在对待测试方法与实践方面与Google打造其他产品如出一辙，允许不断创新以及天马行空般自由思维的存在。

在这里要特别向那些投入巨大精力并勇于承担风险将测试推向云端的人们致敬，他们是Alexis O. Torres, Joe Muharksy, Danielle Drew, Richard Bustamante, Po Hu, Jim Reardon, Tejas Shah, Julie Ralph, Eriel Thomas, Joe Mikhail, Ibrahim El Far。还要感谢我们的编辑，Chris Guzikowski和Chris Zahn，他们一直非常有礼貌地在容忍我们这些工程师的唠叨。感谢那些受访者在书中分享他们的观点与经验，他们是Ankit Mehta, Joel Hynoski, Lindsay Webster, Apple Chow, Mark Striebeck, Neal Norwitz, Tracy Bialik, Russ Rufer, Ted Mao, Shelton Mar, Ashish Kumar, Sujay Sahni, Brad Green, Simon Stewart, Hung Dang。特别要感谢一下Alberto Savoia，他在原型及快速迭代方面的灵感成就了今日Google快速发布的文化。感谢Google餐厅的工作人员，他们提供了美味的餐饮。感谢Phil Waligora, Alan Page, Michael Bachman，他们为本书提供了率直坦诚的反馈。最后，要特别感谢Pat Copeland，是他将来自五湖四海且充满激情的各路精英汇集于此，并投身于质量方面的不断改进工作。

序一
Google软件测试之道
Alberto Savoia

谷歌工程总监

为一本你曾经想自己去撰写的书去做序，是一种尴尬的荣誉，这种感觉有点像你被邀请去为好友做伴郎，但新娘却是你曾经心爱的姑娘。但是James Whittaker却是一个聪明的家伙，在他问我是否愿意为这本书写序之前，先请我吃了一顿我非常喜欢的墨西哥晚餐，并让我喝了几杯墨西哥Dos Equis啤酒。当我还沉浸在牛油果酱带来的愉悦时，他终于提出了这个请求，在当时那种气氛下，我只能强作欢颜并答应了他：“没有问题。”他的诡计“得逞”了，他和他的“新娘”——这本书，一起站在一边，而我却不得不在这里为他们的婚礼做致辞。

正如我说过的，他是一个聪明的家伙。

让我继续写这篇序吧，为这本我曾想自己写的书。

这个世界上真的还需要另外一本关于软件测试的书吗？特别是James Whittaker，这个高产的家伙，一个我曾经不止一次公开地称其为测试书籍出版界高产的“八胞胎妈妈”（译注：不知道“八胞胎妈妈（Octomom）”是什么意思？Google一下你就知道），还需要他的这么一本软件测试书吗？那种讲述陈旧得令人厌烦的测试方法学和宣扬一些可疑、过时的建议的书还少吗？是的，这样的书已经足够多了，但我认为这本书绝非如此。这也是我想自己去写它的原因，这个世界很需要这样一本独特的测试书。

互联网的出现急剧地改变了许多软件设计、开发和发布的方式。很多曾经红极一时的测试书籍里提及的最佳测试实践，在当前的环境下效率会大大下降，或者毫无效果，甚而在某些情况下会事与愿违地起反作用。在互联网和软件产业，一切变化都如此迅速，以至于许多最近几年才出版的软件测试方面的书籍都已陈腐过时，打个比方，它们就像讲述水蛭吸血和开颅驱赶恶鬼的外科手术书一样。对付这种书，最好的办法就是直接把它们扔掉，或者做些有益的事情，例如，循环再利用，做出纸尿裤来，以防止流落到容易上当受骗的人之手。

考虑到软件产业的发展速度如此之快，如果说十年后这本书也过气了，那一点儿也不奇怪。但在下次浪潮来临之前，这本书可以既适时又适用地从内部视角告诉你这个世界上最成功、增长速度最快的互联网公司之一，是如何应对21世纪软件测试的独特挑战的。James Whittaker和他的伙伴们，抓住了Google如何做测试的本质，抓住了Google如何测试我们这个时代最复杂和流行软件的精华。我之所以了解这些，是因为我从头到尾经历了这个伟大的转变。

我于2001年以工程总监的身份加入Google。当时，Google大概有200名开发人员，但只有区区3位测试人员！那个时候，开发人员已经开始做自己代码的测试了，但由于测试驱动开发的模式才刚刚开始，而且像JUnit这样的测试框架也没有大规模使用。当时的测试主要是在做一些随机测试（ad-hoc testing），其好坏取决于编写代码的开发者的责任心。但即使那样也是可以接受的，因为，当时正处在创业阶段，必须快速前进并勇于冒险，否则就无法和那个时代已经非常强大的对手竞争。

然而，当Google逐渐成长变大，Google的一些产品对于最终用户和客户来说开始变得至关重要（例如，竞价广告产品，我曾经负责的产品，很快变成许多网站的主要收入来源），我们清晰地认识到必须加大对测试的关注和投入。但只有3个测试工程师，别无选择，只能让开发来做更多的测试。与其他的几个Googler（译注：Google员工，本书中一般指Google工程师）一起，我们介绍、培训、推行单元测试，我们鼓励开发人员把测试作为优先级较高的事去做，并建议使用一些工具，如JUnit，把测试做成自动化的。但是进展缓慢，并非所有的人都接受、认同开发人员去做测试这件事情。为了继续保持这个势头，在每周五下午公司的啤酒狂欢时（译注：TGIF，Thank God It’s Friday，Google在每周五下午举行全员聚会），我们为一些做测试的开发人员颁发奖品来激励大家。但这种感觉不是很好，有点像杂技训兽师在小狗完成某个动作后给一些奖励一样，但这样至少还是把大家的注意力吸引到测试上了。会如此幸运吗？如此简单就可以让开发做测试了？

很不幸的是这招根本不管用。开发人员发现，为了测试充分，他们不得不针对每一行功能代码，写两到三行的单元测试代码，而且这些测试代码和功能代码一样都需要维护，且有着相同的出错概率。而且大家也意识到，仅做单元测试是不够的，仍然需要集成测试、系统测试、用户界面等方面的测试。当真正开始要去做测试的时候，会发现测试工作量变得非常大（且需要很多知识的学习），并要求在很短的时间内完成测试，要以“迅雷不及掩耳”之势完成。

我们为什么要在很短的时间内迅速地完成测试呢？ 我一直这么认为，对于一个坏点子或考虑欠周的产品，即便再多的测试，也无法把它变成一个成功的产品。但如果测试方法不当，却会扼杀一个本来有机会成功的产品或公司，至少会拖慢这个产品的速度，让竞争对手有机可乘。Google当时正处于这样的紧要关头，测试已经成为Google持续成功道路上的最大障碍。此时，我们需要正确的测试策略来满足产品、用户和员工快速增长的需要，不拖慢公司前进的步伐。这样的测试策略会涉及大量的创新性方法、非常规的解决方案和独特的工具。当然，并非所有的策略都生效了，但在这个过程中，我们得到了宝贵的经验和教训，这对于其他像Google一样快速成长的公司来说也是非常有帮助的。我们学会了如何在保持正常的开发速度的同时，让大家充分意识到质量的重要性。本书将要讲述的，正是这个过程中我们的所作所为、所思所想。如果你想要理解Google是如何面对21世纪最新的互联网、移动和客户端应用等方面的测试挑战的，读这本书就对了。我本想自己为大家讲述整个故事，但James Whittaker和他的伙伴却抢先了一步，他们已经摸索出了Google测试的精髓。

关于这本书，最后要说明一点：是James Whittaker造就了这本书。他加入Google，深入了解了Google的文化，参与了重要的项目，并发布了Chrome、Chrome OS和其他许多产品。有一段时间，他变成了Google测试的代言人。但是，这本书与他曾经出版过的其他书籍略有不同，里面的很多素材都不是来自于他个人。他本人在Google测试演化过程中的角色，更像是一个描绘记录者，而不是一个参与贡献者。在你阅读这本书时，一定要把这一点铭记于心，因为James Whittaker很有可能会把所有的功劳都归功于他自己。

在Google由200人变成2万人的过程中，有许多人在我们的测试战略的形成和实施中做出了杰出贡献。James Whittaker肯定了他们的贡献，在本书中以访谈的形式将他们引入书中。然而没有一个人，包括我、James Whittaker，或者本书中提到的其他任何人的影响力，比得上Patrick Copeland，他是我们今天组织结构的架构师和Google工程生产力部门的负责人，所有Google的测试人员最终都会汇报给Patrick。作为执行官，他以自己的想象力创造了James Whittaker在本书中描述和贡献的一切。如果非要把Google今天的测试成就归功于某人，那这个人一定是Patrick。我这么说的原因不仅在于他是我的老板，而且还在于，作为我的老板，是他命令我这么说的！

Alberto Savoia是Google的工程总监，同时也是一位创新鼓动者。Alberto于2001年加入Google，那个时候主要负责AdWords产品的发布，同时他也是Google“开发者/单元测试”这一文化的主要缔造者。他还是《The Way of Testivus》的作者，以及O’Reilly出版的《Beautiful Code》一书中“Beautiful Tests”一章的作者。

来自James Whittaker的说明：我完全同意Alberto所说的一切。作为这一过程的描绘记录者，绝大多数的材料都归功于Patrick创建的这个测试团队。还有，我这么说并不仅是因为Patrick授权我写这本书。作为我的老板，是Patrick命令我写了这本书。

序二
Google软件测试之道
Patrick Copeland

谷歌测试和部署技术的架构师

我在Google的旅程始于2005年3月。Alberto在前面的序中也介绍了一些当时Google的状况：虽然公司规模还比较小，但已开始感受到成长带来的烦恼。当时适逢快速的技术变革之际，Web世界正在迎接动态内容的到来，而云计算也正在逐渐成为一种新的选择，取代当时还占统治地位的客户机-服务器架构。

在加入Google的第一周里，我和其他Nooglers（译注：New Googler，新加入Google的员工）一起，戴着三色的螺旋桨帽，参加了称为TGIF的公司每周例会，听创始人介绍公司战略。我对彼时的工作情形还知之甚少，有些兴奋，也有些害怕。在我之前10年的研发模式经历中，一个典型的交付周期可长达5年，这种经历在Google的速度和规模面前显得毫无价值。更糟糕的是，我觉得自己是所有戴着Noogler帽子的人中唯一的测试人员。当然，其他地方一定还有更多的测试人员！

我加入Google的时候，工程团队还不足1000人。测试团队大概有50名全职人员和一些临时工，具体数量我一直没搞清楚。测试团队当时的称谓是“测试服务”，工作重点在UI的验证上，随时响应不同项目的测试需求。可以想象，这并不是Google最闪耀的团队。

但这在当时已经足够了。Google当时的主要业务是搜索和广告，规模要比今天小得多，一次彻底的探索式测试足以发现绝大多数的质量问题。然而，世界在变，Web点击量开始史无前例地爆发性增长，文档化的Web正在让位于应用化的Web。你可以感觉到势不可挡的成长和变化，在这种情况下，规模化和快速进入市场的能力变得至关重要和生死攸关。

在Google内部，规模和问题的复杂性给测试服务团队带来了巨大的压力。在之前小型的、类同的项目里的一些可行做法，现在却让优秀的测试人员感到筋疲力尽，疲于奔命在多个急需救火的项目之间。更加火上浇油的是，Google在项目快速发布方面的坚持。是时候采取措施了，我面临两个选择，要么沿用这种劳动密集型的流程增加更多的人手，要么改变整个游戏规则。为了适应业界和Google发生的巨变，测试服务团队需要根本性的变革。

我也很想说自己是借助于丰富的经验构思出了完美的测试组织模型，但实事求是地讲，我从过去的经历中，学到的只不过是一些过时的做法。我所工作或领导过的每个测试组织都有这样或那样的问题。有问题是常态，代码质量很糟糕，测试用例很差劲，团队也问题多多。我完全清楚那种被技术质量债压得喘不过气来的感受，在那种状态下，一切创新性的想法都会被遏制，以免不小心破坏了脆弱的产品。如果说我在以往的经历中有所收获的话，那就是经历了各种错误的测试实践。

那个时候，以我对Google的了解，有一件事情是确定无疑的，那就是Google对于计算机科学和编程能力非常重视。从根本上说，如果测试人员想加入这个俱乐部，就必须具备良好的计算机科学基础和编程能力。

变革Google测试的首要问题是重新定位身为测试人员的意义所在。我过去经常在头脑中想象理想团队的模型，想象这样的团队是如何肩负起质量重任的，每次我都会得到相同的结论：一个团队能编写出高质量软件的唯一途径是全体成员共同对质量负责，包括产品经理、开发人员、测试人员等所有人。我认为，达到此目标的最好方式是使测试人员有能力将测试变成代码库的一个实际功能，而测试功能的地位应该与真实客户看到的任何其他功能同等重要。我所需要的能够实现测试功能的技能，也正是开发人员需要具备的技能。

招聘具备开发能力的测试人员很难，找到懂测试的开发人员就更难，但是维持现状更要命，我只能往前走。我希望测试人员能为他们的产品做更多的事情，同时，我希望演变测试工作的性质和从属，要求开发团队更大地投入。这种组织结构在当时的业界尚未实现，但我坚信它非常适合Google，我相信在这家公司，时机到了。

不幸的是，这种如此深刻、根本性的变革在公司里极度缺乏认同，极少有人能分享我的激情。当我开始推销这种关于软件测试角色的地位平等而作用不同的愿景时，我发现竟然难以找到一个人一起共享午餐！开发工程师们好像被他们将要在测试上发挥更大的作用这个想法吓着了，他们指出“这是测试人员的职责”。而测试人员也不买账，因为很多人已经习惯了当前的角色，维持现状的惯性导致任何变革都变得非常困难。

我毫不松懈地继续努力着，主要是出于对Google的研发过程深陷技术和质量债的困境的恐惧，一旦如此，长达5年的开发周期又会成为现实，而我本来已经很高兴地把它们留在客户机-服务器的世界里了。Google是一家由天才组成的公司，以创新为灵魂，这种企业文化与冗长的开发周期是不相容的。这是一场值得打的战斗，我说服自己，一旦这些天才理解了这种旨在打造一个生产线式的、可重复的“技术工厂”的开发和测试实践 ，他们就会改变看法。他们就会理解我们不再是一个初创公司，快速成长的用户群、不断累积的bug和糟糕结构的代码形成的技术债将会导致开发过程的崩溃。

我逐个接触各产品团队，寻找优秀的案例，试图为我的立论找到比较容易的切入点。在开发人员面前，我描绘了一个持续构建、快速部署的蓝图，一个行动敏捷、省下更多时间用于创新的开发过程；在测试人员面前，我激发他们对于成为同等技能、同等贡献和同等薪酬的完全的工程合作伙伴的渴望。

开发人员的态度是，如果我们招聘到有能力做功能开发的人，那么，我们应当让他们做功能开发。其中一些人对我的想法非常反感，甚至发信给我的主管，非常直率地建议如何来处理我的疯狂之举，这些信塞满了我的主管的邮箱。幸运的是，我的主管并没有采纳那些建议。

令我吃惊的是，测试人员的反应竟然与开发人员类似。他们沉湎于老的做事方式，抱怨自己在开发面前的地位，但又不想去改变。

我的主管对这些抱怨只有一句话：“这里是Google，如果你有想法，尽管去做就是。”

于是我开始付诸行动。我召集了一批志同道合的骨干分子，组成了一个面试团队，开始招聘。事情进行得比较艰难，我们寻找的人要兼具开发人员的技能和测试人员的思维，他们必须会编程，能实现工具、平台和测试自动化。我们必须对招聘和面试的标准与流程做出一些调整，并向已经习惯了既有模式的招聘委员会做出合理解释。

最初的几个季度进行得异常艰难。好的候选人经常在面试过程中失利，也许是因为他们没能很快地解决一些奇怪的编程问题，或是在某些人认为很重要的方面表现得不够好（然而这些方面其实与测试技能毫不相干）。我预料到了招聘过程的困难，每周都要抽出大量时间写辩词。这些辩词最终会到达Google联合创始人Larry Page手里（他一直是招聘的最终批准者）。他批准了足够多的候选人，我的团队开始稳步增长。直到现在，我猜每次Larry听到我的名字时想到的一定是：“招聘测试的！”

当然，到这个时候，我已经做了大量的宣传和鼓动工作，来说服大家这是唯一的选择。整个公司都在看着我们，一旦失败，后果将是灾难性的。对于一个混合了很多不断变化的外包人员和临时人员的小测试团队而言，期望显得如此之高。然而，即使是在我们艰难的招聘进行中同时减少了临时人员的数量时，我已经注意到了变化在发生。测试资源越稀缺，给开发人员留下的测试工作就越多。很多团队都勇敢地接受了挑战。我感觉，如果技术保持不变的话，这个时候的状态已经在接近我们的目标了。

然而，技术不是静止不动的，开发和测试实践处于飞速的变化之中。静态Web应用的时代已经成为过去，浏览器还在努力追赶之中，围绕浏览器的自动化技术比已经迟缓的浏览器还要落后一年。开发人员正面临着巨大的技术变革，在这个时候，把测试交给开发人员，这看上去是徒劳的。我们甚至还不太会手工测试这些应用，更不用提自动化测试了。

开发团队身上的压力也同样巨大。当时Google 开始收购拥有富含动态Web应用的公司。YouTube、Google Docs等后继产品的融入，延展了我们内部的基础设施。开发团队在编写功能代码的过程中，要面临很多问题，与我们测试人员在测试过程中要面临的问题一样，令人生畏！测试人员面对的测试问题无法孤立地解决。把测试和开发割裂开来，看成两个单独的环节，甚至是两类截然不同的问题，这种做法是错误的，沿着这条路走下去意味着什么问题也解决不了。解决测试团队的问题，只是我们前进路上的其中一步而已。

进展在继续。雇佣优秀的人是一件很有意思的事情，他们会推动进展的发生！到了2007年，测试团队有了更好的定位。我们能够很好地处理发布周期的最后环节。开发团队已经视我们为顺利上线的可靠合作伙伴。不过我们仍然是在发布过程的后期才介入的支持团队，局限于传统QA模型。尽管有了优秀的执行能力，我们还没达到我设想的目标。我解决了招聘方面的问题，测试也向着正确的方向发展，但是我们还是在整个流程中介入太晚。

我们在一个被称作“测试认证”（本书后面的章节会详细介绍）的事情上取得了不少进展。我们向开发团队提供咨询，帮助他们改善代码质量并尽早进行单元测试。我们开发工具并指导团队进行持续集成，使产品一直保持可测试的状态。我们进行了无数的改进和调整，从而消除了之前的很多质疑，本书详细介绍了其中的很多方法。但是，在那个时候，还是感觉缺乏整体感，开发依旧是开发，测试依旧是测试。虽然很多文化变革的因素已经存在，但是，我们还需要一个催化剂把它们聚合成一体。

自从根据我的想法开始招聘担当测试角色的开发人员以来，测试组织在不断壮大。基于对这个团队的思考，我意识到测试仅仅是我们所负责的工作的一部分。我们的工具团队开发了从源代码库到编译框架，再到缺陷数据库的各种工具。我们是测试工程师、发布工程师、工具开发工程师和咨询师。触动我的是，我们所做的非测试的工作对生产力的提升产生了巨大的影响力。我们的名称是测试服务，但是我们的职责已经远大于此。

因此，我决定正式把团队名称改为工程生产力（Engineering Productivity）团队。伴随着称谓的改变，随之而来的是文化的革新。人们开始更多地谈论生产力而不是测试和质量。生产力是我们的工作，测试和质量是开发过程里每个人都要承担的工作。这意味着开发人员负责测试，开发人员负责质量。生产力团队负责帮助开发团队搞定这两项任务。

开始的时候，这个观点还只是一种梦想和志向，我们提出的“给Google加速”的口号听起来也很空洞，但是，随着时间的推移和我们的努力，我们实现了这些诺言。我们的工具让开发的动作更快，我们帮助开发人员扫清了一个又一个障碍，消除了一个又一个瓶颈。我们的工具还使开发人员能够编写测试用例，并在每次构建时看到这些测试的结果反馈。测试用例不再只是隔离地运行在某些测试人员的机器上。测试结果会在仪表盘上显示，并把成功的版本积累下来，作为应用发布健康性的公开数据。我们并不是仅仅要求开发人员对测试和质量负责，我们还提供帮助让他们可以轻松地达到这些要求。生产力和测试的区别最终变成了现实——Google的创新能够更为顺畅，技术债也不会累积了。

最终结果如何呢？我可不愿这么早就交了底，因为这本书就是要详细讲述这个问题的。作者们花费了巨大精力，根据自身和其他Googler的经历，把我们的秘诀浓缩成了一套核心实践。但其实，我们的成功有很多方面，从将构建次数以数量级式地降低，到“跑完即忘”式的测试自动化，再到开源一些非常新颖的测试工具。在我写这篇序的时候，生产力团队已经拥有1200名工程师，这个数量比我在2005年加入Google时整个工程部门的工程师的数量还要多。生产力品牌的影响力已经相当大，我们加速Google的使命已经作为工程文化的一部分，被广泛接受。从我困惑、迷茫地坐在TGIF会议上的第一天到现在，这个团队已经走过了漫长的征途。这期间唯一没变的是我那顶三色螺旋桨帽，我把它放在我的桌上，作为我们一路走来的见证。

Patrick Copeland是Google工程生产力部门的高级总监，处于Google整个测试链的最顶端。公司里所有的测试人员都最终汇报给Patrick（而他恰好跨级汇报给Larry Page，Google的联合创始人和CEO）。Patrick加入Google之前是微软的测试总监，并在那里工作了近10年。他经常公开演讲，在Google内部被公认为Google软件快速开发、测试和部署技术的架构师。

前言
Google软件测试之道
软件开发并不简单，测试也一样。谈及整个Web规模的开发和测试，一定会提到Google。如果你对这家互联网上最有名气的公司是如何进行如此大规模的测试感兴趣的话，那么这本书将非常适合你。

每天，Google测试和发布数百万个源文件、亿万行的代码。数以亿计的构建动作会触发几百万自动化测试在几十万个浏览器实例上执行。操作系统按年构建、测试和发布，浏览器的构建每天都在进行，Web应用基本达到持续发布。2011年，Google+在100天之内发布了100个功能。

这就是Google规模和Google速度——正是Web本身的规模——这就是本书描述的测试解决方案。我们会揭示这个架构是如何设计、实现和运行的，介绍在概念和实现阶段都发挥了重大作用的许多人士，解释使之成功的基础架构。

但之前也并非如此。Google走到今天的路线与我们的测试技术一样有趣。回到6年以前，Google的情况与我们之前工作的那些公司非常类似，测试是主流之外的领域，测试人员不受重视、加班加点，测试主要是一个手工的过程，那些善于自动化的人很快就被开发拉走了，因为做开发影响力会更大。在Google被称为“工程生产力”部门的奠基者们必须克服对测试的偏见，以及那种推崇个人英雄主义而轻视工程严谨性的公司文化。今天，Google的测试人员与开发人员同工同酬，奖金、晋升待遇完全一样。测试人员取得成功，以及这种文化能够经受公司巨大成长（产品、多样性和营收）和结构重组带来的实际考验，对于那些跟随Google足迹的公司来说，是非常振奋人心的。测试是在做正确的事情，是可以被产品团队和公司的管理层认可的。

随着越来越多的公司在Web领域淘金，本书介绍的测试技术和组织结构可能会变得更加普及。果真如此的话，请考虑将这本书作为到达目标的指南。

这本Google测试指南按照所涉及的角色组织。第一部分介绍了Google质量流程的所有角色、概念、流程和细节，这一部分建议必读。

本书前面几章可以按任何顺序阅读。首先介绍了SET（Software Engineer in Test，即软件测试开发工程师）这个角色，因为这是现代化的Google测试的起点。SET是技术测试人员，该章内容有适度的技术性，但抽象程度足够能让任何人理解其主要概念。之后的一章涵盖了另一个主要的测试角色——TE（Test Engineer，即测试工程师）。该章内容较多，因为TE的工作非常宽泛，Google的TE在产品生命周期中的职责很广。这个角色同样为许多传统的测试人员所熟知，我们猜测这会是读者最多的一章，因为它的受众面最大。

本书还讲述了测试管理，以及与Google的测试历史或在主要产品上发挥过重要作用的人士的访谈。那些试图建立类似Google的测试流程或团队的人，可能会对这些访谈感兴趣。

任何一位读者都千万不要错过最后一章。James Whittaker介绍了他对于Google测试如何继续演进的见解，并对Google乃至整个业界的测试方向做了一些预言。我们相信很多读者会感受到其中的洞察力，甚至感到震惊。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。

目录
前言
第1章　Google软件测试介绍
1.1节质量不等于测试
1.2节角色
1.3节组织结构
1.4节爬、走、跑
1.5节测试类型
第2章　软件测试开发工程师
2.1节SET的工作
2.2节测试认证
2.3节SET的招聘
2.4节与工具开发工程师Ted Mao的访谈
2.5节与Web Driver的创建者Simon Stewart的对话
第3章　测试工程师
第4章　测试工程经理
第5章　Google软件测试改进
附录A　Chrome OS测试计划
附录B　Chrome的漫游测试
附录C　有关工具和代码的博客文章
附录D　术语表

欢迎来到异步社区！