本节书摘来自异步社区《Google软件测试之道》一书中的第1章1.1节质量不等于测试，作者【美】James Whittaker , Jason Arbon , Jeff Carollo，更多章节内容可以访问云栖社区“异步社区”公众号查看。
第1章 Google软件测试介绍Google软件测试之道C:Documents and SettingsAdministrator桌面页面提取自－ 9780321803023_book.jpg
在许多场合下，不管是在国外访问还是出席会议期间，我总是毫无例外地被问及一个问题。甚至是刚刚加入公司的新员工也会问到同样的问题：“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的测试方法，很有可能成为其他公司竞相模仿的榜样，特别是那些从桌面应用转向网络应用的公司。Patrick Copeland在本书的序言中解释了Google测试方法演变的历史，随着公司的不断成长，它也在不停地、有组织地进化着。Google是个大熔炉，许多来自其他公司的工程师被抛进来熔炼。在前雇主公司使用的技术，如果被证明效率低下，该技术要么被遗弃，要么通过Google的创新文化再进行改良。随着测试工程师队伍的不断膨胀，就有了许多新的想法和实践的尝试，那些在实践中被证明很有用的技术会被Google保留下来，并成为Google的一部分；另外一些被证明是负担的，则会被抛弃掉。Google的测试者很愿意去尝试新技术，但有些技术一旦被发现并不实用，就会立刻被抛弃。
Google是一家以创新和速度为基础的公司，快速地发布有用的代码（如果失败，也只有少数早期用户会失望）、迭代地增加早期用户希望使用的功能（最大化用户反馈）。在这样的环境下，测试不得不变的异常灵活，并且在技能上要做许多前期的规划，只是不停地简单维护并不能真正解决问题。有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离，甚至开发人员都不知道测试在做些什么。
注意
有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离的，甚至开发人员都不知道测试在做些什么。贯穿Google的整个发展史来看，当前Google的发展速度只比创业初期慢了一点点而已。虽然Google创业已是很久以前的历史，但还是可以在一年内就做出一个操作系统、在几周内就发布像Chrome这样的客户端应用、每天都在更新其网络应用程序。在这种环境下，很容易就可以说清楚测试并非“教条式的、强流程、体力密集型、耗时的”——这比定义测试是什么要简单的多，虽然本书一直在尝试解释测试是什么。有一件事是可以确定的，测试不能成为导致创新和开发过程变慢的阻碍。至少，这种情况不能出现两次。
Google在测试上的成功，不能简单地归结为其被测系统规模小且简单。Google软件应用的规模和复杂度与外面其他的公司一样。从客户端的操作系统到网络应用、移动端、企业级应用、商业应用、社交等各个方面，Google几乎无所不包。
Google的软件庞大且复杂，拥有数以亿计的用户，也是黑客们喜爱的攻击目标。绝大多数Google源代码都是开源的，这些代码对外公开，被外界所觊觎。多数代码是历史遗留代码，使用常规的代码审核来做代码评审。Google的代码服务于上百个国家，使用不同的语言，但是用户其实只是期望Google能够提供简单易用且“能够工作”的服务。Google的测试人员每天完成的工作，并非只是解决简单的问题，Google的测试人员每天都在面临不同的测试挑战。
Google的做法是否正确（很有可能是错误的）是一个值得商榷的事情，但有一点是确定的，Google的测试方法与其他我所了解的公司的测试方法有很大的不同。随着软件逐渐由桌面应用迁移到网络云端，Google的测试模式很有可能会逐渐成为测试行业的主流模式。在测试这个行业，如何做测试，从而保证可以开发出可靠的、值得信赖的软件，一直是这个行业值得争议的话题。我和本书的其他作者就希望通过本书可以很好地阐述Google的测试实践，从而可以引起一些讨论，达到抛砖引玉的目的。Google的测试方法或许有它的不足，但我们也乐意去对外公开它们，使之表露在业界和国际测试社区的眼皮之下，在经过外界的严格审查之后，我们才能持续地改进。
Google的测试方法看起来有点违背常理——在整个公司，我们只有非常少的专职测试人员，甚至比我们竞争对手公司的单个产品的测试人员还要少。在通往成功的道路上，Google的测试团队并非雄兵百万，我们更像是小而精的特种部队，我们依靠的是出色的战术和高级武器。由于资源的缺乏，这也是我们向特种部队方向发展的根本原因。没有足够的人手，使得我们不得不去做好优先级的安排，正如Larry Page所说，“少则清晰”。不管是功能方面的技术，还是测试方面的技术，在追求质量方面，我们已经学会了如何运用这些技术，创建高影响力、低阻力的实践活动。测试人员的稀缺会导致测试资源变得非常昂贵，因此，我们的原则就是让这些稀缺且聪明的测试员工保持昂扬的斗志和充沛的精力。当有人来问我，Google成功的关键是什么，我的第一个建议就是，不要招聘太多的测试人员。
注意
当有人来问我，Google成功的关键是什么，我的第一个建议就是，不要招聘太多的测试人员。Google在测试人员如此缺乏的情况下，是如何应对的呢？简单地说，在Google，写代码的开发人员也承担了质量的重任。质量从来就不仅仅是一些测试人员的问题。在Google，每个写代码的开发者本身就是测试者，质量在名义上也由这样的开发测试组合共同承担，如图1.1所示。在Google，谈论开发测试比（译注：这里指在人员数量上，开发和测试的比率）就像讨论太阳表面的空气质量一样，这本身没有任何意义。如果你是一名工程师，那么你同时也是一名测试人员。如果在你的职位头衔上有测试的字样，你的任务就是怎样使那些头衔上没有测试的人可以更好地去做测试。
Google可以打造出世界级的软件，这也足以证明其对待质量的独特方法值得学习。或许其中的一些经验在其他的公司组织中也能适用。当然里面也有需要改进的地方。接下来所述就是关于Google测试方法的概要介绍。在后面的章节里，我们会深入到细节中，以此来阐述在以开发为中心的文化中Google是如何做测试的。
1.1 质量不等于测试 质量不是被测试出来的——这句看似陈词滥调的话却包含着一定的道理。从汽车行业到软件行业，如果在最开始设计创建的时候就是错的，那它永远不会变成正确的。试问一下汽车行业的公司，大量召回事实上有质量问题的产品，代价是多么的昂贵。因此，从最初的创建阶段就要做正确，否则将会陷入混乱的万丈深渊。然而，这句话也并不像听起来那样的简单和准确。虽然质量不是被测出来的，但同样有证据可以表明，未经测试也不可能开发出有质量的软件。如果连测试都没有做，如何保证你的软件具有很高的质量呢？
有一个简单的办法可以解决这个难题，那就是停止开发与测试的隔离对立。开发和测试应该并肩齐趋。你需要在写完每一段代码后立刻测试这段代码，当完成了更多的代码时就要做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分。质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。
注意
质量不等于测试。当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。在Google，这正是我们的目标，就是把开发过程和测试融合在一起——开发和测试必须同时开展。写一段代码就立刻测试这段代码，完成更多的代码就做更多的测试，但这里的关键是由谁来做这些测试呢？众所周知，在Google，专职测试人员的数量非常稀少，与开发相比根本不成比例，唯一可能的去做这些的就只能是开发人员。还有谁能比实际写代码的人更适合做测试呢？还有谁能比实际写代码的人更适合去寻找bug呢？是谁会为了避免受更大刺激而去想办法避免产生bug呢？Google能用如此少的专职测试人员的原因，就是开发对质量的负责。如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个bug的测试人员。
这意味着质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。我们已经成功地将测试实践融入为开发过程的一部分，并创建了一个增量上线的流程。如果一些项目在线上被证实的确是bug重重，它将会被回滚到之前的版本。在确保不出现回滚级别bug发生的前提下，预防了许多客户问题的同时，也很大程度降低了专职测试人员的数量。在Google，测试的目标就是来判断这种预防工作做的怎么样。
把开发过程和测试混合在一起，密不可分，从代码审核问询时的“你的测试在哪儿”，再到在卫生间张贴着的、用来提醒开发人员的最佳测试实践（注3：参见http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html）。测试是开发过程中必不可少的一部分，当开发过程和测试一起携手联姻时，既是质量达成之时。
注意
测试是开发过程中必不可少的一部分，当开发过程和测试一起携手联姻时，即是质量达成之时。
