《Google软件测试之道》，英文原名是《How Google Tests Software》，是软件测试领域的经典著作，由Google的两位资深测试工程师James A. Whittaker和Jason Arbon，以及测试经理Jeff Carollo合著，2012年出版，至今已经快十年了。

这本书，我第一次读。是刚入行做测试的时候，当时读完。觉得很震撼，原来软件测试还可以这么做。原来Google的测试，是这样的。后来。工作了几年，有了一些经验。再读这本书，又有了新的理解和体会。觉得这本书，确实是经典，常读常新。

这本书，虽然出版已经快十年了。Google的测试实践，也可能发生了一些变化。但它的核心思想、核心理念。至今仍然适用，仍然能给我们很多启发。所以。它至今仍然是软件测试领域最受欢迎、最受推荐的书籍之一，很多公司。招测试工程师，都会推荐候选人读这本书。很多测试工程师，也都会把这本书，当成必读书目。

今天，写这篇文章。分享我读这本书的读书笔记和思考，聊聊这本书的核心内容。为什么它能成为经典，以及它对我们做软件测试、做软件开发的启发，希望能给大家一些参考。

一、这本书讲了什么

首先，简单介绍一下，这本书讲了什么。

这本书，主要讲的是Google是怎么做软件测试的，包括Google的测试理念、测试组织、测试角色、测试流程、测试方法、测试工具、测试文化等，全方位地展示了Google的测试实践。

全书，大概可以分为三个部分：

第一部分，讲Google的测试理念和测试组织。包括Google为什么要做测试，Google的测试哲学。Google的测试组织架构，Google的测试角色，以及Google是怎么招聘和培养测试人员的。

第二部分，讲Google的测试实践。包括Google是怎么做单元测试、集成测试、系统测试的，是怎么做自动化测试的。是怎么做探索性测试的，是怎么做性能测试、安全测试的。是怎么做测试管理的，以及Google的测试工具和测试平台。

第三部分，讲Google的测试文化和未来。包括Google的测试文化，测试在Google的地位。测试人员的职业发展，以及软件测试的未来趋势。

整本书。不是纯理论的，而是有很多实际的案例。很多Google内部的实际做法，很多真实的故事。读起来不枯燥，很有趣，也很有启发。

接下来，我挑几个我觉得最核心、最有启发的点，详细聊聊。

二、Google的测试哲学：质量是每个人的责任

这本书，最核心、最颠覆我认知的一个观点，就是：质量是每个人的责任。不是测试团队的责任。

在很多公司，大家的认知是。开发负责写代码，测试负责找bug。质量是测试团队的事情，出了bug。就是测试没测好，就是测试的责任。

但在Google。不是这样的。Google认为，质量。是整个团队的责任，是每个人的责任。尤其是开发的责任。而不是测试团队的责任。测试团队。不是质量的把关者。不是质量的负责人，而是质量的推动者、赋能者。他们的工作，是帮助开发团队。提高质量，建立质量保障体系。而不是替开发团队，把好质量关。

为什么这么说？因为，质量。是在开发过程中，构建到产品里的。不是在测试阶段。测出来的。如果开发写的代码，质量很差。bug很多，那测试再怎么测。也很难保证质量，因为。测试，只能证明bug的存在。不能证明bug不存在。你永远不可能，把所有的bug都测出来。只有开发。在写代码的时候，就注重质量。写高质量的代码，做充分的单元测试。才能从根本上，保证产品的质量。

所以，在Google，开发，对质量负有首要责任。开发。必须写单元测试。必须做代码审查。必须自己测试自己的代码。必须对自己写的代码的质量负责。如果开发写的代码，bug很多，质量很差，那是开发的问题。不是测试的问题。

