谷歌（google）是如何做软件测试的

　　这是这个主题系列的第一篇文章。

　　我听到的最多的一个问题是“Google如何做测试?”这个问题已经在本博客上零零散散的回答过，但这次的回答将会做一个完整的更新。Google的测试策略从来没有变过，我们执行测试的策略随着公司的演化而演化。我们现在是一个集搜索、应用、广告、移动、操作系统等业务于一体的公司。每一个我们关注的领域都是在该领域有意义的问题。随着我们不断的增加新的“关注领域”(Focus Areas)，延伸已经存在的领域，我们的测试也在不断的扩展和改善。而我们当下在做的以及我们预计未来将会发展的方向，就是我将要在这系列文章中将要阐述的问题。

　　让我们先从组织结构的介绍开始，这个或许会让你感到惊奇。在Google并不存在一个真正意义上的测试部门。测试实际存在于一个关注领域，我们称它为“生产率工程”(EngineeringProductivity)。“生产率工程”是一个拥有一定数量的横向和纵向的工程学科，测试是最大的一个。而在这个组织中，“生产率工程”是由以下三部分组成：

　　1. 产品团队(productteam)。他们设计的内部的和开源的工具由公司里的所有工程师完成。他们负责构建和维护代码分析器、开发环境、测试用例管理系统、自动化测试工具、构建系统、源代码控制系统、代码回顾计划、缺陷数据库。他们的目标就是设计一种能让工程师更有效率的工具。工具是在检测预防的战略目标中占非常大的一部分。

　　2. 服务团队(servicesteam)。他们在一个非常宽泛的领域内向产品团队提供诸如包含工具(includingtools)、文档、测试、发布管理、培训等方面的专业技能。他们的专业技能涵盖可靠性、安全性、国际化等方面，也会处理产品团队可能遇到的关于功能细节方面的问题。任何一个其他“关注领域”的服务团队也可以为产品团队提供专业技能服务。

　　3. 嵌入式工程师(embeddedengineer)。他们有效的担负起了Google产品团队在有需要时的需求。有些工程师会跟着同一个的产品团队数年，另一些则只会在一个较短的周期内为产品团队的需要提供服务。Google鼓励所有的工程师经常更换自己服务的产品团队，以保持饱满的精神状态，并保证有效和客观的工作。测试工程师也一样，更换团队的节奏也是因人而异的。有些测试工程师在Chrome项目下数年，而有一些则在加入团队18个月后去了别的团队。在产品知识与新颖的视角间保持一个良好的平衡，是一个测试管理者需要关注的。

　　据上，也就是说测试工程师需要向产品经理的主管报告，但是也需要与产品团队一样自己对产品有所识别，比如搜索、Gmail、Chrome这样的产品团队。从组织架构上来说，他们是共属于两个团队的。他们与产品团队在一起办公，共同参与产品计划，与他们一起共进午餐，拥有相同的奖金，获得和团队所有成员一样的待遇。独立报告这样的组织结构的好处在于提供给了测试工程师一个论坛，去分享他们的看法。好的测试想法不会被产品束缚，可以很容易的由产品工程师传你给所有的测试工程师，获得公司内最好的技术。

　　这种项目与报告结构相分离是有其自身的挑战性的。到目前为止，最大的挑战在于测试工程师是外部资源，产品团队不能在他们身上压太大的赌注，他们必须确保产品的质量合乎预期。是的，在Google，产品团队为他们质量负责，而不是测试工程师。每一个开发工程师需要自己做测试，而测试工程师的工作是确保他们的自动化测试结构的可移植性，以确保其是可信赖的。测试工程师是为了让开发工程师可测试。

　　我喜欢的策略是让开发工程师和测试工程师处于相同的地位。这样做一方面可以确保我们伙伴间对质量有相同的责任，并且把对质量负责的重任交给应该确保其正确性的开发工程师。另一方面，这样会确保我们存在一个“多对一”的开发工程师对测试工程师的比例。开发工程师多于测试工程师。这样的话，他们测试上做得越好，他们在数量上就比我们越多。产品团队也会以这样的高比例而骄傲。

　　现在，我们都到齐了吗?你们都看到了这个我十分确定的策略的漏洞了。有一个非常大的问题，开发工程师不能去做测试。我该去拒绝谁呢?没有多少人让我去拒绝，尤其是在我去年做的一次关于开发工程师与测试工程师对比的游戏之后(告诉你：测试工程师赢得了较量)。

