组织架构

经常有人问“谷歌如何测试？” 本博之前有零零碎碎的介绍，现在我们来做一个系统的介绍。 在谷歌测试策略从来没有改变，但在战术方面随着公司也不断发展而发展。我们现在有搜索，应用服务，广告，手机，操作系统等业务。 这些特定领域有我们必须解决相关的问题。当我们添加新的业务或壮大现有的业务时，我们的测试也得到了扩大和提高。 这个系列文章记录是我们今天所做的和在可预见的未来前进的方向。

我们从组织结构开始讲起，它可能会让你大吃一惊。 在谷歌没有实际的测试部门。测试存在于关注区域，称为工程效率。工程效率拥有很多纵向和横向的工程部门，测试是其中最大的。概括地说，工程效率的组成如下：

• 产品团队：开发内部和开源工具，供公司所有工程师使用。我们建立和维护的代码分析器，集成开发环境，测试用例管理系统，自动化测试工具，编译系统，源代码控制系统，代码审查系统，bug数据库。旨在通过工具使工程更加有效率，工具是防止错误战略目标非常大的一部分。

• 服务团队，为产品团队提供专业知识，包括工具，文档，测试，发布管理，培训等等。 我们的专长包括可靠性，安全，国际化等，以及产品的具体功能问题。

• 嵌入工程师，进驻到谷歌产品团队提供支持。有些工程师可能会伴随同一产品团队多年，有些则在最需要他们的地方周转。谷歌鼓励其所有工程师改变产品团队以保持新鲜、忙碌和有目标。产品知识和新鲜事业的平衡是测试经理必须密切关注的。

因此，这意味着测试人员要向工程效率经理汇报，同时还要关注自己的产品团队，例如搜索，Gmail或浏览器。 在组织上，他们是两支球队的一部分。他们和产品团队一起，参与其规划，与他们共进午餐，分享奖金并得到产品团队正式成员对待。 该独立报告结构的好处是，它提供了分享信息测试环境。良好的测试理念易于在工程效率的所有测试时人员中传播，不管他们的从事什么产品，都获得了公司内最好的技术。

项目和汇报结构的分离也有其挑战。迄今为止最大的是，测试人员是外部资源。产品团队不能过分依赖测试，必须自己保证质量。是的，这是正确的：在谷歌的团队把握自己的产品质量，而不是测试人员。每一个开发应该做自己的测试。测试人员的职责是确保他们有自动化平台和可靠的流程，使开发可以自力更生进行测试。

我喜欢这个策略，它使开发和测试像两只平衡的脚。它使开发和测试称为真正的伙伴，质量应该由开发来负责。它让我们可以开发多于测试。开发越擅长测试，人员就比测试更多。 产品团队应该为一个高开发测试比例自豪！

以上内容节选自：https://googletesting.blogspot.com/2011/01/how-google-tests-software.html

角色

为了做到“you build it, you break it”这句名言所说的那样，有必要在传统的开发人员之上再增加几个工作角色。因为懂技术，开发人员做测试工作就更合适、更有效。在Google，我们新增的工作角色是来让技术人员负责去提高其他人的效率。这些技术人员通常把自己看作是测试人员，但他们真正的使命是提高生产率。他们的存在可以使开发人员更高效，产品更有质量，这些都是生产率最重要的部分。下面是对这些角色的一些概述：

• SWE(Software Engineer)

软件工程师是传统的开发角色。SWE编写需要提交给客户使用的程序功能代码。他们编写设计文档，设计数据结构，以及整个架构，他们主要的时间是花在开发和检查程序代码。SWE会写出大量的测试程序，包括测试驱动设计，单元测试，以及我在下一部分里将会提到的整个开发工程中的小规模(small)，中等(medium)，大规模(large)的测试程序。SWE对他动过的任何程序的质量负责 —— 不论是自己开发的、还是改过bug的，或完善过的程序。

• SET(Software Engineer in Test)