那测试团队，做什么呢？测试团队。不负责具体的测试执行，不负责找bug，而是负责：

  1. 建立测试体系和测试流程，制定测试规范和标准，让整个团队，有章可循。
  2. 开发测试工具和测试平台，提高测试效率，降低测试成本，让开发和测试，都能更高效地做测试。
  3. 做测试培训和咨询，帮助开发团队，提高测试能力，教会开发，怎么写单元测试，怎么做自动化测试，怎么做探索性测试。
  4. 做复杂的、专业的测试，比如性能测试、安全测试、兼容性测试等，这些测试，需要专业的技能和工具，开发做不了，由测试团队来做。
  5. 做测试策略和测试规划，从整体上，把控产品的质量风险，制定测试计划，协调测试资源。

简单来说，在Google。测试团队，是"教练"和"后勤"。不是"运动员"和"守门员"。他们不亲自下场比赛。不亲自把球门，而是教运动员怎么踢球。给运动员提供装备和支持，让运动员自己。把球踢好，把球门守好。

这个观点，对我的冲击很大。以前。我也觉得，测试。就是找bug的，质量。就是测试的责任，出了bug。就是测试没测好。但读了这本书之后，我才明白。质量，是每个人的责任。尤其是开发的责任。测试，只是推动和赋能。不是替开发背锅。

当然，这个理念。在很多公司。可能推行不下去，因为很多公司的开发。不愿意写测试，不愿意对质量负责。觉得测试，就是测试的事情。但至少。这个理念，给了我们一个方向。一个目标，让我们知道。理想的测试。应该是什么样的，我们应该往哪个方向努力。

三、Google的测试角色：SET和TE

在Google，测试团队。有两个主要的角色，一个是SET（Software Engineer in Test。测试开发工程师），一个是TE（Test Engineer。测试工程师），这两个角色。职责不同，定位不同。但都是测试团队，不可或缺的一部分。

SET（Software Engineer in Test，测试开发工程师）

SET，本质上。是软件工程师，是开发。只是他们的开发方向，是测试。他们写代码。开发测试工具、测试框架、测试平台，做自动化测试，做性能测试、安全测试等需要写代码的测试。

SET的主要职责：

  1. 开发和维护测试工具、测试框架、测试平台，提高测试效率，降低测试成本。
  2. 编写和维护自动化测试用例，包括单元测试、集成测试、端到端测试的自动化。
  3. 做代码审查，审查开发的代码，和测试相关的代码，确保代码质量。
  4. 参与产品设计和技术设计，从测试的角度，提出建议，确保产品是可测试的。
  5. 做复杂的、需要写代码的测试，比如性能测试、安全测试、压力测试等。
  6. 做测试培训，教会开发，怎么写测试，怎么用测试工具。

SET，要求有很强的开发能力。会写代码，懂架构。懂设计，和普通的开发工程师。能力要求差不多，只是他们的领域。是测试。在Google，SET的地位。和开发工程师是一样的，薪资、晋升、发展。都一样。不会因为是测试，就低人一等。

TE（Test Engineer，测试工程师）

TE，是传统意义上的测试工程师，他们不写代码。或者写很少的代码，主要做测试用例设计、测试执行、探索性测试、用户场景测试、bug验证等。

TE的主要职责：

  1. 设计测试用例，包括功能测试用例、场景测试用例、回归测试用例等。
  2. 执行测试，包括手动测试、探索性测试、用户场景测试等。
  3. 发现、记录、跟踪bug，验证bug的修复。
  4. 做测试分析，分析产品的质量风险，分析测试的覆盖率，分析bug的趋势。
  5. 做用户体验测试，从用户的角度，测试产品的易用性、可用性。
  6. 做测试管理，制定测试计划，协调测试资源，跟踪测试进度。

TE，要求有很强的测试思维。懂业务，懂用户。懂测试方法，有很强的沟通能力和分析能力。不一定需要很强的开发能力。但需要懂技术，能和开发顺畅沟通，能理解产品的技术实现。

在Google，TE和SET。是平等的，只是分工不同。没有高低贵贱之分。两者配合，共同保障产品的质量。

