博览群书：谷歌软件测试之道

​

关注 BeTester ，学习更多知识

让碎片成体系，让测试更专业

1、前言

1.1 作者介绍

James Whittaker是Google的工程总监，负责Chrome产品的测试，在供职于Google之前曾在微软任职长达10年之久，在之前是一名大学教授。除了本书以外，其还著有《探索性测试》一书而被大家所认识。

1.2 谷歌的服务

谷歌是一家伟大的公司，它给我们的生活提供了无数的便利，我们的生活已经难以离开Google。
当你为工作而焦头烂额时，Google的搜索引擎可以帮你获取网络海量的知识与帮助。

当你为消遣而手足无措时，Google的Android系统可以帮助你畅享移动物互联的便利。

当你为邮箱而苦不堪言时，Google的Gmail横空出世给世人带来了眼前一亮的新鲜。

很难想象，上述所有的优质服务都来自同一家公司。并且，除此之外，还有 谷歌地图、谷歌翻译、YouTube、Chrome、Google Play、Google Drive、Waymo等一系列优质的产品给我们提供着服务。

哇，这简直不可思议。

每天Google都要测试和发布数百万个源文件，亿万行代码，数以亿计的构建动作会触发几百万磁的自动化测试，并在好几十万个浏览器实例或手机实例上执行（2012年数据）。面对这些看似不可能的任务，谷歌是如何完成的？

好奇心驱使我们想一探Google内部，探寻在如此庞然的体型下，谷歌依然保持快速、高质量提供复杂体系服务的答案？尤其作为测试从业人员，Google提供了这么多优质的产品，其测试团队规模得多大？这么大规模的团队里，不同角色之间是如何有效沟通协作？每个角色之间的职责界限如何划定？每个产品究竟如何保证产品的质量？

2、谷歌历程

在了解Google的测试历程之前，我们有必要先了解下Google的愿景与使命，以及其成立以来的关键事件。

2.1 谷歌愿景与使命

Google的愿景：To provide access to the world’s information in one click.

Google的使命：To organize the world’s information and make it universally accessible and useful.

Google的做事行为准则是拒绝邪恶的事物（Don’t be Evil）。

2.2 谷歌关键事件

1. 1998年9月，Google正式成立，创始人是Larry Page和Sergey Borin，像所有的初创公司一样，他们的办公室是在一个车库里。当时Google每天需要处理10,000次的搜索请求。
2. 1999年2月，快速扩张的Google搬到了新办公室，每天处理约50万次的搜索请求。同年，Google成为Linux软件公司Red Hat的商业客户，从此Google成为开放源代码软件的忠实用户和鼓吹者。
3. 1999年6月，硅谷最有名的两家风投巴莱纳和美洲杉向Google投资2500万美元。这标志着Google不再是一家车库公司，而是互联网浪潮中的玩家之一。
4. 2001年3月，由于两位创始人都非常注重技术，在搜索引擎上更是精益求精，傲视业界，但是在互联网惨烈的发展环境下，仅有技术是不够的，Google也面临了发展危机。Google需要更严格的结构体系，需要一位资深的管理者，Eric Schmit空降成为Google CEO。
5. 2004年2月，Google处理了万维网上80%的搜索请求，后来因为雅虎放弃Google的索索技术而有所下跌。
6. 2005年7月，Google宣布设立中国研发中心。
7. 2006年10月，Google以16亿美元收购YouTube。
8. 2007年11月，Google宣布基于Linux平台的开源操作系统名称为Android。安卓公司在2005年被谷歌收购。
9. 2008年9月，Google Map卫星升空，为Google Earth提供50厘米分辨率高清照片。
10. 2009年，Google开启自动驾驶汽车计划。
11. 2010年3月，Google宣布退出中国市场。
12. 2012年2月，Google收购摩托罗拉。
13. 2012年10月，Google市值超越微软，成为世界第二大科技公司。
14. 2014年1月，Google与通用汽车、本田、奥迪、现代和Nvidia联合成立“开放汽车联盟”，将Android系统应用于汽车领域。
15. 2015年10月，Alphabet公司成立，成为Google的母公司，Google是其最大的子公司。

Google的神奇仍在继续，让我们拭目以待。

3. 谷歌测试

每当作者被问到谷歌测试的成功秘诀是什么，他总是建议性的回答：请停止招聘测试工程师！为什么？让我们细细研究。

3.1 谷歌的测试历程

