伟大公司的“理想”测试法

很多时候，人们总会说某些理念或做法太过“理想化”，其实只是低头走路太久，忘记了抬头看天而已。如果我们心中没有理想，又如何可以创造出伟大的成就呢？而当下在测试领域，谷歌就是坚持理想实现了书中理念的典范。

p12~13 小型测试、中型测试、大型测试……mock和fake……小型测试主要尝试解决的问题是“这些代码是否按照预期的方式运行”……中型测试尝试去解决的问题是，一系列临近的模块互相交互的时候，是否如我们预期的那样工作；这种端到端的使用场景以及在整体产品或服务之上的操作行为，即是大型测试关注的重点；重要的是，在Google测试人员使用统一术语来谈论他们测试的是什么，以及这些测试范围是如何划分的。

p15 测试框架（test harnesses）、测试通用测试（test infrastructure）、模拟设施和虚拟设施（mock and fake）

p15 对于功能代码而言，思维模式是创建，重点在于考虑用户、使用场景和数据流程上；而对于测试代码来说，主要思路是去破坏，怎样写测试代码用以扰乱分离用户及其数据。

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

p19 最小化对平台的依赖。所有工程师都有一台桌面工作机器，且操作系统都尽可能地与Google生产环境的操作系统保持一致。……所有对平台有依赖的代码，都会强制要求使用公共的底层库。

p20 使用统一的运行平台和相同的代码库，持续不断地在构建系统中打包。

p21 服务之间的接口需要在项目的早期就确定下来。……这些接口一般都不会真正实现，而只是做一个虚假的实现。

p22 在未来可能失败的项目中投入测试资源来构造测试方面基础设施，这是一种资源浪费。

p24 所有Google项目都有设计文档。这是一个动态的文档，随着项目的演化也在不断地保持更新。

p26 Google protocol buffer （http://code.google.com/apis/protocolbuffers）

p29 提交队列（submit queue）的主要功能是保持“绿色”的构建，这意味着所有测试必须全部通过。这是构建系统和版本控制系统之间的最后一道防线。

p48 检验一个项目里小型测试、中型测试和大型测试之间的比率是否健康，一个好办法是使用代码覆盖率。……Harvester……

p51 持续集成系统使用构建系统中的构建依赖规则。

p63 “SET的招聘” 对于候选者，最好去考察如何思索问题的解决方案，而不是解决方案本身的实现上体现得多么高雅。……只有一件事情需要去做而我正在做这个事情，这个事情就是写代码。SET不会遵循这样的世界观。我们希望先把问题搞清楚。

p70 我认为最艰难和最有趣的挑战总是出现在设计阶段。

p98 与其询问他们关于某个模糊概念的看法，不如拿一个明确的结论来引起辩论。

p101 Google Test Analytics支持上述基于分类赋值（非常罕见、很少、偶尔、经常）的风险分析。……知道A比B风险大就足够了，不需要过分关心它们的具体风险值。

p120 bug分类过程（bug triage process）……聚类算法来自动识别重复记录并确定最频繁的问题。……需要精简到10个左右主要的、共性的问题。

p120 修复会产生一个变更列表（CL），CL排队去接受评审，一旦得到批准，就进入构建目标队伍中。

p121 TE的招聘尤其困难，因为最好的TE不是那些基础算法、定理实现、功能实现上的牛人。……TE是稀缺个体，是技术人，关注用户，能在系统级别和端到端的视角上理解产品。他们是无情的、伟大的谈判专家，更重要的是，他们富有创造性、善于应对模糊性。

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

p124 一开始，我们考察测试资质。……我们寻找的是对于事物结构、对于变量和配置的组合的各种可能性和意义的好奇心。我们寻找的是关于事物应该如何工作的强烈感觉，以及清晰表达的能力。我们还会试图寻找很强的人格魅力。

p127 面试时试图考察的另外一个关键特征，是TE所需要具备的处理模糊性、反驳糟糕想法的能力。……TE面试的最后一环是看候选人是否具有“Google味儿”。

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

p131 TE到SET、SET到SWE是最为常见的。

p131 OKRs（Objectives and Key Results），也即目标和关键结果。

p134 质量机器人（Quality Bot）实验

p143 我的反应是很Google式的：表面同意，但私底下一切照旧。

p145 这个特性有单元测试用例，但只有bot逮住了这个问题，因为它测试的是真正的网页。

p145 BITE代表Browser Integrated Test Environment（浏览器集成测试环境）

p151 我们实现了一个称为Record and Playback framework（RPF）的纯Web的解决方案，是用纯JavaScript实现的……在回放的时候，RPF首先查找精确匹配，在找不到的情况下查找近似匹配。……处于安全原因，某些涉及钱的场景无法通过web API自动化。

p153 这个做法已经成功地用于众包测试，外包测试人员在安装了BITE的浏览器中执行测试，测试任务的分发通过BITE进行。