这种角色划分，我觉得很合理。也很科学。它把测试，分成了"技术"和"业务"两个方向。喜欢写代码、喜欢做工具的。可以做SET；喜欢做业务、喜欢做用户场景、喜欢找bug的。可以做TE。每个人，都可以根据自己的兴趣和特长。选择适合自己的方向，不用都去写代码，也不用都去做手动测试。

而在很多公司，测试角色。是模糊的，测试工程师。既要写代码，做自动化。又要做手动测试，找bug。还要做测试管理，什么都做。结果什么都做不精，什么都做不好。Google的这种角色划分，值得我们学习和借鉴。

四、Google的测试方法：自动化测试和探索性测试并重

在测试方法上，Google的做法。是自动化测试和探索性测试并重，两者结合，共同保障产品的质量。

自动化测试

Google非常重视自动化测试，他们认为，自动化测试，是保障质量、提高效率的关键。尤其是对于快速迭代、频繁发布的产品来说。没有自动化测试，根本无法保障质量。

Google的自动化测试，分为三个层次，也就是我们常说的测试金字塔：

  1. 单元测试（Unit Test）：最底层，数量最多，运行最快，由开发编写，测试单个函数、单个类的功能，确保代码的逻辑正确。单元测试，是自动化测试的基础，也是最重要的部分，Google要求，开发写的代码，必须有单元测试，单元测试覆盖率，要达到一定的标准。
  2. 集成测试（Integration Test）：中间层，数量中等，运行速度中等，测试模块之间、服务之间的交互，确保各个模块，集成在一起，能正常工作。
  3. 端到端测试（End-to-End Test）：最顶层，数量最少，运行最慢，测试整个产品，从用户的角度，模拟用户的操作，确保整个产品，能正常工作，满足用户的需求。

这个测试金字塔，是很经典的测试分层模型。它的核心思想是，单元测试。要多，要快。要便宜；端到端测试，要少。要精，要慢。因为。单元测试，运行快。成本低，容易维护。能快速发现代码层面的问题；端到端测试，运行慢。成本高，难维护。容易出问题。所以。不能太多，只需要覆盖核心的用户场景就行。

Google的自动化测试，还有一个特点。就是持续集成，持续测试。他们有强大的持续集成系统。代码一提交，就会自动运行单元测试、集成测试。自动构建，自动部署。自动运行端到端测试，整个过程。都是自动化的，不需要人工干预。如果测试失败。就会自动通知开发，让开发尽快修复。确保代码库，始终处于可用的状态。

这种持续集成、持续测试的做法，能快速发现问题。快速修复问题，大大提高了开发效率和产品质量，值得我们学习。

探索性测试

虽然Google很重视自动化测试。但他们也没有忽视手动测试。尤其是探索性测试。他们认为，自动化测试。只能测试已知的、预期的场景，只能证明。这些场景。没有问题。但对于未知的、意外的场景，对于用户的奇怪操作。对于边界情况，自动化测试。是覆盖不到的，这时候。就需要探索性测试。需要测试人员，发挥主观能动性。去探索，去发现，那些自动化测试发现不了的bug。

探索性测试，英文是Exploratory Testing。简单来说，就是测试人员。不依赖预先写好的测试用例，而是根据自己的经验、直觉、对产品的理解。自由地探索产品，尝试各种操作。各种场景，去发现bug。它强调的是。测试人员的主观能动性，和创造性，而不是机械地执行测试用例。

Google的TE，很大一部分工作。就是做探索性测试。他们会花很多时间，去使用产品。去探索产品，从用户的角度。去尝试各种操作，各种场景。去发现那些隐藏的、深层的bug。他们不是机械地执行测试用例，而是主动地、创造性地去测试，去发现问题。

Google还发明了一种叫"探索性测试会话"（Exploratory Testing Session）的方法，就是测试人员。花一定的时间（比如一个小时、两个小时），专注地做探索性测试。测试完之后，记录测试了什么。发现了什么，有什么想法。然后和团队分享。这种方法。能让测试人员，专注地、深入地做探索性测试，提高探索性测试的效果。

