Google质量保证体系.docx

1、Google质量保证体系 大家都知道，公司运作情况首先要看员工素质。在很多人印象当中，Google很多高管都是怪人，是一家技术驱动的公司，每创造一个技术点带来的PV提升都可能带来现金。 google走精英化路线，从微博可以看到，经常有业界大牛加盟。招应届生的时候，喜欢招名校顶尖学生。 虽然这个公司工程师达到6000多，但是它能够保持一个很好的效率，通过项目来运作，十来个人或者几个人做一个项目，这种方式保持一种“小公司”氛围。工作分配是“80/20”原则，忙完工作之余，有20%的时间是可自由支配的，做你喜欢做的事情。现实没有那么美好，因为工作往往饱和的，加班也不少。整个组织里面，研发跟测试比例是

2、10：1，大家可能吃惊，会觉得我们这边QA这边加班很多了，他们这么高比例的时候还能运转很好呢？ 事实上Google里面大概有50%项目不用测试人员测试，而是开发人员去保证质量。google内部经常开产品推广会鼓励用Google产品。产品推广会经常安排在星期五，中午吃饭的大家边吃饭边听。网站经常会看到Beta版本， 通过快速发布快速修复也降低测试强度。 各位将来过几年可能也会做到主管，对人的重要性理解会更深一点。google招聘特点，第一是只招聪明人，第二是精英化路线，第三轻技能重技术，看中能力胜于经验。第三点很显著，很多在社会上打拼很多年的人进不了Google，但是有可能一个毛头小伙子可以进G

3、oogle。 google很看中数理基础，很喜欢找业界名人去做技术布道，还有招聘顶尖应届生，从这些角度印证招聪明人的哲学。 Google员工有几个核心能力，第一个是数理逻辑，要求每个人有很好的逻辑思维能力，第二强的开发能力，第三和Google文化匹配度高，称”Googly”，google 首页文章有Google文化详细介绍。 并不是只有阿里巴巴强调文化，强调做事各方面习惯匹配度， Google其实也很关注这一块。大量聪明人存在，整个组织好运作机制都是高度自我驱动的，因此它的管理成本比较低。 在中国应聘的话，很有可能被美国工程师面试的。Google招测试需要经过研发工程师面试，招研发也会让Goo

4、gle测试经理帮面，所以说进去Google的同学，不仅仅coding能力强，测试能力也是可以的，因为他数理能力强，做测试也不逊色的。 再看看Google里面的角色，Google里面有PM，这跟阿里的PM不太一样，有点类似于阿里的PD。工程师没有严格区分研发或者测试，工程师包括test lead、开发、以及测试、专业安全测试团队等等。 UED团队包括WEB静态页面开发、交互设计师、用户体验。管理者其实跟我们B2B还不太一样，管理者本身是技术能力很强的人，他的下属碰到问题，他能够帮忙解决。另外管理跟搞技术的人比例大概是1：10左右。 Google没有项目管理、SQA、SCM、RA。大家可能比较诧异

5、，这些角色由谁担当了，事实上这些角色都是由小团队里面做项目的人，每个人都分担一点，就分掉了。 我们再细看一下常见的那几种角色职责。软件工程师主要是创建产品，保证质量，写测试代码。可以看到作为研发工程师，强调写测试代码的。测试工程师有几块职责，第一个是支持研发，做一些测试咨询，第二是给研发提供一些基础工具或者框架。可靠性方面的工程师，保证整个系统在运作。 Google中国区测试有十多个正式员工，还有十多个外包，分工侧重不同。正式员工，他们基本上不做手工测试的。外包做手工测试以及部分UI自动化，非常明确。外包在一进入google便被告知他们没有机会成为正式员工。不像阿里，在阿里努力一下，还是有机会

6、成为正式员工。 像Google中国测试也接了很多大型项目测试任务，因为他们蛮希望跟google主流接轨。测试会开发测试框架以及搭建测试系统，做性能测试，深入到项目里面挖掘一些可以重构的点，让整个测试系统变得更好，更方便测试。跟传统测试很不一样，需要能够深入代码，找到能够帮测试系统运作更好的做法。 他们都是一帮非常喜欢测试驱动的狂热爱好者。 测试工程师在项目里面的角色分几块： 第一块，测试顾问，能够指导研发怎么样写好代码，怎么样做好code view，你要比普通开发更清楚质量保证是怎么回事。 第二点，是一个测试方面的软件工程师，要求能够写代码，支持研发做一些事情，能够写一些基础测试框架。比如我们

7、做某个项目，可能很多研发用到的测试工具、方法是由测试工程师来写的，提供给研发用。 另外说一下Google里面的晋升。 目前晋升由“晋升委员会”决定，晋升委员会有一票否决权，晋升有两种途径，一种是自己写简历给委员会，第二个是你的经理推荐。 像晋升不是说你简单写写文字就行了，委员会会从内部系统拿很多数据，包括你做过的项目、写过的代码、写的文档,也需要跟你合作的人给评价。导致他们内部工程师非常喜欢用内部系统，很简单，你不用内部系统，很多业绩数据是看不到的，没有说服力。Google里面直接老板对你的晋升影响比较小。 在淘宝晋升机制与google有些类似。淘宝有委员会，高P当委员会成员，晋升还是蛮看能力

