Google质量保证体系

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

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

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

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

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

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

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

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

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

10、, map-reduce很多技术思 想都被其他公司拿过去用。他们比较牛逼的地方还有数据中心管理。开发平台基于 linux 平台，用的编程语言为c/c+ 、 java、 python， 每个领域都会有很顶尖的人。linux os做很多定制。java领域有一个很厉害的 老头也在 google,python创始人在google。多个角度 印证google非常重视技术的。google 内部有专门的项目管理工具，叫做p 系统，这个 p 系统比 b2b 的 aone 简单多，它只是简单的做一些项目管理，没有什么流程，和代码管理工具 preforce 是打通的，可以非常容易的拿到文档和代码。google晋升

11、从p系统里面拿数据，有利益驱动让大家喜欢用 p 系统。没有什么统一的需求管理平台， 写文档也很简单，写文档也不是分角色写的，在项目里面有必要就写，这些文档都是经过非常充分的讨论。有专门的代码管理， 工具叫perforce， 是 google 内部少有的商业工具，google大部分工具都是自产自销的，以及用了很多开源软件rietveld这个code review工具非常好用,web上可看到两个版本之间的变更，也可以从上面直接添加注释。接下来介绍 google 的测试策略。第一非常强调可测性，最近两届google软件测试 大会，主题都是围绕“自动化、可测性” ， gtac 是google组织的测试

12、大会，邀请业界名人分享。可以看 一下google 的东西，了解未来几年发展方向。第二关注代码跟bug 之间的关联关系。第三点是测试工具方面优先用开源的，其次开发很多内部工具。只有极少数商业工具，如perforce。第四点是他们内部性能测试技术非常成熟，只要把脚本放放在云端上，告诉它要做的性能测试，随后云端就把整个性能测试结果跑出来了。第五点，测试运行是依赖测试代码的。只有运行的比较快的测试代码才会放到平台里面去，运行很慢的话，尽可能不放到集成平台。第六点是手工测试、 浏览器测试都是由外包执行，项目是不是要测试，是靠协商的，并没有所谓流程。google测试的内部形态，它分为大、中、小三个力度，

13、所谓 “小” 是在单元颗粒里面， 测试往往用 xunit，中等规模测试属于几个小模块交互， 也是用 xunit 一套工具。系统集成的用xunit+selenium， selenium 是 webui 自动化框架。再细看一下所谓大中小还有什么不一样的地方，越小的，隔离程度越好，找问题非常容易，大的话，定位问题难度大很多。大的形态更看重端对端测试、关注系统级别行为以及跟外部交互行为。还有自动化测试运行时间，对于一些小的测试级能够在几分钟运行完，对于中等规模的，放到集成平台里面去；对于可能要运行好几天规模的自动化测试是按需执行。 b2b测试代码，还没有严格区分大中小。实践当中静态检查， 作用并不是非

14、常显著， 静态检查工具多局限在记语法、 写法方面的问题。 据 infoq 报道,google工程师findbugs,能够找到七千多个bug, 其中有75%需要修复。c+ 是用 cpplint 做静态检查。b2b 这 边 很 多 java 工程 师 findbugs， c+ 是 用 cppcheck。再说一下功能自动化测试， c+ 单元级别他们有gtest框架）gmock框架,内存检测方面是用 valgrind。 google 内部很多测试工具是没有界面的， google 工程 师觉得点图形界面太麻烦，更喜欢用脚本表达，这跟我们工程师不一样，阿里系同学很喜欢造一些图形化界面，降低使用难度。jav

15、a 单元级别是用 junit ， jmock、 easymock、 mockito. mock应用场合包括，解除外部系统依赖，提 高它的运行速度，减少测试环境等。web ui 自动化是用 web driver 或者 selenium2， 我们b2b用pwaitr。selenium开发者目前也是在 google 的，有两到三个人维护这套东西。google内部性能测试非常成熟，真正最难的是背后 运作 的 分布 式 系 统 。 工 具 层 面 有 google performance tools,它能够生成很多图片，可以看得 到某一些方法调用时间、调用次数。系统级别性能测试用 jmeter 的， b

16、2b 是慢慢把loadrunner赶下历史舞台。前端性能工具 pagespeed 和雅虎 yslow 很像，可看到页面渲染时间以及是否符合一些标准规范。性能数据中心是google 性能测试方面的精华所在，将整个性能测试数据存放到中央数据库，这个数据库包含了文件的安装环境等等。 你只要把脚本做好，告诉它要做性能测试，过一会儿，性能测试执行会把性能结果数据存到中央数据库，性能测试报告直接给你了，这是它的神奇所在。google内部审计工具，叫ratproxy。会做一些fuzzing 测试，随机发起请求给服务器，如果有错误或 崩溃 ,能被 fuzzing 系统捕捉到。还有一个工具叫lemon,从动态和

17、静态来做测试的 .目前b2b 也很少做 fuzzing 测试.我们说代码可测性， 确实不是很好度量。 testablity explorer这个工具，看起来界面很漂亮，但是功能非常 弱的，根据颜色不同，能标识出这个程序代码是好的 还是优秀的。你可以拿这个可测性结果做一个基准， 以后代码可测性不能比以前的差，做一个趋势跟踪。代码覆盖率方面，google也是用开源工具，是集成到框架里面去，另外他们也没有约定项目需要什么样的覆盖率。研发、测试，角色是没有严格区分的。没有所谓的提测标准，跟 b2b 也不一样。google bug 管理系统，没有开源， bug 作为需求来源之一， 内部非常重视bug ，

18、 而针对这个bug ，衍生出很多需求。 他们填 bug 的时候， 需要能将 bugid 以及变更列表填进去，想做到代码跟 bug 之间的关联，作为这个代码质量指标。其实我们也是可以尝试做起来的，如果说代码 bug 很多，那这块代码风险度是比较高的。持续集成系统也不开源,里面有很多数据， 有红的、绿的指示器。有一个比较有趣的事情，如果项目失败的话变红灯，如果这个区域的灯亮，嗡嗡叫的话，那就说明出问题了。为什么这么干？比较符合人类心理学，因为我想没有谁希望整天头上的灯亮着。内部测试系统非常庞大的，简单说一组数据，每天都有 65k 的 build， 每年有 20兆的 build， 基于 code bas昉面有 120k test suite每天有运行 7.5 m test suite 然后1400个持续集成，这个数据还是几年前的数据，现在还在上升趋势。 b2b 目前没有统计过这方面数据，很多团队用hudson。再说一下发布，大家看到google产品页面上很多 都是beta版本的，为什么它可以写beta版本，阿里巴 巴不可以，因为我们是收费的，别人不是收费的，它的发布过程是由项目自行组织的，他不大可能找一个人做 scm 的工作，每次build 都是主干取代码。他们这边发布完之后，是所有产品立马让全球都看到，而是少部分人先看到，然后根据少部分