2001年，当时的谷歌约200名工程师，其中只有3名测试工程师。随着业务的增长，Alberto（现任测试总监）明显感觉当前团队已经逐步无法适应团队的需求。于是希望能够作出改变，便与其他工程师一起介绍、培训、推行单元测试，鼓励开发工程师把测试作为优先级较高的事情去做，并建议使用一些工具，如JUnit，把测试做成自动化，但是进展非常缓慢。为了坚持自己的信念，他们每周五下午都会在公司的啤酒狂欢Party（《OKR工作法》里的胜利Party）上，为一些做了测试的开发工程师颁奖。即便这样，至少引起了很多工程师的注意，也有少量的开发工程师逐步萌发了对质量的认识。

2005年，当时的谷歌有约1000名工程师，其中有50名测试工程师以及一些临时工。当时，测试团队的称谓是“测试服务”，重点工作在UI验证上，随时响应不同项目的测试需求。互联网也在爆发式增长，用户的规模和问题的复杂性给测试服务团队带来了巨大的压力。优秀的测试工程师也只能疲于奔命于多个急需救火的项目之间，让整个团队都筋疲力尽。糟糕的是，Google始终坚持项目上的快速节奏，让测试的技术债越积越多而无法脱离。

这种场景是否十分熟悉，是否与我们的工作有很大的相似性？是否普遍存在于互联网公司中？

同年，刚加入Google的Patrick（现Google测试链最顶端的男人）也在思考，是继续让测试团队沿用当前劳动密集型的方法为公司服务，还是改变整个游戏规则，让测试服务团队产生根本性变革？如果要发生变革，那么给测试工程师定位是什么？Patrick经过缜密的思考，得出结论：一个团队能够编写出高质量软件的唯一途径是全体人员共同对质量负责，包括产品经理、开发工程师、测试工程师等。达成此目的的最好方式是使测试工程师有能力将测试变成产品的一个功能，并且测试功能与真实客户感受到的任何功能同等重要。要将测试功能实现，那就需要有 与开发工程师技能相当 的测试工程师。唯一的办法就是从外部招聘具备开发能力的测试工程师？为什么不能找懂测试的开发工程师？因为这个更加困难，要改变一个人的意识形态是难于登天的。

Patrick这种想法十分前卫，身边大多数人都无法理解。开发工程师始终坚持测试是“测试工程师的职责”。甚至是测试工程师也不买账，因为很多人已经习惯当前的工作模式，让人对习惯作出任何改变都需要异常强大的力量。Patrick的主管也收到很多人对Patrick的批评与投诉，但是他主管告诉他：这里是谷歌，如果你有想法，只要不作恶，那尽管去做。

于是Patrick继续付诸行动，召集志同道合的骨干分子，继续招聘，寻找兼具开发技能与测试思维的人，必须会变成，能实现工具、平台和自动化。后来，Patrick领导的工具开发团队开发了从源代码库到编译框架，再到缺陷数据库的各种工具，测试工程师不再局限测试，他们还是发布工程师，工具开发工程师，咨询师。最然人触动的是，测试团队所完成的非测试工作对产品生产力产生了巨大的影响力。藉此机会，测试服务团队也正式改名为工程生产力团队。大家开始讨论的是生产力，而不再是测试或质量。生产力是工程生产力团队的工作，测试和质量是开发过程中每个人都要承担的工作。这意味着，开发工程师负责测试，开发负责质量，生产力团队负责帮助开发团队搞定这两项任务。

在经历了这一顿操作之后，我们来看看（2012年）Google的测试团队是怎么样一个组织架构（工程生产力部门）。与此同时，提出了“给Google提速”的口号。

3.2 谷歌的测试岗位

测试在经历了一系列改革之后，工程生产力部门应运而生，其主要任务是帮助开发更高质量地完成产品的开发 以及 让开发工程师能够更有效率地完成工作。为此，工程生产力部门设立了以下职位：

1. 资深测试总监（有且只有一人）
2. 测试总监
3. 测试工程经理（TME）
4. SET（测试开发工程师）
5. TE（测试工程师）

4、谷歌测试理念

Google的测试规模看起来违背了常理，整个公司只有非常少的专职测试工程师，甚至比竞争对手公司的单品测试工程师还少。

但是，细细探究，在通往成功的路上，Google的测试团队并非雄兵百万，而是小而精的特种部队，依靠出色的战术和高级武器。资源的匮乏，也是Google测试团队向特种部队发展的根本原因。

只有资源匮乏，才会迸发出人的创新精神，才会最大程度地提升工作的效率。

4.1 质量 不等于 测试， 质量不是被测出来的

如果测试连测试工作都没有做，如何保证软件具有很高的质量？简单的办法就是：停止开发与测试的隔离对立。开发和测试应该并肩齐驱、一体的。每写完一段代码后立刻测试这段代码，测试不是独立隔离的活动，它本身就是开发过程的一部分。这意味着 质量 更像是一种 预防行为，而不是检测。 质量是开发过程的问题，而不是测试问题。

