《Google软件测试之道》这本书2013年就已经出版了（英文版出版于2012年）。以前幼稚地以为，开发人员对于测试方法论没必要系统的学习，只要知道怎么与测试人员一起工作就好了，所以一直没有读。最近由于一些机缘巧合，拜读了一下，大有收获。
注意，本文并非《Google软件测试知道》的读书笔记，里面有一些笔者个人思考的结果，如果想了解原书观点，还请阅读原书。
测试之道
“道”即是世界观。每次听到新的道，都是一次对世界观的颠覆。这种打通任督二脉的爽快，正是笔者每次阅读的动力。《Google软件测试之道》书名中的“道”字其实是意译的结果（英文原版书名为《Google是如何测试软件的》，用来致敬《微软是如何测试软件的》），但是却非常贴切。
让我们开始毁三观吧。
如果对于测试只能问一个问题，然后围绕这个问题的答案来安排所有测试活动，笔者认为，这个问题应该是“测试的目标是什么？”。回答了这个问题，也就理解了测试之道。
有人说测试是为了发现产品中的问题，更有经验的人说测试是为了保证产品的质量。笔者认为，这两者都不贴切。测试的目标，跟任何企业活动的目标一样，是减少企业的成本、增加企业的收入，从而提高企业的利润，简而言之，就是
让企业赚钱。换句话说，
不能帮企业赚钱的测试就是耍流氓（注，这里的钱指广义的企业价值，而非狭义的货币资本）。
有人说，这不是废话吗？还真不是废话。因为只有这个目标，才能真正指导决策者在两难的环境下做出正确的抉择。举个例子，自动测试用例该不该写？看起来这似乎是一个绝对政治正确的说法，实则不然。我们套用前面提出的测试的目标，就很容易发现自动测试用例不见得是一件好事。如果一个项目还在原型阶段，存在很大被终止（出于市场、用户习惯等原因）的可能，这时编写自动测试用例就是完全没有必要的。
在《Google软件测试之道》中有着大量的例子和指导方针。这些解决方案的思路都是围绕着“减少成本、提高收入”来展开的。
测试之术
了解了“道”，也就有了行动纲领。那么，在测试的工作中，该如何应用呢？《Google软件测试之道》一书中，给出了大量的指导方针和示例。笔者在此摘录其中几个笔者曾经有所疑惑的问题。
测试应该由谁进行？
有人说测试就是测试人员的事；有人说开发人员就应该保证自己代码的正确性，因此开发就应该进行测试。原作者给出的答案是：以上都不对。前者太狭隘，后者太理想主义。在实践中，绝大多数开发人员是不能站在用户的角度看问题的。这是一个思维模式的问题，并不是喊喊口号就能解决的。更具可操作性的办法是，专门招聘能够站在用户角度看问题的人。Google的做法是三权分立：开发辅助团队（测试开发工程师）负责搭建测试的基础架构，开发人员负责编写测试代码，而由测试工程师负责站在用户的角度进行自动化或手动测试。
怎么决定测试什么？
由于人的精力有限，在从事每一个行动前，找出行动目标，比展开行动更重要。即使是同一款产品，不同特性所分配的精力也是不同的。那么，如何决定怎么分配精力呢？答案是，根据测试之道，最能让企业赚钱的产品特性，就应该分配最多的精力。
Google在实践中，为了发现哪些产品特性更重要，采用了列举ACC的方式。A指产品的属性（attribute），表示产品对用户的核心价值；第一个C是组件（component），表示产品系统所组成的模块；第二个C是能力（capability），表示系统能完成的动作，通常是一个产品属性和组件的组合。如果一个能力没有对应的产品属性，那么这个能力是没什么用的。利用这一点可以验证产品特性是否重要。
了解了产品的能力之后，根据产品能力来安排精力，这种做法最有效率。
测试什么时候开始？
系统的质量是内建的，不是外加的。外部的测试只能发现问题，不能改变系统质量，就像温度计不能帮人解暑一样。因此，测试的效能主要体现在两点：一是保证早期决策的正确性以影响后面的决策，这是因为，后面决策往往依赖于前面的决策，前面决策失误所造成的影响要远大于后面决策；二是保证系统质量不会明显下降。无论是哪一种，都要求测试必须尽早加入到产品当中。一旦测试对于产品出现意义（见前文是否应该编写自动测试一例），需要编写测试，那么测试的关键节点（提交，运行）就应该跟开发的关键节点同时进行，而不是滞后。
如何让开发人员编写测试代码？
作为一名开发人员（曾经是，现在也是），深切地能够体会到当有人强制让你编写测试时的那种痛苦。开发人员不愿意编写测试代码主要有两个原因：投入高、效果差。这并不是开发人员“玻璃心”或者性格问题造成的：如果编写测试代码要占掉比编写代码多很多的时间，而且还要经常花精力来改正一些失败的测试，又看不到对产品质量的提升，任谁都不会喜欢去做这样的事情的。
要解决这个问题，要多从流程上下功夫：
- 不盲目追求代码覆盖率。要认识到代码的变动机会是不同的。变动机会大的代码代码覆盖率越高，维护成本越高。如果维护成本高于收益（不能帮企业赚钱的测试就是耍流氓）的时候，就应该停下来反思一下了。在Google测试能力评级的最高级标准中，整体覆盖也仅有60%而已。
- 根据产品能力（见“怎么决定测试什么”一条），删掉不重要的测试代码。如果认为测试代码留在产品里所带来的维护成本，大于所带来质量提高的收益，大胆地删掉他们吧。
- 即时加入重要功能的测试代码并修正失败的测试。这样开发人员可以知道，测试代码真的在保护着他们正在开发的应用的质量，而不是做做样子的面子工程。
如何分配各种自动化测试的比例？
我们平常说的单元测试、集成测试与端到端测试，在Google被分为小型测试、中型测试和大型测试。简单来说，小型测试不依赖外部系统，全靠mock，用于验证代码单元功能；中型测试会依赖外部系统，但是并不涉及多UI或者网络服务的对接，用于验证多模块之间的交互；大型测试包含多个系统，通常用于验证系统作为一个整体的工作。小/中/大测试的分配比例为70%/20%/10%。
以上只是笔者的几点心得。原书提供了大量可操作的流程和工具，实在是不可多得的一本好书。