　　Google的回答是分解角色。我们在Google用两种不同类型的测试角色解决了两种不同问题。下一章我将谈一谈这些角色，以及我们是如何将问题分解为两个部分的。
 

　　为了践行 “谁构建，谁破坏”的座右铭，一些超出常规意义上的开发工程师的角色是有必要的。也就是说，有必要存在一种让开发工程师更快更有效的做测试的工程作用。在Google，我们设置了一些以提高他人更有成效为工作内容的角色。这些工程师把自身当作一名测试工程师看待，但是他们真正的任务是让测试更有效率。他们的工作是为了让开发工程师更有效率，而提高质量是更有效率的一个很大的组成部分。下面是这些角色的一个简要介绍：

　　软件工程师(Software Engineer，SWE)就是传统的开发工程师的角色。他们为用户编写各个功能的代码。他们创建设计文档，设计数据结构，进行架构总体的设计，并且花费大量的时间编写和检查代码。他们编写大量的测试代码，包括测试驱动设计(test driven design)、单元测试以及其它我们将要在后文中提到的内容，他们参与各种规模的测试构建。他们为他们所接触的一切由他们编写的、维护的、修改的代码负责。

　　测试开发工程师(Software Engineer in Test，SET)同样也是一个开发工程师的角色，只不过他们更多的关注于软件的可测试性。他们检查设计，特别关注代码质量和可能存在的风险。他们不断的检查代码，以确保其可测试性。测试开发工程师编写单元测试框架和自动化脚本，他们在代码层面是软件工程师的伙伴，但是他们更关注不断增长的代码的质量和测试覆盖率，而不是增加几个新的功能特性或者不断优化的性能。

　　测试工程师(Test Engineer，TE)和测试开发工程师恰好完全相反。这个角色的主要职责是将测试放在第一位，开发放在第二位。测试工程师花费大量时间在写自动化测试脚本的形式，编写那些驱动使用的场景以及模仿用户使用的代码。他们也会组织软件工程师和测试开发工程师的测试工作，解释特使结果，驱动执行测试，尤其是在项目后期驱动项目向发布的方向发展。测试工程师是产品方面的砖家，质量的建议者，以及风险的分析师。

　　从质量的角度上讲，软件工程师只对产品的特性和这些特性的质量负责。他们负责容错设计，故障恢复，测试驱动开发，单元测试，以及和软件测试开发工程师一起为产品特性编写测试脚本。

　　测试开发工程师是提供测试特性的开发工程师。一个框架，可以通过模拟新开发的代码与桩(stub)、虚拟对象(mocks)、仿冒(fake)的依赖关系将新开发的代码进行隔离，并且确定提交顺序以管理代码的合入。换句话说，测试开发工程师编写可供让软件开发工程师进行特性测试的代码。实际上大多数测试是由软件开发工程师执行的。测试开发工程师是确保特性的可测试项，而软件工程师则更多参与测试用例的编写。

　　测试开发工程师主要关注在开发工程师(developer)。独立特性的质量是目标，而促使开发工程师容易测试他们编写的代码是开发测试工程师主要关注的目标。我可以十分肯定的说各位读者一定清楚的看到了，这里提到的开发的关注点留下了一个很大的漏洞：用户角度的测试呢?

　　在Google用户集中测试是测试工程师的主要工作。假设软件工程师和测试开发工程师已经将执行模块和特性级别的测试进行得非常充分了，下一步的工作就是了解这个可执行的代码和数据聚合的产品是如何在一起工作以满足用户的需要的。测试工程师扮演着二次检查这些经过勤奋的开发工程师开发出的作品的角色。任何明显的缺陷都是早期开发工程师测试不充分或粗心大意的表现。当这种缺陷非常罕见时，测试工程师就可以把主要工作转为确保软件可以在用户的场景下正常运行，确保软件是高性能的和安全的，是符合国际化标准的等等。测试工程师执行很多测试，协调众多测试工程师测试工作，联系测试工程师、外包测试工程师、代码聚合测试工程师、内部测试人员(dog fooders)、beta版用户和早期用户(early adopters)。他们会不断沟通包括包括基本设计、特性的复杂性以及失败的避免方法在内的可能产生的风险。一旦测试工程师介入，他们的任务会变得无休止。

　　好了，关于各个角色你应该会有一定的了解了。下次，我将更深入的讲解我们是如何通过这些角色进行工作的。感谢你们的关注。

原文转自：http://www.ltesting.net