本文主要为《Google软件测试之道》读书笔记。

一、Google软件测试介绍

Google只有非常少的专职测试人员

Larry Page “少则清晰”

Google 成功的关键是不要招聘太多的测试人员

质量不等于测试，质量不是测试出来的

当把开发过程和测试放在一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。

开发测试融合在一起，开发测试必须同时开展。

质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。

软件测试开发工程师 SET （software engineer in test）开发角色，重点在可测试性和通用基础框架上。

测试工程师 TE (test engineer) 把用户放在首位思考，组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端自动化测试。

组织架构

测试是独立存在的部门，工程生产力部门，有权自己选择决定的优先级，在可靠性，安全性等问题上不会妥协。

爬、走、跑

Google最初发布版本只包含基本的可用功能，后续快速迭代。一般会经历金丝雀版本，开发版本，测试版本，beta或正式发布版本。

1. 金丝雀版本：每日构建版本，用来排除过滤一些明显不适宜的版本
2. 开发版本：开发日常使用版本，每周发布一个
3. 测试版本：通过持续测试的版本，最近一个月的最佳版本，测试版本可被挑选为内部尝鲜（dogfood）版本，比较优秀也可以作为beta测试的候选版本
4. beta或发布版本：非常稳定的测试版本演变而来，经历内部使用和通过所有质量考核，对外发布的第一个版本

测试类型

1. 小型测试：一般来说都是自动化实现的，用于验证一个单独函数或者模块代码，主要由SWE实现
2. 中型测试：通常也是自动化实现，一般设计两个或两个以上，甚至更多模块的交互，验证功能近邻区交互及功能，开发早期由SET驱动测试实现及运行，后期由TE执行
3. 大型测试：涵盖三个及以上的功能模块，使用真实用户场景及数据，验证软件是否满足最终用户需求，三种工程师均会参与

如果能够自动化，并不需要人脑的智睿和直觉来判断，那就应该以自动化的方式实现。

二、软件测试开发工程师

• SWE 功能开发人员
• STE 测试开发人员
• TE 用户开发人员

工程师团队的交付物就是即将要发布的代码。代码的组织形式，开发过程，维护是日常的工作重点。

公开的代码库，和谐的工程工具，公司范围内的资源共享，成就了丰富的Google内部共享代码库与公共服务。

Google在平台方面有特定的目标，就是保持简单且统一。

一个经过良好测试的独立库，一个在可读性和可复用性都不错的公共服务库，一套覆盖所有重要构建目标的单元测试套件。

测试是应用产品的另外一种功能，SET就是这个功能的负责人。

只在软件产品变的重要的时候，质量才显得更重要。

审阅设计文档的要点：完整性，正确性，一致性，设计，接口与协议，测试性。

为了能够尽早的运行集成测试，针对依赖服务，SET提供了mock和fake。

在端到端自动化测试上过度投入，常常会把你与产品的特定功能设计绑定在一起。

小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告;大中型测试会带来整体产品质量和数据验证。

SET 的面试重点在考察候选人如何思索问题的解决方案，而不是解决方案本身的实现上有多么高雅。

三、测试工程师

一种面向用户的测试角色。给项目配备多少测试人员，取决于项目风险和投资回报率。

TE在测试计划及测试完整性上必须更加系统和周密，重点在真实用户的使用方式和系统级别的体验。TE擅长发现需求中的模糊之处，分析沟通不明确的问题。

TE主要职责：

• 测试计划和风险分析
• 评审需求、设计、代码和测试
• 探索式测试
• 用户场景
• 编写测试用例
• 执行测试用例
• 众包
• 使用统计
• 用户反馈

测试计划是最早出现、最先被遗忘的测试产物。

测试计划具有的特性：

• 及时地更新
• 描述了软件的目标和卖点
• 描述了软件的结构、各种组件和功能特性的名称
• 描述了软件的功能和操作简介。从纯粹测试的角度看，我们担心的是测试计划的投入和价值产出是否匹配
• 不必花过多的时间去撰写，必须随时可以被修改
• 应该描述必测点
• 应该能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足

ACC(Attribute Component Capability)，即特质、组件、能力

