2、Test Env

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