Google上海如何测试搜索产品(2)

　　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，比如我参与的香港财经项目，就需要邀请懂粤语或就是香港员工来帮忙做一些习惯用语或当地风俗或当地使用习惯的测试。

　　TotT

　　Testing on the Toilet，在Google办公室的厕所，你会发现墙上经常贴着各种文档，这个是Google专有的厕所文化。

　　文档一般都是各个产品使用工具或做测试的例子，目的是吸引所有工程师做更多的测试，这个文化被Google离职工程师带到了百度，可惜他们没有把页首和页眉去掉，模板也改改吧。

　　示例见此文，TotT: Better Stubbing in Python

　　四、工具

　　从上面可以看出，搜索产品一般是一周一发布的频率(称为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，可以和上一周版本对比。

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