这是一种测试计划的替代方法。

ACC的指导原则：

• 避免散漫的文字，推荐使用简明的列表。
• 不必推销。测试计划不是给客户或分析师看的，它的受众人群是工程师。
• 简洁。测试计划并没有长度的要求。计划的大小与测试问题的规模有关，与作者的写作欲望无关。
• 不要把不重要的、无法执行的东西放进测试计划。相关人员毫不关心的东西，就一个词也不要出现。
• 渐进式的描述(Makeitfow)。测试计划的每个部分应该是前面部分的延伸，以便读者可以随时停止阅读并且对产品的功能有一个初步的印象。如果读者希望了解更多的细节，那么他可以继续读下去。
  指导计划者的思路。一个好的计划过程能帮助计划者思考产品功能及其测试需求从而有条不紊地从高层概念过渡到可以被直接实现的低层细节。
• 最终结果应该是测试用例。在计划完成的时候，它不仅要清楚地描述要做什么样的测试，并且还可以清楚地指导测试用例的编写。做出一个不直接指导测试的计划纯粹是在浪费时间。

ACC通过指导计划者依次考察产品的三个维度达成这个目标：描述产品目标的形容词和副词;确定产品各部分、各特性的名词;描述产品实际做什么的动词。这样，我们通过测试完成的就是验证这些能力(capabilities)能正常运作、产品各组件(component)能满足应用的目标。

A代表特质(Attribute)

在开始测试计划或做ACC分析的时候，必须先确定该产品对用户、对业务的意义。我们为什么要开发这个东西呢?它能带来什么核心价值?它又靠什么来吸引用户?

我们通过一个称为特质、组件、能力分析的过程来记录这些核心价值。在某种程度上，是人们选择你的产品而不是竞争对手的产品的原因。

C代表组件(component)

组件是系统的名词，在特质被识别之后确定。组件是构成待建系统的模块。

C代表能力(capability)

能力是系统的动词，代表着系统在用户指令之下完成的动作。它们是对输入的响应、对查询的应答，以及代表用户完成的活动。

能力处于特质和组件的交点。组件(component)执行某种功能(function)来满足产品的一个特质(attribute)，这个活动的结果是向用户提供某种能力(capability)。

ACC的精髓，就是快速简明的列出保证待验证系统能正常运转的那些最重要的能力。

能力一般是面向用户的，表达的是用户眼里系统的行为，往往比特质和组件都要多很多。ACC的前两步遵循简洁法则，而能力则应当描述系统的完整功能，因此基于应用的功能丰富性和复杂性，能力在数量上可以很大。

能力最重要的一个特点是它的可测试性。我们不得不编写测试用例去验证这个能力得到了正确的实现。

下面是一些能力应该满足的特性：

• 一个能力点应当被表达为一个动作，反映了用户使用被测应用完成一定的活动。
• 一个能力点应当为测试人员提供足够的指导，用以理解在编写测试用例时涉及的变量。
• 一个能力应当与其他能力组合。实际上，一个用户故事或用例可以用一系列能力来描述。
• 每个能力都应该链接到至少一个测试用例。如果能力有足够的重要性被记录下来，也应该有足够的重要性被测试。
• 很多能力需要多个测试用例。每当输入、输入顺序、系统变量、使用的数据等存在变化的时候，就需要编写多个测试用例。
• 并非所有的能力都是同等重要的。

风险

风险分析

Google 确定了两个要素:失败频率(frequency of failure)和影响(impact)。

测试人员用这两个要素给每项能力打分，风险实际上是一个定性的相对值，而非一个定量的绝对值。

风险分析的目标不是要给出一个精确的值，而是要识别一个能力与另一个相比风险是大是小。

风险发生频率有4个预定义值：

• 罕见(rarely):发生故障的可能性很小，发生问题后的恢复也很容易。
• 少见(seldom):在少数情况下会发生故障，但是在使用场景复杂度不高的情况下或使用率较低的情况下，发生的可能性非常小。
• 偶尔(occasionally):故障的情形容易想象、场景有点复杂，而该能力是比较常用的。
• 常见(often):此能力所属的特性使用量大、复杂度高、问题频发。

