《Google的软件测试之道》（1）

第1章 Google软件测试介绍

在Google，软件测试团队归属于“工程生产力（Engineering Productivity）”部门。

随着软件逐渐由桌面应用迁移到网络云端，Google的测试模式很有可能会逐渐成为测试行业的主流模式。

在整个公司，我们只有非常少的专职测试人员。Google成功的关键是什么，（作者的建议）不要招聘太多的测试。

开发人员也承担了质量的重任。质量从来就不仅仅是一些测试人员的问题。在Google，每个写代码的开发者本身就是测试者。不关注开发测试人员比例。

 

1.1 质量不等于测试

开发人员写一段代码就立刻测试一段代码。如果产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是测试人员。当把开发过程和测试过程放到一起，就得到了质量。

 

1.2 组织结构

模式之一：开发人员与测试人员隶属于同一个工程生产团队。汇报给同一个产品团队的管理者。在产品发布时，优先考虑的是功能的完备性和易用性，却很少考虑质量问题。作为同一个团队，测试总是在为开发让路。我们这个行业里总是有各种有缺陷的的产品，或许这就是问题所在。

在Google中，测试是独立存在的部门，是与专注领域部门平行的部门，称为工程生产力团队。测试人员以租借的方式进入产品团队。测试人员有自己选择决定的优先级，在可靠性、安全性等问题上都不会妥协。

好处：

1、保持数量较少的测试人员，一个产品团队不能任意降低测试人员招聘的技术要求，从而雇佣更多的测试人员。与功能有关的脏活累活本来就是开发人员的工作。

2、测试人员在不同项目之间的借调模式，可以让SET和TE时刻保持新鲜感，还能保证一个好的测试想法可以快速在公司内部蔓延。

Google的特殊规定：测试人员如果在某个产品中工作满18个月，可以无理由地自愿转岗到其他产品。可以增强测试人员对各个产品与技术的理解。

 

1.3 产品发布

金丝雀版本：每日都要构建的版本，只有这个产品的工程师才会使用。

开发版本：开发人员日常使用的版本，一般每周发布一个。

测试版本：通过了持续测试的版本，基本上是最近一个月内的最佳版本。

beta或发布版本：由稳定的测试版本演变而来，对外发布的第一个版本。