五、一些标准或一些约定

　　怎样决定可以发布了？

　　搜索产品的标准比较简单，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