搜索
大家都知道，公司运作情况首先要看员工素质。在很多人印象当中，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很多，那这块代码风险度是比较高的。持续集成系统也不开源,里面有很多数据，有红