估计风险影响的方法大致相同，也是从几种偶数取值中选择一个。

• 最小(minimal):用户甚至不会注意到的问题。
• 一些(some):可能会打扰到用户的问题。一旦发生，重试或恢复机制即可解决问题。
• 较大(considerable):故障导致使用受阻。
• 最大(maximal):发生的故障会永久性的损害产品的声誉，并导致用户不再使用它。

风险缓解

• 我们可以围绕风险大的能力点编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束。
• 我们可以编写回归测试用例，以确保问题在重现时可以被捕捉到。
• 我们可以编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性。
• 我们可以插入监听代码(instrumentation and watchdog code)，以便更早地检测到故障。
• 我们可以插入代码监听软件，发现新旧版本间的行为变化以发现回归问题。

ACC 的真正威力在于它能用来确定一系列的能力点，按风险排序，然后分配给所有的质量伙伴。

测试用例管理

Google测试用例管家GTCM (Google Test Case Manager)。

GTCM的设计思想是简化测试用例的编写。它提供了一种灵活的标签格式，任何项目可以自行定制，这使得测试用例便于查找和复用。GTCM可以支持一切测试，从经典的测试和验证步骤，到探索式的漫游、cukes(行为驱动的测试用例描述)、用户故事描述等，甚至有一些团队在 GTCM 测试用例中存储代码或数据片段。

BUG生命周期

许多团队在 bug到达的速度超过了其修复能力的时候，干脆不再进行新功能特性的开发。集中精力于少量测试过的代码、增量式的测试以及内部试用，这些有助于将 bug 率置于有效控制之下。

Google 的 bug管理与其他公司有几个关键的不同之处：

• bug 数据库是完全开放的，任意一名Googler都能看到任一项目的任一bug
• 所有人都提交bug，包括工程总监和高级副总裁(SVP)。即使不属于一个产品团队，Googler 也可以提交该产品的 bug
• 不存在正式的自顶向下的确定bug 优先级的流程

Google Feedback团队实现了非常强大的功能，使用了聚类算法来自动识别重复记录并确定最频繁的问题。Google Feedback有一个dashboard 用于显示经过处理的数据，新应用上线之后，成千上万的问题汹涌而来需要精简到10个左右的主要的、共性的问题。

TE招聘

混合模型：既要考察一般的计算机科学和技术技能，也要考察候选人的测试潜力。编程知识是必需的，但只限于那些完成前述 TE 工作需要的水平：修改而非创建代码、设计端到端的用户使用场景的能力等。再加上TE 工作本身需要的一些特定的能力，如沟通、系统级别的理解以及用户同理心。

TE 面试的最后一环是看候选人是否具有“Google 味儿”。我们需要的是有好奇心、充满热情的工程师，他们不会满足于简单完成被分派的工作，而是会进一步探索各种可能性，尝试工作描述之外的东西。工作职责自然要完成，但是生活和工作的意义在于最大限度地对外部世界产生影响。我们需要的是那些与现实世界和计算机科学团体紧密联系的人。我们需要的是能够与其他人和睦相处、合作愉快的人，是能够影响Google 文化的人。我们需要的是愿意持续学习和成长的人。我们也需要那些带来新鲜思想和经验的人，他们丰富了Google 的人才库。Google的座右铭是“不作恶”，我们希望他们在看到问题时能直言不讳。

Google的原则是宁缺勿滥。我们希望 Google 成为大家愿意为之工作多年的一个公司。

在Google管理TE在于如何激励，而非指令;在于保持凝聚力和一致性，同时又要鼓励创新和实验，信任大家尽可能自己做出正确的决定。

Google的测试管理更多的是激励，而非强悍的管理;更多的是战略指引，而非频繁的督促检查(每天、每周等)。

Google管理的核心是领导力和洞察力、协商、外部沟通、技术水平、战略规划、招聘和面试、完成团队绩效考核。

Google的测试总监、经理和其他领导者都必须在充分信任工程师和确保他们不会发生重大事故或浪费时间之间寻找平衡。Google专注于投资大型的、战略性的方案去解决大问题，避免开发重复的测试框架、或是过多的投入在小型测试上，而应该鼓励宝贵的工程师资源用于更大型的测试执行和基础平台的建设。