测试开发工程师同样也是开发人员，只不过他们更侧重于测试相关的东西。他们审查设计，发现里面的代码质量问题和风险。他们精炼代码，让程序更容易测试。SET编写单元测试/自动化测试框架。他们是SWE开发的程序的共同创造者，但更关注于提高质量和测试覆盖率，而不是增加新功能和提高程序性能。

• TE(Test Engineer)

TE正好和SET反过来。这个角色是以测试第一，开发放在第二。很多Google的测试工程师的大部分时间都是在写自动化测试脚本之类的代码，用来驱动测试用例或模拟一个用户。他们同时也负责组织SWE和SET的测试工作，解释测试结果和驱动测试执行，特别是在项目开发的晚期推动产品正式发布的重要角色。测试工程师是产品专家，质量顾问，风险分析师。

从质量的角度看，软件工程师对产品功能和产品质量负有完全独立的职责。他们负责产品对错误的忍耐度的设计，错误恢复，测试驱动设计，单元测试，以及和SET开发那些用来测试这些程序的测试代码。

测试软件工程师是编写测试功能的开发人员。他们提供一种框架，通过模拟器（桩、mock、fake）来模拟程序依赖，使开发出的新代码单独运行并测试他们的特性。负责管理代码的提交(check-in)。换句话说，测试软件工程师编写编码以便软件工程师可以大部分的实际的测试活动都是软件工程师执行的，测试开发工程师只是来确保程序的各项功能都可测试，软工实际参与测试用例的编写。

很显然，测试开发工程师主要是为开发人员服务的。确保每个功能的质量是他们的目标，他们使开发人员能够容易的测试自己开发出的程序。我相信有人肯定已经看出，在这个开发过程中，存在一个巨大的漏洞：怎么没有用户？

用户测试是Google的测试工程师的工作。假设SＷＥ和SET的测试充分的话，下一步的工作就是看看这一堆的可执行代码和数据集成起来是否满足用户的需求。测试工程师在开发人员的工作基础上做双重检查。任何明显的bug的存在都会说明前期开发测试工作的不充分或者草率。当这种问题很少时，工程师会将主要精力放在软件在用户场景中运行时的性能效率、安全性、国际化等问题上。测试工程部要做大量的测试，并且要在工程师和签约测试人员，目标集体测试者，crowd sourced testers，beta用户，前期用户之间配合测试。他们会同遇到基础设计上、功能复杂度和错误避免方法上的问题的用户进行交流。测试工程部一旦插手，事情就永远没个完了。

以上内容节选自：https://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html

开发和测试融合

在Google，质量并不等于测试。我相信在任何一个地方都是如此。“质量不是被测试出来的”这句老话是再正确不过了。从汽车到软件，如果它们起初制造的就有问题，那它们永远都不会没问题。试问任何一个曾经被迫大量召回的汽车公司，掩盖质量问题的代价有多大。

然而，事实情况并不是像这句话那样既简单又精确。虽然质量并不是测试出来的，但我们有同样的证据表明，没有测试，你不可能开发出任何有质量的东西。一个人怎么可能在没有测试的情况下认定你的构建具有高质量？

对于这种难题，最简单的解决办法就是：不要分隔开发和测试。开发和测试携手合作。编写一点，测试一点。再编写一点，再测试一点。更好的方法是制定测试计划，或者你开发之前先把计划做好。测试并不是一个独立的工作，它是开发工作的一部分，伴随着整个开发过程。质量不等于测试；为了质量，需要你把开发工作和测试结合到一起，搅拌它们，直到分不清你我为止。

在Google，这是我们明确的目标：把开发和测试融合，你不能单独进行任何一项工作。做一点，测试一点。再做一点，再测试一点。关键就是看谁在做测试。因为在Google，专职测试人员是出奇的少，所以唯一可行的方法就是使用开发人员。还有比这些实际开发了这些程序的人员更合适做测试的吗？还有比程序的作者更适合去发现bug的吗？是谁具有更多的愿望在程序第一次写出时避免bug？Google之所以安排这么少的专职测试人员的原因就是，开发者负责质量。事实上，坚持使用大型测试机构的团队通常会开发出有问题的东西。测试机构庞大，这是一个信号表明编码/测试工作的融和有问题。增加测试人员并不能解决任何问题。