8、的，因为会提很多问题。 Google严格来说没有开发流程，合适的就拿过来用，总体来看比较偏敏捷，整个项目不一定要有测试工程师，50%没有测试工程师。项目本身是自行组建，有一个idea，诱惑很多人跟你一起做就可以，在整个项目里面，研发跟测试边界非常模糊，测试如果有能力的话，也会写很多产品代码，他们工作平台这两年全部不用windows了。 代码机制方面，有一个明确的产品owner，每次有代码commit进去的话，产品owner把代码每一行都coding view过。 Google有编程规范，coding view必须确保两个以上， coding view有内部工具支持。 google应用主干开发，

9、为什么要主干开发，就是为了方便持续集成 ，如果有冲突，立马能够检测到。主干开发有一个好处，能够尽早的、非常频繁的提交代码。少量分支开发应用在紧急发布，及bug fixed。 令人惊讶的是Google这么大一个公司，只有一个代码中心，对于Google内部员工来说都是可见的，你要是对哪块代码感兴趣，都可以看，你觉得有疑问，有什么BUG要修，也可以commit，commit完之后，有人coding view。测试之前应了解这个被测试系统的系统架构及业务架构。Google很多技术都是非常有传奇色彩的，发明的一些技术，比如GFS，Map-Reduce，很多技术思想都被其他公司拿过去用。他们比较牛逼的地方

10、还有数据中心管理。开发平台基于LINUX平台，用的编程语言为C/C+、JAVA、python，每个领域都会有很顶尖的人。LINUX OS做很多定制。JAVA领域有一个很厉害的老头也在Google,python创始人在google 。多个角度印证Google非常重视技术的。 Google内部有专门的项目管理工具，叫做P系统，这个P系统比b2b的AONE 简单多，它只是简单的做一些项目管理，没有什么流程，和代码管理工具preforce是打通的，可以非常容易的拿到文档和代码。google晋升从P系统里面拿数据，有利益驱动让大家喜欢用P系统。 没有什么统一的需求管理平台，写文档也很简单，写文档也不是分

11、角色写的，在项目里面有必要就写，这些文档都是经过非常充分的讨论。有专门的代码管理，工具叫perforce，是Google内部少有的商业工具， Google大部分工具都是自产自销的，以及用了很多开源软件 Rietveld这个code review工具非常好用，web 上可看到两个版本之间的变更，也可以从上面直接添加注释。接下来介绍Google的测试策略。第一非常强调可测性，最近两届Google软件测试大会，主题都是围绕“自动化、可测性”，GTAC是Google组织的测试大会，邀请业界名人分享。可以看一下Google的东西，了解未来几年发展方向。第二关注代码跟BUG之间的关联关系。第三点是测试工具

12、方面优先用开源的，其次开发很多内部工具。只有极少数商业工具，如perforce。第四点是他们内部性能测试技术非常成熟，只要把脚本放放在云端上，告诉它要做的性能测试，随后云端就把整个性能测试结果跑出来了。 第五点，测试运行是依赖测试代码的。只有运行的比较快的测试代码才会放到平台里面去，运行很慢的话，尽可能不放到集成平台。 第六点是手工测试、浏览器测试都是由外包执行，项目是不是要测试，是靠协商的，并没有所谓流程。 Google测试的内部形态，它分为大、中、小三个力度，所谓“小”是在单元颗粒里面，测试往往用xunit，中等规模测试属于几个小模块交互，也是用xunit一套工具。系统集成的用xunit+

13、selenium，selenium 是web ui自动化框架。 再细看一下所谓大中小还有什么不一样的地方，越小的，隔离程度越好，找问题非常容易，大的话，定位问题难度大很多。大的形态更看重端对端测试、关注系统级别行为以及跟外部交互行为。还有自动化测试运行时间，对于一些小的测试级能够在几分钟运行完，对于中等规模的，放到集成平台里面去；对于可能要运行好几天规模的自动化测试是按需执行。B2B测试代码，还没有严格区分大中小。实践当中静态检查，作用并不是非常显著， 静态检查工具多局限在记语法、写法方面的问题。据infoq报道,Google工程师findbugs，能够找到七千多个BUG，其中有75%需要修复

14、。C+是用Cpplint做静态检查。 B2B这边很多JAVA工程师findbugs，C+是用cppcheck。再说一下功能自动化测试，C+单元级别他们有Gtest框架，gmock框架, 内存检测方面是用valgrind。Google内部很多测试工具是没有界面的，Google工程师觉得点图形界面太麻烦，更喜欢用脚本表达，这跟我们工程师不一样，阿里系同学很喜欢造一些图形化界面，降低使用难度。java单元级别是用junit， jmock、easymock、mockito. Mock应用场合包括，解除外部系统依赖，提高它的运行速度，减少测试环境等。 web UI自动化是用web driver或者sel