名言：解铃还须系铃人（You build it， you break it， you fix it.）。在构建实验室的人永远不会修复构建失败的问题，只有开发工程师能够修复。

4.2 角色分工

Google测试的职责就是让其他的工程师更有效率和质量意识。测试工程师的存在就是为了让开发工程师的工作更有效率，并且很大一部分体现在避免因马虎粗心而导致的返工。

在一款Google产品中，独立贡献者主要有：

1. SWE，Software Engineer，软件开发工程师，传统上的开发角色，工作内容是实现最终用户所使用的功能代码。
2. SET，Software Engineer in Test，实质上也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。参与设计评审，近距离观察代码质量与风险。为了可测试性，甚至可以对代码进行重构，并编写单元测试框架和自动化测试框架。

SET和SWE、在代码库上是合作伙伴，相比SWE是在增加功能、性能代码，SET更关注质量提升和测试覆盖率的增加。

3. TE，Test Engineer，测试工程师，和SET关系密切。把用户始终放在第一位思考，代表用户的利益。TE组织整体质量事件，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。

测试工程师是以租借的形势进入团队的，去做提高质量相关的事情，寻找一些测试不足的地方，或者公开一些不可接受的缺陷率数据。由于测试工程师不是直接向产品团队进行汇报，因此测试团队负责人并不是简单地被告知某个项目急需发布就可以通过测试。他们有自己选择决定的优先级，在可靠性、安全性等问题上都不会妥协。这样的组织结构可以帮助保持较少的测试工程师。任何团队不能任意降低测试工程师招聘的技术要求，从而雇佣更多的测试工程师，然后让低水平的测试工程师做一些简单和琐碎的脏活累活。这些功能相关的脏活累活本应是开发工程师的工作，不能简单地扔给倒霉的测试工程师。

4.3 发布策略：爬走跑

Google在如此少量测试工程师的情况下还能取得不错成果的核心原因在于：Google从来不会在一次产品发布中包含大量功能。恰恰相反，一个产品的核心功能实现之后，就会立刻对外发布使用，然后从该用户哪里得到最真实的反馈，再进行迭代开发。

以前的产品发布，总是优先考虑的是功能的完备性和易用性，而很少考虑质量问题，测试总是在为开发让路。这也是整个行业内充斥着各种缺陷、早产产品的原因所在。产品质量不行那就再发个补丁 是很多互联网行业的潜规则。

谷歌每个产品发布都要经历完备的测试流程：金丝雀版本（DB版本）、开发版本、测试版本（内部尝鲜版本 dog food）、beta版本 和 正式发布版本。每个测试阶段全员参与质量活动中，共同为质量负责，参与到测试行动中。

4.4 测试类型

Google并没有使用 单元测试、集成测试、系统测试，而是使用 小型测试、中型测试、大型测试，甚至还有超大型测试来强调 测试的范畴规模。

小型测试：都是自动化，验证一个单独函数或独立功能模块代码是否按预期工作，着重与典型功能性问题、数据损坏、错误条件和大小差一错误。一般运行时间比较短，通农场几秒或更短的时间完成，通常由SWE完成，有少量SET参与，TE不参与。测试一般使用 mock 或 fake（mock是指对外面依赖系统的模拟，fake是一种虚假的实现，内容使用了固定的数据或逻辑，只能返回特定结果）。

中型测试也几乎都是自动化，通常涉及多个模块之间的交互。测试重点是功能相邻区之间的交互，以及彼此调用是的功能是否正确。SWE会深度参与，如果失败，SWE会自觉去查看分析原因，后期TE通过手工活自动化方式执行这些用例。

大型测试，涵盖三个以上的功能模块，使用真实用户场景和实际用户数据，一般可能需要消耗数个小时或更多来完成执行。大型测试关注的是所有模块的集成，但更倾向于结果驱动，验证软件是否满足最终用户的需求。所有工程师都会参与到大型测试中，或探索性，或自动化。

测试对象以及测试范围的大小是动态变化的，不同产品之间的区别是比较明显的。

小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告，大型测试会带来整体产品指廊和数据验证。小型、中型、大型的比例遵循 70/20/10 原则。

4.5 测试认证

测试认证是一个团队如果完成了一系类的测试任务，那么这个团队就会得到通过“认证”的标志。所有团队最初的等级都是0，如果掌握了基本的优秀代码习惯，就达到级别1，然后继续通过水平考核，最终达到级别5，类似CMMI成熟度模型。

5.1 20%时间制

Google没有规定怎样的项目才算是真正的项目，更别说规定测试工程师什么时候进入项目。因为通常来说，Google产品初期，工程师都只会投入 20% 的时间。这便是谷歌的20%时间制，没有规定怎样的项目才算是真正的项目，Google Map、Gmail和Chrome就是从这样孵化出来的。

