谷歌如何做软件测试
第一部分
Google的测试策略从来没有变过，我们执行测试的策略随着公司的演化而演化。我们现在是一个集搜索、应用、广告、移动、操作系统等业务于一体的公司。每一个我们关注的领域都是在该领域有意义的问题。随着我们不断的增加新的“关注领域”（Focus Areas），延伸已经存在的领域，我们的测试也在不断的扩展和改善。而我们当下在做的以及我们预计未来将会发展的方向，就是我将要在这系列文章中将要阐述的问题。
  让我们先从组织结构的介绍开始，这个或许会让你感到惊奇。在Google并不存在一个真正意义上的测试部门。测试实际存在于一个关注领域，我们称它为“生产率工程”（EngineeringProductivity）。“生产率工程”是一个拥有一定数量的横向和纵向的工程学科，测试是最大的一个。而在这个组织中，“生产率工程”是由以下三部分组成：
  1、产品团队。他们设计的内部的和开源的工具由公司里的所有工程师完成。他们负责构建和维护代码分析器、开发环境、测试用例管理系统、自动化测试工具、构建系统、源代码控
制系统、代码回顾计划、缺陷数据库。他们的目标就是设计一种能让工程师更有效率的工具。工具是在检测预防的战略目标中占非常大的一部分。
  2、服务团队。他们在一个非常宽泛的领域内向产品团队提供诸如包含工具（includingtools）、文档、测试、发布管理、培训等方面的专业技能。他们的专业技能涵盖可靠性、安全性、国际化等方面，也会处理产品团队可能遇到的关于功能细节方面的问题。任何一个其他“关注领域”的服务团队也可以为产品团队提供专业技能服务。
  3、嵌入式工程师。他们有效的担负起了Google产品团队在有需要时的需求。有些工程师会跟着同一个的产品团队数年，另一些则只会在一个较短的周期内为产品团队的需要提供服务。Google鼓励所有的工程师经常更换自己服务的产品团队，以保持饱满的精神状态，并保证有效和客观的工作。测试工程师也一样，更换团队的节奏也是因人而异的。有些测试工程师在Chrome项目下数年，而有一些则在加入团队18个月后去了别的团队。在产品知识与新颖的视角间保持一个良好的平衡，是一个测试管理者需要关注的。
  所以这意味着测试同学向工程生产力部门的经理汇报，但是他们会把自己看成产品部门团队的一员，像搜索、邮箱、和Chrome部门。从组织架构上看，测试都是两个团队的一部分。
测试和产品团队坐在一起，参与计划，一起吃饭，共享奖金，享受像全职的产品团队成员一样的待遇。这种单独的组织汇报关系的好处是可以给测试人员之间提供良好的共享信息的讨论机会，好的测试思路可以很容易的在工程生产力部门内部蔓延，无论公司内的哪条产品线，都可以很快地使用这些最好的测试技术。
  测试人员的这种项目分离和汇报组织结构也有它的缺点，目前来看，最大的问题是测试人员被看做外部资源。产品部门团队不能对测试人员有太多的依赖，他们自己必须要合理地控制产品质量。是的，没错，在谷歌，是产品部门团队对产品质量负责，而不是测试人员。每个产品部门的开发人员都需要做测试工作，测试人员的任务是为产品部门团队搭建自动化测试基础设施和流程，测试人员让开发可以自给自足地、独立地做完成测试工作。
  在这种模式下，我比较喜欢的是，开发和测试将有相同的地位。在质量方面，开发和测试成为了真正的伙伴，最大的质量重担交给本应属于的开发人员，开发的职责就是正确地实现产品功能。另外这样可以保持多对一的开发测试比率，开发人员在数量上远超测试人员，并且测试工作做的越多，开发测试比率就会越大。产品部门团队也会对这样的高开发测试比率而感到骄傲。
  好，现在好像大家都是好朋友了，对吧？ 相信你已经看到这种模式的一个问题，开发人员不能很好地驱动缺陷【Bug】的运转，开发不会测试。难道我要否认这一点么？不管怎样，我都不会否认，尤其是在我去年做的一次关于开发工程师与测试工程师对比的游戏之后（告诉你：测试工程师赢得了较量）。
  在谷歌，解决这个问题的办法是将角再细分，我们通过设立不同的测试角来解决这两种不同的测试问题。在下一篇文章里，我将详细阐述这些测试角和谷歌是怎样将测试问题分成两部分来分别解决的。
第二部分
本文是从 How Google Tests Software - Part Two 这篇文章翻译而来。本文作者 James Whittaker， 前微软架构师，是“How to Break Software”系列图书中好几部书的作者，现任Google测试工程主管，最近他写了一系列的关于谷歌如何测试软件的文章，本文为其系列的第二部分。
  为了实现”谁的屁股谁自己擦”这句名言所说的那样，在传统的软件开发人员的之上，有必
