How Google Test Software读书笔记(一)

许久都没有写博客了，因为一直在读那本“How Google Test Software”，每天下了班不管回家多晚，我都会看上那么几十页，算是补充补充精神食粮吧。现在终于读完了，想把一些感想摘记下来，记性这玩意始终是靠不住的。

第一章 Introduction of Google Software Testing

其中有个很重要的观点：Quality 不等于Testing, 如果说硬要给Quality下一个定义的话：当把开发和测试混在一起分不清彼此的时候，Quality就产生了。所以文章中提倡的观点是：Code a little and test what you built，这样循序渐进的过程才能产生稳定的质量。补充一点：对于质量来说，预防问题比发现问题本身更重要。质量更多是开发人员的问题，而丌是测试人员的。通过把测试工作融入到开发过程中，我们能降低那些富产Bug的人的出错机会，丌仅可以避免了大量最终用户的使用问题，而丏还可以极大地降低测试人员报无效Bug的数量。

那么Google是如何定义测试工程师的呢？Some engineers are responsible for making other engineers more productive and more quality-minded。除了测试工程师，Google还有一种叫SET的角色，也就是我们所说的测试开发工程师，他们专注代码质量、代码架构里潜在的风险，他们会重构单元测试，负责搭建测试平台并开发出人性化的自动化工具。其实很重要的一点是这里所谓的自动化工具，并不仅仅是自动化测试所用，而是讲一切研发的流程都能提高效率的各个环节都能用上的自动化，哪怕是HR部门使用的、产品经理适用的，或者用户也能用上的，只要是能够提高效率并使得Google产品研发过程更加顺畅的工具，他们都会去尝试做，而且持续的去改进。

那么，Google的工程师们是如何腾出自己自己的时间来制作和维护改进那么多工具的呢？在Google内部有一个20%为了创新的文化，每个员工允许将20%的工作时间拿出来做自己想做的任何事情，相当于每周只有4个工作日是必须专注在自己的工作上的。恰恰是在那20%的时间里，Google的工程师们常常按照各自的兴趣爱好和擅长的领域聚在一起，发起各种工具项目，并最终几乎无一例外的全部开源的放给全世界一起来用，因为他们相信人的思维是无限宽广的，集思广益最好的办法就是开源欢迎所有人下载和改进。事实上，例如像Selenium WebDriver这种优秀框架，就吸引了来自全世界各地的优秀工程师参与，发展迅速几乎都要纳入W3C的Web自动化标准中去了。

此外，这一章还讲解了Google里测试工作的分类，他们喜欢用简洁的Small，Medium和Large来定义测试类型，Size类的单词更加形象直观的表明此种测试的规模也就是它能覆盖多大范围的代码。对应到传统意义上，Small就相当于单元测试，只覆盖单一的代码片段，而Medium就会将一些有关联的代码片段组合在一起测试，有点类似集成测试，真正模拟用户行为的就是端对端的Large测试，类似我们常说的系统测试。在针对代码片段为主的Small和Medium测试中Google大量的使用了Fake和Mock技术来模拟环境因素和数据对象。

第二章 The Software Engineer in Test

这章介绍的是Google的SET，也就是测试开发工程师这种角色。许多Google的SET都是从开发转过来的，他们对测试感兴趣，有着质量保障方面的天赋，也通常乐于分享和制作工具来提高所有人的效率。既需要对测试有兴趣有热情，又要有很强的编码技术，这样的人才，在市面上是很难找到的，从开发工程师中寻找往往是个更靠谱的办法。笔者一直觉得，计算机技术不管是用在开发还是测试还是别的什么地方，终究目的是为了让人们的生活更加美好，何必要纠结自己是在做开发还是测试这些角色呢！

在Google，SET和SWE（研发工程师）是紧密合作的关系，他们的工作甚至有许多重叠的部分。虽然传统的观念认为，工程项目分工精细能导致效率。但如今的互联网IT行业需求瞬息万变，信息爆棚，市场机遇出现得快消失得也快，软件的质量恰恰通过这种分不开的重叠，才能真正让整个团队都来为此负责。分工太明确了，会无端的引入许多人为的因素，对一些出现的问题，谁也不愿意出来承认是自己做得不够好。这两种角色里，SWE会写更多的Small Test代码，而SET会写更多的Mock和Fake Environment的代码，Google的工程一般会以约定好的接口开始，一边白盒一边Mock这样子起步，并预先设置好足够的挑战和里程碑，随时对代码做静态分析跟踪进度。这是一种快速原型的概念，项目长时间处于不明确不可见状态是件很危险的事情，所以Google愿意用最少的时间先让它跑起来，然后在持续的迭代改进，跟Agile里的迭代交付也是同样的概念，随着迭代改进的过程，项目和需求也会变得越发明确。

在Google，大部分项目都共享一份代码库，任何员工都可以去里面下载别的项目别的团队的代码，这给了所有人一个高效学习的机会。例如我们遇到任何程序上的经验问题或者编译错误会去网上Google Search一样，Google的工程师们一般都能在这样一个共享的代码库中找到自己想要的例子做参考。而且敢于把自己的代码Share出来，本身就代表对代码质量的一种负责的态度，欢迎大家来拍砖、指教，也能对自身的代码起到一个监督促进的积极作用。一个题外话是Google基本用到四大编程语言：C++、Java、Python和Javascript，员工用的工作机器基本都是定制化的Linux系统，他们会维护这些Linux内核甚至维护里面包含的编译器，以保障大家的代码都是被同样版本的编译器编译通过的，可以在任何人的机器上无障碍的运行。在项目发起约定接口的时候，Google还有一种自己的语言叫Interface Protocols，通过这种Protocol文件的描述，SET和SWE都清晰明了项目的需求和功能是什么样子于是可以开始并行的写一点测试一点循序渐进。Google有解释器可以把Protocol格式的文件，翻译成常用四大语言中的任何一种，这样把重复人为敲代码的劳动都给省了，也算是工具文化的一个例子吧。

在许多其他的公司，测试开发就是负责做自动化的，关于这一点Google的观点是自动化的摊子铺得越大，随着系统变迁需求变更，自动化本身就会变得越发脆弱。所以Google的方式是：使用一些Mock技术来隔离复杂的系统，为更加明确不易变更的部件做轻量级的自动化。往往工程师在自己的代码Check in之前，就已经利用Mock和自动化在整个系统中运行过一遍经过了验收和检测了，这样可以有力的保障代码库中的代码质量。

关于Google对SET的定位，从他们招聘的一些案例中可以读到许多有意思的故事。他们最期望看到的SET是能够提出解决问题的思路，先不管这思路是否是最优的。例如给定一个简单的方法，思考对它进行单元测试。Google觉得优秀的SET不是简单的去遵循单元测试的原则去按部就班的做，而应该尽可能提出自己的疑点，比如方法的扩展性、可重用性、多线程访问的安全性、是否可以优化，更甚者应该考虑到指针溢出、分布式调用、如何分析它的健壮性，写出的单元测试是否浅显易懂，除了单元测试还可以做什么来分析代码的边界、死锁、内存泄露之类的风险。（由此可见，SET也需要相当强的技术背景）

声明：转载请注明原文出处。