这就是说相对于检测，质量措施更多的应该是一种预防行为。质量属于开发问题，而不是测试问题。通过把测试工作一定程度的融合到开发过程中，我们创建了一个渐进的流程：如果增加bug过多，可以回滚。我们不仅避免了大量的客户方的问题，也减少了处理找回bug的测试人员的数量。在Google，测试工作的目标就是检查这些预防工作是否在有效的运行。测试工程师一直在寻找这种作为bug创造者的软件工程师和作为bug预防者的测试软件工程师之间的联合能达到的效果的证据，一旦这个方法出现问题，他们就会拉响警笛。

这种开发和测试的结合随处可见，从代码审查注释上写的“你的测试呢？”到厕所里的给开发者的最好的测试实践方法的宣传画——这是我们臭名昭著的厕所测试指导方针。测试是开发工作中是必不可少的，开发和测试的联姻是孕育质量的过程。SWE就是测试者，测试开发就是测试者，测试工程师就是测试者。

如果你的企业也有这种类型的结合，请分享出你们成功的经验与挑战。如果没有，那么这是一个给你的企业带来好处的机会：在开发人员和质量之间画上全等号。你们都听过这样一个老故事：小鸡很高兴能为一顿咸猪腿加鸡蛋早餐奉献自己的力量，可猪究竟做错了什么？的确是 … 去对你的开发人员哼哼两声，看能不能得到他们哼哼回应。如果他们发出的是咯咯哒的声音，那说明你们之间存在问题。

以上内容节选自：https://googletesting.blogspot.com/2011/02/how-google-tests-software-part-three.html

版本管理

谷歌实现比许多公司更少的测试人员而达到良好的结果关键方法之一是，我们很少尝试一次组装大量的功能。事实上，目标往往正好相反，我们打造产品的核心并立即发给尽可能多的用户，然后得到他们的反馈并进行迭代。Gmail就是这样开发的，它Beta了四年。我们去掉了beta的标记当我们达到了可以99.99％的处理一个真实的用户的电子邮件数据。显然，质量是一项正在进行的工作！

事实上为了达到测试channel，产品必须经过其他一些channel，以证明它的价值。比如Chrome，我刚进goolge 2年工作的产品，使用了多种channel，并最大限度利用了用户反馈。具体过程如下：

• 金丝雀Channel是用于我们怀疑是不适合发布的代码。 就像在煤矿的金丝雀，如果它不能再生存下去，我们有工作要做。金丝雀通道适用于超宽容的实验性用户，而不是靠应用来完成实际工作的用户。－类似大陆所称的冒烟测试。

• 开发Channel是开发人员的每天都要使用。产品的所有工程师，把这个版本使用实际工作中。

• 测试Channel适用于内部。

• Beta Channel或发布Channel版本是首次对外曝光。

这种爬行，走路，跑步的方式除了可以使用自动化每一轮channel外，还可以使我们有机会来更早的执行测试和实验应用以及收集用户反馈。

该过程也利于分析。如果现场发现bug，测试人员可以在每个channel执行来检验是否修复。

https://googletesting.blogspot.com/2011/03/how-google-tests-software-part-four.html

测试规模

Google不使用代码，集成和系统测试等概念，谷歌使用了小型，中型和大型等强调范围的概念。

• 小型测试

通常是自动化了的针对单个函数或者模块的测试。一般由软件工程师或者测试软件工程师书写，需要mocks和faked的环境。测试工程师诊断特定的故障时也可以使用到这些测试。 小型测试一般关注典型的功能问题，如数据损坏，错误条件等，它检验了代码是否做了该做的事情。

• 中型测试

