《Google软件测试之道》是一本很有名的书，作者是Google的两位测试专家James A. Whittaker、Jason Arbon和Jeff Carollo。这本书详细介绍了Google是如何做软件测试的，里面有很多理念和实践，对整个软件测试行业都产生了深远的影响。

但这本书内容比较多，而且有很多Google内部的具体案例，全部读完需要不少时间。这篇文章，我想帮大家梳理一下这本书的核心观点，用三分钟的时间，让你快速掌握这本书的精华。

Google的测试理念

Google的测试理念和传统的软件测试有很大的不同。

传统的软件测试，通常是开发写完代码，然后交给测试团队去测，测试团队找bug，开发团队修bug，这是一个分离的、串行的过程。但Google不这么做。

Google的核心理念是：测试不是测试团队的事，而是所有人的事。开发人员要对自己的代码质量负责，要自己写单元测试，自己做测试。测试人员不是守门员，而是推动者和赋能者，他们的工作是帮助开发人员更好地测试，而不是代替开发人员测试。

这个理念的背后，是Google对质量的理解。Google认为，质量不是测出来的，而是开发出来的。如果代码本身写得不好，再怎么测也很难保证质量。只有让开发人员从一开始就重视质量，自己写测试，自己保证代码质量，才能真正做出高质量的软件。

所以在Google，开发人员写的代码，如果没有单元测试，是不能提交的。代码审查的时候，测试代码和业务代码一样重要，甚至更重要。这种文化，让质量内建到了开发过程中，而不是靠后期的测试来保证。

测试角色：SET和TE

Google的测试团队有两个主要角色：软件测试开发工程师（SET）和测试工程师（TE）。

SET（Software Engineer in Test），本质上是开发工程师，只是他们的工作是写测试相关的代码。他们会开发测试框架、测试工具、自动化测试脚本，帮助开发人员更容易地写测试。SET的代码能力很强，他们和开发工程师用同样的标准，写同样质量的代码。

TE（Test Engineer），是传统意义上的测试工程师，但他们的工作不是手动点来点去找bug，而是设计测试策略、分析风险、编写测试用例、探索性测试。TE更关注用户视角，关注产品的整体质量，关注那些自动化测试覆盖不到的地方。

这两个角色的分工很明确：SET负责让测试变得容易，TE负责让测试变得有效。SET写工具和框架，TE用这些工具和框架来做测试。两者配合，共同保证产品质量。

但要注意的是，不管是SET还是TE，都不是产品质量的最终负责人。产品质量的最终负责人是开发团队。SET和TE只是帮助开发团队更好地保证质量，而不是代替开发团队承担质量责任。

测试策略：小型、中型、大型测试

Google把测试分成了三类：小型测试、中型测试和大型测试。

小型测试，就是我们通常说的单元测试。它测试的是一个函数或者一个类，不依赖外部系统，运行速度很快，几毫秒就能跑完。小型测试由开发人员自己写，数量最多，应该占所有测试的70%左右。

中型测试，是集成测试。它测试的是几个模块之间的交互，可能会依赖数据库、文件系统等，但不会依赖完整的系统。中型测试运行速度比小型测试慢一些，大概需要几秒钟。中型测试由开发人员和SET一起写，数量占20%左右。

大型测试，是端到端测试。它测试的是整个系统，从用户界面到后端服务，模拟真实的用户操作。大型测试运行速度最慢，可能需要几分钟甚至更久。大型测试主要由TE来写，数量占10%左右。

这个比例就是Google著名的"测试金字塔"：底层是大量的小型测试，中间是适量的中型测试，顶层是少量的大型测试。这样的结构，既能保证测试的覆盖率，又能保证测试的运行速度和稳定性。

很多团队的测试是倒金字塔，大量的端到端测试，少量的单元测试。这样的测试套件运行慢、不稳定、维护成本高，而且出了问题很难定位。Google的测试金字塔，是经过实践验证的最佳实践。

测试左移和质量内建

Google非常强调"测试左移"，就是把测试活动往开发流程的前面移。

传统的测试是在开发完成之后才开始的，这就是"测试右移"。但这样做的问题是，bug发现得越晚，修复的成本越高。如果在设计阶段就发现问题，可能只需要改一下设计文档；如果在开发阶段发现问题，需要改代码；如果在测试阶段发现问题，需要改代码还要回归测试；如果到了用户手里才发现问题，那成本就更高了。

所以Google主张测试左移，在需求阶段、设计阶段、编码阶段就开始考虑测试。需求评审的时候，测试人员就要参与，从可测试性的角度提出意见；设计评审的时候，就要考虑如何测试；编码的时候，开发人员就要写单元测试。

