1）整体来说，这本书到底在谈些什么
Google测试总监James Whittaker介绍了Google是如何进行测试的，介绍了测试解决方案、测试工程师、测试开发工程师、测试经理的角色和职能，应该具有的技术技能。
2）作者细说了什么，怎么说的
测试工程师、测试开发工程师的角色和职能，应该具有的技术技能。
3）这本书说的有道理吗？哪些有道理
首先Google公司名气在外，每天对外发布很多源码，如何对这些代码的质量进行把控肯定有Google的方法在，值得学习，吸取经验。Google对测试相关角色的定义也值得各公司学习，避免测试成为只会点点点的低技术含量的角色。
4）这本书跟你有什么关系？
本书在测试界颇有名气，而本人作为一枚测试攻城狮，需要多想大公司的经验学习，提高自己。
第1章 Google软件测试介绍
在Google，软件测试团队归属于“工程生产力（Engineering Productivity）”部门。
随着软件逐渐由桌面应用迁移到网络云端，Google的测试模式很有可能会逐渐成为测试行业的主流模式。
在整个公司，我们只有非常少的专职测试人员。Google成功的关键是什么，（作者的建议）不要招聘太多的测试。
开发人员也承担了质量的重任。质量从来就不仅仅是一些测试人员的问题。在Google，每个写代码的开发者本身就是测试者。不关注开发测试人员比例。
如果你是一名工程师，那么你同时也是一名测试人员。如果在你的职位头衔上有测试的字样，你的任务就是怎样使那些头衔上没有测试的人可以更好地去做测试。
1.1 质量不等于测试
开发人员写一段代码就立刻测试一段代码。如果产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是测试人员。当把开发过程和测试过程放到一起，就得到了质量。
1.2 角色
1.3 组织结构
模式之一：开发人员与测试人员隶属于同一个工程生产团队。汇报给同一个产品团队的管理者。在产品发布时，优先考虑的是功能的完备性和易用性，却很少考虑质量问题。作为同一个团队，测试总是在为开发让路。我们这个行业里总是有各种有缺陷的的产品，或许这就是问题所在。
在Google中，测试是独立存在的部门，是与专注领域部门平行的部门，称为工程生产力团队。测试人员以租借的方式进入产品团队。测试人员有自己选择决定的优先级，在可靠性、安全性等问题上都不会妥协。
好处：
1、保持数量较少的测试人员，一个产品团队不能任意降低测试人员招聘的技术要求，从而雇佣更多的测试人员。与功能有关的脏活累活本来就是开发人员的工作。
2、测试人员在不同项目之间的借调模式，可以让SET和TE时刻保持新鲜感，还能保证一个好的测试想法可以快速在公司内部蔓延。
Google的特殊规定：测试人员如果在某个产品中工作满18个月，可以无理由地自愿转岗到其他产品。可以增强测试人员对各个产品与技术的理解。
1.4 产品发布
金丝雀版本：每日都要构建的版本，只有这个产品的工程师才会使用。
开发版本：开发人员日常使用的版本，一般每周发布一个。
测试版本：通过了持续测试的版本，基本上是最近一个月内的最佳版本。
beta或发布版本：由稳定的测试版本演变而来，对外发布的第一个版本。
1.5 测试类型
Google没有使用代码测试、集成测试、系统测试这些命名方式。着重强调测试的范畴规模而非形式。
相对于手动测试，倾向于自动化测试。
https://stackoverflow.com/questions/346372/whats-the-difference-between-faking-mocking-and-stubbing
Fake: a class that implements an interface but containsfixed data and no logic. Simply returns "good" or "bad"data depending on the implementation.
Mock: a class that implements an interface and allows theability to dynamically set the values to return/exceptions to throw fromparticular methods and provides the ability to check if particular methods havebeen called/not called.
Stub: Like a mock class, except that it doesn't providethe ability to verify that methods have been called/not called.
Mocks and stubs can be handgenerated or generated by a mocking framework. Fake classes are generated byhand. I use mocks primarily to verify interactions between my class anddependent classes. I use stubs once I have verified the interactions and am testingalternate paths through my code. I use fake classes primarily to abstract outdata dependencies or when mocks/stubs are too tedious to set up each time.
第2章软件测试开发工程师
编写功能代码和编写测试代码在思维方式上有很大的不同。对于功能代码而言，思维模式是创建，重点考虑用户、使用场景和数据流程上；对于测试代码，主要思路是去破坏，写代码用以分离用户及其数据。
2.1 SET的工作
SET会参与到许多测试目标的构建中，并指出哪些地方需要小型测试。同时编写许多mock和fake工具，甚至编写中大型集成测试。
SET究竟是谁：测试是应用产品的另外一种功能，而SET就是这个功能的负责人。
面试SET的时候，在代码要求标准上与SWE的招聘要求是一样的，而且增加了——SET需要了解如何去测试他们编写的代码。
在项目概念阶段，测试人员不会参与进来，而项目一旦真正立项，需要测试人员参与。
SET如何审阅设计文档：
1）完整性
2）正确性
3）一致性
4）设计
5）接口与协议：是否对所使用的协议有清晰的定义
6）测试：可测试性如何
自动化计划：
常见的错误：试图在一个测试套件中自动化所有端到端的测试用例，在端到端的自动化测试上投入过度，常常会与产品的特定功能设计绑定在一起，这部分测试在整个产品稳定之前都不会特别有用。
端到端测试，英文是End to EndTesting。类似于系统测试，测试级的“宏大”的端点，涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。
Google的方法：
首先，将容易出错的接口做隔离，针对它们创建mock和fake。
其次，构建一个轻量级的自动化框架，控制mock系统的创建和执行。
测试大小的定义：
小型测试：验证一个代码单元的功能。不需要外部依赖，外部服务需通过模拟或虚假实现（mock&fake）。（通常为“单元测试”）
中型测试：验证两个或多个模块应用之间的交互。鼓励使用模拟技术（mock）来解决外部服务的依赖问题。（通常称为“集成测试”）
大型测试：验证整个系统作为一个整体是如何工作的。依赖外部系统资源。（通常为“系统测试”或“端到端测试”）
测试规模的优缺点：
这三种测试规模的比例，70/20/10原则：70%是小型测试，20%是中型测试，10%是大型测试。
如果项目是面向用户的，应该有更多的中型或大型测试；如果是基础平台或者面向数据的项目，最好有大量的小型测试。
Google的特殊规定：
20%的时间是Google的一种制度，每周可以拿出一天时间，或者一周工作时间的20%来做自己选择的项目。可以参加不同的项目，提升技能，激发和保持了工作热情。通常，Google不使用商业性工具，高度重视工具的文化，鼓励员工自己开发工具。
2.2 测试认证
从低到高分为1-5级。目的是提高开发人员进行测试的积极性。
P55，测试认证的分级
（使用访谈的方式介绍测试认证在Google中的发展过程）
初期开展比较难，寻找如下的开发团队：①对测试足够感兴趣；②没有太多冗余的代码；③在团队中有一个测试战神。
2.3 SET的招聘
一个优秀的SET候选人不应该被告知要去测试代码，这应该是SET自然要考虑的地方。
2.4 与工具开发工程师Ted Mao的访谈
创建Buganizer和Matrix产品，创建心得，对于开发测试工具的建议。
2.5 与Web Driver的创建者Simon Stewart的对话
介绍Selenium和WebDriver的由来和区别，以及以后的发展。
第3章测试工程师
3.1 一种面向用户的测试角色
Google的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力。
TE的职位描述是最难定义的，因为其职责范围很广而且不确定。
3.2 测试工程师的工作
在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，TE通常没有太多的工作可做。
TE在进入产品时，需考虑如下问题：
当前软件的薄弱点在哪里？
有没有安全、隐私、性能、可靠性、可用性等问题？
主要用户场景是否功能正常？
这个产品能与其他产品互操作吗？
当发生问题的时候，是否容易诊断问题所在？
TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。这个角色需要敏锐的洞察力和领导力。
TE职责：
测试计划和风险分析
评审需求、设计、代码和测试
探索式测试
用户场景
编写测试用例
执行测试用例
外包
使用统计
用户反馈
3.2.1 测试计划
测试计划需要具有如下特性：
及时地更新
描述了软件的目标和卖点
描述了软件的结构、各种组件和功能特性的名称
描述了软件的功能和操作简介
不必花过多的时间去撰写，必须随时可以被修改
描述必测点
能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足。
ACC（Attribute Componet Capability，特质、组件、能力） P82
Google使用ACC作为一种测试计划的替代方法。
A代表特质：
代表产品的品质和特色，是区别竞争对手的关键。产品经理或者开发人员已经确定了产品的特质，测试人员只需将特质记录下来，以备使用。
C代表组件：
组件是构成待建系统的模块。组件容易识别，经常出现在设计文档中。
对于特质和组件来说，花几分钟的时间来理清就足够了。
C代表能力：
组件（Componet）执行某种功能（function）来满足产品的一个特质（Attribute），这个活动的结果是向用户提供某种能力（Capability）。P86
能力最重要的一个特点是它的可测试性。
TE需要将能力转化为测试用例。
ACC的完成，意味着所有可测试的特性都被定义好了。
P90，Google+的案例分析
3.2.2 风险
风险的要素：发生频率和影响。
发生频率：罕见、少见、偶尔、常见
3.2.3 测试用例的生命周期
Google管理测试用例的工具，初期用Test Scribe。后期被GTCM（Google Test CaseManager）取代。这个小章节介绍了GTCM的特点。
3.2.4 bug的生命周期
介绍Google管理bug的工具——Buganizer。
许多团队在bug到达的速度超过了其修复能力的时候，干脆不再进行新功能的开发。强烈推荐这种实践，反对那种只盯着特性或者代码完成的里程碑的做法。
3.2.5 TE的招聘
TE的招聘非常困难，因为他们需要擅长很多事情。
面试TE的意图：
对事物结构、对于变量和配置的组合的各种可能性和意义的好奇心。关于事物应该如何工作的强烈感觉，以及清晰表达的能力。很强的人格魅力。
3.2.6 Google的测试领导和管理工作
Google的测试管理更多的是激励，而非强悍的管理；更多的是战略指引，而非频繁的督促检查（每天、每周等）。
通常，过度的管理和组织会带来紧张的气氛。
作为测试领导层，经常需要妥协，并能尊重个体SET和TE的聪明才智。Google领导和管理的一个标志是辅导和指导下属工作，而不是直接下命令。
3.2.7 维护模式的测试
尽量淘汰手工测试，使用自动化测试。
3.2.9 BITE实验
问题：测试人员花了很多时间在上下文切换和分析大量数据上，经常需要切换多种工具，影响效率。
解决方法：使用BITE工具，将尽可能多的测试活动、测试工具和测试数据集中到浏览器和云里，并在上下文中呈现相关信息，从而减少分散操作的麻烦，使得工作更加高效。
本节介绍了BITE（Browser Integrated Test Enviroment）的由来、功能以及如何使用。
BITE的逆天功能：
1、在网页上提bug时，自动获取浏览器信息；
2、打开页面，自动显示此页面的bug；
3、可以进行录制和回放；
4、自动分配任务，做得快的会自动收到更多的测试任务，暂停的人的任务会自动分给其他人；
3.2.11 零成本测试流程
免费测试特征的想法：
成本几乎为零；
瞬间可得的测试结果；
极少或者无需人工干预；
非常灵活。
Google的免费测试模型——bot流程：
1）通过GTA进行测试计划；
2）测试覆盖度：bot自动抓取网站内容，发现有所变化立刻提交人工去判断；
3）bug评审：BITE提供现有的bug和丰富的测试上下文信息；
4）探索式测试
5）bug提交：基于BITE，很容易提交bug
6）bug查看和调试：开发或测试经理可以看到实时的bug趋势图。
7）部署新版本并回到步骤1）。
价值在于：测试人员无需为了少数几个可能发生回归的特性变化，而去手工执行成百上千的回归测试。bot可以几分钟内完成一个测试周期，从产品新版本的部署到bug的发现之间的间隔很短。
3.3 与Google Docs测试工程师Lindsay Webster的访谈
参与一个新项目时，首先去做哪些工作：
首先了解这个产品；包括所有文档；关注项目的状态，特别是质量状态，了解bug的情况；检查应用的代码库，查看运行对应的单元测试是否通过。评审自动化测试，是否有自动化测试，检查代码；关注团队，了解他们的沟通方式和期望，加入他们的通讯组里。
开始进行测试工作，将应用分解为合理的功能模块，排列测试的优先级。创建测试集合，维护和更新：更新测试用例，增加新特性的文档，更新变化了的模块的截屏或视频。
最后，观察哪些bug遗漏到了生产环境，来告诉我们测试覆盖上的不足。
与开发的关系：
当我坦诚地指出某些组件或领域的测试不应该由我负责，而应该由他们自己负责的时候，开发反而更加看重我的工作了。
很多测试人员试图避免自我宣传，避免公开讨论他们不会测试的东西，担心这样做会使人轻看测试的价值。但在我的经验里，事实却恰恰相反，开发会因此而尊敬你。
介绍如何开展Google Sites的测试。
3.4 与YouTube测试工程师Apple Chow的访谈
为什么加入Google：大量使用自动化，重视工具的开发；开发负责质量，以测试为中心的SWE文化。
如何在YouTube中应用探索式测试和Selenium自动化测试；
第四章测试工程经理
4.1 测试工程经理的工作
测试工程经理可能是Google里最具挑战的一个职位，不仅需要同时具备TE和SET的技能，还需要拥有足够的管理技能来负责下属的职业发展。
测试工程经理汇报给测试总监。
要求：
1、了解你的产品，相关项目中最强的产品专家。
2、知人善用；没用的自动化会被抛弃
4.2 获得项目和人员
员工可以根据内部条件（满18个月）自由选择项目，项目经理也可以自己选择。
4.3 影响力
晋升取决于员工对项目的影响力。组建测试团队的目的就是让他们发挥影响力。
4.4 Gmail测试工程经理Ankit Mehta的访谈
谈论如何管理Gmail团队；
管理下属的同时，如何确保自己在技术上有所贡献：
留一部分工作自己来完成，在设计阶段会积极地参与，持续地跟进项目并且自己也编写测试；
最关键的部分，每周都花一两天的时间做自己的工作。
人员配备问题：绝不妥协。选用不合适的人来填充名额永远要比等待合适的人员要糟糕。
经验：
使用与应用程序开发语言相同的编程语言来编写测试；
20%的用例覆盖了80%的使用场景，把20%自动化而别管剩下的。把那些测试通过手工完成。
TE和SET常会犯哪些错误；
在测试领域什么东西会引发你的激情？快速创建一个高质量的产品。
4.5 Android测试工程经理Huang Dang的访谈
Android项目最初的经历；
团队基调：创造价值。做的每一件事都要创造价值，并且能够持续地创造价值。
团队的组成以及对手工测试、自动化测试的分配。
4.6 Chrome测试工程经理Joel Hynoski的访谈
如何与浏览器关联的各种插件涉及的开发团队进行沟通；
Chrome如何进行测试；
面临的最大的挑战：变化多端的互联网；
Chrome测试的难点：兼容性和UI自动化。
如何招聘以及对测试的理解。
4.7 测试总监
测试总监的自由度很高，管理方式也不尽相同。
总监负责批准招聘和转岗，全面掌控测试团队人事方面的各种问题。
发挥领导才能:建设强大的团队，足够的技术素养，具备创新意识，对Google的各项工具和基础架构了如指掌。
以下采访5位测试总监。
4.8搜索和地理信息测试总监Shelton Mar的访谈
Google早期如何进行测试，如何转型
Google搜索测试最难的部分是什么？理解索引和搜索算法，理解整套系统是如何运作的。
接手一个新项目时，通常会怎么做？
让团队思考：对被测系统来说，什么是最重要的。
对自动化测试的理解以及如何进行测试。
4.9 工程工具总监Ashish Kumar的访谈
介绍工程工具团队。工具集分为如下：
源码工具，管理源码，检查代码风格；
开发工具；
构建框架，构建代码，分发到各语言开发的项目；
测试基础架构；
本地化工具；
度量、可视化和报表。
什么工具想法是一开始不看好但最后成功的？大规模的持续集成。
什么工具想法是一开始看好但最后失败的？远程结对编程。
如何宣传工具：每周主持一次工程生产力工具播报的活动，展示我们工具。
对工具的理解。
4.10 印度Google测试总监SujaySahni访谈
印度在Google测试中的作用，以及目前参与了哪些项目；
对全球各地的软件公司提供测试工程支持，有哪些经验。
4.11 工程经理Brad Green访谈
对Google测试的看法，在Google做测试经理的感受；
介绍Feedback；
4.12 James Whittaker访谈
加入Google的过程，为Google带来的变化，对Google的组织结构的感受；
James所理解的Google成功的秘诀：技能、稀缺性4、自动化和迭代集成。
写书的计划；
第5章 Google软件测试改进
5.1 Google流程中的致命缺陷
第一个致命缺陷：测试成了开发的拐杖。
我们越不让开发考虑测试的问题，把测试变得简单，开发就越来越不会去做测试。
第二个致命缺陷：开发与测试的组织结构分离。
测试人员更关注自己的角色，而不是他们的产品。健康的组织的一个标志是，人们会说“我在为Chrome工作”，而不是“我是测试”。
任何角色都不应该被过分强调。团队的每个人都是在为产品工作，而不是为了开发过程中的某个部分。
第三个致命缺陷：测试人员往往崇拜测试产物胜过软件本身。
测试的价值在于测试的动作，而不是测试产物。
测试人员必须把产品放在第一位。
第四个致命缺陷：产品经过最严格的测试发布后，用户有多大可能仍然发现测试中遗漏的问题？几乎必然发现。
5.2 SET的未来
作者认为SET没有未来。SET就是开发，与开发的待遇一致。
测试特性应该由团队的新成员负责，特别是那些资历尚浅的员工。
5.3 TE的未来
TE的需求量会越来越少。
测试工程会转型成测试设计。少量的测试设计师快速地规划出测试范围、风险热图和应用程序的漫游路线。可以识别需要专业技能的地方，比如安全性、隐私、性能和探索式测试。
5.4 测试总监和经理的未来
数量大幅减少。他们将作为思想领袖，为维系松散的测试工程师和负责质量的软件工程师的关系而存在，但不会最终为某个特别项目的质量或管理负责。
5.5 未来的测试基础设施
目前Google的测试基础设施是基于客户端的，在测试创建和执行上花费昂贵的人工和机器建设成本。
测试基础设施会最终整体迁移到云端，使用更加开放、基于云计算的方式。测试用例库、测试代码的编辑、录制和执行等都将在一个网站或通过浏览器插件完成。
附录A Chrome OS测试计划
附录B Chrome的漫游测试
附录C 有关工具和代码的博客文章
使用BITE从bug和冗余的工作中解脱出来
发布QualityBot
RPF：Google的录制回放框架
Google测试分析系统（Google Test Analytics）
评论此书：
本书首先介绍了Google如何进行软件测试，然后从软件测试开发（SET）、软件测试（TE）、测试经理的角度分别介绍。章节分配非常有条理，重点的句子作者会单独标记出来，便于加深理解。有几个观点印象特别深。
首先，质量不仅仅是测试的事儿，开发也需要为质量负责任，这样开发就会在测试过程中富有责任心。国内的软件公司缺少这样的想法，开发对质量完全不负责，不仅仅造成了产品质量差，还会加深开发与测试的矛盾。
测试人员如果在某个产品中工作满18个月，可以无理由地自愿转岗到其他产品。给员工足够的自由，体现民主精神。
Google对开发工具、进行自动化十分痴狂，一切工作都试图使用自动化来完成。20%的时间是Google的一种制度，每周可以拿出一天时间，或者一周工作时间的20%来做自己选择的项目，鼓励员工进行创新、自己开发工具。Google之所以成为全球知名的公司，跟它对技术与创新的追求是分不开的。
访谈，本书分别对比较优秀的SET、TE和测试经理进行访谈，与他们谈谈对测试的想法、如何开展测试等等，从这点也可以看出Google很注重听取大家的意见，与一般的技术类书籍相比，本书中访谈内容占了很多篇幅，各个员工各抒己见，值得学习。
本书最后作者预测了下软件测试的未来，普通的TE会越来越少，SET也会消失，由开发取代，测试会向测试设计和测试决策的方向发展。
综上，推荐所有软件从业人员读一读。
---------------------
作者：雪莉斯诺
来源：CSDN
原文：https://blog.csdn.net/shirley5229/article/details/79230964
版权声明：本文为博主原创文章，转载请附上博文链接！