Google质量保证体系.docx

Google质量保证体系.docx

《Google质量保证体系.docx》由会员分享，可在线阅读，更多相关《Google质量保证体系.docx（6页珍藏版）》请在冰豆网上搜索。

Google质量保证体系

大家都知道，公司运作情况首先要看员工素质。

在很多人印象当中，Google很多高管都是怪人，是一家技术驱动的公司，每创造一个技术点带来的PV提升都可能带来现金。

google走精英化路线，从微博可以看到，经常有业界大牛加盟。

招应届生的时候，喜欢招名校顶尖学生。

虽然这个公司工程师达到6000多，但是它能够保持一个很好的效率，通过项目来运作，十来个人或者几个人做一个项目，这种方式保持一种“小公司”氛围。

工作分配是“80/20”原则，忙完工作之余，有20%的时间是可自由支配的，做你喜欢做的事情。

现实没有那么美好，因为工作往往饱和的，加班也不少。

整个组织里面，研发跟测试比例是10：

1，大家可能吃惊，会觉得我们这边QA这边加班很多了，他们这么高比例的时候还能运转很好呢？

事实上Google里面大概有50%项目不用测试人员测试，而是开发人员去保证质量。

google内部经常开产品推广会鼓励用Google产品。

产品推广会经常安排在星期五，中午吃饭的大家边吃饭边听。

网站经常会看到Beta版本，通过快速发布快速修复也降低测试强度。

各位将来过几年可能也会做到主管，对人的重要性理解会更深一点。

google招聘特点，第一是只招聪明人，第二是精英化路线，第三轻技能重技术，看中能力胜于经验。

第三点很显著，很多在社会上打拼很多年的人进不了Google，但是有可能一个毛头小伙子可以进Google。

google很看中数理基础，很喜欢找业界名人去做技术布道，还有招聘顶尖应届生，从这些角度印证招聪明人的哲学。

Google员工有几个核心能力，第一个是数理逻辑，要求每个人有很好的逻辑思维能力，第二强的开发能力，第三和Google文化匹配度高，称”Googly”，google首页文章有Google文化详细介绍。

并不是只有阿里巴巴强调文化，强调做事各方面习惯匹配度，Google其实也很关注这一块。

大量聪明人存在，整个组织好运作机制都是高度自我驱动的，因此它的管理成本比较低。

在中国应聘的话，很有可能被美国工程师面试的。

Google招测试需要经过研发工程师面试，招研发也会让Google测试经理帮面，所以说进去Google的同学，不仅仅coding能力强，测试能力也是可以的，因为他数理能力强，做测试也不逊色的。

再看看Google里面的角色，Google里面有PM，这跟阿里的PM不太一样，有点类似于阿里的PD。

工程师没有严格区分研发或者测试，工程师包括testlead、开发、以及测试、专业安全测试团队等等。

UED团队包括WEB静态页面开发、交互设计师、用户体验。

管理者其实跟我们B2B还不太一样，管理者本身是技术能力很强的人，他的下属碰到问题，他能够帮忙解决。

另外管理跟搞技术的人比例大概是1：

10左右。

Google没有项目管理、SQA、SCM、RA。

大家可能比较诧异，这些角色由谁担当了，事实上这些角色都是由小团队里面做项目的人，每个人都分担一点，就分掉了。

我们再细看一下常见的那几种角色职责。

软件工程师主要是创建产品，保证质量，写测试代码。

可以看到作为研发工程师，强调写测试代码的。

测试工程师有几块职责，第一个是支持研发，做一些测试咨询，第二是给研发提供一些基础工具或者框架。

可靠性方面的工程师，保证整个系统在运作。

Google中国区测试有十多个正式员工，还有十多个外包，分工侧重不同。

正式员工，他们基本上不做手工测试的。

外包做手工测试以及部分UI自动化，非常明确。

外包在一进入google便被告知他们没有机会成为正式员工。

不像阿里，在阿里努力一下，还是有机会成为正式员工。

像Google中国测试也接了很多大型项目测试任务，因为他们蛮希望跟google主流接轨。

测试会开发测试框架以及搭建测试系统，做性能测试，深入到项目里面挖掘一些可以重构的点，让整个测试系统变得更好，更方便测试。

跟传统测试很不一样，需要能够深入代码，找到能够帮测试系统运作更好的做法。

他们都是一帮非常喜欢测试驱动的狂热爱好者。

测试工程师在项目里面的角色分几块：

第一块，测试顾问，能够指导研发怎么样写好代码，怎么样做好codeview，你要比普通开发更清楚质量保证是怎么回事。

第二点，是一个测试方面的软件工程师，要求能够写代码，支持研发做一些事情，能够写一些基础测试框架。

比如我们做某个项目，可能很多研发用到的测试工具、方法是由测试工程师来写的，提供给研发用。

另外说一下Google里面的晋升。

目前晋升由“晋升委员会”决定，晋升委员会有一票否决权，晋升有两种途径，一种是自己写简历给委员会，第二个是你的经理推荐。

