谷歌观点：软件质量只能内建，不能外加

关注我，每天收获一个新技能!

原文来源：阿里开发者社区

乔帮主加入了一部分历史细节信息。

近期，一篇关于谷歌测试思考方式的文章在国内测试界引起了广泛关注。这激发了我对谷歌测试文化的兴趣，特别是考虑到过去十年技术与商业环境的快速变化，这种文化如何适应并发展。

本文结合了对《谷歌软件工程》和《谷歌软件测试之道》两书的阅读体会，以及个人在软件测试领域的经验，对软件质量文化进行了深入的思考。

图1：两本间隔十年的书

谷歌自1998年成立以来，市值增长显著，其商业和技术产品广受全球用户欢迎。谷歌的成功与其企业文化，尤其是软件工程文化紧密相关。测试文化作为软件工程文化的核心部分，对谷歌的持续成长起到了关键作用。

巴菲特说过，股市短期是投票器，长期是称重机。谷歌2004年上市至今，20年来市值增长40倍，截止目前总市值1.36万亿美金，位列硅谷科技公司第3名，仅次于苹果和微软。

图2：谷歌上市20年来市值变化曲线图

谷歌不仅打造了搜索、Gmail、YouTube、谷歌Earth等100+优秀的商业产品，服务了全球43亿用户，而且它创造的技术产品也是如雷贯耳，包括操作系统Android、前端编程语言Angular、编译系统Bazel、跨端开发框架Flutter、后端编程语言Go、机器学习框架TensorFlow等。

图3：谷歌核心商业与技术产品一览

在快速变化的互联网领域，谷歌早已不是一家年轻的公司。然而，谷歌成长的速度并没有随着规模的增长而变慢。从市值观察，谷歌上市后第1个十年市值增长6～7倍，第2个十年市值也是增长6～7倍。

谷歌的成功，毫无疑问跟它的企业文化有关系。但是否与它的软件工程文化有关系却不好直接评判。

然而，我们可以说，谷歌工程文化一定是谷歌文化的一部分，而测试文化是谷歌工程文化的一部分。

那么，谷歌的测试文化究竟是一种什么样的存在？在过去的十年，它变和不变的地方是什么？

谷歌测试文化的代表："马桶上的测试"

谷歌的测试文化中，"马桶上的测试"是一个标志性活动，始于2006年，通过在卫生间张贴海报的方式，宣传测试理念和方法。这一活动不仅在谷歌内部产生了深远影响，也被其他科技公司效仿。当年曾经作为新闻被华盛顿邮报报道，引起社会的关注。如今，外界早已不再关心这件事情，但是它仍然在谷歌公司运行，迄今已走过17年的历程。

什么是“马桶上的测试”？它是一张不定期更新的海报，张贴在谷歌全球各个办公区卫生间的马桶旁边。

这是谷歌公司早期一群对软件测试抱有极大热情的志愿者(内部称为测试小分队，Testing Grouplet)发起的，一个旨在宣传、鼓励和帮助谷歌工程师(主要是开发工程师)更好开展测试的文化活动。

海报内容从测试理念、方法、技术、工具、实践，到测试的上下游工作，包括静态分析、代码评审、代码覆盖等，可以说囊括了软件测试与质量的方方面面，并且内容生动、引人关注。

持续交付2.0 注：在国内很多大厂看到的可能更多的是自家产品广告。另外，也不好说它的作用到底有多大，可能有相关性，但应该没有直接的因果关系。企业文化是一个复杂问题。

质量变革的核心：开发工程师的测试责任

谷歌测试小分队的先驱们很早就意识到一个常识：软件质量只能内建，不能外加。

谷歌的测试先驱们推动开发工程师承担主要测试工作，而非简单增加测试工程师数量。

测试文化的变革，不管在认知层面还是在组织层面，这都堪称是一场革命，其推进难度之大、阻力之巨可想而知。仅靠“马桶上的测试”海报对于测试文化的宣扬，显然不足以支撑这一目标的达成。"测试认证"项目应运而生，通过定义测试成熟度标准和提供操作指南，帮助产品和项目提升质量。

“测试认证”同样持续了十几年时间，成为谷歌测试文化的一部分。

