Google上海如何测试搜索产品-2
上一篇 / 下一篇 2012-08-24 09:57:58 / 个人分类：测试经验
见上文介绍，这里面还会有Global和Local的多语言环境，需要和其他办公室的团队协同工作。
3、Test Cases
测试用例在Google内部是通过一个叫TestScribe的工具来管理，各个产品创建自己的产品的测试用例，一般会根据页面->功能来，产品所有测试用例创建好后，需要团队来审核，根据反馈做修改，同时也要把发现的Bug当做用例补充进来。
Test Scribe里还有一个Test sets概念，也就是说根据不同的测试策略，从所有测试用例中选取相应部分保存成Test set，例如Basic Test、Full Test、Automated Test等等，当具体执行测试时，可以创建Build从这些Test sets选取合并在一起。
4、Bug
前面有提到过Bug库是使用Buganizer来管理，但是Bug库不仅仅是存放缺陷，需求和改进以及你认为有问题的都需要记录进去，根据优先级跟踪开发修复，同时可以根据不同类型，比如新功能或每周发布版本建立Hotlists，将对应的Bug保存便于跟踪统计。
5、Test Report
测试报告，每一轮测试执行结束后，通过TestScribe都可以生成相应的测试报告，例如每周发布的回归测试，会 有对应的测试报告，记录测试使用了哪些用例、发现了哪些Bug、严重程度如何，当然，也可以通过TestScibe和Buganizer提供的接口自己建 立一个状态页面。
6、Matrix
搜索产品都是基于Web的，这就涉及到兼容性测试，需要根据具体产品监控的反馈统计出用户的喜好情况，建立对应的平台和浏览器Matrix，里面会有一个百分比关系，根据百分比来划分优先级，分配测试资源。
7、Metrics
产品质量的情况反馈需要有一些度量，那么会建立哪些度量呢，需要建立一些矩阵：
a）发布的矩阵，哪些bug是手工测试发现的、哪些是自动化发现的、验证了哪些bug、哪些是新功能的bug
b）每周回归的矩阵，回归发现了哪些新bug、回归验证哪些bug
c）功能发布记录，某个新功能是在哪个版本第一次发布，新功能发布到哪个国家或地区，新功能做了第几次试验
Findit
大家一起来找茬，就是邀请所有员工来找bug，发现有效bug的员工会获得一件T-shirt和其他奖品，T- shirt的图标一般是一只狗狗拿个放大镜照骨头。有点类似于微软的“bug bash”，但是这个是整个公司的，bug bash一般是在团队使用，会在某个新版本发布前，整个团队一起来找bug并且使用一周时间一起修复bug。那么根据多国家地区和多语言的特点，还可以分 为ChinaFindit，JapanFindit，比如我参与的香港财经项目，就需要邀请懂粤语或就是香港员工来帮忙做一些习惯用语或当地风俗或当地使 用习惯的测试。
TotT
Testing on the Toilet，在Google各个办公室的厕所，你会发现墙上经常贴着各种文档，这个是Google专有的厕所文化。
文档一般是各个产品使用工具或做测试的例子，目的是吸引所有工程师做更多的测试，这个文化被Google离职工程师带到了百度，可惜他们太懒了没有把页首和页眉去掉，模板也改改吧，当然他们加了一个像框，Google就张纸贴在墙上。
四、工具
从上面可以看出，搜索产品一般是一周一发布的频率（称为Weekly Push），测试人员除了做常规的RC测试，还需要了解新功能的需求、提早介入新功能测试、编写测试计划和测试用例，和开发人员协作提高代码质量，那么时 间有限，提高效率就需要工具的帮助，下面介绍一些使用到的工具或策略。
1、Clearsilver Diff Tool
我们知道测试里面的“二八原则”，很多新的功能会发现大量的bug，同时在旧功能也会发现由于新功能或是代码修改引入的bug。
通过Diff工具，我们可以了解新版本和上一版本的区别，更利于测试资源的分配，关注修改部分的质量，而原有功能模块的质量通过自动化来做回归测试。
2、Selenium UI Automation
UI的自动化，其实解决的更多是各个浏览器上的功能测试，界面的测试还是需要通过人来查看，当然也可以通过UI自动化截取图片，运行完成后统一查看。在搜索产品中有个原则，由于UI的频繁变更，推荐UI的自动化率一般达到30%即可，太多了对于维护是个很大的成本。
3、Data Comparison Tool
数据比较工具，在财经搜索中使用，因为财经产品有些特殊，数据来源是第三方提供后解析保存到Google的数据库，而不像其他产品都是爬虫爬取的，使用这工具可以和其他流行的财经网站做数据对比。
提到数据的准确性，除了各个产品团队对关键字的结果进行对比，Google还有专门的搜索质量团队。
4、Lflip
内部工具，通过此工具，可以将TestScribe中的每条测试用例都嵌在Iframe中自动运行，不过每个测试用例都需要指定运行环境的URL。
5、Puppet
搜索产品中大量使用的基于JS的冒烟测试工具，在产品编译后执行，可以提前发现问题。
6、Statix
性能测试工具，支持Jmeter的JMX文件，通常运用在每周发布后的回归性能测试上，自动生成Dashboard，可以和上一周版本对比。
五、一些标准或一些约定
怎样决定可以发布了？
搜索产品的标准比较简单，No P0/P1 Bug。
每个产品就一个测试，如果保证质量？
前面已经提到测试的提早介入，同时开发也参与了很多测试，例如UnitTest、Sanity Check、Smoke Test，而测试投入在手工测试、兼容性测试、自动化测试，同时在闲时请求其他搜索子频道同事做交叉测试，快速发布、快速获得反馈和快速修复。
20%时间存在么？
中美文化的差异确实很大，美国的工程师充分的利用这20%，甚至在产品团队中由于自己掌握主动权，他们选择自己喜欢或是感兴趣的事情来做。而中 国的工程师更多还是在优化团队产品，不过也有使用20%实现创意的团队，例如最近发布的Knowledge Graph产品就有上海和北京的团队参与，并申请了专利（Knowledge）
Google内部使用哪些语言？
一般是三种语言：C++、Java和Python，当然还有Javascript，这个不用说，只要是Web产品，必然会使用到。
Code Review
代码审查，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后，彻底打破角色界线，全员工程师既开 发又测试，对人的要求大幅提高，工具的大量使用提供工作效率，但是测试的过程并没有减少，只是换了种形式。
测试是一个持续改进的过程，各个公司可以从知名公司中学习某方面来制定针对自身企业自身团队的流程，照搬照抄是不可能成功的，也不用赶时髦，比如自动化很火推自动化、敏捷很火上敏捷、探索性测试来了是否也跟进，组织的测试改进需要一个过程。
最后，以上如有不妥之处，欢迎各位前同事现同事指正拍砖。
本文出自：http://www.cnblogs.com/oscarxie/archive/2012/08/21/2648603.html
TAG:
-
引用 删除 leavechime / 2015-07-17 16:47:18
-
评 5 分
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 3335865
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
