提高软件质量实践――google 篇

转自：http://blogs.msdn.com/b/billliu/archive/2012/06/07/google.aspx

很多人应该都看过James whittaker的博客或新书 《how google test software》，在这里我不想重复他的内容，而是从另外一个角度来分析对比google是如何保障它的产品质量的。

 首先申明的是本人并没有在google工作过所以没有第一手的经验，仅以一个旁观者的身份来分析google的质量控制实践。主要信息来源于google测试博客，在西雅图google工作的朋友聊天和项目上合作，以及James的新书<<how google tests software>>。不过旁观者有旁观的优势，可以看见整个森林；相比较许多在大公司工作的工程师往往专注于一个产品或者一个团队，只看见了一颗树木J。不管如何，个人观点仅供参考。

 我们前面在微软的质量控制实践中谈到，因为微软大部分的产品还是以桌面型产品为主，比如windows, office,sql server等等。桌面型产品的最大特定就是产品召回或发布热修复的成本太大，而且运行很多关键业务，这就迫使微软必须在产品发布之前投入大量人力物力来充分测试产品用以保障产品的高质量。与微软不同的是，google采用不同的策略来保证软件质量。在理解分析google的质量策略之前，我们必须了解google的采取该策略的根源：

1. Google质量文化：google起源于校园。在有限的资金下，那时候创始人只能使用廉价的机器，把多个廉价的机器放在一起来提高处理能力。这些廉价的机器最大的问题是经常死机或报废，所以google在起始阶段就必须有很强的容错能力。也就是说在系统在部分机器死机或报废的情况下仍然可以提供服务。或者说，系统部分可以出错但是整个系统不可以宕机 （Graceful Degradation）。Google这个从一开始因为被迫置入的高容错能力反而成就了现在他们运行在数据中心上的服务的巨大优势。我们知道通常硬件的出错概率大概在万分之一，如果有一万台机��，其中一台出错概率就达到百分之百。在现在的数据中心里少则几万台，多者几十万台的机器。所以产品的容错能力已经不是可有可无，而是必须有的功能。所以google信奉的原则是单个模块可以出错可以有bug，它通过系统强大的容错能力来保障系统的整体高质量。
2. 互联网产品：google是互联网公司成功的代表。互联网产品的最大特点就是“快”：产品定义快，开发快，反馈快，死掉的也快。所以为了有效利用有限的测试资源，google信奉的另外一个原则是：build the right it before you build it right.也就就是说只有确认了产品的确是用户需要的产品(build the right it)之后才开始提高它的质量(build it right)。道理很简单如果未知产品是否正确的情况下，没有必要浪费资源来提高它的质量。所以google的大部分产品测试人员介入较晚，开发人员不得不自己先测试以保障基本质量。

 在理解了goolge对产品质量认识这两个根本出发点后，就不难理解google采用什么样的测试策略了：

1. Dev owns quality

Google认为：谁写的的代码谁负责，谁开发的模块谁负责质量。所以开发在写代码的同时也要花很多时间测试，主要是单元测试和模块测试。Google坚信软件质量是先天就创建出来的，而不是通过后天测试测出来的。让开发做测试对产品质量负责不是件容易的事情，google通过主要三个途径：一是减少测试人员数量，所以开发不得不做测试；而是通过一些活动比如test certificate program来正面影响开发做测试；最重要的第三点是通过建立强大的完善的基础设施，使得开发很容易地写测试自动化很容易地运行测试。

 

2. Tester is to enable developer to test effectively

这个是对传统意义上的测试人员的职责非常大的改变。传统意义上的测试人员的主要职责是寻找产品中的bug。既然google要求开发对质量负责，当然就不太需要传统意义上的测试人员了。所以google中的测试更多时间是在开发测试自动化，开发测试工具，开发基础设施。相对花很少的时间做真正意义上的测试了。所以后来干脆把测试部门从原来的“Test Service”改名子为“engineering productivity”。测试的主要职责是让开发更为容易地做测试。

 但是最近两年，随着它的产品的日趋成熟和越来越复杂，google开始加强产品的后期测试。主要原因是虽然开发可以做很多单元和模块测试来保障模块的质量，但是很多bug是在和其它模块集成的时候才被发现。所以google把测试工程师分成两种：一种是和开发一起负责开发的，最要做单元测试，测试工具等。另外一种是面向用户的测试工程师，主要做面向用户的集成场景测试。

 

3.Continuous Integration

这个就不用多介绍了，搞互联网或基于服务的产品的项目组，如果不使用持续集成的话有点太out了。Google的持续集成是行业的领先者，一方面有强大的测试自动化和完善的基础设施做为保障，使得开发测试工程师不用在如何部署，如何运行，如何分析结果等等上浪费时间，而是专注于开发和测试自动化。代码提交后会有成千上万个测试用例自动运行，并且很快返回结果以供进一步分析之用。另一方面，google继续优化现有的工具和基础设施来进一步提过持续集成的效率。比如在做持续集成中最为头疼的一个问题是运行那些测试用例？运行多了当然会延长运行时间从而降低了效率，运行少了又有漏测的风险。Google开发了一套测试用例分析工具用以分析代码和测试用例的依赖关系。如果修改了某行代码后，该工具决定哪些测试用例必须运行，也就是说不多不少。微软也有类似的工具在帮助测试人员决定运行测试用例的优先权，但是个人感觉效果不太好。所以我也对google的工具到底效果如何应用情况很感兴趣。

另外一点就是持续集成是以自动化做为基本保障的。测试自动化不是万能的，但是没有测试自动化是万万不能的。注意的是测试自动化不仅仅解放了人，也不仅仅是为了回归，更为重要的一点是逼迫开发在设计的时候就考虑到如何自动测试该模块从而大大提高模块的可测试性（我们知道这是提高软件质量的一个重要指标）。当然除了测试自动化外，google开发了许许多多的工具和平台来大大提高测试效率。

 

4. Measure everything

客观上说以上几点我都觉得没什么特殊之处，但是下面这个绝对让我受益匪浅：measure everything。从最底层的硬件驱动器，到操作系统的CPU, memory,  disk IO, 再到每个API的调用， 最后到最高层的用户体验，Google监控和衡量所有的这些活动。然后对监控和衡量的数据进行数据挖掘和分析，从而对整个系统的运行情况了如指掌。一方面，如果有bug的话，它可以在最短的时间内发现并根据监控的数据很快找到bug的根源加以修复；另一方面根据详细的监控数据清楚地表明哪些地方需要改进，尤其是在系统性能方面；再一方面就是了解用户的使用情况和规律从而为产品功能的改进提供精确的数据和预测。Google认为： If you can’t measure your product/component, don’t build it。

 

小结，google是互联网公司成功的代表，他在互联网产品上的质量控制实践和经验对于广大的互联网公司有值得借鉴意义。在产品发布速度和产品发布质量的权衡和取舍中，google选择发布速度。在保障基本产品质量的前提下，用最快的速度把产品推到市场中，然后通过丰富的反馈渠道和工具再不断演变。这样即控制了用户又保障了质量，而且也做到了对没有用户的产品：fail fast, fail cheap。除了google之外，在西雅图的另外一家公司也是互联网产品的大哥大，特别是在在线销售和云计算应用服务类型的产品。所以下一次和大家探讨：提高软件质量实践――Amazon 篇。