像晋升不是说你简单写写文字就行了，委员会会从内部系统拿很多数据，包括你做过的项目、写过的代码、写的文档,也需要跟你合作的人给评价。

导致他们内部工程师非常喜欢用内部系统，很简单，你不用内部系统，很多业绩数据是看不到的，没有说服力。

Google里面直接老板对你的晋升影响比较小。

在淘宝晋升机制与google有些类似。

淘宝有委员会，高P当委员会成员，晋升还是蛮看能力的，因为会提很多问题。

Google严格来说没有开发流程，合适的就拿过来用，总体来看比较偏敏捷，整个项目不一定要有测试工程师，50%没有测试工程师。

项目本身是自行组建，有一个idea，诱惑很多人跟你一起做就可以，在整个项目里面，研发跟测试边界非常模糊，测试如果有能力的话，也会写很多产品代码，他们工作平台这两年全部不用windows了。

代码机制方面，有一个明确的产品owner，每次有代码commit进去的话，产品owner把代码每一行都codingview过。

Google有编程规范，codingview必须确保两个以上，codingview有内部工具支持。

google应用主干开发，为什么要主干开发，就是为了方便持续集成，如果有冲突，立马能够检测到。

主干开发有一个好处，能够尽早的、非常频繁的提交代码。

少量分支开发应用在紧急发布，及bugfixed。

令人惊讶的是Google这么大一个公司，只有一个代码中心，对于Google内部员工来说都是可见的，你要是对哪块代码感兴趣，都可以看，你觉得有疑问，有什么BUG要修，也可以commit，commit完之后，有人codingview。

测试之前应了解这个被测试系统的系统架构及业务架构。

Google很多技术都是非常有传奇色彩的，发明的一些技术，比如GFS，Map-Reduce，很多技术思想都被其他公司拿过去用。

他们比较牛逼的地方还有数据中心管理。

开发平台基于LINUX平台，用的编程语言为C/C++、JAVA、python，每个领域都会有很顶尖的人。

LINUXOS做很多定制。

JAVA领域有一个很厉害的老头也在Google,python创始人在google。

多个角度印证Google非常重视技术的。

Google内部有专门的项目管理工具，叫做P系统，这个P系统比b2b的AONE简单多，它只是简单的做一些项目管理，没有什么流程，和代码管理工具preforce是打通的，可以非常容易的拿到文档和代码。

google晋升从P系统里面拿数据，有利益驱动让大家喜欢用P系统。

没有什么统一的需求管理平台，写文档也很简单，写文档也不是分角色写的，在项目里面有必要就写，这些文档都是经过非常充分的讨论。

有专门的代码管理，工具叫perforce，是Google内部少有的商业工具，Google大部分工具都是自产自销的，以及用了很多开源软件

Rietveld这个codereview工具非常好用，web上可看到两个版本之间的变更，也可以从上面直接添加注释。

接下来介绍Google的测试策略。

第一非常强调可测性，最近两届Google软件测试大会，主题都是围绕“自动化、可测性”，GTAC是Google组织的测试大会，邀请业界名人分享。

可以看一下Google的东西，了解未来几年发展方向。

第二关注代码跟BUG之间的关联关系。

第三点是测试工具方面优先用开源的，其次开发很多内部工具。

只有极少数商业工具，如perforce。

第四点是他们内部性能测试技术非常成熟，只要把脚本放放在云端上，告诉它要做的性能测试，随后云端就把整个性能测试结果跑出来了。

第五点，测试运行是依赖测试代码的。

只有运行的比较快的测试代码才会放到平台里面去，运行很慢的话，尽可能不放到集成平台。

第六点是手工测试、浏览器测试都是由外包执行，项目是不是要测试，是靠协商的，并没有所谓流程。

Google测试的内部形态，它分为大、中、小三个力度，所谓“小”是在单元颗粒里面，测试往往用xunit，中等规模测试属于几个小模块交互，也是用xunit一套工具。

系统集成的用xunit+selenium，selenium是webui自动化框架。

再细看一下所谓大中小还有什么不一样的地方，越小的，隔离程度越好，找问题非常容易，大的话，定位问题难度大很多。

大的形态更看重端对端测试、关注系统级别行为以及跟外部交互行为。

还有自动化测试运行时间，对于一些小的测试级能够在几分钟运行完，

对于中等规模的，放到集成平台里面去；对于可能要运行好几天规模的自动化测试是按需执行。

B2B测试代码，还没有严格区分大中小。

实践当中静态检查，作用并不是非常显著，静态检查工具多局限在记语法、写法方面的问题。

据infoq报道,Google工程师findbugs，能够找到七千多个BUG，其中有75%需要修复。

C++是用Cpplint做静态检查。

B2B这边很多JAVA工程师findbugs，C++是用cppcheck。

再说一下功能自动化测试，C++单元级别他们有Gtest框架，gmock框架,内存检测方面是用valgrind。

