Google上海如何测试搜索产品

　　James Whittaker在Google Testing Blog上连载了How Google Tests Software，How Google Tests Software，James 是前Google西雅图的技术总监(目前回到微软工作)，主要参与Gmail、Chrome和内部工具特别是测试工具开发等产品，不过Google如何测试这个题目太大了，Google除了常规的产品，每年还会新立项很多产品同时也杀死很多产品，每个产品的团队会根据自身情况制定有针对性的测试策略。

　　本文我们来谈谈Google上海是怎么测试搜索产品的。可能很多人经常使用的是Google的网页搜索，但在Google首页的Onegoogle bar上还提供了很多搜索的子频道，例如图片搜索、地图搜索、资讯搜索、视频搜索等，见下图。以下介绍的就是这些子频道的测试。

　　一、人员结构

　　从上图我们可以看出搜索产品团队是一个扁平化的组织

　　工程师经理：负责多个项目/产品(一般2个)的预算管理，工程师人员管理，Team Building

　　产品经理：负责多个项目/产品(一般2个)，产品特性定义设计和确定发展方向，竞争对手产品分析，主导产品创新讨论，确定新功能发布优先级

　　技术组长：制定和跟踪项目进度表，统筹开发人员

　　开发人员：设计开发文档，开发功能，单元测试，code review，提交发布

　　测试人员：建立产品质量流程，设计自动化测试框架，推动开发人员对质量的认知度，提高开发测试覆盖率

　　UX：可选，在某些功能上提供用户体验分析，前台UI设计

　　基本上每个搜索子频道都是这个结构，不到10人的团队，充分发挥每个成员的主动性，积极的沟通，产品经理引领产品走向，每个成员通过头脑风暴提供创意排好优先级来实现自己的想法。

　　OKRs

　　Objectives and Key Results的简称，Google特有的考核指标，分为Team的OKR和个人的OKR。每个季度，各个产品团队会根据自身产品的需求设定目标，是一个结果导向的考核。制定出团队的OKR后，团队成员根据它制定自己的OKR，指标是需要能具体量化或实际看到成果的，同时分享给团队成员让其他人知道你的目标和这个季度想要做的事情，季度结束时根据结果打分。具体可以参考这篇文章，OKR的解说

　　二、环境

　　已经上线运行的搜索产品一般会有以下四种环境，每个环境都会加入测试过程。

　　Local Demo

　　当开发人员开发好某个新功能，会在他本机起一个本地的服务用来做前期的验证，测试人员也可以通过这个demo看到初步的设计，为编写测试计划和测试用例做准备，形成初步的测试大纲或测试要点，同时可以提前和开发沟通，了解他是如何设计这个功能块，使用哪些技术评估风险，代码可测试性如何，单元测试覆盖率是否达到一定程度。在这个阶段，开发人员会在Buganizer(bugzilla/' target='_blank'>Bugzilla二次开发版，google内部使用的bug管理工具)为他开发的这个新功能建一个Hotlist，测试人员和开发人员将bug、feature request、improvement等提交进去便于跟踪。测试人员和开发人员在这个环节会有很多OneOne沟通(Google talk、Gmail、面对面)，需要发挥测试的主动性，特别是需求的理解，双方要达成共识，有异议的地方提交给产品经理来确认。

　　Dev Env(corp)

　　这是整个开发团队的环境，所有开发提交的功能会部署到这个环境中，测试人员可以在上面做集成测试，发现的任何问题，包括用户体验，需求改进都要提交到Bug库中，重大的问题可以放到周会上来讨论，这个阶段Tech leader会起主导作用。

　　Test Env/RC(borg)

　　正式的测试环境，搜索产品的发布周期现在各个子产品基本都达到了一周一发布的频率，Google有一个borg环境，由成千上万的服务器组成，各个产品申请获得某台服务器，之后这个产品的测试环境就部署在这台borg机器上，团队的每个工程师轮流来担任发布工程师，在每周的某一天先做代码冻结，之后发布产品，当这个版本通过sanity check/smoke test，就可以通知测试人员来做正式的新功能测试和回归测试。

　　Production

　　搜索产品自身不产生内容的特点，在之前的环境，数据和生产环境上是一致的，但是生产环境上有成千上万台服务器，为了避免环境差异的问题，需要 Testing in Production，当每周RC测试通过且sign off后，测试人员需要到生产环境上跑一圈(go through)，看看是否有遗漏的严重问题，如果有，及时的回滚到上一版本，这个版本废弃同时研究为什么会有严重问题遗漏，记录下来防止今后再出现类似问题，如果没有，。

　　DogFood

　　"吃狗食"，产品做大改版或一个新立项的产品经常会有这个环境，一般是个相对稳定的版本，用途是在内部推广，产品经理会邀请其他团队人员来使用并提供反馈，内部员工就是第一批用户。如果公司内部不认可，发布的几率会大大降低，因此，整个团队很关注这个版本。

　　Experiment

　　试验功能版，互联网的特点决定了需要不断的试错，很多创意在内部通过后会采用这种方式发布。根据不同地理位置不同IP不同平台不同浏览器等等，选取一些特殊的用户来试用，产品经理收集反馈后在周会上整个团队来评估这个试验效果是否可以全部推广。

　　三、测试

　　在讲测试内容之前先谈下测试人资源，哪些人来做测试，从第一部分的人员结构图可以看到产品团队的全职测试人员一般只有一个，即使算上全球版和本地版 (Global和Local，常用Google搜索的应该会知道搜索除了google.com还会有各个国家的版本，比如CN/HK/TW)也不会超过3 个人，所以测试人员需要尽早测试，同时测试需要推动开发测试、培养开发的质量意识，让开发也承担一部分测试任务，所以外面都说Google的开发和测试比例是10:1，而我觉得确切的说应该是10:11，开发和产品经理也参与了很多测试工作，全员测试，全员对质量负有责任。

原文转自：http://www.ltesting.net