持续交付2.0 注：《谷歌软件工程》中，并没有写谷歌公司在这一过程中所经历的痛苦，更多是描述了当年（2020年）在公司中软件工程管理的现状。

什么是“测试认证”项目呢？概括地说，它定义了一套度量项目测试成熟度的标准，并且更重要的是，提供了测试成熟度从低等级往高等级跃迁的操作指导。

“测试认证”有着明确的度量标准，这看起来似乎是一件非常适合借助管理层行政命令在各个研发团队强制推动落地的事情。毕竟这样做可以在短期内快速落地、看到结果。

然而，在经过深思熟虑后，他们主动放弃了这样的想法。他们意识到，这样的想法不仅与谷歌的企业文化不匹配，而且更重要的是，不利于“测试认证”项目的长期成功。当然，这个认证的确受到了官方的默认，而且，很多工程技术经理为在其工作总结中提及其在团队进行的相关工作及成果。

于是他们采取了很多动作，包括：选择测试意识较高的团队优先试点、全程的教练支持、及时的鼓励和赞美、降低入门等级的达成门槛(先入门再提高)、趣味性十足的宣传等。在谷歌的事实证明，“测试认证”项目的发起人当初的决定在谷歌公司是正确的。

当然，这个过程中，也有瓶颈期。因为，任何事物都逃不过经典的钟型曲线。

在最初期，很快有十多个工程团队参与了这个认证，他们积极地申请测试雇佣兵到团队帮助他们建立基本的测试基础设施（例如，搭建持续集成服务，帮助编写测试脚手架，培训自动化测试框架的使用等）。

然而，参与的团队数量还没有过百（谷歌的工程团队都比较小，当时这样的小团队有近千个），他们就遇到了瓶颈。他们也通过各种渠道获得了公司的支持。

图5：谷歌“测试认证”项目关于测试成熟度的5层定义

注意到，2017年开始，谷歌内部将“测试认证”已升级成了“项目健康度量”，

链接如下：

《谷歌PH值：软件项目的健康度度量》。其关注的指标从项目质量扩展到了项目健康度，内涵更丰富。

根据金字塔理论，软件测试被划分为单元测试、集成测试和系统测试等有着不同目的和特点的类型。

金字塔模型认为：不同类型测试用例的大致比例应该符合金字塔结构，即最底层的单元测试占比最多，中间的集成测试其次，最上层的系统测试最少。与测试金字塔模型形成对立的，有冰淇淋模型、沙漏模型、纺锤模型、奖杯模型等。各种模型的本质，是在不同特点的测试类型之间寻找一个平衡，目的是用尽可能低的成本达成尽可能高的质量。

测试金字塔理论建立在软件测试的一个基本共识之上：BUG发现得越早，其解决的成本越低。

下面关于谷歌使用的测试金字塔的内容截选自《持续交付2.0》第十章：自动化测试策略与方法。

为什么是金字塔，为什么下面是70%。谷歌总是鼓励工程师尽可能地缩小用例尺度，编写范围较小的测试。

通常来说，如果还没有建设自动化测试用例集的公司，从短期来看，端到端的大型测试用例，无疑是更能证明软件是否正常工作，从而达到立竿见影的测试效果。但是，大型测试用例在执行效率、维护成本、稳定性等方面的固有劣势，对于长期测试结果与质量目标的达成是不利的。

谷歌的测试金字塔基本等同于自动化金字塔，尤其是对于后台服务来说，更是这样。并且，绝大多数自动化用例(如果不是全部的话)是由开发工程师编写和维护的，因为大多数自动化用例都是小型测试用例，相当于单元测试级别。

开发工程师驱动的自动化测试，是谷歌测试文化的核心内容。

创新驱动的自动化测试

在谷歌，开发者驱动的自动化测试早已与软件开发流程深度融合在一起。

从代码提交前、提交后到发布前，在开发流程的各个关键节点，海量自动化测试不知疲倦地运行着。

由于谷歌采取的是单一代码仓和主干开发模式，成熟的自动化覆盖叠加海量的自动化执行，所构成的“谷歌规模”的自动化测试，面临着史无前例的技术挑战，包括：