Google管理测试工程团队的方式，可以用海盗船来做类比。测试工程师的天性就是质疑、要求确定性的数据、不断评估主管或经理的指令。要靠技术洞察力、令人兴奋的技术冒险、有趣的停靠港口来带领团队。

Google有几种不同类型的主管和经理:技术负责人(tech lead)、技术主管(tech lead manager)、工程经理(engineering manager)和总监 (director)。

• 技术负责人(tech lead)：测试技术负责人出现在大型项目的大型团队里，里面有大量的 SET 和 TE，他们参与解决共同的技术问题或是共享相同的基础平台。他们一般不会管人。他们是当你遇到技术或测试问题时要求助的人。
• 技术主管(tech lead manager, TLM):当技术负责人同时也被正式任命为相关工程师的经理时，就被称为技术主管。这些人一般德高望重、能力卓著。他们通常在同一时间只关注一个项目。
• 测试工程经理 (test engineering manager):工程经理监督跨团队的技术工作，几乎没有例外，都是一级一级晋升上来的。工程经理通常管理12~35人，具体数量取决于工作的复杂性。他们负责共享跨团队的工具和流程，根据风险评估安排资源，并指导招聘和面试。
• 测试总监 (test director):测试总监数量很少，他们会带若干测试工程经理、跨几个产品线，负责整体的测试工作，推动战略性的、有时是转型性的技术架构或测试方法的实施。他们的关注点在于怎样通过质量和测试去帮助业务(粗略的成本分析、收益分析等),并经常抛头露面参与业界同行的交流和分享。测试总监一般有40~70名下属。
• 资深测试总监(senior test director):只有一个，他负责保证公司层面的统一的职责描述、招聘、外部沟通和总的测试战略。他日常的工作包括分享最佳实践，建立和推动新的大动作如全局构建、测试基础平台、静态分析，以及跨越不同产品、用户问题和代码库的测试活动。

1. 技术型:测试经理、尤其是测试主管的定位是技术型人才。他们应该会编写代码、评审代码，并且总应该比团队的其他人更懂产品和客户。

2. 协商:不可能什么都测，测试无止境。面对经常性的资源申请和其他要求，工程经理和总监需要掌握拒绝的艺术、以理服人(politely say no with great reasoning)。

3. 外部沟通:测试管理层还要经常安排外包测试事宜，组织与外部同行的交流，以及面向更大的社区建立论坛，用于测试工程问题的讨论和分享等。

4. 战略性举措:测试主管和经理经常会问自己，有哪些事情别人做不了但我们能做?如何扩展和共享我们的测试架构来帮助大家，携手共创更美好的互联网?如果合并资源，投资长期的赌注会怎么样?支持这些战略性举措需要业务和技术上的洞察力、需要经费预算、需要顶住其他工作对测试资源的竞争，这确实得是一份全职的工作。

5. 绩效考评:Google的绩效考评综合了同事反馈和由主管、经理推动的跨团队比照，每季度一次。重点是你最近做了什么事情?在质量和效率上、对用户而言产生了什么影响?

经理还会帮助团队成员设定季度和年度的OKRs (OKR 代表 Objectives and Key Results，即目标和关键结果。在Google，关注可衡量的指标。达到70%意味着你可能设定了较高的目标，然后努力工作去实现它。达到100%意味着你可能在设定目标时不够有进取心)。他们要保证有一些高目标的OKR，即使不必或可能不会达成，这些目标仍能起到促进在做计划时力争上游的作用。

作为测试领导层，经常需要妥协，并能尊重个体 SET 和 TE 的聪明才智。Google领导和管理的一个标志是辅导和指导(mentoring and guiding) 下属工作，而不是直接下命令(dictating)。

维护模式的测试(Maintenance Mode Testing )

Google 一向以尽早交付、经常交付、尽快失败(shipping early and often, and failing fast)闻名于世。资源也会冲向那些最高风险的项目。

在把一个项目置于质量维护模式的时候，我们需要减少保持质量所需的人工干预的比重。代码会随着时间的流逝而变坏、出错。这同时适用于产品代码和测试代码。维护模式下，大部分工作是监控质量，而不是寻找新问题。后来的测试人员有必要给测试瘦身。