以自动化或者手工方式执行，一般包含了2个或者多个特性以及特性间的交互。一些测试开发工程师这样描述中型测试：测试一个功能及其最近的功能。当产品开发早期单个特性完成的时候，测试开发工程师驱动开发这些测试，开发工程师书写，调试和维护测试。如果测试失败或者终端，开发独立处理。产品开发后期，测试工程师可能执行中型测试。中型测试试图解答：相邻特性写作是否正常。

• 大型测试

包括三个大型以上（通常更多）功能并且尽可能接近用户场景。这涉及所有特性的集成，不过大型测试更倾向于结果导向，即软件是否是用户希望的？

小型，中型和大型的表达方式并不重要。 重要的是，谷歌测试人员都有一个共同的语言。要尽量多使用自动化，涉及到主观判断和隐私的，可以不自动化。

以上内容节选自：https://googletesting.blogspot.com/2011/03/how-google-tests-software-part-five.html

SET的职业生涯

SET是测试方面的软件工程师，他书写测试功能。首先SET是开发，在招聘和内部晋升资料中被我们奉为100%的编码角色。当在招聘面试软件测试开发工程师的时候，对于编码的要求几乎和对软件开发工程师的要求是一模一样的，而且更强调如何去测试自己写的代码。换句话说，软件开发工程师和SET都需要回答编码问题，而且SET会被问到一系列测试相关的问题。

正如你可能想到的，这是一个很难满足的角色。SET的数量如此之少的最有可能的原因是具备所需技能的人非常难找。

通常SET不会在早期设计阶段就介入。不是故意这样做，而是和多数谷歌的产品是如何诞生的有关。一个常见的新产品诞生是已有的谷歌产品的员工会投入20%时间来开始新的产品。Gmail和Chrome OS这2个产品，从一个简单的想法开始，并非正式地由谷歌授权去做的，慢慢地随着时间的推移，越来越多的开发和测试加入进来并把产品发布。在这种情况下，早期的开发要关注的重心并不是质量，更关注提供一些理念，在解决了扩展性和性能的问题之后，再更多地关注质量。如果你还不能创建可扩展的web servic时，测试并不是你最大的问题。

你可以想象这样一个过程，某人有了一个好主意，他开始思考并写了一些试验性质的代码，从其他人那里获取一些建议然后对这些代码做了改进，并劝说更多的人加入，写了越来越多的代码，然后意识到他们做的事情很重要，通过更多的代码把这个想法变成可以呈现给他人并得到反馈的模型… ?这个项目在谷歌的项目库中就创建了，这个项目慢慢地转正。

所有正式项目都有专职的测试人员么？ 默认是没有的。小型项软件测试开发工程师目和用户数有限的项目一般由开发人员自试。其他的一些对个人或者企业用户有潜在风险的项目测试才会介入。

当开发团队寻求测试团队参与并帮助他们时，他们有责任使测试人员相信他们的项目是令人兴奋并充满潜力的。开发总监会给测试总监解释他们的项目、进度、发布计划，一起讨论测试工作如何划分，并就开发需要满足的单元测试水平及开发参与测试工作程度上达成一致，发布流程中开发与测试的责任也需要明确。SET在项目初期可能不会参与进来，但项目转正后他会对运作发挥巨大的影响力。

当我说“测试”时，并不是仅仅意味着单纯的检查验证代码路径。测试人员不是从开始就参与进来的，但“测试”却至始至终都有。实际上开发上传代码或者之前，SET的影响力已经显现。

参考资料：

https://googletesting.blogspot.com/2011/05/how-google-tests-software-part-six.html

https://googletesting.blogspot.com/2011/04/set-career-path.html

软件测试工程师的职业生涯

相比SWE和SET而言，软件测试工程师(Software Test Engineer TE)是一个较新的角色，甚至这个角色本身目前还在定义完善之中。当前谷歌测试工程师们正在对未来这一角色的定义上进行 实践尝试中。在这里，我们讲述的这个角色的定义过程，是正在进行中的，也是我们认为最适宜谷歌的。