我觉得，自动化测试和探索性测试并重。这个做法，非常科学。也非常合理。自动化测试，负责回归。负责已知场景，负责快速反馈；探索性测试。负责发现新问题，负责未知场景。负责用户体验。两者结合，才能既有效率。又有效果，才能真正保障产品的质量。

而在很多公司，要么只重视自动化测试。觉得手动测试没用，要全部自动化。结果自动化做了很多。但效果不好，bug还是很多；要么只重视手动测试。觉得自动化没用，还是手动靠谱。结果测试效率很低，回归测试做不过来。产品质量也保障不了。这两种极端，都不可取。最好的做法，就是像Google一样。自动化和探索性测试并重，两者结合。

五、Google的测试文化：测试不是二等公民

这本书，还有一点。让我印象很深，就是Google的测试文化。测试，在Google。不是二等公民。不是边缘部门。而是和开发平等的，是产品团队，不可或缺的一部分。

在很多公司，测试。是边缘部门，是二等公民。地位比开发低，薪资比开发低。晋升比开发难，话语权比开发小。大家都觉得，测试。就是找bug的，就是背锅的。技术含量低，谁都能做。很多测试工程师。自己也觉得，低人一等。想转开发，想转产品，不想做测试。

但在Google。不是这样的。在Google，测试。和开发，是平等的。地位一样，薪资一样。晋升一样，发展一样。SET。本身就是软件工程师，和开发工程师。没有区别；TE。也是专业的技术岗位，有自己的职业发展路径。有自己的晋升通道。不会因为是测试，就低人一等。

而且，在Google。测试，有很大的话语权。他们参与产品的整个生命周期，从需求分析。到产品设计，到技术设计。到开发，到测试。到发布，到运维。测试，都有参与。都有发言权。他们不是在开发写完代码之后，才介入。才开始测试，而是从一开始。就介入，就参与。从测试的角度，提出建议。确保产品，是可测试的，是高质量的。

Google还有一个很有意思的做法，就是测试人员。会轮岗到开发团队，和开发一起工作。一起写代码，一起做测试。深入了解产品的技术实现，了解开发的工作方式。这样，测试。才能更好地和开发配合，更好地做测试。同样。开发，也会轮岗到测试团队。体验测试的工作，了解测试的困难。这样，开发。才能更重视质量，更重视测试，更好地配合测试。

这种轮岗的做法，能增进开发和测试之间的理解和信任。减少矛盾和冲突，让团队。更有凝聚力，更高效地工作，非常值得我们学习。

我觉得，测试文化。是这本书，最有价值的部分之一。因为。测试理念、测试方法、测试工具，这些。都是可以学的。可以复制的。但测试文化，是很难学的。很难复制的，它需要公司。从上到下，真正地重视质量。重视测试，把测试。当成和开发平等的、不可或缺的一部分，而不是边缘部门。不是背锅侠。

如果一个公司。没有好的测试文化，不重视测试。不重视质量，那就算你学了Google的测试方法、测试工具。也没用，也做不好测试。因为。测试。不是测试团队一个团队的事情，是整个公司、整个团队的事情。需要从上到下，所有人的重视和参与。

所以，我觉得。我们读这本书，不仅要学Google的测试方法、测试工具。更要学Google的测试文化，学他们对质量的重视。对测试的重视。然后，在自己的公司。自己的团队，慢慢推动。建立好的测试文化，让测试。不再是二等公民，不再是背锅侠。而是和开发平等的，共同保障产品质量的重要力量。

六、为什么这本书能成为经典

聊了这么多，最后。说说，为什么这本书。能成为经典，能在出版快十年之后。仍然被广泛推荐，仍然有这么大的影响力。

我觉得，主要有以下几个原因：

1. 它来自Google，有权威性