p165~170 “Lindsay Webster的访谈” 对于一个新项目，我首先要站在用户的角度了解这个产品。……从头到尾的理解产品。……关注项目的状态，特别是质量状态。……只有熟悉了团队的全貌，才能真正有效的展开工作。……我会了解他们沟通的方式和对测试人员的期望。……询问他们对测试的期望，会帮助发现开发团队没有测试过的内容。……第一件事是把应用分解为合理的功能模块。……排列测试的优先级……再次检查Bug库……按照优先级顺序更加细致地遍历所有模块，创建用户故事……通常会编写测试用例并链接到相应模块的用户故事。……有了测试集合，我接下来会通过再次检查bug和应用来寻找覆盖度上的不足。……有了这些基础材料，我的工作通常只是维护和更新：更新测试用例，增加新特性的文档，更新变化了的模块的截屏或视频。最后，观察哪些bug遗漏到了生产环境，会告诉我们测试覆盖上的不足。……我把自己变成用户，就这么简单。……换句话说，测试要清楚地指出当做之事。……开发经常会低估我的工作，知道我们在一起工作了几个月之后，他们才会改变想法。我在完成了上述工作之后，将邀请整个团队开会，介绍一下我设定的测试流程。……当我坦诚地指出某些组件或领域的测试不应该由我负责，而应该由他们自己负责的时候，开发反而更加看重我的工作了。……这就是为什么要按照一定的优先级处理应用的各种功能和环境支持。……重要的是，要维护团队的这份信任——如果我强烈感到发布时机未到，那么这可能也是他们希望的。……当然，还是有一些不那么尊敬我的工作的SET，但他们就像有类似想法的开发人员一样，不曾与我或其他TE一起工作过。一旦发生了合作，他们的态度通常会迅速的转变。

p174 “Apple Chow的访谈” 遵守70-20-10法则：小型的用来验证单个类或功能的单元测试占70%，中型的用来验证一个或多个应用模块之间集成的测试占20%，大型的高级别的用来验证完整应用的测试占10%。

p178 想成为优秀的测试工程经理，第一条建议就是去了解你的产品。……第二条建议是知人善用。

p179 不能仅仅依赖于某位明星测试人员。……必须要沉淀为可用的工具，或者总结成一套方法，这样可以帮助其他人也能走上这条成为明星的道路。

p181 在Google，对工程师最好的褒奖就是称赞他的影响力。而对于测试工程经理来说，就是建立一支有影响力的团队。

p183 多年来，通过不断地聆听，我发现最有力的问题就是“为什么”。

p184 所以经验就是解决掉一些难题来赢得尊重。

p187 我们更专注于预防bug而不是检测bug，这为我们带来了巨大收益。

p193 目前我还是倾向于使用一种综合的方式，混合使用开发自测、脚本化测试、探索式测试、基于风险的测试、自动化功能测试等多种方法。

p198 我们经常由于太难保证后台系统的质量而不能按时发布。后台系统不能出现差错，因为它影响太多产品线了。……在后台系统中如果仅仅使用端到端测试，要是不能发现问题，就会导致连锁反应。

p200 一般来说，我首先会让我的团队思考，“对被测系统来说，什么是最为重要的东西？”

p201~203 “Ashish Kumar的访谈” 整个工具集包括：源码工具；开发工具；测试基础架构；本地化工具；度量、可视化和报表。……大规模的持续集成（是我一开始不看好但最后成功的）……从小做起，不断证明其价值，然后当项目体现价值以后扩大规模。……特别重要的一件事，是要关注团队里新来的开发工程师必须使用到的开发环境。要让代码的获取、编辑、测试、运行、调试和部署都非常简单。

p214~216 “James Whittaker访谈” 第一条，是先花一些时间来观察学习。……聆听而不是直接发言，询问而不是直接尝试。……第二条建议，“兄弟，我知道你在来Google之前已富盛名，但是在这个公司里，你还什么成就也没做出来呢。”……先虚心学习，再在一线做出成绩，然后开始寻求创新的方法。……其他公司要想仿效Google的做法，应该从这四个方面做起：技能、稀缺性、自动化和迭代集成。这就是Google测试的“秘方”。

p219~221 “Google流程中的致命缺陷” 第一个致命的缺陷：测试成了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不去做测试。……第二个致命缺陷，还是与开发和测试的组织结构分离有关。……第三个致命的缺陷，是测试人员往往崇拜测试产物（test artifact）胜过软件本身。……最后一个致命缺陷也许是最深刻的。产品经过最严格的测试发布以后，用户有多大可能仍然发现测试中遗漏的问题？答案是：几乎必然发现。……是谁在做测试并不重要，关键是进行了测试。……SET的角色越来越像开发，而TE的角色向着相反的方向越来越像用户。……质量需要每一个任的贡献。

p222 测试的技能被平均地分散到各个层级的开发工程师身上，而不是集中于测试开发工程师（SET）那里。

p223 测试工程会转型成为测试设计。……这个工作需要的是规划、组织和管理近于免费的测试资源。……测试工程师会转变成像安全工程师这样的专家型角色，或者他们会变成测试活动的管理者。

p224 技术型的主管，将会更多地转向成为诸如杰出工程师这样的个人角色。……作为思想领袖，为维系……关系而存在……测试活动应该对人们具体工作的产品负责。

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

==========
徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件开发、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。