策略上讲，项目配备多少测试资源，是和项目风险、投资回报率息息相关的。如果对用户（不管是个人还是企业用户）的风险较大，则意味着在测试上 要投入较多的资源，需要更多的测试工程师。但投入的资源需要和其潜在的回报成正比。我们需要在合适的时间，投入合适数量的测试工程师，并得到合适的收益。

当测试工程师，进入产品的时候，并不需要一切重头开始。在项目最开始的时候，开发工程师和测试开发工程师已经在测试工程和质量方面做了大量工作。测试工程师在进入产品时，需要考虑以下一些问题：

• 当前软件的薄弱点在哪里？
• 从安全、隐私、性能、稳定性这几个角度出发都关注哪些内容？
• 对于主流用户来说，是否可以满足他们的预期？对于全球所有的用户也是这样么？
• 这个产品是否需要和其他产品交互（软件和硬件上）？
• 当发生问题的时候，诊断工具是否很好地使用？

上面所有问题，都会被当做软件发布过程中的风险进行讨论。测试工程师并不需要自己去解决所有这些问题，但必须保证这些问题被解决掉，这就需要去评估 其他人的工作来看还有多少工作需要去做。其实，测试工程师之所以被雇佣，就是为了保护软件的最终个人企业用户的利益，使之不受糟糕的设计、令人疑惑的用户交互界面、功能缺陷、安全和隐私等问题带来的不良影响。在谷歌，测试工程师是团队中唯一全职对整体产品弱点关注的角色。和SET相比， TE的工作并不是那么清晰和一致。测试工程师会被要求在项目的各个阶段都提供援助，无论产品是一个想法的时候，还是产品已经到了第八个版本，甚至需要为一些已经过时封存已久的项目提供支持。有些测试工程师，比如在安全的，通常会同时负责多个项目。

显然，不同项目中的测试工程师的工作内容也会不同。一些TE像SET一样编码为主，但更多关注端对端的用户使用场景。其他TE利用已有的代码和设计来验证失败的场景。TE必须对测试计划及测试完成做系统全面的考虑， 特别是在真实使用方式和系统体验上。在需求不明确的情况下，测试工程师善于对一些说不清的问题上做原因分析和沟通处理。

考虑到测试工程师需要的技术技能、领导力、对产品的深厚理解力等多方面要求，其职位描述会是令人恐惧的，如果没有正确的指导，这个角色会很难去做。 幸运的是，在谷歌，一个由测试工程师们组成的强大社区的出现解决了这个问题。在所有的工作角色中，测试工程师可能是最好可以相互提供帮助的角色，这个角色需要敏锐的洞察力和领导力，因此谷歌的许多高级测试经理从测试工程师起步的。

测试工程师的工作经常需要去打破常规。在任何时刻，一旦测试工程师进入项目，他就需要去评估项目、代码、设计、用户的当前状态，并决定当前需要去首 先关注些什么。如果进入项目的时候，项目刚刚开始，这个时候测试计划会是第一优先级要解决的问题。有些时候测试在产品的晚期才进入，这个时候需要去评估这 个项目是否已久为产品发布做好了准备，或者在“beta”版本发布之前还需要解决哪些主要的问题。如果测试工程师进入了一个新的产品，或者他对这样产品中 有较少经验的时候，通常情况下会先去做一些不需要测试计划的探索性测试工作。在另外一些时候，项目已经很久没有发布了，只是需要去做一些修饰或者安全方面 的修复，或者用户交互方面的更新，这需要测试工程师针对不同阶段的项目使用不同的方法。谷歌的测试工程师需要在不同的项目做不同的事情，并且他们很少做相同的事情。

参考资料：https://googletesting.blogspot.com/2011/05/how-google-tests-software-part-seven.html

后记

谷歌的测试方式成为业界的标杆之一，上述文章很受欢迎。为此谷歌相关测试人员后面整理了一本书：

How Google Tests Software - 2012.pdf

参考资料

• 讨论 钉钉群21745728 qq群144081101 567351477
• 本文最新版本地址
• Google软件测试之道 书籍下载
• 本文源码地址
• 本文涉及的python测试开发库 谢谢点赞！
• 本文相关海量书籍下载