本文我们来谈谈Google上海是怎么测试搜索产品的。可能很多人经常使用的是Google的网页搜索，但在Google首页的Onegoogle bar上还提供了很多搜索的子频道，例如图片搜索、地图搜索、资讯搜索、视频搜索等，见下图。以下介绍的就是这些子频道的测试。
一、人员结构
从上图我们可以看出搜索产品团队是一个扁平化的组织
工程师经理：负责多个项目/产品(一般2个)的预算管理，工程师人员管理，Team Building
产品经理：负责多个项目/产品(一般2个)，产品特性定义设计和确定发展方向，竞争对手产品分析，主导产品创新讨论，确定新功能发布优先级
技术组长：制定和跟踪项目进度表，统筹开发人员
开发人员：设计开发文档，开发功能，单元测试，code review，提交发布
测试人员：建立产品质量流程，设计自动化测试框架，推动开发人员对质量的认知度，提高开发测试覆盖率，日常的测试任务
UX：可选，在某些功能上提供用户体验分析，前台UI设计
基本上每个搜索子频道都是这个结构，不到10人的团队，充分发挥每个成员的主动性，积极的沟通，产品经理引领产品走向，每个成员通过头脑风暴提供创意排好优先级来实现想法。
工程师经理：负责多个项目/产品(一般2个)的预算管理，工程师人员管理，Team Building
产品经理：负责多个项目/产品(一般2个)，产品特性定义设计和确定发展方向，竞争对手产品分析，主导产品创新讨论，确定新功能发布优先级
技术组长：制定和跟踪项目进度表，统筹开发人员
开发人员：设计开发文档，开发功能，单元测试，code review，提交发布
测试人员：建立产品质量流程，设计自动化测试框架，推动开发人员对质量的认知度，提高开发测试覆盖率，日常的测试任务
UX：可选，在某些功能上提供用户体验分析，前台UI设计
基本上每个搜索子频道都是这个结构，不到10人的团队，充分发挥每个成员的主动性，积极的沟通，产品经理引领产品走向，每个成员通过头脑风暴提供创意排好优先级来实现想法。
OKRs
Objectives and Key Results的简称，Google特有的考核指标，分为Team的OKR和个人的OKR。每个季度，各个产品团队会根据自身产品的需求设定目标，是一个结果导向的考核。制定出团队的OKR后，团队成员根据它制定自己的OKR，指标是需要能具体量化或实际看到成果的，同时分享给团队成员让其他人知道你的目标和这个季度想要做的事情，季度结束时根据结果打分。具体可以参考这篇文章，OKR的解说
Objectives and Key Results的简称，Google特有的考核指标，分为Team的OKR和个人的OKR。每个季度，各个产品团队会根据自身产品的需求设定目标，是一个结果导向的考核。制定出团队的OKR后，团队成员根据它制定自己的OKR，指标是需要能具体量化或实际看到成果的，同时分享给团队成员让其他人知道你的目标和这个季度想要做的事情，季度结束时根据结果打分。具体可以参考这篇文章，OKR的解说
二、环境
已经上线运行的搜索产品一般会有以下四种环境，每个环境都会加入测试过程。
已经上线运行的搜索产品一般会有以下四种环境，每个环境都会加入测试过程。
- Local Demo
当开发人员开发好某个新功能，会在他本机起一个本地的服务用来做前期的验证，测试人员也可以通过这个demo看到初步的设计，为编写测试计划和测试用例做准备，形成初步的测试大纲或测试要点，同时可以提前和开发沟通，了解他是如何设计这个功能块，使用哪些技术评估风险，代码可测试性如何，单元测试覆盖率是否达到一定程度。在这个阶段，开发人员会在Buganizer(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不同平台不同浏览器等等，选取一些特殊的用户来试用，产品经理收集反馈后在周会上整个团队来评估这个试验效果是否可以全部推广。
试验功能版，互联网的特点决定了需要不断的试错，很多创意在内部通过后会采用这种方式发布。根据不同地理位置不同IP不同平台不同浏览器等等，选取一些特殊的用户来试用，产品经理收集反馈后在周会上整个团队来评估这个试验效果是否可以全部推广。
三、测试
在讲测试内容之前先谈下测试人资源，哪些人来做测试，从第一部分的人员结构图可以看到产品团队的全职测试人员一般只有一个，即使算上全球版和本地版(Global和Local，常用Google搜索的应该会知道搜索除了google.com还会有各个国家的版本，比如CN/HK/TW)也不会超过3个人，所以测试人员需要尽早测试，同时测试需要推动开发测试、培养开发的质量意识，让开发也承担一部分测试任务，所以外面都说Google的开发和测试比例是10:1，而我觉得确切的说应该是10:11，开发和产品经理也参与了很多测试工作，全员测试，全员对质量负有责任。
在讲测试内容之前先谈下测试人资源，哪些人来做测试，从第一部分的人员结构图可以看到产品团队的全职测试人员一般只有一个，即使算上全球版和本地版(Global和Local，常用Google搜索的应该会知道搜索除了google.com还会有各个国家的版本，比如CN/HK/TW)也不会超过3个人，所以测试人员需要尽早测试，同时测试需要推动开发测试、培养开发的质量意识，让开发也承担一部分测试任务，所以外面都说Google的开发和测试比例是10:1，而我觉得确切的说应该是10:11，开发和产品经理也参与了很多测试工作，全员测试，全员对质量负有责任。
- One Page Test Plan
整个产品的测试计划一般就一页纸但并不是说只能一页纸，而是一个轻文档的概念，里面包括了产品背景、测试策略、测试内容、哪些功能需要测试、哪些功能目前还没有加入测试、使用了哪些测试类型、目前在线的功能、测试环境、日程/进度表、资源、风险和依赖等等。
针对具体某个比较大的功能模块也同样适用，也就是说测试计划包括整个产品的还包括产品内部功能模块的。 - Test Env
见上文介绍，这里面还会有Global和Local的多语言环境，需要和其他办公室的团队协同工作。
- Test Cases
测试用例在Google内部是通过一个叫TestScribe的工具来管理，各个产品创建自己的产品的测试用例，一般会 根据页面->功能来，产品所有测试用例创建好后，需要团队来审核，根据反馈做修改，同时也要把发现的Bug当做用例补充进来。
Test Scribe里还有一个Test sets概念，也就是说根据不同的测试策略，从所有测试用例中选取相应部分保存成Test set，例如Basic Test、Full Test、Automated Test等等，当具体执行测试时，可以创建Build从这些Test sets选取合并在一起。 - Bug
前面有提到过Bug库是使用Buganizer来管理，但是Bug库不仅仅是存放缺陷，需求和改进以及你认为有问题的都需要记录进去，根据优先级跟踪开发修复，同时可以根据不同类型，比如新功能或每周发布版本建立Hotlists，将对应的Bug保存便于跟踪统计。 - Test Report
测试报告，每一轮测试执行结束后，通过TestScribe都可以生成相应的测试报告，例如每周发布的回归测试，会有对应的测试报告，记录测试使用了哪些用例、发现了哪些Bug、严重程度如何，当然，也可以通过TestScibe和Buganizer提供的接口自己建立一个状态页面。 - Matrix
搜索产品都是基于Web的，这就涉及到兼容性测试，需要根据具体产品监控的反馈统计出用户的喜好情况，建立对应的平台和浏览器Matrix，里面会有一个百分比关系，根据百分比来划分优先级，分配测试资源。 - Metrics
产品质量的情况反馈需要有一些度量，那么会建立哪些度量呢，需要建立一些矩阵：
a.发布的矩阵，哪些bug是手工测试发现的、哪些是自动化发现的、验证了哪些bug、哪些是新功能的bug
b.每周回归的矩阵，回归发现了哪些新bug、回归验证哪些bug
c.功能发布记录，某个新功能是在哪个版本第一次发布，新功能发布到哪个国家或地区，新功能做了第几次试验
Findit
大家一起来找茬，就是邀请所有员工来找bug，发现有效bug的员工会获得一件T-shirt和其他奖品，T-shirt的图标一般是一只狗狗拿个放大镜照骨头。有点类似于微软的"bug bash"，但是这个是整个公司的，bug bash一般是在团队使用，会在某个新版本发布前，整个团队一起来找bug并且使用一周时间一起修复bug。那么根据多国家地区和多语言的特点，还可以分为ChinaFindit，JapanFindit，比如我参与的香港财经项目，就需要邀请懂粤语或就是香港员工来帮忙做一些习惯用语或当地风俗或当地使用习惯的测试。
大家一起来找茬，就是邀请所有员工来找bug，发现有效bug的员工会获得一件T-shirt和其他奖品，T-shirt的图标一般是一只狗狗拿个放大镜照骨头。有点类似于微软的"bug bash"，但是这个是整个公司的，bug bash一般是在团队使用，会在某个新版本发布前，整个团队一起来找bug并且使用一周时间一起修复bug。那么根据多国家地区和多语言的特点，还可以分为ChinaFindit，JapanFindit，比如我参与的香港财经项目，就需要邀请懂粤语或就是香港员工来帮忙做一些习惯用语或当地风俗或当地使用习惯的测试。
TotT
Testing on the Toilet，在Google各个办公室的厕所，你会发现墙上经常贴着各种文档，这个是Google专有的厕所文化。
文档一般是各个产品使用工具或做测试的例子，目的是吸引所有工程师做更多的测试，这个文化被Google离职工程师带到了百度，可惜他们太懒了没有把页首和页眉去掉，模板也改改吧，当然他们加了一个像框，Google就张纸贴在墙上。
Testing on the Toilet，在Google各个办公室的厕所，你会发现墙上经常贴着各种文档，这个是Google专有的厕所文化。
文档一般是各个产品使用工具或做测试的例子，目的是吸引所有工程师做更多的测试，这个文化被Google离职工程师带到了百度，可惜他们太懒了没有把页首和页眉去掉，模板也改改吧，当然他们加了一个像框，Google就张纸贴在墙上。
四、工具
从上面可以看出，搜索产品一般是一周一发布的频率(称为Weekly Push)，测试人员除了做常规的RC测试，还需要了解新功能的需求、提早介入新功能测试、编写测试计划和测试用例，和开发人员协作提高代码质量，那么时间有限，提高效率就需要工具的帮助，下面介绍一些使用到的工具或策略。
从上面可以看出，搜索产品一般是一周一发布的频率(称为Weekly Push)，测试人员除了做常规的RC测试，还需要了解新功能的需求、提早介入新功能测试、编写测试计划和测试用例，和开发人员协作提高代码质量，那么时间有限，提高效率就需要工具的帮助，下面介绍一些使用到的工具或策略。
- Clearsilver Diff Tool
我们知道测试里面的"二八原则"，很多新的功能会发现大量的bug，同时在旧功能也会发现由于新功能或是代码修改引入的bug。
通过Diff工具，我们可以了解新版本和上一版本的区别，更利于测试资源的分配，关注修改部分的质量，而原有功能模块的质量通过自动化来做回归测试。 - Selenium UI Automation
UI的自动化，其实解决的更多是各个浏览器上的功能测试，界面的测试还是需要通过人来查看，当然也可以通过UI自动化截取图片，运行完成后统一查看。在搜索产品中有个原则，由于UI的频繁变更，推荐UI的自动化率一般达到30%即可，太多了对于维护是个很大的成本。 - Data Comparison Tool
数据比较工具，在财经搜索中使用，因为财经产品有些特殊，数据来源是第三方提供后解析保存到Google的数据库，而不像其他产品都是爬虫爬取的，使用这工具可以和其他流行的财经网站做数据对比。
提到数据的准确性，除了各个产品团队对关键字的结果进行对比，Google还有专门的搜索质量团队。 - Lflip
内部工具，通过此工具，可以将TestScribe中的每条测试用例都嵌在Iframe中自动运行，不过每个测试用例都需要指定运行环境的URL。 - Puppet
搜索产品中大量使用的基于JS的冒烟测试工具，在产品编译后执行，可以提前发现问题。 - Statix
性能测试工具，支持Jmeter的JMX文件，通常运用在每周发布后的回归性能测试上，自动生成Dashboard，可以和上一周版本对比。
五、一些标准或一些约定
怎样决定可以发布了?
搜索产品的标准比较简单，No P0/P1 Bug。
怎样决定可以发布了?
搜索产品的标准比较简单，No P0/P1 Bug。
每个产品就一个测试，如果保证质量?
前面已经提到测试的提早介入，同时开发也参与了很多测试，例如UnitTest、Sanity Check、Smoke Test，而测试投入在手工测试、兼容性测试、自动化测试，同时在闲时请求其他搜索子频道同事做交叉测试，快速发布、快速获得反馈和快速修复。
前面已经提到测试的提早介入，同时开发也参与了很多测试，例如UnitTest、Sanity Check、Smoke Test，而测试投入在手工测试、兼容性测试、自动化测试，同时在闲时请求其他搜索子频道同事做交叉测试，快速发布、快速获得反馈和快速修复。
20%时间存在么？
中美文化的差异确实很大，美国的工程师充分的利用这20%，甚至在产品团队中由于自己掌握主动权，他们选择自己喜欢或是感兴趣的事情来做。而中国的工程师更多还是在优化团队产品，不过也有使用20%实现创意的团队，例如最近发布的Knowledge Graph产品就有上海和北京的团队参与，并申请了专利(Knowledge)
中美文化的差异确实很大，美国的工程师充分的利用这20%，甚至在产品团队中由于自己掌握主动权，他们选择自己喜欢或是感兴趣的事情来做。而中国的工程师更多还是在优化团队产品，不过也有使用20%实现创意的团队，例如最近发布的Knowledge Graph产品就有上海和北京的团队参与，并申请了专利(Knowledge)
Google内部使用哪些语言？
一般是三种语言：C++、Java和Python，当然还有Javascript，这个不用说，只要是Web产品，必然会使用到。
一般是三种语言：C++、Java和Python，当然还有Javascript，这个不用说，只要是Web产品，必然会使用到。
Code Review
代码审查，Google非常关注代码审查，并且投入很大资源，我们认为，代码质量的稳定和代码的规范，可以减少后期修复的成本增加可读性可维护性，同时不会随意的破坏目前稳定的持续集成，所以如果你生成了一个Changelist(CL)提交后，依赖或相应的人员就会来参与Code Review，我印象最深的是第一次提交Puppet代码(一种JS code)，因为不知道小而快的原则，一次性提交了10个文件，美国的一个老外很快的响应来Review，这个过程是痛苦的，基本每一段都有Comment，来回了十几次，信心越来越低，老外也意识到了，鼓励说就快好了，呵呵。从此对Code Review有了新的认识，绝对不是走过场，我提交的是测试代码，如果是开发代码，一定会检查你是否也提交了单元测试文件。代码审核不仅可以提高提交代码时的谨慎做更多的测试，也可以通过审核别人的CL学习如何写出高质量的代码，更优化的代码。
代码审查，Google非常关注代码审查，并且投入很大资源，我们认为，代码质量的稳定和代码的规范，可以减少后期修复的成本增加可读性可维护性，同时不会随意的破坏目前稳定的持续集成，所以如果你生成了一个Changelist(CL)提交后，依赖或相应的人员就会来参与Code Review，我印象最深的是第一次提交Puppet代码(一种JS code)，因为不知道小而快的原则，一次性提交了10个文件，美国的一个老外很快的响应来Review，这个过程是痛苦的，基本每一段都有Comment，来回了十几次，信心越来越低，老外也意识到了，鼓励说就快好了，呵呵。从此对Code Review有了新的认识，绝对不是走过场，我提交的是测试代码，如果是开发代码，一定会检查你是否也提交了单元测试文件。代码审核不仅可以提高提交代码时的谨慎做更多的测试，也可以通过审核别人的CL学习如何写出高质量的代码，更优化的代码。
Test-Certified
内部的质量认证，这个认证不是对测试团队的，而是对产品团队的，每隔一段时间内部会审核各个产品团队的总体质量，评估越好的团队能得到更多的资源，这也是鼓励开发测试一个活动。
内部的质量认证，这个认证不是对测试团队的，而是对产品团队的，每隔一段时间内部会审核各个产品团队的总体质量，评估越好的团队能得到更多的资源，这也是鼓励开发测试一个活动。
六、一家之言
软件工程从作坊时代发展到现今，测试模式也随着不断改变，这里选取Microsoft、Google、Facebook为例，这是一个测试进化史。
从微软的传统项目大规模测试，开发测试比例达到了1:1甚至1:2；微软的员工到Google后发现，传统的测试方式不适合互联网，针对互联网小功能快发布且质量要求度不同的特点制定出敏捷测试的方式，开发测试比例下降；Google员工进Facebook后，彻底打破角色界线，全员工程师既开发又测试，对人的要求大幅提高，工具的大量使用提供工作效率，但是测试的过程并没有减少，只是换了种形式。
测试是一个持续改进的过程，各个公司可以从知名公司中学习某方面来制定针对自身企业自身团队的流程，照搬照抄是不可能成功的，也不用赶时髦，比如自动化很火推自动化、敏捷很火上敏捷、探索性测试来了是否也跟进，组织的测试改进需要一个过程。
软件工程从作坊时代发展到现今，测试模式也随着不断改变，这里选取Microsoft、Google、Facebook为例，这是一个测试进化史。
从微软的传统项目大规模测试，开发测试比例达到了1:1甚至1:2；微软的员工到Google后发现，传统的测试方式不适合互联网，针对互联网小功能快发布且质量要求度不同的特点制定出敏捷测试的方式，开发测试比例下降；Google员工进Facebook后，彻底打破角色界线，全员工程师既开发又测试，对人的要求大幅提高，工具的大量使用提供工作效率，但是测试的过程并没有减少，只是换了种形式。
测试是一个持续改进的过程，各个公司可以从知名公司中学习某方面来制定针对自身企业自身团队的流程，照搬照抄是不可能成功的，也不用赶时髦，比如自动化很火推自动化、敏捷很火上敏捷、探索性测试来了是否也跟进，组织的测试改进需要一个过程。
七、非官方声明
经常有人问，Google不是退出中国了么，你们还在？
这里只解释一次，Google只是把域名从google.cn迁移到了google.com.hk，当然功能上变成一个中文版，但是google.cn上仍然保留了音乐、翻译、购物和时惠这些产品；Google上海曾经负责图片、视频、资讯、财经、博客、翻译等搜索产品，现在成为更重要的广告平台中心。
Google在北京和上海的办公室没有变化，上海办公室搬了新家，规模也在扩大，招聘也没有停止。
经常有人问，Google不是退出中国了么，你们还在？
这里只解释一次，Google只是把域名从google.cn迁移到了google.com.hk，当然功能上变成一个中文版，但是google.cn上仍然保留了音乐、翻译、购物和时惠这些产品；Google上海曾经负责图片、视频、资讯、财经、博客、翻译等搜索产品，现在成为更重要的广告平台中心。
Google在北京和上海的办公室没有变化，上海办公室搬了新家，规模也在扩大，招聘也没有停止。
Google网站不稳定，是什么原因？
这个就不要再问了，什么原因你懂的。
这个就不要再问了，什么原因你懂的。
最后，以上如有不妥之处，欢迎各位前同事现同事指正拍砖。
------------------------------------------------------------------------------------------------------------------------
作者：Oscar Xie