要增加了几个角，特别是需要工程技术方面的特殊角，这种角可以让开发更高效低做测试。在谷歌，这样角的职责是让其他人工作的更有效率，这样的工程师通常会把自己当做测试人员，但他们真正的使命是提高生产力/生产率。他们的存在是为了让开发人员效率提升，特别是在质量方面的提升，因为产品质量是生产率中最重要的一部分。这里是这些角的总结：
  软件开发工程师， 就是传统的开发人员。软件工程师实现一些功能代码并把最终产品提供给用户使用，他们创建设计文档、设计数据结构和总体的架构搭建，他们大多数时间都在写代码和评审代码。同时，他们也会写很多的测试代码，包括测试驱动设计，单元测试，并参与后面的文章会讲到的小、中、大型测试的创建工作。软件工程师需要对他们自己写的代码、修复缺陷的代码、改进的代码，只要是他们接触过的代码的质量负责。
  软件测试开发工程师，和软件开发工程师一样是开发工程师，主要负责软件的可测试性。他们参与设计评审，近距离地关注代码质量和风险，对代码做重构为了系统有更好的可测试性，同时他们负责写单元测试框架和自动化测试的框架。在代码级别上他们和软件开发工程师是合作伙伴，但如果和增加新功能或提升性能相比较，他们更关心产品的质量和测试覆盖率的提升。
  软件测试工程师，和软件测试开发工程师恰恰相反，他得主要工作是做测试而不是开发。许多谷歌的软件测试工程师会花很多的时间在写测试代码上，包括自动化脚本、使用场景的代码、甚至模拟最终用户的操作方面的代码。他们对软件开发工程师和软件测试开发工程师的测试工作做一些组织安排，解释测试结果、驱动测试的执行，特别是在项目即将发布的后期将起到非常重要的作用。软件测试工程师既是产品专家也是质量顾问更是风险分析师。
  从质量的角度来看，软件开发工程师对功能开发和质量负有全责。同时，他们还负责容错设计、故障恢复、TDD、单元测试、和在软件测试开发工程师的帮助下写测试代码，这些测试代码会验证开发的功能。
  软件测试开发工程师是提供测试支持的开发人员。他们提供一种能够将新添加的代码通过模拟其依赖的方式做功能验证的技术框架，并应用在代码提交之前的提交队列管理之中【注，这样可以在代码check in 的时候保证新代码的功能完备】。可以这样说，软件测试开发工程师就是为了让软件工程师可以测试他们的功能代码，所有真正的测试都是软件开发工程师完成的，软件测试开发工程师是保证这些功能有很好的可测试性，这样可以让软件开发工程师很积极地参与到测试用例代码的编写中去。
  现在所有的一切很清楚了，软件测试开发工程师就是服务人员，他们的主要职责就让开发人员很方便简单的做测试并保证模块级别的产品质量。读者可能已经意识到一个问题，在这样的研发流程下，使用软件的最终用户会怎样？
  在谷歌，软件测试工程师的职责就是最终用户级别的测试。如果软件开发工程师和软件测试开发工程师很好地做了模块级别的功能测试，下一个工作就是看许多功能集成和数据的组合是否能够满足最终用户的使用需求。软件测试工程师在这里就是扮演一个双重确认开发工程师测试工作的角，任何明显的缺陷都会说明之前一轮的开发自测不够或比较草率，如果没有出现这种情况之后，软件测试工程师会将注意力转移到普通用户的使用场景测试上，保证性能、安全、国际化等方面没有问题。软件测试工程师们需要做大量的测试工作，并在测试工程师、测试合同工、吃狗粮的尝鲜者、beta测试用户、早期最终用户之间做很多沟通交流的工作，他们会和基础设计、功能复杂度、避免错误的方法等方面遇到问题的人做确认。一旦软件测试工程师开始介入，总是会没完没了。
  好了，现在大家对这些角应该有比较好的理解了，接下来我会在他们之间是怎么分工合作做更详尽的剖析。下次再聊。。。谢谢您的关注。
第三部分
本文作者 James Whittaker, 前微软架构师，是“How to Break Software”系列图书中好几部书的作者，现任Google测试工程主管，最近他写了一系列的关于谷歌如何测试软件的文章，本文为其系列的第三部分。
在前两部分的文章中，很多人在评论里提出了问题。我没有忘记他们。希望大部分的人能在余下的几部分文章里到答案。我现在还是开始这篇文章的主题。
在Google，质量并不等于测试。我相信在任何一个地方都是如此。“质量不是被测试出来的”这句老话是再正确不过了。从汽车到软件，如果它们起初制造的就有问题，那它们永远都不会没问题。试问任何一个曾经被迫大量召回的汽车公司，掩盖质量问题的代价有多大。
然而，事实情况并不是像这句话那样既简单又精确。虽然质量并不是测试出来的，但我们有同样的证据表明，没有测试，你不可能开发出任何有质量的东西。一个人怎么可能在没有测试的情况下认定你的工程具有高质量？
游戏开发工程师需要学什么对于这种难题，最简单的解决办法就是：禁止对开发工作开方便之门，以独立自由之精神进行测试。测试和开发工作需要同步进行。编写一点，测试一点。再编写一点，再测试一点。更好的方法是制定测试计划，或者你开发之前先把计划做好。测试并不是一个独立的工作，它是开发工作的一部分，伴随着整个开发过程。质量不等于测试；为了质量，需要你把开发工作和测试结合到一起，搅拌它们，直到分不清你我为止。
在Google，这是我们明确的目标：把开发和测试融合，你不能单独进行任何一项工作。做一点，测试一点。再做一点，再测试一点。关键就是看谁在做测试。因为在Google，专职测试人员是出奇的少，所以唯一可行的方法就是使用开发人员。还有比这些实际开发了这些程序的人员更合适做测试的吗？还有比程序的作者更适合去发现bug的吗？是谁具有更多的愿望在程序第一次写出时避免bug？Google之所以安排这么少的专职测试人员的原因就是，开发者负责质量。事实上，坚持使用大型测试机构的团队通常会开发出有问题的东西。测试机构庞大，这是一个信号表明编码/测试工作的融和有问题。增加测试人员并不能解决任何问题。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。