作者：[美]JamesWhittaker JasonArbon JeffCarollo（著）
出版社：信息技术第一出版分社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
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软件测试介绍
在许多场合下，不管是在国外访问还是出席会议期间，我总是毫无例外地被问及一个问题。甚至是刚刚加入公司的新员工也会问到同样的问题：“Google是如何测试的？”
虽然我已经不太确定曾经多少次回答过这个问题，以及给出了多少个不同版本的答案，但可以确定的是，随着我在Google工作的时间越来越长，发现Google的各种测试实践的不同之处也越来越多，答案也一直在变化。这些测试实践总是浮现在脑海里，并幻想着有朝一日能够将它们整理成书。直到有一天，Alberto（译注：Alberto Savoia，Google的测试总监，详细介绍参见本书序言中的Alberto部分），这个一贯认为所有测试相关的书籍都要为自己的存在找一个理由，否则就应该被扔掉做成纸尿裤的人，当他建议我应该写这样一本书的时候，我觉得时机已经成熟，是时候开始考虑写这样一本书了。
然而，我依旧还在等待。第一，我并非是写这样一本书的最佳人选。在Google，有很多我的前辈，我想先把机会让给他们来写；第二，我只是Chrome和Chrome OS产品的测试总监（现在这个职位被我之前的一个下属担任着），我看到的也只是 Google 所有测试实践中很小的一部分，我还需要去了解很多其他Google产品的测试方法。
在 Google，软件测试团队归属于一个被称为“工程生产力”（译注：Engineering Productivity，也译为工程效率或工程生产率）的中心组织部门，这个部门的职责横跨开发测试人员使用工具的研发、产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。Google拥有大量针对互联网产品的共享工具与测试基础框架，服务于包括搜索、广告、Apps、YouTube视频和其他我们在Web上提供的产品。Google已经成功解决了许多有关速度和扩展性方面的问题，使得Google作为一个大公司，却依然能以创业公司的速度来发布产品。正如Patrick Copeland在本书的序言中所说的那样，拥有如此的魔力，Google的测试团队功不可没。
注意
在 Google，软件测试团队归属于一个被称为工程生产力部门的中心组织的部门。
Chrome OS在2010年12月发布以后，我把团队顺利地交接给我的一个直接汇报者，然后开始把自己的工作重点慢慢转移到其他产品上。在这本书刚开始准备的阶段，我使用博客的方式做了一些尝试，发布了第一篇“Google是如何测试的”的系列文章（注：参见http://googletesting.blogspot.com/2011/01/how-google-tests-software.html）。6个月之后，本书终于完成，希望没有拖太长的时间。在这六个月的时间里，我了解到的Google测试实践比我过去两年在Google学到的都要多。现在有了这本书，Google的新员工们也可以通过阅读此书来熟悉Google的环境。
这并不是第一本介绍关于大公司是如何做测试的书籍。当我还在 Microsoft 的时候，Alan Page,BJ Rollison和Ken Johnston合著了《微软的软件测试之道》（译注：How We Test Software at Microsoft），我当时亲身经历了他们书中写的许多事情。Microsoft在测试领域独步全球，也是一个测试精英云集的圣地。Microsoft的测试工程师在各种技术大会中也是广受欢迎的演讲嘉宾。Microsoft的第一任测试总监——Roger Sherman，吸引了来自全球的测试精英加入华盛顿的雷德蒙德（译注：微软总部所在地）。那是一个软件测试的黄金时代。
因此，Microsoft写了这样一本书来记录其发生的一切。
我没能赶上参与《微软的软件测试之道》的编写，但是在Google却有幸得到这样的机会。我来Google的时候，其测试正处于一个蓬勃发展的上升期。工程生产力团队的员工数量正以火箭喷发般的速度增长，从几百人迅猛发展到今天的1200人。正如Patrick在本书序言中所说的那样，这种增速随之而来的是成长的烦恼，这也是他们最后的阵痛，此后这个组织开始了前所未有的井喷式增长。Google的测试博客每月吸引了成千上万的人来浏览阅读，GTAC（注：GTAC是Google Test Automation Conference的缩写，即Google测试自动化大会，参见 http://www.gtac.biz）大会也已经成了测试行业的旗帜性会议。在我来到Google不久之后，Patrick也得到了晋升，手下有十几个总监和工程经理直接汇报给他。如果你认为软件测试又进入到新的文艺复兴时期，那么Google一定就是位于中心的罗马。
这意味着Google背后的测试故事其实可以写成一本很厚的书。但问题是，我并不想这样做。Google之所以闻名于世，在于其实现软件的方法：简单和直截了当。或许这本书也可以保持这样的风格。《Google软件测试之道》这本书的核心内容包括：详细讲述了作为一个Google的测试人员究竟意味着什么，同时也包含Google是如何解决软件在扩展性、复杂性和大并发方面的问题。如果想知道这些，阅读本书将是你的最佳获取途径。如果书中的内容还是不能满足你想要充分了解Google是如何测试的需求，互联网上还有更多的信息，你只需要“Google一下”。
关于本书由来的故事，不得不说的大概就是这些了。我也终于做好了准备来讲述Google是如何进行测试的。随着越来越多的软件公司从桌面应用转向网络应用，Google测试软件的方法也很有可能成为其他公司的榜样。如果你已经读了《微软测试之道》，那么千万不要试图在这本书中找一些共同点。除了两本书的作者都是三个人，且都是在讲述大型软件公司的测试实践之外，这两本书中所描述的测试方法可谓大相径庭。
注意
书中关于Google的测试方法，很有可能成为其他公司竞相模仿的榜样，特别是那些从桌面应用转向网络应用的公司。
试读结束[说明：试读内容隐藏了图片]