0 缘起
前段时间，一篇题为《谷歌资深工程师讲述谷歌如何思考测试》的博文在国内测试圈广泛流传，引起了我的关注。
我特意去调查了一下这篇文章的背景，发现它实在是新书《谷歌软件工程》(2022)的一个章节，于是果断下单了一本。
当拿到这本书时，我不禁想起从前买过的另一本书，2013年由3位阿里测试先辈翻译出版、至今仍在测试圈产生广泛影响的《谷歌软件测试之道》。
这两本书出版的时间差不多隔断十年。
在把这两本书摆在一起时，我产生了强烈的好奇：过去十年，不管商业领域、技能领域还是测试领域都发生了很大的厘革。
那么，对于谷歌测试，尤其是它最焦点的测试文化来说，变与稳定的地方在哪里？背后的原因是什么？对我们有什么启示？
时间最好的试金石。是啊，十年是一个充足长的时间跨度。
一件错误的事情，很难坚持十年(而不被众人发现、挑战、抛弃)；能坚持十年的事情，大概率是正确的事情(能产生恒久价值)。
这篇文章，就是我在阅读上述2本书之后，并联合自己8年的测试职业经历和5年的测试公众号运营经历，对于软件测试文化(或质量文化，两个词语含义略有差异，在本文范围内等价)这个我以为很紧张但国内测试圈探讨并不多的话题，所产生的心得体会。
本日禀享给各人，接待对软件质量文化感兴趣的朋友们一起交换、指正。
1 谷歌这十年
只管谷歌是个家喻户晓的公司，但是我以为在进入正文之前，有必要简要介绍一下谷歌的基本情况，尤其是过去十年的发展情况。
谷歌成立于1998年，已有25年汗青。由于宏观经济与市场环境的影响，用市值或股价来衡量一家公司不是一个好主意。
但是巴菲特说过，股市短期是投票器，恒久是称重机。
谷歌2004年上市至今，20年来市值增长40倍，截止目前总市值1.36万亿美金，位列硅谷科技公司第3名，仅次于苹果和微软。
图1：谷歌上市20年来市值厘革曲线图
谷歌不仅打造了搜索、Gmail、YouTube、谷歌Earth等100+优秀的商业产物，服务了环球43亿用户，而且它创造的技能产物也是如雷贯耳，包罗操作体系Android、前端编程语言Angular、编译体系Bazel、跨端开发框架Flutter、后端编程语言Go、机器学习框架TensorFlow等。
图2：谷歌焦点商业与技能产物一览
在快速厘革的互联网领域，谷歌早已不是一家年轻的公司。
然而，风趣的是，谷歌成长的速率并没有随着规模的增长而变慢。
例如，从市值观察，谷歌上市后第1个十年市值增长6～7倍，第2个十年市值也是增长6～7倍。
“大象在起舞，巨人在成长”。
谷歌的成功，毫无疑问跟它的企业文化尤其是软件工程文化有很大关系。
那么作为谷歌工程文化的组成部分，谷歌的测试文化毕竟是一种什么样的存在？在过去的十年，它变和稳定的地方是什么？
2 一个持续17年的活动
说到谷歌代表性的测试文化，不能不提的一张名片就是“Testing on the toilet”，即“马桶上的测试”。
这是谷歌公司早期一群对软件测试抱有极大热情的志愿者(内部称为测试小分队，Testing Grouplet)发起的，一个旨在宣传、鼓励和帮助谷歌工程师(主要是开发工程师)更好开展测试的文化活动。
活动创始于2006年，当年曾经作为消息被华盛顿邮报报道，引起社会的关注。
现在，外界早已不再关心这件事情，但是它仍然在谷歌公司运行，迄今已走过17年的进程。
什么是“马桶上的测试”？它是一张不定期更新的海报，张贴在谷歌环球各个办公区卫生间的马桶旁边。
海报内容从测试理念、方法、技能、工具、实践，到测试的上下游工作，包罗静态分析、代码评审、代码覆盖等，可以说席卷了软件测试与质量的方方面面，并且内容生动、引人关注。
在测试小分队的先驱们看来，卫生间是工程师们每天至少要去一次的地方，并且上卫生间的这段时间，工程师的留意力更容易被捕捉。
因此，在卫生间张贴的海报，成为一个宣传测试的绝佳场所，能够最大程度上实现对目的读者的有效覆盖。
“马桶上的测试”海报，从最初的志愿者编写到厥后的谷歌工程师自动投稿，成功地从一个想法酿成了持续17年的活动。
在潜移默化中，它改变了谷歌的测试氛围，影响了几代谷歌工程师，成为谷歌测试文化历久弥新的最好见证。
同时，这个活动也在业界产生影响，被其他科技公司纷纷效仿。
图3：马桶上的宣传 (a) 谷歌测试海报 (b) 阿里“杰出工程”小贴士
3 质量厘革的焦点抓手
谷歌测试小分队的先驱们很早就意识到一个知识：软件质量只能内建，不能外加。
因此，他们确定了积极方向，通过让开发工程师承担主要的测试工作(而不是增加测试工程师的数目)来提升软件质量。
不管在认知层面还是在组织层面，这都堪称是一场革命，其推进难度之大、阻力之巨可想而知。
仅靠“马桶上的测试”海报对于测试文化的宣扬，显然不敷以支持这一目的的告竣。
如果说海报只是激发开发工程师开展测试的想法，那么当他们真正想要进行测试时，其必要的是一套可执行的操作指南。
在谷歌，“测试认证”(Test Certified)项目，承担的就是这个职责。
是的，就是这个名字很不起眼的项目，帮助了谷歌内部无数产物和项目改善了质量。
与“马桶上的测试”一样，“测试认证”同样持续了十几年时间，成为谷歌测试文化的一部分。
什么是“测试认证”项目呢？概括地说，它界说了一套度量项目测试成熟度的标准，并且更紧张的是，提供了测试成熟度从低等级往高等级跃迁的操作指导。
留意到，“测试项目”有着明确的度量标准，这看起来似乎是一件非常适合借助管理层行政下令在各个研发团队强制推动落地的事情。
简直，项目的发起人(即测试小分队的先驱们)一开始也有这样的想法，毕竟这样做可以在短期内快速落地、看到效果。
然而，在经过深思熟虑后，他们自动放弃了这样的想法。
他们意识到，这样的想法不仅与谷歌的企业文化不匹配，而且更紧张的是，倒霉于“测试认证”项目的恒久成功。
欺压工程师做测试，这不是一件可持续的事情。
如果工程师真正担当了这个想法，他们会自己决定要做测试，纵然在没有人欺压或监视他们的情况下，也能继续做正确的事。
项目发起人信赖，好的想法会被担当，成功的故事会传播，因此重点在于展示成功。
于是他们采取了许多动作，包罗：选择测试意识较高的团队优先试点、全程的锻练支持、及时的鼓励和称赞、低落入门等级的告竣门槛(先入门再提高)、意见意义性十足的宣传等。
事实证明，“测试认证”项目的发起人当初的决定是正确的。
这个项目在没有行政下令推动下，通过项目成员的积极，从“星星之火”渐成“燎原之势”，累计促成1500多个产物团队接入该项目并从中受益。
这里，附上谷歌“测试认证”项目对测试成熟度的5级模子界说，仅供参考。
图4：谷歌“测试认证”项目关于测试成熟度的5层界说
留意到，最近谷歌内部将“测试认证”升级成了“项目康健度量”，关注的指标从项目质量扩展到了项目康健度，内涵更丰富。
4 对尺度保持警惕
在测试领域，测试金字塔理论几乎无人不知。
根据金字塔理论，软件测试被划分为单位测试、集成测试和体系测试等有着不同目的和特点的类型。
金字塔模子以为：不同类型测试用例的大致比例应该符合金字塔结构，即最底层的单位测试占比最多，中心的集成测试其次，最上层的体系测试最少。
与测试金字塔模子形成对立的，有冰淇淋模子、沙漏模子、纺锤模子、奖杯模子等。
图5：各种测试分层模子对比
测试金字塔理论创建在软件测试的一个基本知识之上：BUG发现得越早，其解决的本钱越低。
因此，我们应该将测试资源尽可能地向软件开发的早期阶段倾斜。
金字塔的本质，是在不同特点的测试类型之间探求一个平衡，目的是用尽可能低的本钱告竣尽可能高的质量。
与大部分公司一样，金字塔模子同样是指导谷歌大部分测试工作的黄金法则。所不同的是，谷歌的表达方式略有差异。
在谷歌，使用小型测试、中型测试和大型测试来分别描述一样平常意义上的单位测试、集成测试和体系测试。
我们知道，单位测试、集成测试和体系测试作为完全不同的测试类型，其差异之处是方方面面的，而用例的尺度只是浩繁差异之一。
图6：三种类型(小型测试、中型测试和大型测试)测试的全面临比
为什么谷歌特殊夸大用例尺度这个差异，有其深刻背景。
作为谷歌特色的金字塔模子，其在夸大用例分布比例的同时(作为指导原则，一个项目的测试用例由80%的小型测试 + 15%的中型测试 + 5%的大型测试组成)，对扩大用例尺度的行为保持警惕。
换句话说，它总是鼓励工程师尽可能地缩小用例尺度，编写范围较小的测试。
从短期来看，端到端的大型测试用例，无疑更能证明软件是否工作，从而到达立竿见影的测试效果。
但是，大型测试用例在执行效率、维护本钱、稳定性等方面的固有劣势，对于恒久测试效果与质量目的的告竣是倒霉的。
关于测试金字塔，谷歌的别的一个特殊之处是：谷歌的测试金字塔基本等同于自动化金字塔(谷歌总是尽可能地将每个测试用例自动化)，并且，绝大多数自动化用例(如果不是全部的话)是由开发工程师编写和维护的。
开发工程师驱动的自动化测试，是谷歌测试文化的焦点内容。
5 创新不止
在谷歌，开发者驱动的自动化测试早已与软件开发流程深度融合在一起。
从代码提交前、提交后到发布前，在开发流程的各个关键节点，海量自动化测试不知疲倦地运行着。
由于谷歌采取的是单一代码仓和主干开发模式，成熟的自动化覆盖叠加海量的自动化执行，所构成的“谷歌规模”的自动化测试，面临着史无前例的技能挑战，包罗：
1) 效率挑战：开发工程师的时间是非常贵的，自动化测试如何在尽可能短的时间内给予工程师质量效果反馈？
2) 稳定性挑战：自动化规模扩大时，用例不稳定性(Test Flakiness)成为挥之不去的噩梦，如何降服或减轻不稳定性用例的影响？
3) 有效性挑战：自动化用例是否能够真正覆盖逻辑、检测缺陷，发挥它应该发挥的价值？
这里，用几个简单的数据，说明“谷歌规模”的自动化测试复杂度有多高：2.5w名开发工作在同一代码库，每天产生4w次代码提交，改动一个文件最多要执行420w个测试用例，总共556w个用例中有4.7w个不稳定用例。
为了降服这些挑战，谷歌进行了大量技能创新。
过去十年，谷歌在软件工程学科的顶级会议/期刊上，发表的关于软件测试的部分高引用论文列表如下：
图6：谷歌过去十年在测试领域发表的高引论文列表(部分)
面向大规模自动化测试效率、稳定性、有效性的技能创新研究，也是谷歌测试文化的一部分。
6 那些离开的先驱们
“马桶上的测试”、“测试认证”、开发工程师驱动的自动化测试金字塔、浓厚的测试技能创新氛围，共同构成了谷歌测试文化的焦点。
当然，这些不是谷歌测试文化的全部，其他测试文化还有：面向谷歌新员工的测试培训课程、从2007年至今更新不停(只管更新频率明显低落)的谷歌测试博客(https://testing.googleblog.com)等。
谷歌测试文化的传承和连续，与每一个谷歌工程师的坚持与积极密不可分。
但是，“饮水思源”，那些发起“马桶上的测试”、“测试认证”等文化活动，至今仍然深刻影响每一个谷歌工程师的测试小分队的先驱们，是应当被各人熟悉和铭记的。
为此，我调研了一下谷歌早期测试先驱们的近况，效果发现他们大部分都已经离开了谷歌。
图7：那些离开谷歌的测试先驱们
这些离开谷歌的测试先驱们，许多都去了硅谷其他的科技公司，并且将谷歌的测试经验和文化带了过去。
从某种程度上可以说，他们将谷歌测试文化发扬光大，形成了硅谷测试文化。
测试小分队早期焦点人物Mike Bland在离开谷歌时，在个人博客中骄傲地写道：我们改变了这家改变天下的公司。
We changed the company that changed the world。
他厥后参加了苹果公司。在苹果，他组织和发起了苹果质量文化倡议(Apple Quality Culture Initiative)活动，改变了苹果的软件质量文化。
图8：大同小异的谷歌测试文化与苹果测试文化
7 测试职业厘革
谷歌测试文化的巨大厘革，在繁荣开发者测试的同时，也给测试工程师的职业发展带来了很大的冲击。
在谷歌，名称中带有“测试”的岗位有两种：测试开发工程师(Software Engineer in Test, SET)和测试工程师(Test Engineer, TE)。
随着开发工程师徐徐承担主要甚至全部的测试工作，以及DevOps、CI/CD、灰度发布、众包等软件开发与交付模式的厘革，SET和TE的工作职责也在不可避免地发生厘革。
SET不再负责功能/产物相关的自动化用例的开发，而是聚焦在自动化测试工具和基础设施的开发。
SET和测试的关系越来越小，本质上成为了开发工程师。SET不仅开发测试工具，而且也开发全部推动软件工程生产效率提升的生产力工具。
显然，SET的职位名称已经过时了。2016年，谷歌针对全部SET发起了一项调查，让他们选择一个新的岗位名称。效果有91%的SET选择了新的名称：Software Engineer, Tools & Infrastructure，SETI。
“Testing”不复存在。
TE的工作则渐渐脱离具体的测试设计和执行，而酿成了专家型大概管理型的角色。
就像《COOL to be a TE @ Google，2020》一文中总结的，谷歌测试工程师的焦点特质酿成了4点：持续的学习者(Constant learner)，冲破通例的思考者(Out-of-box thinker)，编排者(Orchestrator)和前沿的用户(Leading-edge user)。
一方面，作为专家角色，测试工程师与开发工程师密切协作，订定测试战略、识别息争决可测性挑战。
另一方面，作为组织者角色，测试工程师通过管理和驱动内部用户、外包测试、众包测试、早期尝鲜用户等低本钱的测试资源来来完成测试工作。
作为专家大概组织者的测试工程师，显然不再必要保持从前那样的数目了。
SET和TE职业岗位的变迁，是以“开发者驱动的测试”为焦点的质量文化在谷歌落地生根、枝繁叶茂的自然效果。
8 在争议中前行
纵然是通过激发内涵兴趣而不是采取强制下令来驱动开发工程师做测试，在谷歌质量文化落地的过程中，各种争议仍然无处不在的、甚至至今还在继续。
微观层面的争议，既有：“我没有时间做测试”、“写测试会让我的开发速率变慢”、“我想写测试但是组织是否承认写测试的价值”、“我的代码很难进行测试”、“测试代码对用户不可见，为什么要投入时间去写”，
也有：“100%的代码覆盖率不能说明代码没有题目，为什么还要提升代码覆盖率”、“既然我写再多测试也不能避免不发生题目，那我还要写更多测试吗”？
宏观层面的争议，既有：“考虑自动化测试的维护本钱，ROI值吗？”、“测试必要做到什么程度，产物质量才能好？”，
也有：“加强质量工作，是否意味着更高的本钱投入？”、“加强质量工作，是否会让团队交付效率变慢？”。
类似的争议，不仅在谷歌存在，在其他公司也是存在的。
关于测试或质量工作，之以是会存在这么多的争议，与软件质量的一些特质有关：质量可见性不敷、没有完美的质量、质量好坏缺乏一致的度量、质量投入和效果显现的恒久性。
对于种种争议，谷歌的测试先驱们的态度是：坦然面临争议，但是坚持“质量是一件正确的事情”的基本价值判断。
既然是正确的事情，应该做的事情，那么做就行了。
9 Where we are
至此，本文介绍了谷歌的质量文化是什么样的，怎么创建质量文化，以及过去十年谷歌质量文化的厘革。
可以说，谷歌的质量文化基本上代表了硅谷的质量文化。
公开的资料表现，亚马逊、苹果、Facebook等科技公司，其质量文化与谷歌是类似的。
纵然是曾经作为传统测试文化代表的微软公司，也已经针对测试进行了庞大厘革，越来越向谷歌模式靠近。
当然，微软在转型过程发生了诸如win10质量下滑这样的负向变乱。但是，转型的趋势已不可逆转。
坦白说，我自己并没有在硅谷工作过，了解到的关于谷歌大概硅谷测试的统统，都是来源于公开资料。
只管如此，根据自己8年的测试职业经历和5年的测试技能公众号运营经历，以及与许多测试偕行直接大概间接的交换，整体感受是：国内测试也在受到硅谷测试文化的影响。
一个大的趋势是，开发工程师越来越多地承担测试工作，而测试工程师的职业发展则面临着挑战。
不同公司、不同产物、不同团队，厘革的节奏有差异，但是厘革的方向趋于一致。
客观来说，由于测试是上下文依靠的(软件测试的基本原则之一)，就像天下上没有两片相同的树叶，天下上没有两个产物能够采取完全相同的测试战略。
积极的一面是，我们看到测试团队紧贴业务实际，建设了符合业务特点和发展近况的质量保障体系、能力和工具，贡献了测试人应该贡献的价值。
在我所经历的每个测试团队，不管是通信、云计算还是电商行业，不管测开比是1:3、1:10还是1:30，不管是中央化的质量团队还是分散到业务的质量小团队。
各人都在客观条件(包罗管理层对质量的重视度、开发的质量意识、测试资源、项目交付压力)的束缚下，围绕用更高效率、更低本钱发现更多BUG的目的，积极工作。
但是，当各人希望软件质量发生根天性好转(多数情况)、大概让质量水平更上一层楼(少数情况)的时间，都碰面临着一个共同的挑战，那就是怎样推动测试左移，从源头上把质量做好。
要攻克这个挑战，测试工程师思考的题目，必要从“术”的层面，上升到“道”的层面。
因为，我们要解决的不再是测试战略、测试能力、测试工具的题目，而是测试文化的题目。
10 文化是根本
最近我在思考一个题目，如果接办一个自己完全不熟悉的业务，该如何建设相应的质量工程体系？
业务的不同，必然会带来保障体系的差异化。但是，从宏观层面看，面向不同业务的质量工程体系应当有一个通用的框架。
于是，我产生了质量金字塔(Quality Pyramid，区别于测试金字塔 Test Pyramid)的构想，其由3层组成。
图9：质量金字塔示意图
最上层：线上质量，包含稳定性、安全生产、用户体验相关工作；这是质量领域可见度最高的工作。
任何线上题目都可能引发广泛关注；一个严峻线上故障，甚至可能引发消息舆情，对产物甚至公司未来产生庞大影响。
中心层：这一层是为了尽可能避免(无法绝对避免)线上题目发生，这也是测试的中央目的。
它由2部分组成：开发工程师驱动的质量内建和测试工程师驱动的质量防护网。
绝大部分质量题目应该在质量内建阶段发现息争决，质量防护网致力于发现那些在质量内建阶段难以发现的题目。
留意到，中心层工作涉及测试与开发两个工种的深度协同。
最底层：质量流程、质量工具、质量文化，3部分共同构成质量工作的基石。
质量流程相对容易创建，只要流程各方告竣一致、按照规则执行就行了。
质量工具有开源产物可以利用，纵然要自研，投入资源短期内也能搞定。
唯独质量文化的创建与坚持，非一朝一夕之功。
毕竟，质量文化不是孤立的，而是工程文化、企业文化的一部分。
谈到质量文化，我不禁起来贵州茅台公司的“四个服从”：
当产量与质量发生矛盾时，产量服从质量；
当本钱与质量发生矛盾时，本钱服从质量；
当效益与质量发生矛盾时，效益服从质量；
当速率与质量发生矛盾时，速率服从质量。
茅台酒做的百年生意，它对质量文化的要求果然不一样平常。
相反，如果一个公司做的是“昙花一现”的生意、开发的是“没有生命力”的产物，那么谈论质量文化，大概说投入资源去搞质量工作，又有什么意义？
因此，我们建设质量文化有一个大的前提：质量攸关产物的前途命运、各人对质量愿景有共识并期望把质量工作做好。
11 结语
软件测试从来都不是一件在聚光灯下的工作，但是它对产物有益，对用户有益，是一件正确的事情。
感谢谷歌为我们探索了一条“把软件测试这件正确的事情做正确”的有效路径。
路径的焦点不是惊世骇俗的测试理论、炫酷的测试工具、让人敬拜的测试论文，而是杰出的、可持续的、工程师自驱的软件质量文化。
末了，以一句话结束本文。
打造经过一两代工程师仍然屹立不倒的质量文化，是质量领域最难的工作，值得每一个测试人为之奋斗。
与各人共勉！
末了： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果必要可以自行免费领取【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
