软件测试泰斗传道解惑，Google软件测试精髓完美呈现。
　　淘宝测试技术专家翻译，测试界知名专家鼎力推荐。

　　惠特克（JamesWhittaker），Google的工程总监，负责Google部分产品的测试，包括Chrome、地图、GoogleWebApp。在加盟Google之前，James在Microsoft工作，再之前是一名大学教授。James在全球测试领域闻名遐迩。

　　阿尔邦（JasonArbon），Google的一名测试工程师（TE），曾参与负责Google桌面、Chrome和ChromeOS的测试。同时，Jason也是一系列开源测试工具和个性化实验的开发负责人。在加入Google之前，他在Microsoft工作。

　　卡罗洛（JeffCarollo），Google的一名测试开发工程师（SET），曾参与负责GoogleVoice、工具框、Chrome、ChromeOS产品的测试。Jeff为许多Google内部的开发团队提供咨询服务，帮助提升这些团队初期的代码质量。在2010年，Jeff转岗为软件开发工程师（SE），并领导负责Google+API的开发。在加入Google之前，Jeff在Microsoft工作。

　　第1章 Google软件测试介绍
　　在许多场合下，不管是在国外访问还是出席会议期间，我总是毫无例外地被问及一个问题。甚至是刚刚加入公司的新员工也会问到同样的问题：“Google是如何测试的？”
　　虽然我已经不太确定曾经多少次回答过这个问题，以及给出了多少个不同版本的答案，但可以确定的是，随着我在Google工作的时间越来越长，发现Google的各种测试实践的不同之处也越来越多，答案也一直在变化。这些测试实践总是浮现在脑海里，并幻想着有朝一日能够将它们整理成书。直到有一天，Alberto（译注：Albert0Savoia，（~oogle的测试总监，详细介绍参见本书序言中的A1berto部分），这个一贯认为所有测试相关的书籍都要为自己的存在找一个理由，否则就应该被扔掉做成纸尿裤的人，当他建议我应该写这样一本书的时候，我觉得时机已经成熟，是时候开始考虑写这样一本书了。
　　然而，我依旧还在等待。第一，我并非是写这样一本书的最佳人选。在Google，有很多我的前辈，我想先把机会让给他们宋写；第二，我只是Chrome和ChromeOS产品的测试总监（现在这个职位被我之前的一个下属担任着），我看到的也只是Google所有测试实践中很小的一部分，我还需要去了解很多其他Google产品的测试方法。
　　在Google，软件测试团队归属于一个被称为“工程生产力”（译注：EngineeringProductivity，也译为工程效率或工程生产率）的中心组织部门，这个部门的职责横跨开发测试人员使用工具的研发、产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。Google拥有大量针对互联网产品的共享工具与测试基础框架，服务于包括搜索、广告、Apps、YouT‘ube视频和其他我们在Web上提供的产品。Google已经成功解决了许多有关速度和扩展性方面的问题，使得Google作为一个大公司，却依然能以创业公司的速度来发布产品。正如Patrick（30peland在本书的序言中所说的那样，拥有如此的魔力，Google的测试团队功不可没。
　　ChromeOS在2010年12月发布以后，我把团队顺利地交接给我的一个直接汇报者，然后开始把自己的工作重点慢慢转移到其他产品上。在这本书刚开始准备的阶段，我使用博客的方式做了一些尝试，发布了第一篇“Google是如何测试的”的系列文章（注：参见hup：／／googletesting．blogspot．com／20〕I／01／how。google—tests．soffware．html）。6个月之后，本书终于完成，希望没有拖太长的时间。在这六个月的时间里，我了解到的Google测试实践比我过去两年在。Google学到的都要多。现在有了这本书，Google的新员工们也可以通过阅读此书来熟悉Google的环境。
　　这并不是第一本介绍关于大公司是如何做测试的书籍．当我还在Microsoft的时候，AlanPage．BTRollison和Ken．Johnston合著了《微软的软件测试之道》（译注：I-lowWe．TestSoftwareatMicrosoft），我当时亲身经历了他们书中写的许多事情。Microson在测试领域独步全球，也是一个测试精英云集的圣地。Microsoft的测试工程师在各种技术大会中也是广受欢迎的演讲嘉宾。Microsoft的第…任测试总监一一RogerSherman，吸引了来自全球的测试精英加入华盛顿的雷德蒙德（译注：微软总部所在地）。那是一个软件测试的黄金时代。
　　因此，Microsoft写了这样一本书来记录其发生的一切。
　　我没能赶上参与《微软的软件测试之道》的编写，但是在300gle却有幸得到这样的机会。我来Google的时候，其测试正处于一个蓬勃发展的上升期。工程生产力团队的员工数量正以火箭喷发般的速度增长，从几百人迅猛发展到今天的1．200人。正如Patrick在本书序言中所说的那样，这种增速随之而宋的是成长的烦恼，这也是他们最后的阵痛，此后这个组织开始了前所未有的井喷式增长。Google的测试博客每月吸引了成千上万的人来浏览阅读，GI’AC（注：G．I‘AC：是GoogleTestAutomationConference的缩写，即Google测试自动化大会，参见大会也已经成了测试行业的旗帜性会议。在我来到Google不久之后，Patrick也得到了晋升，手下有十几个总监和工程经理直接汇报给他。如果你认为软件测试又进入到新的文艺复兴时期，那么Google一定就是位于中心的罗马。
　　这意味着Google背后的测试故事其实可以写成一本很厚的书。但问题是，我并不想这样做。Google之所以闻名于世，在于其实现软件的方法：简单和直截了当。或许这本书也可以保持这样的风格。
　　（（Google软件测试之道》这本书的核心内容包括：详细讲述了作为一个Google的测试人员究竟意味着什么，同时也包含Google是如何解决软件在扩展性、复杂性和大并发方面的问题。如果想知道这些，阅读本书将是你的最佳获取途径。如果书中的内容还是不能满足你想要充分了解GOOgle是如何测试的需求，互联网上还有更多的信息，你只需要“GOOle一下”。
　　关于本书由来的故事，不得不说的大概就是这些了。我也终于做好了准备来讲述GOogle是如何进行测试的。随着越来越多的软件公司从桌面应用转向网络应用，G00gle测试软件的方法也很有可能成为其他公司的榜样。如果你已经读了《微软测试之道》，那么千万不要试图在这本书中找一些共同点。除了两本书的作者都是三个人，且都是在讲述大型软件公司的测试实践之外，这两本书中所描述的测试方法可谓大相径庭。
　　PatickCOpeland在本书的序言中解释了G00gle测试方法演变的历史，随着公司的不断成长，它也在不停地、有组织地进化着。G00gle是个大熔炉，许多来自其他公司的工程师被抛进来熔炼。在前雇主公司使用的技术，如果被证明效率低下，该技术要么被遗弃，要么通过G00gle的创新文化再进行改良。随着测试工程师队伍的不断膨胀，就有了许多新的想法和实践的尝试，那些在实践中被证明很有用的技术会被GOogle保留下来，并成为GOOgle的一部分；另外一些被证明是负担的，则会被抛弃掉。G00gle的测试者很愿意去尝试新技术，但有些技术一旦被发现并不实用，就会立刻被抛弃。
　　G00gle是一家以创新和速度为基础的公司，快速地发布有用的代码（如果失败，也只有少数早期用户会失望）、迭代地增加早期用户希望使用的功能（最大化用户反馈）。在这样的环境下，测试不得不变的异常灵活，并且在技能上要做许多前期的规划，只是不停地简单维护并不能真正解决问题。有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离，甚至开发人员都不知道测试在做些什么。
　　……

