我读完了一本非常有趣的书，《How Google Tests Software》。我是从一个对这本书的作者之一， James Whittaker，的IT访谈中听到这本书的。访谈的内容实际上对这本书里的很多关键点做了很好的概述，但我仍然从读这本书的过程中发现了很多很有价值的内容。
这并不是一本讲“如何做”的书，并不是在说关于如何测试软件的具体步骤。相反，它站在一个更高层面上，大部分的篇幅都在致力于描述谷歌公司里各种不同的测试角色。从这个访谈以及这本书里，我感觉有三个独特的主题呈现在我面前。
测试工具的规模
谷歌对测试/软件质量投入了大量的精力，给人非常深刻的印象。他们为自动化编译，自动化回归测试，延迟测试，代码审查和用户反馈所制作的各种基础工具让人眼花缭乱。当这些复杂的工具和各种复杂的谷歌产品混合在一起时，你很难想象这样一个相互交织的软件世界里各部分是如何发挥作用的。同时，你也很容易看出谷歌的产品有多么的复杂，如果没有这些他们自己开发出的测试工具，这些产品是不可能完成的。
测试行为实用主义
对于测试，谷歌给人的感觉似乎是非常实用主义。如果某个自动化测试很难维护，他们就会丢掉它们。如果某个软件功能不是高风险的或高影响力的，他们甚至不在意是否有测试(或者更好的做法是砍掉这个功能)。相较于在软件完成后写测试计划，谷歌却是专注于ACC(属性，组件，能力)模型。按照这三个概念，一个软件应用会按下面的方式描述。
- 属性：系统中的形容词，通常是销售、市场关注的(例如，速度，安全，稳定等)。
- 组件：系统中的名词(例如 购物篮，打印/格式化功能)。
- 能力：系统中的动词(例如往购物篮添加商品，计算购物金额).
测试用例必须涵盖每个概念里的至少一项，以此保证应用的主要功能被测试到，并且不做无用功。
另外有趣的一点是，谷歌刻意保持测试人员的最少化，以此保障测试力量的最优化。最少化测试人员还能迫使开发人员在软件的整个生命期间都参与到测试中，尤其是在项目的早期阶段，测试基础架构容易建立的时候。
软件测试的未来
最后，作者对软件测试给我们展示了一个非常壮丽的未来(至少是针对商业应用软件)。传统的测试角色将会消失，取而代之的是开发人员测试和自动化测试。相较于依赖于手工测试人员，未来的软件团队将依赖内部全体员工测试，beta版大众测试和早期用户测试。传统的测试角色将转变职能，变成“测试人员”开发测试工具，开发用户反馈工具，处理用户bug报告提交。这是一个壮丽的愿景，我认为只有像谷歌这样具有相当规模的公司才能够实现。对于小公司来说，我很难想象它们能实施这样的测试流程。毕竟，并不是每个公司都有2万个内部职员来一起试用测试谷歌浏览器。但由于测试工具的改进，以及这个领域的OSS逐渐建立，大的趋势看起来正像这个方向发展。
因为我正是一个苦恼于如何将TDD集成到日常的开发流程中的人，这本书给我来相当大的启发。它在鼓励我们在测试中适当的采用一种适用主义的态度，不要让完美主义成为好愿望的敌人。隔绝部分代码，让测试易于维护，减少应用中的高风险区域，这给了我们从担心100% 测试覆盖率的思路上找到了第二个值得考虑的方向。
