《Google软件测试之道》读后感

一本关于测试传道授业解惑方面的书，书中阐述了Google主要采取的测试模型（ACC等）、自动化测试、探索式测试（Exploratory Testing）等方面，同时也讲述了Google在测试组织方面的进化及各岗位的职责分工及协作。经过努力，Google的测试部门已经从原先的测试服务部门进化为工程生产力部门（Engineering Productivity)。
从本书能感觉到Google是把自动化测试、开发测试工具提高效率作为测试的首要任务。提高开发和测试的生产力是测试最为关注的问题，所以Google入职的测试员工在技术方面的能力是丝毫不亚于相关的开发人员。测试要在组织中持续灌输质量是全员负责的概念，在开发阶段就必须做好相关的单元测试，通过每日构建，能把问题提前发现、及时处理，不把有问题的代码带到代码库。

为了支持这些，Google测试工程师在基础设施、测试框架（包括单元测试框架、自动化测试框架等）的设计、开发投入非常大的精力，主要目的就是方便开发同事能在测试框架内方便的进行相关测试、问题定位和修复。所以，在Google，产品进入手工测试的阶段的时候，大部分的单元测试、集成测试，甚至端到端的系统测试都已经处理完毕，在手工测试阶段更多的是进行一些探索性测试，发挥人的主观能动性。按照Google的经验值，测试的成本遵守70-20-10的原则，单元测试占70%，集成测试占20%，系统测试占10%。
书中也提到了Google在测试分析、计划、编写测试用例、执行等方面的管理。Google采用的ACC矩阵表模型，能把测试需要关注的特质（A:Attribute）、组件（C:Component）、能力（C:Capability）三方面在一个矩阵中体现，相关的测试用例、风险分析也能整合在一起，方便了测试的过程管理，避免了目前测试计划对实际工作没有任何指导意义的弊病。

Google在测试工具方面的开发，包括BITE（Browser Integrated Test Environment）、QualityBot，BITE是Chrome的一个扩展，使工程师的注意力集中在实实在在的探索式测试和回归测试上，而不是流程和技术细节。它把测试、用例管理、BUG提交、BUG跟踪、录制/回访等功能整合在一起，避免了测试人员不断在应用和Bug管理平台之间切换的问题。质量机器人（QualityBot）能自动比较网页在不同Chrome版本之间显示和渲染的区别，能区别到像素层面，这样方便测试人员在Chrome版本升级的时候，快速发现对相关网页的影响。
本书一个比较特别的地方就是，书中大量采用了对Google各层面员工的采访，在增加趣味性的同时，也使本书的结构显得有点凌乱。

参考资料

    测试建模 Google ACC http://www.cnblogs.com/liangshi/archive/2012/04/23/2465897.html  
    Make 命令教程  http://www.ruanyifeng.com/blog/2015/02/make.html

文章摘录

• 测试需要思考：如何在制约质量和快速发布之间寻找平衡。
  
• 变更Google测试的首要问题是重新定位身为测试人员的意义所在。...一个团队能编写出高质量软件的唯一途径就是全体成员共同对质量负责。
  
• 维持现状的惯性导致任何变革都变得非常困难。
  
• 这里是Google，如果你有想法，尽管去做就是。
  
• 把测试和开发割裂开来，看成两个单独的环节，甚至是两类截然不同的问题，这种做法是错误的，沿着这条路走下去意味着什么问题也解决不了。
  
• Google是一家以创新和速度为基础的公司。
  
• 测试团队更像是小而精的特种部队，我们依靠的是出色的战术和高级武器。
  
• 质量不是被测试出来的---这句话看似陈词滥调的话却包含一定的道理。
  
• 质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。我们已经成功的将测试实践融入为开发过程的一部分，并创建了一个增量上线的流程。如果一些项目在线上被证实的确是Bug重重，它将会被回滚到之前的版本。在确保不出现回滚级别Bug发生的前提下，预防了许多客户问题的同时，也很大程度降低了专职测试人员的数量。在Google，测试的目标就是来判断这种预防工作做的怎么样。
  
• 解铃还须系铃人：You build it,you break it.
  
• 这种测试人员在不同项目之间的借调模式，....另外还能保证一个好的测试想法可以快速在公司内部蔓延。
  
• Google经常在最初的版本中只包含最基本的可用功能，然后后续快速迭代过程中得到内部和外部用户的反馈，而且每次迭代过程当中都非常注重质量。一个产品在发布给用户使用之前，一定要经理金丝雀版本、开发版本、测试版本、Beta版或正式版本。
  
• 小型测试涵盖单一的代码段，一般运行在完全虚假实现（Fake）的环境里。中型测试涵盖多个模块且重点关注在模块之间的交互上，一般运行在虚假实现环境或真实环境中。大型测试涵盖任意多个模块，一般运行在真实的环境中，并使用真正的用户数据和资源。
  分别对应单元测试、集成测试、系统测试。
  
• 打包是一个过程，包括将源代码编译成二进制文件，然后把二进制文件统一封装在一个包里面。
  -为了保证单独的服务可以并行的开发，服务之间的接口需要在项目早期就要定下来。这样，开发者会依赖在协商好的接口上，而不是需要依赖在特定开发的库上。为了不影响服务级别之间的测试，这些接口早期一般做一个虚假的实现。
  
• 审阅设计文档的时候应该有一定的目的性：完整性、正确性、一致性、设计、接口与协议、测试。
  
• 可以做代码编译、测试执行、数据存储、报表展示的通用测试框架。Google工程师专注于测试程序的编写，运行的细节留给通用基础执行框架。
  
• 与其询问他们一个关于某个模糊概念的看法，不如拿一个明确的结论来引起大家的争论。通常来说，都是排除容易下定义难。
  
• Bug的分级：
  P0 -Must have： 如果缺失，产品不能发布
  P1 -Should have： 如果缺失，产品能发布，但不能达到预定目标（功能/性能）
  P2 -Nice to have： 做了则更好
  P3 -Neutral： 对产品没有明显的好处，用户不在意
  
• 那些能反驳或者质疑规格说明书的人，往往在工作中有优异的表现。
  
• Google管理的核心是领导力、洞察力、协商、外部沟通能力、技术水平、战略规划、招聘和面试、完成团队绩效考核。
  
• 在Google，我们关注可衡量指标，达到70%，意味着你制定了比较高的目标，然后努力工作去实现它。达到100%，意味着你可能在设定目标的时候不够有进取心。
  
• 我把自己变成用户，就这么简单。我认为，除非能以某种方式将自己置于用户的视角，否则就不可能真正有效的对一个应用进行测试。
  
• 测试的成本遵守70-20-10的原则，单元测试占70%，集成测试占20%，系统测试占10%
  
• 所以经验就是靠解决一些难题来赢得尊重。
  
• 我还是坚信只应该关注最重要的事情。
  
• 很多年轻的测试工程师，他们编写了很多的测试，但是忘记思考为什么要写这些测试，怎么让这些测试为整理目标，为产品服务。
  
• 团队建设完毕之后，我给他们定下了基表：创造价值，最好还能找到可以复制创造价值的方法。通过价值来驱动团队。
  
• 综合的测试方法：开发自动、脚本化测试、探索性测试、基于风险的测试、自动化功能测试等。
  
• 工程开发工具：集成开发环境、代码审查系统、构建系统、源码控制、静态检查、通用测试框架等等。
  
• 要超出自己习惯的舒适地带。
  
• 随着敏捷开发、持续构建、早期用户介入、总包测试、在线软件交付的不断兴起，软件开发的问题也已经彻底改变。
  
• 测试执行框架、自动构建系统、自动测试、持续集成、版本管理