• 总是通过的测试，淘汰!在高优先级的测试都来不及做的时候，低优先级的测试，淘汰!
• 确保正确理解即将被淘汰的测试用例。从即将淘汰的领域里，挑选几个有代表性的测试。如果可能就与原作者聊一聊，理解其意图，避免失误。
• 我们把释放出来的时间用于测试自动化、高优先级的测试或探索式测试。
• 我们还会抛弃之前可能发生过误报或者行为反常的自动化测试一它们只会发出错误警报，浪费工程师的时间。

进入维护模式前要考虑的要点：

• 撤离之前，把困难的问题解决掉，而不是轻易放过。
• 即使一个小型的、负责端到端测试的自动化测试集，也会以近乎为零的成本提供长期的质量保证。如果没有，一定要建立一个这样的自动化测试集。
• 留下一份how-to 文档，以便公司的任何人都可以运行你的测试集，这也会减少你在将来繁忙时还被突然打扰的可能性。
• 确保有一个问题解决通道 (escalation path)，愿意承担一些责任。
• 时刻准备着返回到你曾经工作的项目里帮忙，这对产品、团队和用户都有益。

BITE 实验

BITE 代表 Browser Integrated Test Environment (浏览器集成测试环境)，目标是把尽可能多的测试活动、测试工具和测试数据集中到浏览器和云里，并在上下文中呈现相关信息，从而减少分散操作的麻烦，使得测试工作更高效。

零成本测试

• 成本几乎为零。
• 瞬间可得的测试结果。
• 极少或者无需人工干预。
• 非常灵活，因为没有万灵丹。

现有免费模型测试流程要点：

• 通过GTA 进行测试计划:基于风险的、快速的、可以自动化更新的。
• 测试覆盖度:每当一个产品部署了新版本，bot 就会连续抓取网站、索引内容、扫描差异。
• Bug评审:当产品的差别被发现时，它们会被自动的转给人工去做快速判断。
• 探索式测试:频繁的探索式测试由外包测试人员和早期用户执行。
• Bug提交:只需要点击几次鼠标就可以提交 bug,并且大量相关数据被自动附上，包括问题的精确位置、截屏和调试信息。
• Bug triage 和调试:开发或者测试经理能看到近乎端到端的免费测试流程实时的bug趋势图、需要用来分析失败原因的丰富的bug 数据，甚至是bug 发现过程的一键重放。
• 部署新的版本并回到第一步。重复上述步骤。

四、测试工程经理

测试工程经理是作为独立贡献者的一个技术岗位，负责所有的支持团队(开发、产品管理、产品发布、文档等)之间的联络。

测试工程经理需要拥有技术能力、领导能力和协调能力。他们通常都是成长于Google的内部团队，空降的员工通常(但不是全部)都作为独立贡献者。

想成为优秀的测试工程经理：

• 第一条建议就是去了解你的产品。对于与被测产品相关的任何使用问题，测试工程经理都应该是专家。

• 第二条建议是知人善用。

在 Google的软件测试项目中，问题不能简单地通过增加人手来解决，需要使用工具并使其流水线化。不允许不必要的工作存在，也不需要不产生价值的改进。

测试工程经理有职责优化整个过程。测试工程经理如果对产品有深入的理解，就能清楚地找到最高优先级的工作，对相关模块进行合理的覆盖。测试工程经理如果对他的团队成员足够了解，就能根据具体的测试问题安排具有最适合测试技能的员工。

影响力

每位工程师的个人目标都应该是建立影响力。测试团队的目标也应该是建立影响力。有责任确保测试团队影响力的那个人就是测试工程经理。

测试工程经理还有一项工作就是处理跨团队的沟通。

选用不合适的人来填充名额永远要比等待合适的人员要糟糕。只选用最好的人，不能动摇。

Gmail项目人员配备：

• 20%的测试人员进行探索式测试。任何关注用户体验的产品都需要探索式测试。
• 30%的测试工程师关注于产品的整体性测试，他们和测试开发工程师一起来保证测试的效果
• 50%的工作，是测试开发工程师开发相关的自动化测试和工具，以保持代码库的健壮和提高开发人员的工作效率。