15、enium2，我们B2B用pwaitr。selenium开发者目前也是在Google的，有两到三个人维护这套东西。 Google内部性能测试非常成熟，真正最难的是背后运作的分布式系统。工具层面有Google performance tools，它能够生成很多图片，可以看得到某一些方法调用时间、调用次数。 系统级别性能测试用jmeter的， b2b是慢慢把loadrunner赶下历史舞台。前端性能工具pagespeed，和雅虎 yslow很像，可看到页面渲染时间以及是否符合一些标准规范。 性能数据中心是Google性能测试方面的精华所在，将整个性能测试数据存放到中央数据库，这个数据库包含了文件的

16、安装环境等等。你只要把脚本做好，告诉它要做性能测试，过一会儿，性能测试执行会把性能结果数据存到中央数据库，性能测试报告直接给你了，这是它的神奇所在。 Google内部审计工具，叫ratproxy。会做一些fuzzing测试，随机发起请求给服务器，如果有错误或崩溃,能被fuzzing系统捕捉到。还有一个工具叫Lemon,从动态和静态来做测试的.目前B2B也很少做fuzzing测试. 我们说代码可测性，确实不是很好度量。Testablity explorer这个工具，看起来界面很漂亮，但是功能非常弱的，根据颜色不同，能标识出这个程序代码是好的还是优秀的。你可以拿这个可测性结果做一个基准，以后代码可

17、测性不能比以前的差，做一个趋势跟踪。 代码覆盖率方面，Google也是用开源工具, 是集成到框架里面去，另外他们也没有约定项目需要什么样的覆盖率。研发、测试，角色是没有严格区分的。没有所谓的提测标准，跟B2B也不一样。 Google BUG管理系统，没有开源，BUG作为需求来源之一，内部非常重视BUG，而针对这个BUG，衍生出很多需求。他们填BUG的时候，需要能将BUG ID以及变更列表填进去，想做到代码跟BUG之间的关联，作为这个代码质量指标。其实我们也是可以尝试做起来的，如果说代码BUG很多，那这块代码风险度是比较高的。 持续集成系统也不开源,里面有很多数据，有红的、绿的指示器。有一个比较

18、有趣的事情，如果项目失败的话变红灯，如果这个区域的灯亮，嗡嗡叫的话，那就说明出问题了。为什么这么干？比较符合人类心理学，因为我想没有谁希望整天头上的灯亮着。 内部测试系统非常庞大的，简单说一组数据，每天都有65k的build，每年有20兆的build，基于code base方面有120k test suite，每天有运行7.5 M test suite，然后1400个持续集成，这个数据还是几年前的数据，现在还在上升趋势。B2B目前没有统计过这方面数据，很多团队用hudson。再说一下发布，大家看到Google产品页面上很多都是beta版本的，为什么它可以写beta版本，阿里巴巴不可以，因为我们

19、是收费的，别人不是收费的，它的发布过程是由项目自行组织的，他不大可能找一个人做SCM的工作，每次build都是主干取代码。他们这边发布完之后，是所有产品立马让全球都看到，而是少部分人先看到，然后根据少部分人反馈再来改进产品，达到一定程度才让所有人看见。发布周期是一般一周一次，甚至每天都有发布，它能做到每天都能发布，我想它的集成系统非常强大的，不然改一个BUG就会心惊肉跳。Google在中午吃饭时间，很多人拿着饭碗听内部大牛或者业界精英讲课，中午吃饭的时候是最多人听讲座的时候，反而上班时间听讲座的比较少，但也会有。不仅仅介绍公司产品，也介绍业界动态等，非常杂。Google每年冬天都会有GTAC大

20、会，06年以来到09年，他们已经连续开了四届， PPT都是写的非常专业，里面有很多前瞻性的东西。 这几年专题主要集中在这几个方面，第一个是早期测试，怎么样在项目早期能够尽早介入进去，采用什么样的方式能够让整个产品质量更高，第二方面是可测性方面，应用testablity exporler，可看到整个项目的可测性，目前可测性也有一些专著，偏理论一点的，实际操作起来没有那么简单了。 第三个是测试自动化。有同学会问为什么没有性能测试的，Google比较少介绍性能测试，因为他们觉得性能测试这块已经比较成熟了，都希望能够做到自动化，希望能够从现有系统里面获取很多数据，不需要大量手工操作。 DSL领域，用一种语言让一些非专业用户写一些测试代码。Google testing网站需要翻墙，里面介绍很多Google内部测试的东西，还有Google微博，也有专门安全方面的博客。 Google内部也有一个专门的安全团队，跟质量保证团队分开，有点像B2B的模式。