Google，是全球最顶尖的科技公司之一。它的工程实践，它的软件开发方法。一直是行业的标杆，是大家学习和模仿的对象。这本书。是Google的测试工程师，写的Google内部的测试实践。是第一手的资料。不是道听途说。不是纸上谈兵。所以，有很强的权威性。大家都愿意信，愿意学。

2. 它的理念先进，有启发性

这本书，提出了很多先进的测试理念。比如"质量是每个人的责任"、"测试是赋能。不是把关"、"自动化和探索性测试并重"、"测试和开发平等"等。这些理念，即使在今天看来。仍然是先进的，仍然有很强的启发性。能让我们重新思考，测试的本质是什么。测试的价值是什么，我们应该怎么做测试。

3. 它的内容实用，可落地

这本书。不是纯理论的。不是空喊口号的，而是有很多实际的做法。很多具体的案例，很多可落地的方法。比如测试角色的划分、测试金字塔、持续集成、探索性测试会话、轮岗制度等。这些，都是可以直接学习。直接应用到自己的工作中的。所以，很实用，很有价值。

4. 它写得有趣，可读性强

这本书。不是干巴巴的教科书，而是有很多故事。很多案例，很多Google内部的真实做法。写得很生动，很有趣。可读性很强，读起来不枯燥。很容易读进去。所以，很受欢迎，流传很广。

5. 它关注的问题，是永恒的

这本书，关注的问题。比如。什么是质量，谁对质量负责。测试的价值是什么，怎么做好测试。怎么提高测试效率，这些问题。是软件测试领域，永恒的问题。不管技术怎么发展，不管工具怎么变化。这些问题，都存在。都需要我们去思考，去解决。所以。这本书。不会因为技术的发展，而过时。它的核心思想，核心理念。至今仍然适用，仍然有价值。

因为以上这些原因，这本书。成了软件测试领域的经典，成了测试工程师的必读书目。常读常新，每次读，都有新的收获和体会。

七、写在最后

《Google软件测试之道》，是一本很有价值的书。不管你是测试工程师，还是开发工程师。还是产品经理，还是技术管理者，都值得读一读。

它能让测试工程师，重新思考。测试的本质是什么，测试的价值是什么。我们应该怎么做测试，怎么提高自己的能力，怎么提升自己的地位。

它能让开发工程师，重新思考。质量是什么，谁对质量负责。我们应该怎么写高质量的代码，怎么做好单元测试。怎么和测试配合，共同保障产品的质量。

它能让技术管理者，重新思考。应该建立什么样的测试文化。什么样的测试组织，什么样的测试流程。怎么提高整个团队的质量意识，怎么提高产品的质量。

当然，这本书。也不是完美的，它写的是Google的实践。Google的情况，和我们自己的公司。自己的团队。可能不一样。不能完全照搬。不能生搬硬套。我们要做的，是学习它的理念。它的思想，它的方法。然后。结合自己的实际情况，灵活应用，找到适合自己的测试方法和测试流程。

而且，这本书。出版已经快十年了，这十年。软件测试领域，也发生了很多变化。比如。DevOps的兴起，CI/CD的普及。测试左移、测试右移的提出，AI在测试中的应用等。这些新的趋势，新的方法。这本书里。没有提到。或者讲得不多，我们需要在这本书的基础上。继续学习，继续探索，跟上时代的发展。

但不管怎么说，这本书。仍然是软件测试领域的经典，仍然值得我们反复阅读。反复体会。它的核心思想，核心理念。至今仍然适用，仍然能给我们很多启发。

最后，用一句话。总结我读这本书的感受：测试。不是找bug的。不是背锅的。不是二等公民，而是质量的推动者。是赋能者，是和开发平等的。共同保障产品质量的重要力量。质量，是每个人的责任。尤其是开发的责任。测试，只是帮助大家，把质量做得更好。

希望这本书，也能给你带来启发。带来思考，让你在测试的道路上。走得更远，走得更好。

如果你还没读过这本书，推荐你读一读，相信我，你一定会有收获的。