和测试左移对应的是"质量内建"，就是把质量要求内建到开发的每一个环节，而不是靠后期的测试来把关。比如代码规范、代码审查、持续集成、自动化测试，这些都是质量内建的手段。

Google有一个很有名的实践，就是"发布火车"。产品每隔一段时间就发布一个版本，不管功能有没有做完，做完的功能就上，没做完的就等下一班。这种模式下，质量必须内建到开发过程中，因为没有时间在发布前做大规模的测试。每个开发人员都必须保证自己提交的代码是高质量的，否则就会影响整个发布火车的运行。

持续集成和自动化测试

Google非常重视持续集成和自动化测试。

在Google，代码提交之后，会自动触发构建和测试。如果构建失败或者测试失败，代码就不能合入主干。这个过程是完全自动化的，不需要人工干预。

Google的自动化测试覆盖率非常高。大部分功能都有对应的自动化测试，而且测试运行速度很快，几分钟就能跑完。这样开发人员提交代码之后，很快就能知道自己的代码有没有问题，不需要等很久。

除了单元测试和集成测试，Google还有很多专门的自动化测试工具。比如静态代码分析工具，能自动发现代码中的潜在问题；模糊测试工具，能自动生成随机输入来测试程序的健壮性；性能测试工具，能自动监控性能的变化。

这些自动化工具，让测试变得更高效、更可靠。测试人员不需要手动做那些重复的测试工作，可以把精力放在更有创造性的测试设计和探索性测试上。

探索性测试

虽然Google非常重视自动化测试，但他们并没有否定手动测试的价值。相反，Google非常重视探索性测试。

探索性测试，就是测试人员不依赖预先写好的测试用例，而是根据自己的经验和直觉，自由地探索产品，发现潜在的问题。这种测试方式，能发现很多自动化测试发现不了的问题，特别是用户体验方面的问题。

Google的TE会花很多时间做探索性测试。他们会像真实用户一样使用产品，从用户的角度去发现问题。他们会尝试各种奇怪的操作，各种边界情况，各种异常场景，看看产品会不会出问题。

探索性测试和自动化测试是互补的。自动化测试负责覆盖那些已知的、重复的场景，保证基本功能不出问题；探索性测试负责发现那些未知的、意外的问题，保证产品的用户体验。

Google有一个很有意思的实践，叫做"探索性测试session"。测试人员会设定一个时间，比如一个小时，在这个时间里专注地探索产品的某个方面，然后记录发现的问题。这种方式比漫无目的地测试更有效率。

测试文化

最后，也是最重要的，是Google的测试文化。

在Google，测试不是一个部门的事，而是整个公司的事。从工程师到产品经理，从设计师到运营，所有人都重视质量，都参与测试。

Google的文化里，有几个特点。第一，数据驱动。所有的决策都基于数据，测试也不例外。测试覆盖率、bug数量、用户反馈，这些数据都会被收集和分析，用来指导测试工作。

第二，持续改进。Google不会满足于现状，他们会不断地优化测试流程、测试工具、测试策略。今天的最佳实践，明天可能就会被更好的方法取代。

第三，开放和分享。Google内部有很多技术分享，测试人员会分享自己的经验和工具，大家互相学习，共同进步。很多Google的测试工具和框架，后来都开源了，造福了整个行业。

第四，用户至上。Google做所有的事情，都是从用户的角度出发。测试也不例外，测试的最终目的不是为了找bug，而是为了给用户提供更好的产品体验。

写在最后

《Google软件测试之道》这本书，不仅仅是讲测试技术的，更是讲测试理念和测试文化的。

它告诉我们，测试不是开发完成之后的一道工序，而是贯穿整个开发过程的活动。质量不是测出来的，而是开发出来的。测试人员不是守门员，而是赋能者。

这些理念，虽然是Google在很多年前提出的，但直到今天依然很有价值。特别是在敏捷开发、DevOps、持续交付成为主流的今天，Google的测试理念显得更加重要。

如果你是测试人员，这本书能帮你开阔视野，了解业界最佳实践。如果你是开发人员，这本书能帮你理解测试的重要性，写出更高质量的代码。如果你是管理者，这本书能帮你建立正确的质量文化，打造高效的测试团队。

最后用一句话来结束这篇文章："质量不是测试出来的，是开发出来的；测试不是一个人的事，是所有人的事。"

愿每一个软件团队，都能建立起正确的测试文化，做出高质量的产品。