Google内部很多测试工具是没有界面的，Google工程师觉得点图形界面太麻烦，更喜欢用脚本表达，这跟我们工程师不一样，阿里系同学很喜欢造一些图形化界面，降低使用难度。

java单元级别是用junit，jmock、easymock、mockito.Mock应用场合包括，解除外部系统依赖，提高它的运行速度，减少测试环境等。

webUI自动化是用webdriver或者selenium2，我们B2B用pwaitr。

selenium开发者目前也是在Google的，有两到三个人维护这套东西。

Google内部性能测试非常成熟，真正最难的是背后运作的分布式系统。

工具层面有Googleperformancetools，它能够生成很多图片，可以看得到某一些方法调用时间、调用次数。

系统级别性能测试用jmeter的，b2b是慢慢把loadrunner赶下历史舞台。

前端性能工具pagespeed，和雅虎yslow很像，可看到页面渲染时间以及是否符合一些标准规范。

性能数据中心是Google性能测试方面的精华所在，将整个性能测试数据存放到中央数据库，这个数据库包含了文件的安装环境等等。

你只要把脚本做好，告诉它要做性能测试，过一会儿，性能测试执行会把性能结果数据存到中央数据库，性能测试报告直接给你了，这是它的神奇所在。

Google内部审计工具，叫ratproxy。

会做一些fuzzing测试，随机发起请求给服务器，如果有错误或崩溃,能被fuzzing系统捕捉到。

还有一个工具叫Lemon,从动态和静态来做测试的.目前B2B也很少做fuzzing测试.

我们说代码可测性，确实不是很好度量。

Testablityexplorer这个工具，看起来界面很漂亮，但是功能非常弱的，根据颜色不同，能标识出这个程序代码是好的还是优秀的。

你可以拿这个可测性结果做一个基准，以后代码可测性不能比以前的差，做一个趋势跟踪。

代码覆盖率方面，Google也是用开源工具,是集成到框架里面去，另外他们也没有约定项目需要什么样的覆盖率。

研发、测试，角色是没有严格区分的。

没有所谓的提测标准，跟B2B也不一样。

GoogleBUG管理系统，没有开源，BUG作为需求来源之一，内部非常重视BUG，而针对这个BUG，衍生出很多需求。

他们填BUG的时候，需要能将BUGID以及变更列表填进去，想做到代码跟BUG之间的关联，作为这个代码质量指标。

其实我们也是可以尝试做起来的，如果说代码BUG很多，那这块代码风险度是比较高的。

持续集成系统也不开源,里面有很多数据，有红的、绿的指示器。

有一个比较有趣的事情，如果项目失败的话变红灯，如果这个区域的灯亮，嗡嗡叫的话，那就说明出问题了。

为什么这么干？

比较符合人类心理学，因为我想没有谁希望整天头上的灯亮着。

内部测试系统非常庞大的，简单说一组数据，每天都有65k的build，每年有20兆的build，基于codebase方面有120ktestsuite，每天有运行7.5Mtestsuite，然后1400个持续集成，这个数据还是几年前的数据，现在还在上升趋势。

B2B目前没有统计过这方面数据，很多团队用hudson。

再说一下发布，大家看到Google产品页面上很多都是beta版本的，为什么它可以写beta版本，阿里巴巴不可以，因为我们是收费的，别人不是收费的，它的发布过程是由项目自行组织的，他不大可能找一个人做SCM的工作，每次build都是主干取代码。

他们这边发布完之后，是所有产品立马让全球都看到，而是少部分人先看到，然后根据少部分人反馈再来改进产品，达到一定程度才让所有人看见。

发布周期是一般一周一次，甚至每天都有发布，它能做到每天都能发布，我想它的集成系统非常强大的，不然改一个BUG就会心惊肉跳。

Google在中午吃饭时间，很多人拿着饭碗听内部大牛或者业界精英讲课，中午吃饭的时候是最多人听讲座的时候，反而上班时间听讲座的比较少，但也会有。

不仅仅介绍公司产品，也介绍业界动态等，非常杂。

Google每年冬天都会有GTAC大会，06年以来到09年，他们已经连续开了四届，PPT都是写的非常专业，里面有很多前瞻性的东西。

这几年专题主要集中在这几个方面，第一个是早期测试，怎么样在项目早期能够尽早介入进去，采用什么样的方式能够让整个产品质量更高，第二方面是可测性方面，应用testablityexporler，可看到整个项目的可测性，目前可测性也有一些专著，偏理论一点的，实际操作起来没有那么简单了。

第三个是测试自动化。

有同学会问为什么没有性能测试的，Google比较少介绍性能测试，因为他们觉得性能测试这块已经比较成熟了，都希望能够做到自动化，希望能够从现有系统里面获取很多数据，不需要大量手工操作。

DSL领域，用一种语言让一些非专业用户写一些测试代码。

Googletesting网站需要翻墙，里面介绍很多Google内部测试的东西，还有Google微博，也有专门安全方面的博客。

Google内部也有一个专门的安全团队，跟质量保证团队分开，有点像B2B的模式。