　　毫无疑问，在当前这个时代，处于浪潮之巅的伟大公司非Google莫属。很长一段时间以来，Google的技术一直被外界所觊觎，其所宣扬的工程师文化氛围也成为了许多工程师梦寐以求的技术殿堂，其内部的工程实践更是技术分享大会中最热门的话题之一。但迄今为止，没有一本书系统地介绍Google内部产品的研发流程与模式，包括开发、测试、发布、团队成员如何分工协作等细节，直到《How Googleests Software））的出现，才使得我们有机会管中窥豹，了解Google技术神秘之处。这也是我们翻译这本书的第一个原因。
　　正如本书中所提及的那样，互联网的出现改变了许多软件研发的模式。许多曾经红极一时的传统测试书籍里提及的最佳测试实践，在当前的环境下，效率会大大下降，在一些极端的情况下甚至会适得其反。我自己就是一名测试工程师，从事互联网方面的测试工作，对此深有体会，也经常焦虑如何在制约质量和快速发布之间寻找平衡，所以，也特别想从一些主流互联网公司的测试模式中得到启发和借鉴，特别是想看一下这个世界上最成功、增长速度最快的互联网公司——oogle，是如何应对互联网测试挑战的。通过翻译这本书，自己学到了更多感兴趣的知识。这也是我们翻译这本书的第二个原因。
　　JamesWhittaker在正式撰写本书英文版之前，于2011年1月在GoogleestingBlog上尝试发表了towGoogle．1estSoftware”系列文章。当看到第一篇时我就被深深地吸引住了，第一感觉就是，太棒了！Google测试团队居然是这样组织的！之后，随着这个系列文章的逐一公开，Google也逐渐揭开了其神秘面纱，让我对其测试实践也有了越来越多的了解，但了解的越多，疑惑也就越多。不得不承认，这几篇文章就像正餐前的开胃小菜，它完全勾起了大家的食欲，仅仅依赖这几篇文章完全不能满足窥探Google测试体系的需求。在2011年11月的G．TALCGoogleest Automation C0nference）大会上，我见到了James本人，便聊起了《Htow Goog leest Software》这本书，James一听到又有人在打探这本书的下落，乐呵得嘴都合不拢了，却卖起了关子来，只是说书快出版了。大约在2012年9月，这本书的英文版终于问世之后，突然接到李中杰（本书的合译者之一）的电话，问我为什么不去翻译一下这本书呢。之前虽然是兴趣使然，做过那几篇文章的翻译，但与翻译一本书相比，还是有些微不足道的。但几经转辗，还是机缘巧合地去做了这件事情，这也是翻译这本书的第三个原因吧。
　　最后要说的，也是最重要的一个原因。我原本根本没有这么大的勇气来完成这件事情。众所周知，James不仅是测试领域的泰山北斗，而且他颇具文学功底，语言诙谐幽默，妙笔生花，翻译他的书籍，让我诚惶诚恐，以至于焦虑得昼夜不安。但两位合译者，李中杰博士和薛明，他们的乐观与自信让本书的翻译得以完成。与他们两位的合作，幸福之感难以言表，所收获的也不仅仅是长知识那么简单，更有许多惊喜深藏内心。翻译别人的书，像是在反刍，再精彩也是在讲别人的故事，还是期待有朝一日，能够也有机会讲讲自己的故事。
　　最后祝愿国内的读者能够从这本书中有所借鉴，找到适合自己现状的开发测试模式。由于译者水平有限，错漏之处在所难免，若有欠妥之处，欢迎指正。