Gmail项目测试经验：

• 使用与应用程序开发语言相同的编程语言来编写测试。
• 让负责开发新特性的人同时负责相应测试的执行，他需要对漏掉的测试负责。
• 关注测试基础设施的建设，让测试的编写和执行非常容易，甚至比忽略它们还要容易。
• 20%的用例覆盖了80%的使用场景。把这20%自动化而别管剩下的。把那些测试通过手工完成。
• 这里是Google，速度才是王道。确保我们的产品足够快。进行性能分析以便于可以证明给所有人看。
• 与开发团队的沟通至关重要。
• Google的DNA里富含着创新精神。测试团队也应该被看做创新者。发现重要的问题并能创造性地提出解决方案。

测试本身就是一种平衡的艺术。

• 一方面，我们必须能让产品发布，对每个发布版本做所需的检查以保证没有问题。
• 另一方面，我们必须开发优秀的自动化测试，并为自动化投入开发自己的框架和基础设施。
• 再有，我们需要围绕“开发一构建一测试一发布”的流程模式计划和安排我们的工作。
• 还有，测试专家们不断向世界展示他们进行测试的最新方法。

五、Google软件测试改进

Google的测试流程可以非常简练地概括为：让每个工程师都注重质量。

质量是内建的，而不是外加的。

• 这就带来了第一个致命的缺陷：测试成了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。

• 第二个致命缺陷，还是与开发和测试的组织结构分离有关。测试人员更关注自己的角色，而不是他们的产品。用户爱上的是产品，而不是开发产品的流程。

• 第三个致命的缺陷，是测试人员往往崇拜测试产物(test artifact)胜过软件本身。测试的价值是在于测试的动作，而不是测试产物。测试人员必须把产品放在第一位。

• 最后一个致命缺陷也许是最深刻的。产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题?答案是:几乎必然发现。

是谁在做测试并不重要，关键是进行了测试。

内部试用者、可信赖的测试者、众包测试者，以及早期用户都可能比测试工程师更容易发现 bug。实际上，让TE做的测试越少，支持其他人做的测试越多，效果就越好。

在Google，SET的角色越来越像开发，而TE的角色向着相反的方向越来越像用户。

SET 没有未来。SET 就是开发。SET 直接负责很多功能特性，如可测试性、可靠性、可调试性等。SET 就是负责这些功能特性的开发工程师。测试特性应该由团队的新成员负责，特别是那些资历尚浅的员工。

对优秀测试工程师TE的需求之大前所未有。然而，这种需求即将达到顶峰并会迅速下降。传统意义上进行测试用例的撰写、执行、回归等工作，它们实际上已经有了更为全面而且低成本的形式。

测试工程会转型成测试设计。快速规划出测试范围、风险热图和应用程序的漫游路线。然后，内部试用者、可信赖的测试者、早期用户或者众包测试者提交反馈，由测试设计师来评估覆盖率，计算风险影响，确保发现的问题不断减少，并相应地对测试活动进行调整。这些测试设计师还可以识别需要专业技能的地方，比如安全性、隐私、性能和探索式测试，并安排具有这些技能的人通过众包的形式完成工作。还会需要开发或购买工具来收集、分析这些提交上来的数据，但他们的工作中没有测试用例编写，没有测试执行，没有实际的测试行为。这个工作需要的是规划、组织和管理近于免费的测试资源。

测试工程师会转变成像安全工程师这样的专家型角色，或者变成测试活动的管理者，而那些具体的测试活动则由其他人来完成。

测试总监和经理这些技术型的主管，将会更多地转向成为诸如杰出工程师这样的个人角色。他们将作为思想领袖，为维系松散的测试工程师和负责质量的软件工程师的关系而存在，但不会最终为某个特别项目的质量或管理负责。

测试基础设施会最终整体迁移到云端。测试用例库，测试代码的编辑、录制和执行都将在一个网站或通过浏览器插件完成。测试编写、执行和调试需要使用与被测的应用程序本身相同的语言和环境才最为高效。“Web端优先 - 本地端从属”策略。