Google认为只有软件产品变得重要的时候，质量才显得重要。如果一个产品在概念上还没有完全确定成型就去关注质量，这是优先级混乱的表现。但是，如果长期没有测试的介入，早期在可测试性设计上就很难改变，导致自动化越来越难以实施。

不过据Yahoo前CEO梅耶尔透露，20%时间制实际上让员工花费了120%的时间。因为在提倡该活动的同时，工程师们的工作并没有减少，而是在压迫工程师为工作去做更多的优化。

5、谷歌测试角色详解

5.1 SET

SET在国内叫做测试开发工程师。前面我们曾介绍过，Patrick希望测试是应用产品的一个功能，最终这个计划得以实现，而负责测试功能的责任人便是SET。

SET的工作职责：

1. 产品早期的产品开发工作。
2. 熟悉系统设计，审阅设计文档（正确性、一致性、可测试性等）。
3. 接口与协议（模板定义及mock/fake测试）。
4. 制定自动化计划并提供自动化框架服务，使得开发工程师能够在这些框架的基础之上自己写测试。
5. 测试执行，包括小型测试、中型测试和大型测试。

5.2 TE

TE的根本使命是保护用户和业务的利益，使之不受糟糕的设计、令人困惑的用户体验、功能Bug、安全和隐私问题的困扰。TE的重点在于评估对用户的影响以及软件产品整体目标上的风险。TE的工作涉及编程，但是编程只是很小一部分，实际上，在所有工程师中他们的职责范围堪称最广。

TE很少参与，甚至不参与试验性、尚无明确目标或用户故事的早期产品。因为如果产品很大可能性被取消，或者还没能吸引用户使用，或者功能还没定型，那么测试的工作一般都应该有产品的开发工程师自己完成。即便已经定型，在早期，功能不断变化，TE通常也没有太多工作可做。过早介入测试意味着资源的浪费，尤其在SET已经介入的时候。过早完成的测试产物可能会被丢弃，也可能出现更糟糕的情况。策略上讲，给一个项目配备多少测试工程师，取决于项目风险和投资回报率。

TE的职责范围：

1. 评审需求、设计、代码和测试
2. 探索性测试
3. 用户场景分析
4. 编写测试用例
5. 执行测试用例
6. 众包测试管理
7. 产品发布信息统计
8. 用户反馈与分析

TE进入项目时，需要考虑以下问题：

1. 当前软件薄弱点在哪里？
2. 有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面问题？
3. 主要用户场景是否正常？全球不同国家都这么使用么？
4. 这个产品和其他产品交互吗？
5. 当发生问题的时候，容易诊断问题所在吗？

很多Google高级测试经理都是从TE开始做起。

5.3 测试工程经理 TME

TE和SET分别致力于支持用户和开发工程师，二者看起来工作的关联性并不太大，那如何将二者关联起来呢？这时候我们需要测试工程经理。测试工程经理作为独立贡献者的一个技术岗位，负责所有的技术团队之间的联络。不仅需要具备TE和SET的技能，还要拥有足够的管理能力。

测试工程经理直接汇报给测试总监，独立贡献者（TE或SET）一般向测试工程经理汇报，而资深工程师和技术负责人一般直接汇报给他们的总监，所有总监都汇报给资深总监（Patrick Copeland）。测试工程经理需要技术能力、领导能力、协调能力，他们都是成长与内部，而不是从外部空降的，超过一半的测试工程经理之前都做过TE的工作。

要成为优秀的测试工程经理，需要具备两个素质：

1. 了解产品。
2. 知人善用。

每位工程师的个人目标都应该是建立影响力，测试团队的目标也应该建立影响力。作为技术团队之间的联络，测试工程经理更有能力通过技术、领导、协调来提升个人影响力。在Google，对员工最好的褒奖就是称赞他的影响力。对于测试工程经理来说，就是简历一支有影响力的团队。

小结

Google的测试团队的历程，可以说是互联网测试的一个缩影，但是仍有很多的互联网公司仍在Google初始阶段中挣扎。通过了解Google的测试历程人，可以让我们少走一些弯路，让我们更加向往 “别人家” 的测试，有了更多的期望。

但这并不是说Google的测试经历就是银弹，就是灵丹妙药，每个团队有自己的困境，我们需要批判性的学习其中的优秀经验。

需要特别强调的是，谷歌的测试资源匮乏的做法 并不等于是 让互联网公司一味精简测试团队规模，认为测试团队内能够自发生长成为下一个谷歌的工程生产力团队。如果如此，请让开发团队与谷歌的开发实力对齐，请让贵公司的目标与谷歌对齐。