1) 效率挑战：开发工程师的时间是非常贵的，自动化测试如何在尽可能短的时间内给予工程师质量结果反馈？

2) 稳定性挑战：自动化规模扩大时，用例不稳定性(Test Flakiness)成为挥之不去的噩梦，如何克服或减轻不稳定性用例的影响？

3) 有效性挑战：自动化用例是否能够真正覆盖逻辑、检测缺陷，发挥它应该发挥的价值？

这里，用几个简单的数据，说明“谷歌规模”的自动化测试复杂度有多高：2.5w名开发工作在同一代码库，每天产生4w次代码提交，改动一个文件最多要执行420w个测试用例，总共556w个用例中有4.7w个不稳定用例。为了克服这些挑战，谷歌进行了大量技术创新。过去十年，谷歌在软件工程学科的顶级会议/期刊上，发表的关于软件测试的部分高引用论文列表如下：

测试文化的传承与变革

“马桶上的测试”、“测试认证”、开发工程师驱动的自动化测试金字塔、浓郁的测试技术创新氛围，共同构成了谷歌测试文化的核心。当然，这些不是谷歌测试文化的全部，其他测试文化还有：面向谷歌新员工的测试培训课程、从2007年至今更新不断(尽管更新频率显著降低)的谷歌测试博客(https://testing.googleblog.com)等。

“饮水思源”，那些发起“马桶上的测试”、“测试认证”等文化活动，至今仍然深刻影响每一个谷歌工程师的测试小分队的先驱们，是应当被大家认识和铭记的。

为此，我调研了一下谷歌早期测试先驱们的近况，结果发现他们大部分都已经离开了谷歌。

图9：那些离开谷歌的测试先驱们

测试小分队早期核心人物Mike Bland在个人博客中骄傲地写道：我们改变了这家改变世界的公司。We changed the company that changed the world。

他在离开谷歌后，也曾加入过苹果公司。在苹果，他组织和发起了苹果质量文化倡议(Apple Quality Culture Initiative)活动，改变了苹果的软件质量文化。

图10：大同小异的谷歌质量文化与苹果质量文化

随着开发工程师逐渐承担更多测试工作，测试工程师的职业发展面临挑战。在谷歌，测试开发工程师(SET)和测试工程师(TE)的角色发生了转变，SET转向开发测试工具和基础设施，而TE慢慢脱离具体的测试设计和执行，成为专家型或管理型角色。当然，人数上也少了很多。

TE，作为专家角色，测试工程师与开发工程师密切协作，制定测试策略、识别和解决可测性挑战。

TE ，作为组织者角色，测试工程师通过管理和驱动内部用户、外包测试、众包测试、早期尝鲜用户等低成本的测试资源来来完成测试工作。

SET和Testing的关系越来越小，本质上成为了开发工程师。SET不仅开发测试工具，而且也开发所有推动软件工程生产效率提升的生产力工具。显然，SET的职位名称已经过时了。

2016年，谷歌针对所有SET发起了一项调查，让他们选择一个新的岗位名称。结果有91%的SET选择了新的名称：Software Engineer, Tools & Infrastructure，SETI。“Testing”不复存在。

就像《COOL to be a TE @ Google，2020》一文中总结的，

https://testing.googleblog.com/2020/05/cool-to-be-te-google.html

谷歌测试工程师的核心特质变成了4点：

1. 持续的学习者(Constant learner)，

2. 打破常规的思考者(Out-of-box thinker)，

3. 编排者(Orchestrator)

4. 前沿的用户(Leading-edge user)。

质量文化的争议与前行

即使是通过激发内在兴趣来驱动开发工程师做测试，在谷歌质量文化落地的过程中，各种争议仍然无处不在的、甚至至今还在继续。

微观层面的争议，既有：“我没有时间做测试”、“写测试会让我的开发速度变慢”、“我想写测试但是组织是否认可写测试的价值”、“我的代码很难进行测试”、“测试代码对用户不可见，为什么要投入时间去写”，也有：“100%的代码覆盖率不能说明代码没有问题，为什么还要提升代码覆盖率”、“既然我写再多测试也不能避免不发生问题，那我还要写更多测试吗”？

宏观层面的争议，既有：“考虑自动化测试的维护成本，ROI值吗？”、“测试需要做到什么程度，产品质量才能好？”，也有：“加强质量工作，是否意味着更高的成本投入？”、“加强质量工作，是否会让团队交付效率变慢？”。

对于种种争议，谷歌的测试先驱们的态度是：坦然面对争议，但是坚持“质量是一件正确的事情”的基本价值判断。既然是正确的事情，应该做的事情，那么做就行了。

国内测试文化的发展趋势

可以说，谷歌的质量文化基本上代表了硅谷的质量文化。公开的资料显示，亚马逊、苹果、Facebook等科技公司，其质量文化与谷歌是类似的。

即使是曾经作为传统测试文化代表的微软公司，也已经针对测试进行了重大变革，越来越向谷歌模式靠近。

参见以下文章：

《微软：测试左移，更快、更可靠》

《微软：测试右移，Test in Production》

《微软承认了在软件测试方面的失误》

当然，微软在转型过程发生了诸如win10质量下滑这样的负向事件。但是，转型的趋势已不可逆转。

客观来说，由于测试是上下文依赖的(软件测试的基本原则之一)，就像世界上没有两片相同的树叶，世界上没有两个产品能够采取完全相同的测试策略。

当大家都会面临着一个共同的挑战，那就是怎样推动测试左移，从源头上把质量做好。要攻克这个挑战，测试工程师思考的问题，需要从“术”的层面，上升到“道”的层面。

帮主说：“道无术，术可得；术无道，术止步”

因为，我们要解决的不再是测试策略、测试能力、测试工具的问题，而是测试文化的问题。

业务的不同，必然会带来保障体系的差异化。但是，从宏观层面看，面向不同业务的质量工程体系应当有一个通用的框架。于是，作者产生了质量金字塔(Quality Pyramid，区别于测试金字塔 Test Pyramid)的构想，其由3层组成。

图11：质量金字塔示意图

持续交付2.0 作者注：在上图中，我对“质量文化”的位置持保留意见。因为所谓的文化意识与价值都是无形的，可以感知，但无法直接落地。文化是一种组织人员之间互动的结果，却不是互动的机制本身。这里应该参考《持续交付2.0》一书的第四章：四步构建组织文化，将其替换成组织机制，也就是组织架构与管理机制。

最上层：线上质量，包含稳定性、安全生产、用户体验相关工作；这是质量领域可见度最高的工作。任何线上问题都可能引发广泛关注；一个严重线上故障，甚至可能引发新闻舆情，对产品甚至公司未来产生重大影响。

中间层：这一层是为了尽可能避免(无法绝对避免)线上问题发生，这也是测试的中心目的。它由2部分组成：开发工程师驱动的质量内建和测试工程师驱动的质量防护网。绝大部分质量问题应该在质量内建阶段发现和解决，质量防护网致力于发现那些在质量内建阶段难以发现的问题。注意到，中间层工作涉及测试与开发两个工种的深度协同。

最底层：质量流程、质量工具、质量文化，3部分共同构成质量工作的基石。质量流程相对容易建立，只要流程各方达成一致、按照规则执行就行了。质量工具有开源产品可以利用，即使要自研，投入资源短期内也能搞定。唯独质量文化的建立与坚持，非一朝一夕之功。

毕竟，质量文化不是孤立的，而是工程文化、企业文化的一部分。谈到质量文化，我不禁起来贵州茅台公司的“四个服从”：当产量与质量发生矛盾时，产量服从质量；当成本与质量发生矛盾时，成本服从质量；当效益与质量发生矛盾时，效益服从质量；当速度与质量发生矛盾时，速度服从质量。

软件测试从来都不是一件在聚光灯下的工作，但是它对产品有益，对用户有益，是一件正确的事情。

感谢谷歌为我们探索了一条“把软件测试这件正确的事情做正确”的有效路径。路径的核心不是惊世骇俗的测试理论、炫酷的测试工具、让人膜拜的测试论文，而是卓越的、可持续的、工程师自驱的软件质量文化。

参考资料：《谷歌软件测试之道，2013》，《谷歌软件工程， 2022》，谷歌测试博客testing.google.com等。